By Piotr Gaczkowski, IOD Expert
When I first started writing for IOD, my belief was that writing was optional for engineers.
I’ve changed my mind.
Even though your main responsibility involves solving problems and writing code, prose is something you can indulge in. Most don’t and that’s fine. But I’ve learned there are many benefits to writing beyond code. I no longer think it’s optional.
Writing Is Not Just Blogging
A lot of engineers I know see the world in black and white. For instance, there is writing code, which is good and pure. And there are the other “dirty” fields like sales, marketing, and customer relations. Ask an engineer and you will hear that these areas are wild, unscientific, and dominated by extroverts.
With this belief, every time a coder hears about writing as anything other than code, he assumes it’s to serve the Dark Side. It doesn’t matter if it’s documentation for a customer, a blog post for content marketing, or a simple slide for a sales deck. None of those activities are worthy of the time of any respectable black-and-white-thinking engineer.
But writing comes in many different forms and the deliverables I mentioned above are only a tiny fraction of the greater whole.
Journaling, for instance, is a habit that’s been exercised by many great minds in history — including scientists! — from Isaac Newton to Leonardo Da Vinci to Charles Darwin.
I’ll Be My Rubber Duck
“How can journaling help me as an engineer?” you may be asking. For one, Tim Ferriss believes that journaling helps to declutter the mind. By writing down problems, thoughts, and ideas, we empty our brain of distractions. We may consider ourselves smart, but the fact is we can be easily fooled. Writing things down tricks the brain into thinking we have accomplished something.
But there is another use of journaling that can help you very much, especially during debugging. You are probably familiar with the so-called “rubber duck effect.” The idea is that when you run into a problem, you’re supposed to tell the problem to a rubber duck. Chances are high that while you articulate the problem, the solution will present itself. It’s caused by sudden cooperation of both brain hemispheres: the one that is responsible for analytical thinking and the other one that’s responsible for speech. Luckily for us, we can skip the rubber duck and activate both hemispheres just by describing our problems in prose.
Want to know an equally effective trick? Stop every half hour and write about the progress of your task. Or simply describe the task. What is the hypothesis? What will this task test? What is the desired outcome?
By answering these questions, you can catch yourself “yak shaving” much earlier than you would normally.
IOD IS A CONTENT CREATION AND RESEARCH COMPANY WORKING WITH SOME OF THE TOP NAMES IN I.T.
Our philosophy is experts are not writers and writers are not experts, so we pair tech experts with experienced editors to produce high-quality, deeply technical content.
Being Great Is Not Enough
What I am about to tell you will certainly sound like advice from the Dark Side: As an engineer, you need to build your personal brand.
I already hear the black & white thinking again: “It’s marketing and that’s evil!” I don’t want to try to convince anyone that marketing is not evil. What I want to say is this: if you don’t take care of your personal brand, nobody else will.
Many great painters and composers died in poverty. It wasn’t because they weren’t talented. It was because being great means nothing when no one knows about you or your greatness. All caring for your personal brand really means is showcasing your abilities and conveying a well-thought-out message to the appropriate audience.
Say you want to start doing webapp backend and eventually move to a Machine Learning position. Get some experience with the topic by completing courses or participating in open source projects and show your new talents to the world. How? By blogging about it, of course.
Then you can write it on your CV, and on a LinkedIn profile! What’s important is to let potential employers know you are somebody who can handle a Machine Learning position in their company.
Are You a Knowledge Hoarder or a Knowledge Sharer?
I am counting on the fact that you are smart and have learned at least a few useful tricks during your years on the job. Do you keep those tricks to yourself or do you share them with your colleagues? In other words: do you hoard the knowledge you have been given or do you share it freely so others can benefit as well?
As our field of work is knowledge-based, most of us fall into one of those those two camps. Knowledge hoarders believe that in a dog-eat-dog society, sharing too much of your advantage can lead to unemployment pretty quickly. It’s therefore better to be an expert in some obscure technology no one else knows about because this means steady employment.
Knowledge sharers, however, believe that due to their advantage and better experience they are obliged to help others. For some, this belief may stem from the fact they want to give back for the “free” the lessons they received from people before them. For others, the main motivation is the mentality that the more the team knows the better the decisions it will make, which leads to success for all.
If you side with the knowledge sharers, I have a tip for you. You can tell the same story ten times to ten different people and each time it will help those people a tiny bit. But you can invest a similar amount of time and write the story down. Worst case scenario? You’ll reach the same audience as you originally would have. Best case? You’ll reach 10x, 100x, or 1000x more people. Your contribution will be exponential!
Automation? Time Saving?
Yup, even writing a simple FAQ can mean you spend less time answering questions and more time working in a flow state (hopefully). And if your projects feature an up-to-date README, new people joining the project won’t need to tear the installation and building instructions from other busy team-members. They might still be less productive than the old guard, but at least they are independent and don’t slow others down. So writing can be considered a productivity hack, too!
Trust me when I tell you creative writing really has so many benefits for an engineer. It’s changed my life and my professional trajectory for the better. If you find the same to be true for you, share your comments with us below!