On Writing Code
I love to read in my spare time. One of my favourite authors is Stephen King, whom I assume needs no introduction. You might not know that he wrote a book about the craft of writing, in a book aptly named On Writing.
As I read the book, which I picked up to improve my writing, I realized the sheer number of commonalities between writing and programming. I started wondering: What lessons could apply to this profession of ours, software engineering?
Accumulate a solid toolbox
The best part of On Writing for me was Stephen King's metaphor of a toolbox. Have you ever seen one of those handy toolboxes that you can fold open with nifty layers, each holding a different set of tools? To King, a person's writing skills can be seen as one of those toolboxes.
In writing, he says, you start accumulating basic skills like vocabulary, which end up in the top drawer. Your skills grow and deepen, and the next tier might contain character development or dialogue writing. Eventually, you might amass such a body of knowledge that the toolbox needs an upgrade!
As I read this metaphor, I started thinking about what this toolbox would look like in the realm of software engineering. The top layer contains knowledge of control flow, iteration and methods, and a "native language." As you gain experience, you start deepening your knowledge, filling the next tier with frameworks, design principles, programming paradigms, coupling/decoupling, etc.
Who knows how many tiers of knowledge there are to explore? I guess this is one of the exciting aspects of our profession: the endless possibility to improve at the craft, shaping your own unique toolbox. A toolbox that becomes a testimony to your one-of-a-kind experience, the journey of your career.
All that's left is for you to utilize the toolbox to solve business problems using technology and deliver value to the organization and, hopefully, the world.
Read broadly
King is a voracious reader, a habit he picked up at a young age. He thinks it is a large part of his success, though not just the sheer amount he reads. He also reads broadly.
If you want to become a better writer, he states, you shouldn't just read a lot; you should also read broadly. He argues that this feeds into mastery of different skills, for instance, by exposing yourself to various styles and techniques.
For Software Engineering, I interpret this point two ways: the obvious one is reading books on different aspects of the craft, and the less obvious one is reading other people's code.
There are many books on software engineering out there, many of which contain a massive body of knowledge about our profession. Reading broadly exposes you to a plethora of skills relevant to the craft, expanding your toolbox with many distinct tools. The result: more tools to choose from and, perhaps more importantly, the ability to determine when to use which.
Code reading is a crucial skill. We typically spend more time reading than writing code, but we practice the latter much more than the former. Reading code not only improves the skill itself but also exposes you to different styles of coding and ways to solve problems—a great way to expand your toolbox.
Write often
Read all you want, but the only way to become a better writer is to sit down and write. Consistent practice of the deliberate kind is a recipe for mastery (for more on the topic, definitely take a look at this book.) Writing is a skill that's battle-forged, not developed by theory alone.
If you are a Software Engineer, chances are you write code regularly, and it might seem like practice is taken care of. As I wrote in an earlier post, writing production code is a form of practice, but not necessarily the best kind. Supplementing your day-to-day coding with some dedicated practice every now and then could yield even better results!
Writing alone doesn't get you there; you must also actively reflect. What about revisiting some of your earlier work or commits? How would you solve the problem now? In which ways have you changed since then? Yes, this might be embarrassing at times, I've been there. Just view those moments as a testimony to your growth.
Writing is more than language
King argues that neither a colorful and diverse vocabulary nor deep mastery of grammar makes for exceptional writing. Writing is the synthesis of all the skills in the toolbox; the whole is greater than the sum of its parts.
Tool obsession infects software engineering. I have gotten questions like "Which version of Java have you worked with?" and was even interrogated on my recollection of specific library API's. I take King's stance in this matter. To me, these tools belong to the top layer of the toolbox – good to know about, but it doesn't make you a great writer.
Most precious of all is the synthesis of tools. I imagine a craftsman creating a beautiful piece of woodwork. In a flurry of deft movements, moving from one tool to the next, an elegant symphony materializing what's in the mind's eye. Contrast that with the person obsessing over how the hammer is held or pondering whether it's the latest and greatest chisel. Indeed, any craft is about so much more than its tools.
Summary
As I type this article, I realize another similarity: the satisfaction of bringing an idea into the world. The act of creation is deeply gratifying, something easily forgotten. Pause every now and then to savour your creations in all their glory.
With that, I take my leave, but not before sharing one more piece of wisdom from the world of writers:
Writing is an art, but it is primarily a craft, and like every other craft, it takes many years and arduous journeys to improve it, and that process of learning never comes to an end. Writers have to be learners. Writers are life-long students.
And so are we.