Writing: the hardest skill of software engineering
When I first started out as a Software Engineer for Amazon, I was hyper-concerned about my ability to code. And to an extent, I still am. Imposter syndrome is mostly about confidence in code-writing, since its such an unknown. If my task is to write a README, I know at the end of the day I’ll be able to turn in something, even if what I write isn’t as elegant as I’d hope. But there’s an innate binary involved in writing code: either it works or it doesn’t. That’s where imposter syndrome kicks into overdrive for me. I think, what if I can’t get my code to work?
That thought process makes it really hard to focus on other aspects of being a good software engineer. However, my few years working in industry has taught me that coding is not actually what makes a good software engineer.
“The kicker is that I’ve seen, time and again, that the real force multipliers spin incredibly powerful narratives in opinion docs that make you think, ‘damn, why are we not doing this already.’”
The point I’m trying to make is that ability to write clean, maintainable code is important, but you’re going to be able to do that adequately. That’s the fun part about being a software engineer. Unless you’re an actual imposter, writing code is why you’re an engineer in the first place. It’s going to naturally be the skill you practice and care about the most.
The kicker is that I’ve seen, time and again, that the real force multipliers spin incredibly powerful narratives in opinion docs that make you think, ‘damn, why are we not doing this already’. Expressing your ideas in writing is the most powerful tool in the software engineer’s toolbox. It’s not particularly close. Good writing gets buy-in from others who will happily do your bidding for you since they believe in a shared vision. Good code on the other hand, simply makes you a lone wolf. The impact of your code will always stay at an individual level.
Writing is also the interface between software engineers and leadership. No leader, no matter how technically savvy, is going to be able to recognize good code from okay code. But they sure can recognize good writing. An inability to communicate effectively with your leaders (basically, anyone who has a say in telling you what to do) does not bode well for your standing in your organization.
This might not sound like a novel idea but then explain to me this: why are software engineers so pitifully horrid at writing? Why do I read docs where it’s clear that the author’s brilliance is lost in the word scramble, typos and run-on sentences, and incorrect assumptions?
Writing is hard. To be effective, you have to walk a tightrope for your audience, who are fellow engineers, product managers, people managers, and more. Deciding on the necessary background and depth of ideas is difficult because parts of your audience are looking for different things. Software engineers reading your masterpiece may be scrutinizing the technical feasibility of your idea. But managers are likely scrunching their nose at the resources required to greenlight your vision and stacking that ask up against all the other initiatives at play.
This isn’t an article about how to become a more effective writer. I don’t even think I’m truly an effective writer yet. But when I write docs, I try to evolve my work to encompass feedback on the last and see what tactics result in the best outcome when they are read. For example, write a longer doc and you might lose your audience halfway through. Write a short & sweet doc and expect comments asking why you didn’t flesh out one section a bit more. Although you can’t please everyone, I find shorter, scoped-down opinion docs end up getting the quickest buy-in. That’s something I’ve learned, through trial and error.
This is an article about desire to improve. It’s about recognizing gaps and filling them. Being able to write effectively is a career-advancing skill. If you haven’t figured that out yet, get on the bandwagon. Go hunting for opportunities to hone your craft. Your career may depend on it.
