Over the last four or five years, there’s been a dramatic increase in the number of books about programming: not the specifics of this language or that framework, but the act of programming itself. Fogel’s Producing Open Source Software, Spinellis’s Code Reading, Ford’s The Productive Programmer, Doar’s Practical Development Environments, and multi-author collections like Beautiful Code and Beautiful Testing all discuss the things that separate people who can write code that compiles and runs from people who can build useful software.
The most recent entry in this category is Seibel’s Coders at Work, which collects his interviews with 15 great programmers. I haven’t finished it yet, but two things keep jumping out at me. The first is the importance of getting things into users’ hands as early as possible. It doesn’t have to be finished, and it certainly doesn’t have to be perfect; as long as it does something—anything—that they find useful, they’ll start giving you feedback. No matter how smart you are, you can only foresee a small fraction of what people will actually want to do, or how they’ll want to do it; letting them drive your software around is the best way to get the early course corrections that can save you days or weeks of wasted effort.
The second thing that jumps out at me is how focused these programmers are on avoiding waste—or rather, on delivering value. Will adding this feature or refactoring that module make the user’s life better in the near term? If not, file a ticket and move on, because there are plenty of other things that will. No, you shouldn’t let too much technical debt pile up, and yes, there are times when writing another abstraction layer will make development of the next dozen things so much faster that you’ll be ahead overall, but you have to know both your users and your code very well to be sure of that payoff. It’s all to easy to go from, “I want to fix this bug,” to, “Hm, I should refactor these classes first,” and then to, “Well, if I’m going to do that, I should upgrade this library,” and, “So first I’ll patch my OS,” until you find yourself three hours later saying, “OK, so once I’ve shaved the yak…”
So does this mean people should just hack together whatever works today with no thought for tomorrow? Of course not. Well-written code is its own reward, and one of your goals as a professional should be to make the right way of doing things a habit so that you won’t make silly mistakes when you’re tired, stressed, and up against a deadline. As an inveterate yak-shaver, I’ve found it helpful to always ask someone by email, “Should I be doing this?” before I start anything that’s going to take more than half an hour. At the very least, it keeps my teammates up to date with what I’m working on, and more often than you’d think, someone on the team will say, “Actually, wouldn’t it be more productive for you to do this other thing instead?”
Now, if you’ll excuse me, I need to go milk a whale…