Read, Write, and Refactor

A couple of years ago, I got to realize a lifelong dream when I became a published author. I was surprised to learn that many of the skills that I gained in becoming a good software developer were actually useful to me in becoming a good writer. Like code, prose should be well-encapsulated and cohesive, assertive and non-redundant, and all the other qualities that are virtuous in software apply equally well to prose.

I learned how to keep my writing and my speaking focused and engaging. I learned that when I deal with things on the same level of abstraction that it's easier to understand and communicate. I learned that very often a central image or metaphor around an important concept really helps us understand at a much deeper level.

What I wasn't expecting — and turned out to be quite a pleasant surprise — was that as I gained more skill as a writer, some of that knowledge could be transferred to writing good code. I want my code to be engaging and clear, just like my writing. I find that even the basics of story structure can be used to help make the narrative of a piece of software more descriptive and interesting.

The stories that we use in Agile speak of what, why, and for whom a feature is being built. This is used to drive our acceptance criteria. At a lower level, we describe the behaviors that we want to create using a "given-when-then" format that says, "Given some precondition, when a trigger happens, then some post-condition will occur."

These statements can be translated directly into unit test code, so they can be very useful. Our goal is to break down features into smaller steps that produce some measurable result so that we can write a test around it.

I've read many books on writing, and still one of my very favorite books is Stephen King's On Writing. One of the things he says is that, in order to be a good writer, you have to do two things above all else. First, you have to read a lot of other people's work, because that's how you expand your knowledge on how to turn a phrase and improve as a writer. Read from all genres and all styles. Read to study structure as well as execution.

The other piece of advice that Stephen King gives is that, in order to be a writer, you also must write a lot. This is one characteristic that all great writers have in common — they spend a lot of their day writing. Not all of it is good, of course. But when the mood is right, they are able to capture a lot because their butt was in the seat.

So, read a lot and write a lot. That's the advice that Stephen King has for aspiring writers. For aspiring software developers, I would give some very similar advice with some caveats.

One thing the developers don't do nearly as often as they should at all levels of experience is to read other people's code. One of the big problems around this is that most people write really crappy code. Also, many developers may write good code but just simply choose to approach problems in a different way than we would. However, this is good because it teaches us different perspectives and ways of thinking.

Unfortunately, there are no libraries packed with best practices for coding in a variety of different environments. There is a lot of code out there if you know where to look for it. There are open-source projects and tons of projects on GitHub and other repositories. But reading through this kind of code is not like reading the classics. Still, every once in a while, I find some really interesting tidbits in code that make it worthwhile.

The second piece of advice, to write a lot, is easier for most of us. As professional software developers, a good part of our job is writing code. The challenge is to continue to improve our skills as we continue to write code.

But there's another aspect to software development. It doesn't have a strong correlation in literature, but is very important for us developers to practice. We're just beginning to realize the importance of refactoring code and how software is part of a lifecycle. We can use refactoring to safely and effectively transform even the most intractable legacy code into something better.

Knowing how to look at its design and discover patterns that we can easily refactor means that we can constantly improve the design of software and treat it like an asset that can be maintained and improved.