I read this the other day and I was wondering if you had heard about this or if you have experienced or seen this?
I hadn’t seen it. As I turns out, I have a ton of responses to it, shotgun-style.
- “Process” in this article seems to be shorthand for “things I don’t like doing.” Hard to argue with the notion that it’s not fun doing things you don’t like.
- Turns out, all programmers have process, whether they like it or not. Unless you take a completely different approach to writing code every time you sit down at the keyboard, you work in a particular way. How you work: that’s process.
- I have an inherent distrust of anyone who says “I’ve learned all I need to; the way I work is perfect.” I don’t care if you’ve been programming for thirty years. The world is always changing around you, and you need to change with it.
- Every job has less pleasant parts to it. That doesn’t mean that you get a pass on those parts in the name of “maintaining your passion.” Passion is one thing. Craft is another. If you can’t maintain your passion in the service of your craft, you’re not as passionate as you think.
- Now, the mindless application of process is something I am opposed to. There needs to be a reason why you do certain things. I don’t think this focus on process and metrics is new at all. Look back at CMMI or at structured programming. Every software process or technique ever assembled was developed to harness the current understanding of how projects and programs fail in an effort to improve how things are done. There are reasons why these ideas are put together. Programmers need to understand them in order to figure out what processes and techniques can help them in their current circumstances. Just as we shouldn’t adopt processes mindlessly, we shouldn’t reject them mindlessly either.
- The profession of programming is much, much more than writing code. If that’s all you want to do, don’t pursue it as a career. Keep it as a hobby. Being a professional means spending a lot of time asking “What code do I need to write?”, “What code do I not need to write?”, and “How do I know that the code I wrote does what I intended?” Those questions, to my mind, are what every software process try to help us answer.
I could go on, but I think that’s the stuff that’s worth saying.
UpdateFitness: Biked 10 miles
Writing: 413 words, 269 average