I see a lot of programmers move so fast from story to story they forget to listen to the code. They’re too busy programming to create small quiet periods after landing changes to reflect on the state of the code. And that’s too bad, because it is a very useful technique to purposefully step back and listen to what the code has to say, instead of rushing through to work on the next task.
Listen?
I mean set aside a bit of unstructured time to just… go through the code, follow its threads of logic, sense the clumps of structure. Maybe some test-files aren’t really clear, what could simplify them? Maybe some domain-language has leaked through its abstractions, is a refactor in order? Maybe some subsystems are unnecessarily coupled, and it’s time to tease them apart? Creating this quiet moment is a time to play around with the code-structure, maybe try to decouple some intertwined portions, or restructure sections for better flow. It’s a time to strive for equilibrium, to sense areas that are complex and angry compared to the simpler and calm systems that surround them. By focusing on the architecture and robustness of the code, we can prune and refine it to improve its maintainability.
I personally like to put on music for this, because it softens my cognition a bit which surfaces the “feel” of the code, which lets me more easily identify some of the rough edges.
So next time, after a story is done, consider if now is that opportunity to explore the code, to ensure the newly implemented features are not just operational but also understandable and optimized and fits in with the whole. Set the rigid flow of user stories and tickets aside for a moment, and just… take a stroll. Imagine what could be, and try it out 🌱
Top comments (0)