High performing engineering teams continuously raise the bar for technical quality. Previous technical decisions are likely to not meet the current technical quality bar. Closing the gap between the two helps address tech debt and adopt a growth mindset about the team and codebase. All teams that are improving quality will notice the gap and that is to be expected. Failure to close that gap leads to more tech debt.
Read Managing technical quality from Lethain.
See also:
Links to this note
-
With so much emphasis on productivity these days, an underappreciated problem is work avoidance—not doing what you should be doing because you are doing something else. This is particularly sinister because there is often too much work to do in any given day and we reduce anxiety with activity.
-
The Line Between Micro Management and Leadership
When things are going poorly, a natural response is for managers to get closer to the details. This can come across as micro management to others and they can be defensive about it. There is an important difference between micro management and leadership.
-
When building systems that require monitoring and alerting, a false alarm should be treated as a bug. If it’s not resolved quickly, it diminishes the usefulness of the alerts and trains responders to ignore it. When alerts are ignored, the potential for an actual incident increases along with the severity due to time to detection.
-
As software grows, patterns and practices naturally evolve. Inevitably, someone comes to the conclusion that a change should happen and code should be migrated to the new thing.
-
Linters Automate Quality Control
Using linters on a codebase is a way of automating quality control. It frees up time for engineers by shifting the meticulous checking for minor details to the linter instead of code reviewers. It also helps the engineer writing the code to get faster feedback directly in their text editor.