Are you a software archaeologist?

I call a software archaeologist the developer who spends much of their time digging through the code to find a bug or the perfect spot to add a feature.

In many cases, we spend more time looking for where to act than actually coding. In large, complex systems — sometimes poorly designed — this becomes tedious and demotivating. You get bored, you lose time, and the team’s velocity drops.

A few ways to dig less

• Keep documentation clear, organized and up to date.
• Add relevant comments — without overdoing it.
• Reduce technical debt as soon as possible.
• Take the time to do good code reviews.
• Use the same terminology as the domain experts in the code (see Domain Driven Design).
• Stabilize the team and limit turnover.
• Rely on go-to people who know both the functional and the technical sides.
• Remove useless features: they always end up causing confusion.
• Encourage exchanges between colleagues, so no one spins in circles too long.
• Write code that introduces as few bugs as possible. TDD helps a lot: tests serve as documentation and can be replayed at will.

Less time digging means more time creating — and a far more motivated team.