Rohan Ranade

Today, I want to talk about a silent killer of software engineer reputations — bad coding hygiene.

I’ve seen it happen over and over again. A new engineer joins the team, eager to start strong. They dive into the code, push a few commits, open their first pull request… and then it hits. Reviewers look at the code and find a mess: test cases that don’t follow naming conventions, i and j used as variable names, dead code hanging around like forgotten leftovers, unformatted blocks of logic, and the classic — TODOs that scream “I didn’t finish this but please merge anyway.”

Now here’s the thing: none of these issues are rocket science. They’re not even “hard” problems. These are the little things. The basics. And yet, they leave a big impression. Not a good one.

Why does this happen?

Sometimes it’s because the engineer came from a place where no one cared (surprisingly I have observed a pattern here — early stage startups where founders over emphasized “moving fast”). They weren’t used to teams that hold high bars, so they think these “little things” are just unnecessary ceremony.

Other times, they just don’t bother reading the docs or understanding the conventions already in place. They get their task, write code in a vacuum, and call it a day — not realizing that the team sees more than just functionality. They see craft.

And then there are the “I only care about my task” types. These engineers slap their changes into the codebase with zero awareness of what’s around them. Their PRs not only break hygiene — they break cohesion. And if you look deeper, their work often shows bigger problems: poor design choices, fragile abstractions, and code that doesn't feel like it belongs.

And finally, some folks just think, “That’s what reviewers are for, right?” Nope. Reviewers aren’t your personal quality assurance team. They’re collaborators, not cleanup crew.

How does the team respond?

On healthy teams, this kind of behavior gets flagged right away. It comes up in PR comments, in 1:1s, maybe even escalates if needed. And that’s a good thing — teams that care about quality should hold the bar.

But on teams where management is distracted, overly political, or simply doesn’t want to rock the boat? It gets brushed aside. That’s when the rot sets in. Quality slips. Trust erodes. Morale drops. And soon, the team starts normalizing mediocrity.

Why it matters

If you’re a new engineer, here’s the real talk: **you are building your personal brand from day one **(HT to Adan Amarillas who introduced me to this concept of an engineer’s personal brand). Your teammates are watching — not because they’re judging, but because they’re learning whether they can count on you. Can they trust your code? Will you leave things better than you found them? Do you care?

If your first impression is “I don’t bother with the basics,” then don’t be surprised when you don’t get the meaty projects, or when feedback about your work is lukewarm. You’re not just writing code — you’re telling your team how seriously you take your craft.

And if you’re a manager, here’s your part: don’t ignore this. If someone’s not willing to do the little things right, why would you trust them with the big things? Protecting them, excusing them, or just staying silent doesn’t help them — and it definitely doesn’t help your team.

Clean code isn’t about perfection. It’s about respect — for the craft, the team, and the product. And it’s one of the easiest ways to show that you give a damn.

Ultimately, you are what you ship.