Listening to the Code

One pattern I often see programmers overlook, is creating quiet periods after cycles of innovation. By stepping back and listening to what our code says, instead of rushing through even more tasks, we can gain numerous benefits.

Listening?

By listening, I mean an unstructured process of perusing the code, following threads of logic, and identifying clumps of structure. Maybe some test-files have a lot of mocks, could a better architecture simplify that? Maybe some elements of the domain-language have become unclear, could they benefit from renaming? It's a time to play around with structure, decouple intertwined portions, restructure sections for better flow, and try some refactorings. It’s a strive for equilibrium, tuning our focus to the architecture and robustness of our code, ensuring its sustainability.

I personally like to put on music for this, because it softens my cognition a bit which lets the “feel” of the code surface more easily.

Is this as exhilarating as introducing ambitious features and making broad strides? To most people probably not, undeniably it's the big features where we have the most impact on our customers so that's a compelling focus. But it's just as crucial to look for opportunities to engage in reflection and to prune and trim the code, because it's this attention to detail that paves the way for future expansions.

So after an expansion phase, take the opportunity to observe and analyze the work, to ensure the newly implemented features are not just operational, but also understandable and optimized. Set the rigid flow of user stories and tickets aside for a time, and just... take a stroll. Imagine what could be, and try it out.

No Hacking

It's important to note this isn't to advocate leaving our code in chaotic, broken states with the promise of cleaning it up later. We always aim for small, incremental changes and going at a sustainable pace. And, the leap and prune process is not strictly linear, we don't mechanically just leap, prune, and repeat in a regimented fashion. We always strive for a balance. But I want to recognize that every change affects the entire codebase, and we don't always land all our small incremental changes in a way that neatly fits into the entire solution, which is why we benefit from occasionally listening to the code so we can better see and understand this interconnected relationship.

Striking the right balance is an invaluable skill, as it involves knowing when to stick to the rhythm of small increments, when to push the limits of the system a bit to cover greater leaps, and when to take a stroll to listen to the code.