⇥ The lost art of using your brain

“I thought all serious programmers used an IDE”

“My tests have 100 percent code coverage!”

“You mean you don’t use OOP?”

If words like these ever escaped your mouth in my presence, you should know that only the strongest rules of good social behaviour stopped me from punching you in the face.

We may agree or disagree on whether IDEs are useful, or whether code coverage is an important metric of the effectiveness of your testing strategy, or whether object orientation is an important, useful and positive technique to use in your code.

But one thing we need to agree on: people need to use their brains more and rely on the brains of others less.

The world of technology is riddled with inhabitants who treat tools as if they were religions. OOP, unit tests, patterns… these are all instruments that are supposed to make some jobs better, and not theological formulas that will magically make every single line of code written on the face of the Earth better.

And yet, the vast majority of people treats them like they are, sparking everything from language wars to endless—and pointless—discussions on whether a particular technique is better than another. I swear I sometimes look at threads on mailing lists that look like one giant Hello, world program: not merely pointless, but counterproductive.

Tools are not just pieces of software

Programming is about one thing, and one thing only: solving problems. As developers, we must look at everything that we do in that light; whenever we don’t, we are doing ourselves and our clients a horrible disservice.

The fact is, there is no accepted “true” way of writing code. This should serve as a powerful hint to developers that there is no “best” way to work; rather, we must build a war chest of tools, attempting to understand how each of them can best be applied to a specific problem.

The “why,” as is so often the case, is more important than the “how.” And yet, so much of the training material that we have at our disposal is focused on the latter and completely ignores the former, leaving the incautious student in the same conditions as a plumber who is given a wrench and not told they should make sure the water is off before unscrewing the faucet.

My partner Keith Casey made a great example of this at last year’s Codeworks tour; he picked an example from a book on unit testing that shows a simple class (I can’t remember what the class did, but it was something absolutely trivial) and then the associated unit tests. The example concludes with something like “of course, you would never write a class like this in real life, but this is how you achieve 100 percent code coverage on it.”

The question is: if I’m never going to write code like this in real life, how am I supposed to learn why I should use unit tests?

The why of the why

I can think of at least three reasons why this malaise seems to be so commonly spread.

The first is that the proponents of a tool are usually less than fully honest about its benefits and drawbacks themselves. This could be out of intellectual dishonesty (that is, because they want to sell you something), or because they want to see their own work validated by means of adoption. Nothing wrong with either of these things—people have to eat, and hard work needs rewarding. Why, I am probably doing the same thing right now.

The second is that it’s easier to sell a practical something than a theoretical something else. We like to delude ourselves into thinking that we like choice, but the harsh reality is that end users don’t want to choose: they want to be told what to do. This includes most developers, who would rather rely on someone else’s blind advice than apply their own critical thinking. We all do it—it’s a common failing of all men and women.

The third, finally, is that a lot of people are not taught to deal with the consequences of their actions. From childhood, they are told that they are special, that they deserve better, that it’s OK to be less than the best. And this shows in so much of the work I see every day: “architect” makes a decision that goes south; “architect” disappears; remainder of the company is left to deal with “architect’s” mistake. Rinse, lather, repeat.

The way to the how

How does one stand apart from the masses? Simple: by learning to apply his or her own critical thinking to a problem.

The first step is never to accept anything at face value. Question everything—not for the sake of questioning, but for the sake of getting to the truth. Once you have all the facts, making a decision is a matter of weighing each factor against the others and picking the tools that give you the best resolution. You’ll still make mistakes, but your batting average will get much better. (Also: you’ll have some way to figure out why you made a mistake and learn something.)

The second step is to continuously question your knowledge. In the past eighteen months, I have begun writing for Macworld, taught myself how to program in Objective-C for both OS X and iOS, have played with XNA and just started delving into Ruby with some level of details. I haven’t become a master at any of these¹, but I have learned things from each one of them that I have been able to apply elsewhere in my day job.

The third step is to surround yourself with people who have as different (and diverse) a perspective from yours as possible. If you only ever stick around people who think the same way you do, you will stagnate and never grow. If you surround yourself with people who respect you but don’t always agree with what you have to say, you’ll be forced to question yourself more often and learn a thing or two.

Of course, these things are true of many other aspects of life—politics, philosophy, sports, you name it. As applied to technology, however, they will at least make you not be one of those people I want to punch in the face.

Update: I posted a postscript to this post in response to some of the comment I received.