There’s a trend in the technology industry that I wish I saw less than I do. In many blog posts, programming books, tweet storms, etc., you’ll frequently see arguments along the lines of “I admire people who are X,” where X is a commonly-acknowledged negative trait. The author then goes on to argue how the apparent flaw is actually a virtue.
I understand the appeal in making statements like this. It makes for great copy. Counterintuitive arguments are just naturally more interesting than stating obvious truths.
Plus, there’s the added benefit that the author gains “rebel” credibility points. There’s no better way to establish yourself as an independent, “outside the box” individual than to say something that sounds so wrong that it borders on provocative and then defend the position.
One thing I don’t like about the tactic is that it often feels like a cheap way to get attention. When it’s overused, it becomes as cliche as the phrase “outside the box.” Usually, I don’t mind the tactic when the argument is compelling; in spite of the fact that when the argument is compelling, it can often be made just as effectively without the flamboyant showmanship.
What really bothers me is that frequently the author bends the definition of the negative term to the point of breaking. In Code Complete, Steve McConnell argues that laziness is something programmers should aspire to (second edition, page 830). Lazy people want to avoid doing unnecessary work, so lazy people will build tools that do repetitive tasks, and therefore lazy people will complete tasks more efficiently.
I’ve worked with my fair share of lazy programmers. Lazy programmers will never, ever build a tool. Ever. Building a tool requires thinking about the problem, doing work that wasn’t asked for, and then verifying that the tool works. Lazy programmers will copy several thousand lines of code on both sides of a conditional because they can’t be bothered to think about the problem. They will not write a tool to make the work easier. Never.
The desire to do work more efficiently is the virtue, not laziness. People who want to work efficiently may be trying to make the job easier, but to call that laziness is simply describing the impulse to work smarter as laziness for the sake of being clever.
However, the thing that bugs me most about this technique is how easily these sound bites can be abused. One of Paul Graham’s more notable quotes is:
“When I see patterns in my programs, I consider it a sign of trouble.” – Paul Graham
Doesn’t that sound smart? Isn’t that such an interesting idea? Sure it is. But it’s also part of a very large essay that was written in 2002. At the time that essay was written, the world was full of “Capital E” enterprise development advocates who tended to overzealously sell one-size-fits-all approaches to building software. People who argued that something as simple as “Hello World” should leverage a Singleton, a Factory, and a couple of Commands. When cast against that world view, Paul’s statement takes on a more nuanced relevance.
But that doesn’t diminish the huge value design patterns provide to software developers. They provide a vocabulary for describing time-tested, well-understood solutions to common problems. In an industry as young as software development, a tool like that is invaluable.
But on its own, Paul’s quote reduces the notion of their value to smart-alec one liners. Taken out of context, the quote leaves no room for discussion, they clearly must be bad. I’ve heard Paul’s quote used by a colleague to argue that anything described as a pattern must be overly complex and unnecessary.
Because of these reasons, I hope the trend of using smart-sounding, provocative statements to get attention runs out of steam soon. Or maybe I’m just too lazy to keep arguing the point.