Code Is Our Friend
Rich Skrenta’s “Code Is Our Enemy” made some excellent points. But now, my take from the flip side! (This isn’t a tit-for-tat of his article; it’s just my general thoughts on the subject.)
What New Code Is
New code isn’t any more “brittle” than old code. All code is inherently brittle, in that one tiny change can break it. And more code isn’t more brittle than less code — unless the memory of your computer is subject to random, mutational attack or something crazy like that. (Still using vacuum tube memory? Time for an upgrade.)
New code doesn’t increase compile times — once it’s compiled, any decent compiler will leave it alone until (and unless) you change it. And besides, just how achingly long are compile times these days? Computer power has been increasing much faster than the human ability to write code, and will only continue to do so in the years to come.
No matter how well-commented and well-organized, no one but you (the author of your new code) will understand it quite as well as you did when you created it. That’s because you typed every line and had to think carefully about what every line does as you wrote it. No one else has done that. But that’s not a flaw of new code; that’s a property of all code. Which is better — code you intimately understand, or code you don’t (and probably can’t even examine)? The apparent simplicity of using someone else’s compiled code is an illusion created by the fact that you never see their sourcecode — just a few little calls to it in your code.
New code doesn’t have to be “maintained.” Once it’s working correctly, it just keeps working correctly. It doesn’t need an oil change every 3,000 miles or anything like that. New code does, of course, increase the percentage of your project’s sourcecode that is under your control — but so what? If you don’t want the burden of safely changing that new code someday in the future, then just don’t change it! If it was a precompiled module written by some other party, you wouldn’t be able to change it either. Is it somehow better not to have the option? Remember, the alternative to your code is not mystic, code-free, gremlin-driven solutions from hyperspace. It’s just someone else’s code.
Make It Happen
New code lets you do things that other people haven’t imagined yet. There are definite limits to what you can accomplish by wiring together pieces of code other people have already written. Really magical things happen when you write new code that does something really new, or does something in a new way that’s a better solution to the problem at hand.
Don’t think that your new code is supposed to be some kind of general-purpose library. It probably isn’t. It’s supposed to make something happen on people’s computers that hasn’t happened before. Something sweet. Many educators would have you believe that the most important thing your code can do is enable other coders by providing them with a library of functionality. But enable them to do what — write more libraries? That help still other coders write libraries? Enough already — write some code that does something cool. Doom wasn’t a code library; it was just a kick-ass hunk of new code! Educators want you to think that coding is about enabling other coders because that’s what they do. Doom wasn’t written by educators.
Practice Makes Perfect
Writing new code makes you better at writing code. The more code you write (particularly on the same project and/or in the same development environment), the better you become at writing it. The fewer mistakes you make. The more easily you detect and correct mistakes when you do make them. Avoiding writing code, for avoidance’s sake, is like trying to improve your tennis game by hiring someone else to play in your place. If you can do that indefinitely, great — and congrats on your new career in management.
Update 2009.09.24 — Don’t miss Joel Spolsky’s “The Duct Tape Programmer.”
© 2012 Darel Rex Finley | design by 