When people say that "good programmers are lazy" it means that good programmers try to find ways to cut down the amount of time spent on boring and/or repetitive things. Boring and repetitive things include build and deploy processes, boilerplate code and documentation, repeating oneself, and so on. We *could* do all those things manually. We *could* write the same code over and over and change only a few details. We *could* execute our tests by hand.
But we'd rather not. We'd rather our tools did our builds. We'd rather abstract our code so we can re-use it across projects. We'd rather spend the time and effort to create something we can use over and over again--thus saving *more* time in the future (and maybe even saving *other* people's time).
Does that mean we're lazy in the strictest, non-humorous sense of the word? Of course not. It's usually much more time-consuming, the first time around, to produce something that will save time in the future. It requires more thought, more testing, more development, more of just about everything.
But we do it anyway, because we're lazy: we don't want to have to do the same work *again*. Cort Dougan took a humorous aphorism and turned it into a diatribe against... well, something the aphorism never was. His article continues an assault against several unrelated topics.
Testing is no longer part of the development process?! If anything the burgeoning TDD movement has brought it closer to the forefront than ever before. Apprenticeship is gone? Hardly--mentoring is stronger now than ever before, in both professional and amateur programming.
XP couples distinct modules because it encourages making sure changes don't break existing code? Continuous integration doesn't promote tight coupling--only code can be tightly coupled. How often code is checked in, built, and tested has nothing to do with our architecture.
"Languages with garbage collection and sophisticated data types hide complexities from programmers. These languages are useful for teaching programming but are dangerous for production use."I don't even know where to begin on that one. How is a language with GC dangerous for production? Java is dangerous for production? What kind of production are we talking about here? If we're talking a resource-constrained, deterministic real-time system maybe it is (and even that is just a maybe). What constitutes a "sophisticated data type"? Don't we *want* to shield ourselves from complexity when practical?
The article then moves into a "solutions" section, including things like "have a list of tasks that must be completed". Even us "lazy" programmers have a TODO list. "Design then write?" Even the *most* extreme of extreme programmers will usually sketch out a data model or high-level system overview. "Write an example." Oh, you mean XP and/or TDD. Check.
Then it moves into bizzarro world: "fire software testers." Right, because I'm guaranteed to catch every error present in a system. "Know what you're doing at all times." Okay, thanks for that.
"A useful exercise I used for someone I worked with once was to stop him every 10 minutes and ask him what he was trying to do."I'm trying to get you to STOP INTERRUPTING ME EVERY 10 MINUTES, so I don't have to spend an additional 15 minutes getting back into flow. I'm trying not to punch you in the face. I'm trying to find another job.
"Good programmers are lazy" doesn't mean we sit around in a pile of our own filth and make the pizza delivery guy step over empty boxes to hand us our next meal. It means that good programmers attempt to find reusable solutions to problems so that the next time we face them we *can* be lazy, push a button, and have our work done for us.
Being lazy often means a large up-front investment: that's not lazy, that's just prudent.
No comments:
Post a Comment