8 Striking Similarities Between Writers and Developers. And 1 Major Difference
Ok, time for a listicle, friends!
Introductory note: The writing experience is all mine. But the dev perspective is based on my short touch-base with some Python tutorials, my expertise from working a good number of years in IT, and, more importantly, the professional know-how of a good friend of mine, kind enough to share it.
So, have you ever considered how similar journalistic writing is to coding? Yeah, me neither. Until I started to try to learn Python. Then the subject begun to interest me greatly. And I noticed how much alike these 2 occupations are. Let’s list-go through some of these striking resemblances.
- From idea to first line, they undergo a tedious process (by “they “ I mean both writers and programmers)
You know that feeling you have when your bathroom idea is so great that you are wondering why it didn’t start to make money already? You’ve got it and it blows your mind. Absolutely must you share it with the world.
Fire up laptop. Set up favorite music on repeat. Open editor (yes, developers’ tools are also called editors). Hit the keyboard. Where should I start? What is the very first line I am going to write?
At this point, the next step is to think about structure. The usefulness of the piece of hand. Ways to keep it simple. Ways to make it “green”. As in, still valuable and working over a number of years. Ways to optimize it. etc.
It is a painful process. Experience and, according to a ridiculous number of Medium writers, having a routine to get “in the zone” helps. Since I am unable to speak from my own authority, I am going to give them the benefit of the doubt. And trust them.
But, by both these standards, I am a newb. The process of writing anything new is Sisyphic for me. I consider and reconsider and re-reconsider the structure of the idea too the point of exhaustion. Then I delete most of the initial work and start over. Until it begins to look right. It is the most time-consuming part of the whole process.
Development-wise, a number of really good engineers, proficient in multiple programing languages, say the same. The biggest, hardest, differentiating part of writing code is actually planning the structure of the piece at hand. This happens mostly in their head. Or by a paper-diagram. It is a lot more time consuming than the actual coding.
2. They understand the word “elegance”.
Elegance is not about being shocking, trendy or expensive. Elegance is about interacting with other people so that you don’t offend anyone. Not sugar-coat it, not hiding it, absolutely not lying. Just find a way to say what’s on your mind without offending anyone. And no, not diplomacy. Diplomacy involves a sort of shadiness to some degree. Elegance means truth.
Now, I am not deluding myself. I know, what you are about to say. It is not possible. People will misunderstand writers and be offended anyway. Yes, they will. But not because the writing is not elegant. But because people are highly subjective creatures with big egos and think everything around them is, naturally, about them. Myself included. There are writers here, on Medium, who wrote about this: Be Prepared to be Misunderstood If You Plan To Write Online.
I was saying that the mark of a good writer is to find a way to be elegant. This means short, clear text that appeals to everybody without offending anyone. Even if they treat critical or negative topics.
I don’t know how elegant applies to code from my own experience. But my friend tells me it is about clear, short lines of code that are easily understandable by anyone new at first sight, despite all the exception cases. Exception cases are ALL production outcomes that must be considered and treated from the initial project outline. Examples can be found at entry 5 of this article.
3. They have online records of their work and have to build up a follower base
Not necessary a must you would say. But it certainly helps.
It is easier for a writer to be acknowledged if, on top of their writings, they come up with a loyal, large follower base. One would even argue it is the proof of how good of a writer one can be. Or how big the size of the egos. Depends on the perspective.
Same for developers. Granted, the followers base required might be significantly smaller for coders. However, the size of their egos can remain just as impressive.
Medium is for writers, GitHub is for developers. Now there is a rare breed who can mix both. I wonder which one is more time consuming? Or which one captures their attention more often at nights. Or which one makes them more proud?
4. They have to follow syntax. Punctuation makes it or breaks it.
Aaaah….syntax. It’s like the foundation on top of which I can show off my extensive vocabulary and witty line of thinking. Essential part of writing. Learnt fairly easily. And quite mandatory for any job requiring some form of communication.
But, my, how do things change when it comes to coding syntax. As I mentioned, in my short experience, Python taught me there is such thing as syntax error. And sometimes it’s not even at the line specified by the error message. It’s one or two lines above! Figure that! Will not dwell on it too much because they are difficult to decipher only for beginners. Professionals handle them a lot faster.
In the writing world, images are conveyed through words. Which is not always enough. To capture a state of mind or an emotion, you have to augment sentences with punctuation marks. For instance, there is a subtle difference between these two, exactly the same worded, phrases:
“What a sunset….a strange sense of eerie is slowly wrapping me….what follows next?”
“What a sunset! A strange sense of eerie is slowly wrapping me. What follows next?”
First is meditative. Second is anticipative. Reader’s expectation is set with punctuation marks.
In programming, punctuation marks are equally important. Typing a “:” when a “;” is required can crash the script execution. For traditional writing, punctuation sets rules and gives nuances. For coding, punctuation sets rules and throws error messages. With a stubborn persistence, until you get it right. My, how restrictive!
5. Here’s the one that puzzled me most: imagination counts.
It is fairly understandable for a writer that the more developed their imagination is, the better the writing. Originality makes the difference between mastery vs just really good skills. Sometimes, a poorly articulated idea can be of so much more value that an extremely well written idea that brings nothing new to the table. Originality and imagination go hand in hand.
A vivid imagination allows the writer to set different stages for their characters. Different adventures. And, most importantly, more perspectives to the same debate. Eventually contradictory. Hence a bunch of new, untold ideas to the same old world problems. Hence originality. The more you can imagine new outcomes to a given situation, the more fresh perspectives you will find to it.
When doing code for production, you have to be careful at which existing modules your changes will impact. Imagination helps with that, as it can encompass multiple, new use case situations. Devs call this treating exception cases. It’s like fixing a broken chair leg. You use glue? You use nails? You use 4 completely new legs? Obviously this decision is based on the structure of the chair. You cannot use nails, if the exterior of the legs is all decorations and fine carvings. Glue is much more suitable. Especially if the destination of the chair is a coffee shop, not a beach.
Overly-simplified, of course, this example. So, complicate this type of decisioning with all possible coding outcomes. Then multiply everything by a 1000, and you get a bit closer to the actual programmer work.
Good devs keep variables in their mind when creating code. They can actually have entire programs “written” inside their memory, to which they add or abstract new features. A more vivid imagination helps them to keep in mind more variables and running programs in the same time. This, in turn, allows them to better forecast production situations. Just as imaginative writers can forecast multiple, original perspectives.
6. They can obsess and fine tune on a single piece for days in a row
You know the deal with good professionals? They always doubt themselves and the quality of their work. They are perfectionists who think are never good enough. Which, by itself, is a good thing. Helps along with the progress of humanity.
Buuut, there is a time to fight and there is time to let go. If the 1 through 5 points are met, it is safe to assume that the writing is pretty ok. Yet, we all do it. At every sentence. Even after already decided the article is good enough for publishing. Still find a small comma to correct. A synonym to replace. An (allegedly) extra word to delete.
It is the same when coding. Even if 1 through 5 are met programing wise, the refining of an algorithm can keep devs awake at nights. Especially if there is some bug in the code logic. Which in essence is not a bad thing. But, the mark of a good professional is to know how to balance a deadline with overly fine tuning. This does not mean the bug must hit production. It just means that, once the logic is sorted out, the feature release should hit production. Even if algorithm can be further improved upon.
I would venture to say it is the concept known as over-optimization. But, to my humble understanding, over-optimization is dwelling on concepts and abstractions vs. actual understanding of production rigors and concrete problems. Maybe a more qualified technical dev can shed some light on this one.
7. They delete work. Especially at night whims. And when alcohol is involved
Here’s what frequently happens to me. I write, and I write and I write, and I am quite happy with the outcome. Until night hits and I wake up in the middle of it to remember something that’s been constantly running in the back of my head. And nagging me. Of course, I couldn’t quite put my finger on it. It was just there. Until the insomnia night inspiration. When I suddenly realize the cause of my nagging. And the cause of my nagging, more often than not, is a small inconsistency in the article I’m working on. Because of that, especially if these considerations are accompanied by alcohol, I delete most of my work and start over.
Here’s what I don’t think mixes well with development but (usually!) works wonders for writing. Alcohol. It even has the miraculous effect of snapping people out of procrastination habits.
Yet, somehow, I don’t see it helping too much with a monster-type application, with a n-tier server architecture that needs to be optimized for speed and bottleneck failures.
So I asked.
Me “ Does alcohol helps when coding? Makes you more productive?”
Suspicion confirmed! Crystal clear head when coding, people. I will not list this as a differentiator though, as in my humble opinion, it is not the major one.
But, they do delete work, if they feel it is not good enough. And start over. It’s called code optimization (different than over-optimization!). Sometimes it’s part of a bigger process called code refactoring. When they evaluate a piece of work, part of the optimization is to delete code lines that are complicating the product. Or are not sufficiently reliable in terms of possible logic errors.
8. For some reason, the word research comes up in their work more often than in research labs
This one is so impossible similar that it makes me think I could be a kick ass programmer. It involves banging your head against a wall until you understand completely new concepts from completely new domains.
It is true that writers give authenticity from their own experiences. However, should they be limited only to that, writing would be really boring. And only in first person narrative.
I will exemplify here with Bernard Werber and his “Trilogy of Ants”. It is an amazing cycle about how alien beings living on the same Earth as us (ants) completely escape our understanding. To illustrate an entire saga of a warrior ant, the author proves a deep knowledge of the tiny creatures. I must admit, I learnt more about ants from his books than my entire lifetime of watching National Geographic. He is ultimately a writer. Even if he has an intimidating, extensive background in ant life cycles.
If you hear a developer who has just been assigned a new task, this is the first thing they will say. “I have to do a research first”. And they, as well, keep at it until every detail of the new task is not only clear to them, but they know the very reasons for using that specific set of technologies.
So, dear HR managers in search of ….um…rockstar developers!?!. Should you wish to test at interviews how good the logic or algorithmic skills of your candidates are, stop with the “gotcha” questions. You know, the kind that asks people to re-arrange sticks on tables or to poor water into less glasses than needed.
Instead, start giving them writing assignments. Talk about an actual story that maybe happened to them and ask to put it in writing. See how well they abstract, summarize, describe, and, generally, how understandable their writing is. And seeing how I don’t like to preach without trying it first, I actually asked a technical leader if this testing method would be of any relevance to him. He said yes, by all means. Not sure if he was polite or the idea has some actual value in it.
Obviously, I haven’t actually put it into practice. So maybe, if you’re adventurous enough to ask tech people to do essays at interviews, you can give it a try. It should at least tell you how well they react in a completely new, stressful situation.
Then return to this article and drop us a comment about how it went. Share some live reactions with us. :)
The 1 Major Difference
And now, for the 1 major difference: My fellow writers, brace yourselves, it is a bitter conclusion. Developers make considerably more money than writers. Even those who hit it big. By comparison, I think (I don’t have the numbers yet) Zuckerberg has more money then R.R. Martin with all the HBO royalties.
So I would say: give it a lot of thought if art is worth your while. For me the answer is still yes, as I find writing text a lot more enjoyable than writing code. Sure, no doubt about it, it is also because I am not as good at writing code. But, but…but, it is also because I feel I can communicate with far more people by traditional writing than I would ever manage to do by writing code. Regardless of how good I might (eventually!) become at it.
Not sure if it’s the smarter answer, but for the time being, I remain true to my initial calling.