6 Things Programmers Can Learn From Writers

The art of writing actually has a lot to teach programmers about good software. Here are six tips you learn as a writer that can also be used by developers.

1. The First Draft Will Probably Suck

When writing, your first draft is usually… not great. As you get better at writing, the quality of your first draft will improve as well. Fewer and fewer adjustments will be needed over time, but the point remains: Your first draft will almost always be the worst version.

Programming is no different! Accept that your first draft is exactly that — a draft. That doesn’t mean you don’t put your best effort into it, but you shouldn’t be prematurely optimizing and spending a bunch of time “beautifying” your code. There is a high chance that no matter what you do, when you come back to your desk on the next go-around, you will have thought of a far better solution.

2. Proofread Your Own Work

This is an obvious one. Anyone can usually tell when a writer didn’t even proofread their own work (spoiler alert, I didn't proof read this article!). The same applies to programmers.

Typos, leftover console logs, bugs so obvious you can catch them at a glance — these are all typically red flags in a code review that the programmer didn’t do much proofreading of their own work.

This is a bit of a stretch in the comparison between writers and coders, but I would say “proof-testing your own work” is equally important. If you are submitting a feature as ready for user testing/review, make sure it actually works or you will look silly. I think we have all been in this position before.

3. Then Let Others Proofread Your Work

Great writers usually have someone proofread their work. Sometimes no matter how much you look over your own work, you just can’t catch the obvious (or not so obvious) issues. Programming in a team is no different. The whole concept of “code reviews” revolves around this one idea of having others proofread your work to minimize problems.

4. There Will Probably Be a Second or Third Draft

When you had to write essays in school, how often did you submit your first draft and never have to touch it again? I assume (hope?) that has never happened. I remember having to revise my work two or three times before I was allowed to submit it as “complete.”

Programmers often tie their ego to getting their code right the first time (code interviews and competitions kind of push that).

Considering that an error-free piece of software has never been written, I’d say that kind of thinking will set you up for disappointment.

Your pull request may get rejected even when you think you did everything perfectly. That’s OK. You should be happy someone has given you the opportunity to learn and improve. We all have something to learn from each other.

Now, you may submit a second pull request and get rejected yet again. OK, I’ll admit that hurts the ego a bit, but it’s the same principle: Learn, improve, repeat.

5. A Finished Piece Is Better Than a Perfect Work in Progress

The article that is never complete will always be worse than the article never written. Have you ever not submitted an essay to your teacher because you were perfecting it and received an A+ as a grade? Hell no. You got a big fat F for failure.

Coding is absolutely no different. If your software takes two years to build because you want it to be perfect, you’ve probably already failed (and a year ago at that).

Accept that even your completed work won’t be a masterpiece and you will still be iterating on it long after you considered it done. The most important theme shared between writers and developers is that it is important to get feedback as soon as possible so we can make the necessary improvements sooner rather than later.

6. Keep a Cohesive Narrative

Have you ever read an article that can’t seem to stay on track? It’s like a roller coaster, but on a roller coaster, you enjoy the random twists, turns, and loops. In an article where all you want is information (or a good story), this is usually not desirable.

Something that requires a lot of skill in both writers and developers is the ability to elegantly flow the narrative from start to finish. To make the reader feel like they went on a journey, even if all they read was “I watched paint dry yesterday,” is part of what makes the top writers here on Medium so successful.

Programmers may be thinking, “Code should be optimal and easy to read — not tell a story.”

Is that so? What if I told you code that tells a story is easier to read? There is a reason humans are so responsive to a well-told story. Just check out this article on the psychology of storytelling.

When your code has a clear start, middle, and end, it naturally forms a story (an admittedly boring one), which makes it easier for other programmers to follow it.

If you really want to level up your programming skills, see if you can write code that is not only optimal but tells a narrative as well. I think you will find that others have a much easier time navigating your code.

Conclusion

Writing and programming have more in common than you may have thought.

See more connections? Add them in the comments section!