I spend a lot of time and effort trying to get better at the craft of software development. My goal every day is to fall asleep as a better programmer than the one that awoke that morning. While this involves a lot of reading and practice within the field, I usually learn more by studying older disciplines since software development is still such a young craft.
Earlier today I read an essay on the decline of the English language by George Orwell. The essay is excellent, and I’m already trying to apply its lessons to my writing, but there was one passage that struck me as being particularly useful for software development.
When you think of something abstract you are more inclined to use words from the start, and unless you make a conscious effort to prevent it, the existing dialect will come rushing in and do the job for you, at the expense of blurring or even changing your meaning. Probably it is better to put off using words as long as possible and get one’s meaning as clear as one can through pictures and sensations. Afterward one can choose — not simply accept — the phrases that will best cover the meaning, and then switch round and decide what impressions one’s words are likely to make on another person.
To apply the quote above to software development, replace “words” with “code” and “dialect” with “programming language.” When you become accustomed to using a particular language or coding pattern, you tend to think of any new problem in those terms. If you choose the wrong strategy for solving the problem and start implementing too quickly you may end up with a solution that is too “wordy” or that does not express the abstractions accurately.
Earlier today, before I read the essay, I put this very lesson into practice without even realizing exactly why I like to do it. Whenever I come up with an idea for a new feature that I need to implement, or whenever I need to make a radical change to some system I’m working on, I’ll get up and walk away from the PC before the idea forms too fully and I start to write code. I’ll go for a walk or do some mindless activity (today it was sweeping the driveway) while I think about the idea. I’ll consider different implementations to see what problems might arise before I commit to a solution. Though I’ve never thought of it this way, it’s the same sort of process that Orwell describes in the quote above. Now that I’ve read Orwell’s precise definition of why this is good for writing prose, I better understand why it’s also effective for writing code.
Software development is hard. The job of a software developer is to turn an abstract idea into a concrete implementation in an efficient manner. Until you fully understand the abstractions, it’s impossible to consider any concrete implementation, let alone one that is efficient. I find that I write better code once I’ve thought enough about a problem to create a sort of landscape in my mind. It really is a landscape, too. It’s almost as if I can walk though the implementation in my mind and explore its darker corners. If I can find a way to build a mental model with fewer dark corners and dead-end hallways, then the concrete implementation will usually be more solid.
As you try to become a better developer, look for lessons from other fields like writing, architecture, the building trades, or any craft or profession that has been around for a long time. You’ll find that many problems that look like they’re peculiar to software development were actually considered and solved in other trades hundreds or even thousands of years ago.
Share
