203
Your Engineers Aren't Lazy, Your Codebase Is Punishing Them
(piechowski.io)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 31 Mar 2026
203 points (99.5% liked)
Programming
26725 readers
149 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
I find most bad codebases exist because of a culture that isn't focused on quality, and I'm not talking about bug counts or code coverage. Clean codebases stay clean by being proactive about keeping them clean. This should include meticulous peer reviews, establishing design patterns, enforcing best practices, and taking initiative to leave things better than you found them (we used to call that boy scouting).
If your teams PR comments only contain LGTM, and the average time spent reviewing them is 5 minutes, your team isn't focused on quality. If a PR contains more files than an average person can keep in their mental context window, it won't get the attention it needs to be properly reviewed. If there is no accountability to keep a clean codebase, you'll end up with 2 hours of work taking 5 days to complete.
The signal-to-noise ratio of reviews is nearly zero in my experience. It’s for the least productive people on the team to argue about spaces or gotos or grind other ideological axes.
I find PRs really dumb things down, but not in a way that makes code more understandable. And it certainly doesn’t improve quality.
If your team is only focused on tabs/spaces or soapboxing during code reviews, you have bigger issues to take care of.
Show me a place where this isn’t the case. Because I’ve never seen it not be the case in 20+ years in the field.
15+ years in engineering here. 10+ in leadership.
Code formatting hasn't been an issue since the early '10s. Tabs or spaces? Who cares. Your editor can make it look like whatever you want and it won't effect the code.
As for other asshole-ish behavior or gatekeeping, I open it up to a vote. Let the team determine best practices. Don't like what your team decides? Find another team to shitlord over.
You must work in dreadful places. I've seen it a few times, but most places have been productive.
It needs a good lead dev to set the culture though.
Whitespace change debates can be avoided by using rule sets in IDEs and agreeing standards within the team.
Good static code analysis tools in pipelines and IDEs handle most technical issues leaving reviewers to focus on design, maintainability, clarity and readability.
You can avoid pickiness if you communicate why, so they learn and understand. If you use PRs as a training and learning tool they're quite productive. If not sure, ask why something was done.
And if you get picky comments respond with "personal preference and not part of team rules". But also, you cannot be defensive in your PRS. You have to be open to feedback and points and happy to discuss. Be polite even when feedback is invalid. Defendivesness kills constructive feedback and no matter how old you are and how long you've been doing it, you can still improve. Oh and if you been doing it that long, you're a senior or lead and can influence how things are done.