Coworkers Producing Shit Code | Hacker News Reader

Coworkers Producing Shit Code

3 pointsGamingAtWork7 comments

hey im a jr software dev, somehow it seems like all my coworkers produce shit code 24/7. They are either trying to get it done as quickly as possible or they are lazy, or they are just clueless. They basically take the entire sprint to fix the new defects their features introduce. At first when I joined the team as a jr I didn't know exactly what their code did, now that I have been working in the codebase for 9 months I can clearly tell the code quality they are producing is just shit. what should I do? Basically their shit code gets through code review with just cosmetic changes, but the maintainability/robustness etc. is usually just enough to meet the AC's the next one to work off their feature is doomed since everything is hard-coded bs copied and pasted from features developed 10 years ago by another shit coder.

View on HN

> what should I do?

Does your team have a manager, a project manager, and/or a tech lead? And do you feel like you can trust them to take criticism and not retaliate?

If so, raise your concerns with them.

If the answer to any of those questions is no, you have two options:

1. Step up and try to lead the team to a better place.

2. Get a different job at a better place.

the team manager is the one who is reviewing & approving the shit code so idk how I can tell them "hey why are you approving shit code ?" I think i will either wait to be promoted or just find a new job but rn swe jobs are pretty hard to get for new grunt developers out of college. I have been coding and developing things since I was in middle school so maybe that's why i can tell that the code is so bad but for everyone else maybe that's just how it is?

It's all in how you phrase it.

"Mgr, I've got some concerns about our code quality. We seem to be prioritizing velocity over quality, and paying for it - X% of our sprints are spent fixing bugs introduced by what we shipped the previous sprint, instead of adding new features. Slowing down will actually increase the speed at which we can ship features, and make us look better to the higher ups as well."

yes I actually tried doing that in the last retrospective. Immediately got attacked by the scrum master and my manager literally couldn't figure out what to say (super indian guy). literally a few days later the entire jira board is full of defects lol.

Then it sounds like option #2 is probably your way out.

Remember when interviewing, don't just shit all over your current job - phrase that well, too. "I'm looking for a place with a more mature software development philosophy, with a higher focus on QA than my team currently has."

Look for another job.

First time?

Reply on news.ycombinator.com