Programming Is Supposed to Be Messy
Before I started programming, I assumed it worked like a glorified paint-by-numbers kit. Sure, it might take time to correctly match each color and number, but there would be no doubt about the correct way to proceed.
[bctt tweet="#Programming is Supposed to Be Messy, by @benjiwheeler"]
People who have never programmed often think of it this way. And I don’t blame them. People who have programmed a little still imagine that there are “real” programmers somewhere whose projects don’t look like a nightmare most of the time.
To understand just how wrong they are, programmers must transform their comfort with messiness, in three stages.
Stage I: Crisis of Confidence
Beginning programmers often feel a sense of absurd helplessness when they start working on hard projects. They expected that becoming a programmer meant gaining expertise and then applying it steadily, writing lines 0 to 99 on Monday, 100 to 199 on Tuesday, etc.
Instead, they find themselves muddling through project after project, reacting to an endless march of unforeseen snags, cobbling together their attempts to deal with each problem that pops up. Nothing is ever really finished, and often the best answer to the question “does it work?” is an awkward “I hope so.”
How do you push through? By accepting that projects will seem like a hopeless mess. It’ll seem like everyone else knows what they’re doing, but programming languages and tools and conventions move too fast, and projects are too different from each other for anyone to truly know what they’re doing. Just dive in, get dirty, ask questions and listen well, and have faith that you’ll figure out what you need to figure out.
It turns out everyone’s in the muddle; find friends in there, and learn not to fear it.
[bctt tweet="What if your code is messy? Dive in, get dirty, have faith that you'll figure it out—@benjiwheeler"]
Stage II: Obsession with Refactoring
A joy universally appreciated among programmers is working your code into a state that is concise, comprehensible, and stable in the face of edge cases and heavy use. We call code like that “elegant”.
But elegant creations aren’t born that way. Look at the notebook of a poet or lyricist and you’ll find that their jewels of written wisdom passed through some brutal revisions; don’t be surprised to see page after page of mistakes, obliterated with angry strokes. Elegant programs spend most of their developing lives in that seemingly disastrous state before they can appear anything close to elegant.
[bctt tweet="Elegant code wasn't born that way. Embrace re-factoring—@benjiwheeler #learntocode"]
Part of the joy of working your code into a pleasing state is being able to eliminate all of the piecemeal handling of this case or that case that you must write in order to start to see common patterns.
There’s a famous story from the early days of Apple about the legendary programmer Bill Atkinson. The managers had concocted an evaluation system: each programmer had to report the number of lines of code she wrote each week. One week, Bill re-factored a graphical library to make it six times faster, and when he was done, the code was 2000 lines shorter!
What to write on the form? After thinking about it for a second, he wrote in: -2000.
They soon stopped asking him to fill out the form.
This sort of triumph feels glorious for a programmer, but the siren song of beautiful code can prove dangerous. Every programmer can recall days or even months spent perfecting code for a project, only to realize too late that the project wasn’t important or necessary enough to deserve being refined so completely.[bctt tweet="The siren song of beautiful code is dangerous. Some prjcts aren't worthy of the effort— @benjiwheeler"]
It’s been said, in fact, that the best code is code that you never actually write. One startup founder who went through YCombinator told its founder, Paul Graham, that “when coding, I try to think, how can I write this so that if people saw my code, they’d be amazed at how little there is and how little it does?”
Code elegance is something to be proud of, but don’t be so proud that you can’t leave your code in a messy state until it absolutely needs to be re-factored.
Stage III: The Joy of Sketching
Paul Graham argues in his essay “Hackers and Painters” that programmers should accept that their code will be a mess at first, and stay focused on creatively exploring whatever they’re trying to do with the code in the first place.
He sees coding as more like painting an impressionist landscape than painting by numbers. There’s still plenty of power in skill and experience; you can look at the work of a top painter and appreciate their expertise. But watch their process, and compare it to the process of a beginner: both will involve adjustments, backtracking, undoing mistakes and patching holes.
[bctt tweet="The key to elegant #code? Be creative, sketch, revise, focus on solving real problems—@benjiwheeler"]
After all, Picasso didn’t pick up a paintbrush for the first time and doodle his famous Don Quixote sketch; that doodle needed decades of practice in order to make his blotches and lines evoke such character. That’s the goal: to hone your ability to make expressive code in quick sketching sessions, to love revising your code, and to always stay focused on solving real problems.