I've been reading "A Philosophy Of Software Design" by John Ousterhout. It is viewed as one of the best books for software engineering professionals. So far I'm enjoying it. A relatively small book by engineering book standards but filled with useful information about practical approaches to software design. After reading some initial chapters, I immediately began to implement some of the book's concepts into my professional and personal software development. It has made my code clearer, easier to read, and therefore easier to debug.
One idea the book explains is why strategic programming is better overall than tactical programming. Tactical programming is generally trying to get something working first, often haphazardly through brute force development. Strategic programming, as the name suggests, emphasizes producing a design first and then developing off of that. From this concept, Ousterhout brings up the term, "tactical tornado." This is a developer that writes code at an extreme pace, faster than most people on their team or in the whole organization. The issue with this type of person is that the copious amount of work ends up being poor to average at best. Additionally, the engineers that end up having to take on this codebase afterwards will endure the pain of spaghetti code.
One idea the book explains is why strategic programming is better overall than tactical programming. Tactical programming is generally trying to get something working first, often haphazardly through brute force development. Strategic programming, as the name suggests, emphasizes producing a design first and then developing off of that. From this concept, Ousterhout brings up the term, "tactical tornado." This is a developer that writes code at an extreme pace, faster than most people on their team or in the whole organization. The issue with this type of person is that the copious amount of work ends up being poor to average at best. Additionally, the engineers that end up having to take on this codebase afterwards will endure the pain of spaghetti code.
Upon reading his definition of this, I kind of had an "oh damn, is that me?" moment.
Am I The Problem?
While I won't say I'm 100% guilty of this. After all, my career so far has been relatively short so it would be a little out of reach to do this. However, I am guilty of having this mindset. Since I've started working professionally, I've always thought that I should be committing a significant amount of code. It's the advice that early career software developers hear from more experienced professionals. The early years should be spent learning as much as possible and working on as many projects as possible. So that was what I did. I was first to volunteer to take on challenges and write as many lines of code as my fingers could bear. As the book mentions, management reacted to this quite positively, which incentivized me even more to go about my tactical ways.
I should mention that none of this code was for production purposes. It was merely for demos and to show that I could quickly get something working for a prototype. I have since learned that this isn't the best approach.
As Ousterhout mentions, working code isn't enough. What matters more is understanding the long-term goals (to the best of your abilities, sometimes long-term goals aren't clearly defined) and producing a design that works. If we're being honest, writing most code is easy; it's the ideas behind the code that can be complex. I think this is especially important in the age of AI-enabled coding. Nowadays, with various AI coding tools, you describe the general outline of what you're trying to do and get a good template back from an AI. Of course, this code isn't going to be perfect and should be thoroughly checked by human engineers. It just makes "tactical tornadoes" look less effective because anybody can produce lines of code with the help of AI.
The addition of AI pair programming has been neutralizer to my tactical tornado ways.
A better image from Sora.
Solution
There is a balance between aimlessly working on something to get a working prototype and strategically working toward a solution. Over time, as you iteratively plan and design, you make small improvements and understand more about what you're trying to build. This is the point Ousterhout makes for this topic. I'm continuously learning this lesson in my professional work. Documenting and planning are now even more important now that developers have AI to help with coding tasks.
I'm still applying myself to learning more and working on diverse projects. I have just learned to take a minute to think about what I'm doing. This includes thinking about the goals of the work, how it applies to the product and business goals of my team. I have not fully defeated my tactical tornado urges, but it is substantially less of a problem moving forward.