Make Your Codebase a Little Better Every Day

Introduction

I recently came across Sean Goedecke's post on What Can Strong Engineers Do That Weak Engineers Can't?, and I found it to be a compelling read. His thesis is that strong engineers can tackle tasks that others simply cannot. While I agree with much of what he describes, translating those observations into actionable advice that helps one become a stronger engineer is not always straightforward.

Among the many skills an engineer can develop, one mindset stands out to me: proactively make the codebase you contribute to and maintain better. In this post, I want to share a few practical tips to make your codebase better every day.

A Shared Codebase Is Like a Shared Campground

Camping at a well-maintained campsite is a wonderful experience. A clean and organized campsite means you can set up your tent and enjoy nature immediately without worrying about leftover mess. In contrast, arriving at a disorganized and dirty site can be frustrating—you have to clean up before you can even start to enjoy your surroundings.

A software codebase functions similarly to a shared campsite. While each engineer can work independently to ship code, the final product is the collective effort of everyone involved—past, present, and future. Software engineering is inherently collaborative, relying on design discussions, code reviews, and shared knowledge to function effectively. This is especially true for any sufficiently large software project.

When you modify a piece of code, chances are that someone else wrote it before you. Your task then becomes understanding what was built, what the author's intent was, and why certain implementation choices were made. If the original code was not thoughtfully written, future engineers are left guessing about its purpose, how to modify it without introducing bugs, and whether they might trigger hidden landmines in the process.

Strategic Mindset

Some of the best engineers I know approach software development with a long-term mindset. When writing code, they use meaningful variable names, write complete docstrings, and ensure clarity in their implementations. When shipping new features, they aim for minimal, well-structured changes to extend functionality. When introducing major components, they consider not just development costs but also long-term maintenance.

Most importantly, they think about the future state of the codebase—from the perspective of their future selves and teammates. They strive to make the codebase cleaner, even if they don’t refactor everything immediately. They have a keen sense of which parts of the codebase need improvement and take pragmatic steps to address them. They embody the Boy Scout Rule: Always leave the campground cleaner than you found it.

What Strategic Mindset Looks Like

Here's a non-exhaustive list of actions starting today to make your codebase cleaner everyday, using strategic mindset:

1. Proactively Addressing Issues – Instead of waiting for a bug to escalate into a customer complaint or a system outage, proactive engineers fix problems early. They take responsibility for issues, even if they didn’t create them.
2. Thinking Beyond Immediate Tasks – While a typical engineer might implement a feature as specified, a proactive engineer asks deeper questions: Is this the right approach? How will this scale? What are the potential failure modes?
3. Maintaining a High-Quality Codebase – They don’t just ship code that works; they ensure it's maintainable, well-documented, and efficient. If they encounter a confusing or outdated module, they take the time to improve it.
4. Caring About the Developer Experience – They recognize that engineering is a team effort and work to improve tooling, documentation, and onboarding processes to make life easier for their colleagues.

What Tactical Mindset Looks Like

On the other hand, engineers who lack a strategic mindset are tactical by nature. They tend to let problems fester, sometimes allowing them to escalate into significant issues. These engineers often adopt a “not my problem” mentality, leaving inefficiencies, technical debt, and small bugs unresolved until they become intractable. This undermines the collective effort of the team, creating friction and slowing down progress.

Signs of a lack of strategic mindset include:

• Neglecting minor issues because they fall outside the scope of immediate tasks, rather than addressing them as opportunities for improvement.
• Writing code that meets the minimum requirements but lacks consideration for future maintainability, scalability, or integration with the broader system
• Avoiding proactive improvements, such as refactoring, updating documentation, or adopting better design practices, even when they know such changes would benefit the team in the long term.
• Failing to migrate legacy systems or communicate necessary changes, leaving teammates in the dark or users unprepared for migration or system upgrades.

A highly skilled engineer with only tactical mindset can still be a liability to the team. They might write impressive code but leave behind technical debt, make short-sighted decisions, or be indifferent to the long-term health of the system.

Conclusion

Every team should encourage strategic mindset when it comes to software development. Otherwise, the maintenance burden of critical infrastructure often falls on a small group of engineers who deeply understand the system. This increases the bus factor and can lead to burnout and frustration.

Building a strong engineering culture and strategic mindset means fostering an environment where engineers take pride in their work, think about long-term maintainability, and actively contribute to the overall health of the codebase. A cleaner, more maintainable codebase benefits everyone—not just today, but for years to come. This mindset is not just psychology; it’s about contributing to a healthier, more sustainable engineering culture.

When engineers take responsibility for the codebase, they create an environment where innovation can thrive, technical debt is minimized, and collaboration is seamless. So next time you touch a piece of code, ask yourself: Am I leaving this better than I found it?

Bonus

I found the book, A Philosophy of Software Design, extremely relevant to this topic. If you don’t have time to read the whole book (though I highly recommend it), here’s a great talk summarizing its philosophy.