by Chris Rowe
How often do you get the fear? What do I mean by fear? How about the knot I got in my stomach just before I plunged out of plane on a parachute jump? It’s more than the brain logically planning to avoid danger, your whole body feels it, a foreboding about what’s coming next.
Working in IT means sudden severe physical dangers are unlikely. But aversion to fear continues to exist when we get asked to do certain tasks.
In my first job, it was when my boss asked me “Have you completed the documentation?”
In my 2nd job it was “Did you send that email to the customer yet?”
And later “How’s that presentation going?”
What was the problem? All those tasks involved writing. It couldn’t get much worse than that. Very few developers like writing (unless it’s in Slack). The bigger the audience and the more important it is, the more fear the writing task brings.
Back to coding. When was the last time your code worked the first time? The time you wrote a couple of hundred lines of code that were error free and to perfection, so that it compiled and ran exactly as expected the first time?
We as developers would never expect first time code perfection, and coding is our main task. Yet when asked to write some documentation, an important customer email, or a presentation, we freeze. The empty coffee cups and Fritz Cola bottles pile up on the desk while we’re staring at a blank page, waiting for the perfect text to flow out from us.
This doesn’t make much sense. Could it be that our expectations for a side task that we often don’t like are higher than for the core task that we love and practice all the time?
Writing and coding have a lot more in common than you might think. And surprisingly you can use your coding skills to improve your writing.
As developers, we’re usually keen to jump straight into coding as quickly as possible. We don’t want to think the code through to perfection in our heads. We want to try out and experiment. We want to get a result. Once we’ve got the basics sorted then we can expand and refine our work. So much so that we’ve got terminology and methodologies to back this up. Think Scrum or refactoring.
Scrum is a framework based on getting something out there and improving it. It was created to move away from the unrealistic expectations of the waterfall methodology. Where you can theoretically completely define everything that you need to do before you start doing it.
With Scrum, the idea is inspect and adapt. Perfection is never the aim of the first sprint. Get the most important thing out in the open so it can be refined and added to later.
[Refactoring] advantages include improved code readability and reduced complexity (Wikipedia)
With code, the first version is not expected to be perfect. It’s about getting the initial version out and then improving it afterwards to make it easier to read and simpler.
Can you edit a blank page?
But what happens when you switch your favorite coding IDE for an email editor or PowerPoint? I’ve seen countless developers freeze with fear, staring at a blank screen. Unsure what to write, worried it won’t be perfect and so we write nothing. You can sense the fear when your co-workers have it, it’s the constant sighing and nervous energy of tapping fingers.
But if we’re honest with ourselves this “perfection or nothing” is the exact opposite to the coding approach that we spend all day practicing. If it was coding we’d be happy to try some of the simple cases and get it up and running. Not for writing. Perhaps it’s because we’re worried about our clarity, structure, or style. And this all before we’ve even got any words the page.
Waiting for the perfect words to form in our heads so we can just write them down is never going to happen. It doesn’t happen with coding so why do we expect it with writing.
Switching contexts can show this. Have you ever tried to refactor a program that’s zero lines long? So why are you trying to do that when it comes to documentation, email or a presentation. I like this quote from Jodi Picoult…
You can always edit a bad page. You can’t edit a blank page.
You have to actually get something down on the page before you can improve it. In Marion Smith’s book she refers to this as “vomiting” the first draft. Anne Lamott calls it the “sh*tty first draft”. One thing is clear. The first draft is not going to be pretty, but it’s the necessary first step.
Feel the weight lifting off your shoulders as you give yourself permission to write the first thing that comes to mind, regardless of the quality. With coding you want the first version to do something OK. With writing you just need to get some words on the page. Any words. There’s no compiler to reject them so what are you worrying about?
Getting a minor dose of fear before you start writing is normal. It happens to professional writers so it’s not surprising that it also happens to developers when they need to write.
My recommendations are:
- Get something on paper, anything at all. Write down whatever comes into your head.
- Use agile/Scrum rules: iterate and adapt
- Use coding refactoring rules: reduce complexity and improve readability over time
Just remember, the next time your boss asks “Have you sent that customer email out?” you’re not doing a parachute jump. All you need to overcome your fear is to vomit out your first draft and iterate.
You already have the coding skills, now you just have to apply them to your writing.
Originally published by Chris Rowe at leadtechie.com on March 3, 2019.