Don’t leave broken windows

Don’t leave dirty code, even if it works. Coworkers or your future self might follow your lead. Quality is a team issue.

Every time you touch code, treat it like a mini cleanup mission. If something is messy, confusing, or inconsistent, fix it before committing. Even if it works, leaving “broken windows” - smelly code, unclear names, duplicated logic - signals to your team that shortcuts are acceptable. This multiplies over time and drags the whole project down.

In Java, this could be renaming unclear variables, extracting methods, or removing dead code. For example, instead of leaving a long, confusing method:

public void process(Data d) {
    if(d != null) {
        // complicated nested logic
    }
}

Refactor it into clear, readable pieces:

public void process(Data data) {
    if (data == null) return;
    validate(data);
    transform(data);
    persist(data);
}

Even small cleanups count: consistent formatting, proper exception handling, removing commented-out code, and following naming conventions. This principle isn’t about perfection, it’s about setting a standard every time you touch the codebase. It protects your team from technical debt and makes future changes faster and safer.

Before every git commit, ask: “If someone read this in isolation, would it be clear, safe, and consistent?” If not, clean it. Small, continuous improvements build a culture of quality and make your life and your team’s life dramatically easier. Clean code spreads. Broken windows spread too. Choose wisely.