Have you ever noticed there are no self-help books for programming? Sure, there are for loop explanations, and guides to this coding language or that. But what about our behavioral practices? If you have been keeping up with Silicon Valley, the TV show, you’ll know that programmers are just as subject to getting blocked as writers are: Richard stopped sleeping and walked into a pool with his clothes on, but there must be a better way.
Turns out that writers know the secrets to prevent Programmer’s Block. These ten writing-inspired tips will make you a more efficient, creative, and confident programmer, whether you are a novice or expert programmer. Where did these come from? To assuage my guilt the last year of my PhD during faculty interviews, I read a lot of books about writing on airplanes (see reading list at end). What I discovered was that many of the writing books had insights and methods applicable to programming.
Obviously the list starts with zero.
Programming takes focus, and people are busy. So what’s the solution? We are at our most creative in the morning, so make the first hour of your day sacrosanct. Don’t schedule meetings. Don’t check your email or social media. If you’re at home, maybe don’t even brush your teeth. For me, coffee is sacred. But after that, just put yourself in the chair. (Some people say the writer’s most useful tool is glue). Put this in your schedule like a meeting, and protect this time from all other commitments.
Before you turn on that screen, diagram out your thoughts, jot ideas on a notepad, make a list. Writing Your Dissertation in Fifteen Minutes a Day emphasizes the importance of getting to draft zero, the conceptual template predates the first draft. You have spent all evening and night tossing ideas around in your subconscious. Let them surface. The Artist’s Way suggests that free-writing can make you a better programmer (sculptor, investment banker). Do what works for you.
Humans are creatures of habit. So make programming part of your schedule, setting reasonable goals. This concept comes from Writing Down the Bones. After a couple weeks, you will start to miss it if you forgo a session. I swear my PhD advisor used the first 10 minutes of every advisor meeting to tap away at some program that wasn’t working. There would be grumbling, the hallmark loss of time sensitivity in flow, and the eventual ripping himself away to begin our meeting. (By then, I was fully prepped too.) Little minutes add up, and establishing a schedule is the best way to guarantee accomplishment.
Keep a running log of ideas and problems that you can return too when you’re stuck or looking for the next thing to tackle. The programming schedule (Tip 2) is a great start, but creativity may not always follow a schedule, or you might be busy with something else, so catch your ideas when you can. They say writing begets more writing, so the more you code, the more ideas you will have about coding. I always carry a notebook.
People do better when we have accountability. Establish weekly check-ins where you set goals, discuss roadblocks and share resources or strategies. For example, my Computer Vision friends at CMU did 15-minute standing meetings Monday mornings in our campus cafe. All people (even programmers) care about social pressures. In person is best, but also use online forums. People will probably be tickled that you are asking about their code.
Just like taking things apart is often a predates putting things together, programmers can develop an “ear” for code by reading and modifying that of others. In The Sense of Style, Stephen Pinker emphasizes that “good writers are avid readers.” Unlike writing, it’s very much encouraged to use pre-existing libraries and samples to scaffold your project needs. Reference where things come from, but there’s no need to re-invent the wheel when someone has already figured a problem out.
Conceptualizing how code should be structured or what problems to tackle begins as a creative process. Imagine having two desks in your office, one for writing (current Tip), one for editing (Tip 7). The writing desk looks out the window, whimsical, open-ended, and encouraging you to chase butterflies of an idea. Don’t be afraid to take a walk or try something out that may or may not be the best final solution. One of my most productive interns was prone to pacing the hallways at CMU when she was figuring out the next step in her code. Programming, like writing, involves more than just typing characters on a screen, so celebrate activities that fertilize the soil before planting, and water it afterwards.
If you are in an editing stage, you often “kill your darlings.” This quote has been popularized by many writers, including Stephen King. It’s about removing the superfluous. For example, you may have spent much time getting a code-block to work, but now you have something better. Comment it all out if you truly can’t bear to part with it, but kill, kill, kill. In contrast to the Tip 6, your editing desk is unadorned and in a corner. Programmers are generally good at this step (though I prefer windows, myself). The tricky part is findings mistakes without recrimination. Google apparently gives employees failure-bonuses for tanking projects that would never have worked out anyway (from How Google Works). So be heartless when it comes to the essential purpose of your code, but kind when it comes to yourself.
One of the reasons we don’t (often) program in assembly languages is that it is not easily human readable. As higher level coding languages empower us with abstraction, so should we choose abstractions that make sense. Calling something variable1 and variable2 is a disservice to anyone else using your code (especially yourself) if it needs to be changed later. One of the biggest challenges of writing is ensuring the audience follows. Use whitespace, comment your code, and spend time creating sensible abstractions and structures. It doesn’t matter how clever your prose (or code) is, if people cannot deconstruct the story.
Each morning should start the day before. Dedicate the last 10% of your time each day to what you will do the next one. Maybe you structure your next code block as comments. Maybe you make a list. I drive a stick shift car, and by parking on a downward slope, I know that even if my car’s battery dies overnight, I will be able to use the hill’s potential energy to jump start my engine. It’s like leaving your exercise clothes laid out the night before. You don’t have to think, you just go.
Think of this as a programmer self-help list. Programming is a creative process, just like writing, and I believe these ten strategies can make you more creative, more productive, and less likely to get stuck.
What approaches do you use? Let’s extend this list in the comments.