I live a double life. It is not because I want to. It is because I have to.
Every day, I sit down with music beaming from my speakers and begin writing code. It is the part of me that I am known for. I earn my living by it.
But, after my day is over, I sit down again; this time with calmer music - enough to zone me in but not take my concentration away. This is when I start writing a blog like this.
For the past few months, I have noted many similarities between my two lives. For one thing, I am speaking to my fellow programmers when I write code (like I am doing with you right now), and for another, I am helping you navigate through a problem when I write this (like when I write a piece of code with an intent to solve a problem).
Just as I am speaking to you as I write this, my job when coding is to talk with other people. I see many junior programmers make this mistake. They mistake their job as being speaking to a computer. As a result, they write code that only a computer understands and think their job is over.
But if I start talking just to the computer, I will be limited by how much impact I can create. Computers aren’t smart enough (yet!) to expand my vision and build on top of my work. Humans, however, can. You write code, and your team uses it to solve another set of problems. You create an ever-increasing chain of influence just through your code (think about how significant this influence is in Open-source software.).
And, when I am writing, I have a clear intention in my mind - to answer specific questions about the topic I choose. For example, when coding, I first write a function name and then describe programmatical steps to define what the function stands to do. It is the same when I write blogs; I give myself a topic and answer specific questions that the topic poses. (When I started writing this blog, the question was: “How is a writer’s life similar to a programmer’s life?)
I want to do the best I can in both of my lives. I don’t want to be an average programmer and an excellent writer - that is a disservice to my fellow programmers and me. And, I wouldn’t want to be an average writer; that would not be fair on you. Luckily for me, I have found it is about the same framework and habits that help you get better at both things.
In the programming world, simple solutions are hard to find. Meanwhile, good writers write good stuff, but the best ones make the same stuff simple. This simplicity is what I strive to have in both my lives.
I spent hours improving the same sentences as a writer in search of this simplicity. But, it never satisfied me, and often, I would stop midway. However, perhaps through mentorship or pure luck, I always wrote the code that worked first and then cut the unnecessary parts out.
So, one day, I thought to myself, “Why don’t I take the lessons from my programming life to the writers’ life?”
I stopped searching for perfection in my writing. Perfection froze me. I let it flow without judgment. At first, it was a discovery process about what I thought about the topic. Then, after I put everything out in the open, I started eliminating everything there for the show. I wanted my real message to shine through.
It is how I have always coded. I first write things that work. I don’t care if it’s something that only a computer can understand. But I don’t stop there. Now that I know how to answer the topic, I start making sure my future self (someone who isn’t working on this daily) understands it. I want to make sure my teammates don’t look at it someday and think they are stupid for not getting it. They are not. It is all me. My code should have “Aha” moments as people go through it, not constant “WTF” s.
Often though, I cannot judge my work impartially. I am a biased human being. I spend hours writing the piece of code, so I get attached to the solution I write. I get so zoned in my writing I have no other perspective left. As such, your best bet is to find enough people to go through your work and give you some feedback.
I have a set of people in my writing life who are open to giving feedback whenever I send it to them. They do it because I would do the same for them. And it is even easier with my code. Code Reviews are a part of a programmer’s job description. If my fellow programmers cannot understand the code today, they will not understand it tomorrow. So, their honesty forces me to re-think and improve.
A good writer can teach a lot of things to a good programmer. I am lucky I love doing both. The only difference between my two lives is that I need to learn two different languages. One requires you to be creative while honing on the technical; the other requires you to be more creative than technical. But hone into my secret. Take the lessons from me. If you are a good writer, think about how you could improve your craft if you were to step onto a programmer’s shoes. Think about how a writer’s craft can enhance your work if you are a programmer. Or best yet, live a double life.