psidev in 
Full Stack a year ago
Velocity over Quality?
I've been a SWE about 13 years now, my last few roles have been sort of a let down or at least smoke and mirrors until I walk in the door. They all talk about high standards and are looking for someone to champion quality, yet it ends up being another time crunch chopppng block. I'm starting to lose my passion for this and I'm no longer hopeful of finding a job that I can be happy with.
It is always, what can we sacrafice to push a release out or just do it quick and dirty then throw a note in the tech debt back log and keep pumping out tickets and to yell with testing/code coverage.
Again today I had a boss compare me to a less experienced teammate saying that I should strive to be more like him - since by the numbers he is delivering "more value". When he is just working JIRA to his advantage making tickets for every line of code or minor change and cranking them out with no regard for performance, quality, or testing (bypassing quality gates). While I am given large epics and spikes, deliver full code coverage.
Do i keep hope alive that a better role will come?
Do I just give in and start turning out sub par work at a higher velocity?
Anyone else experience this? How have you dealt with it?
25
6719
13
tmilewskiSoftware Engineer a year ago
I should clarify, there’s a definitely a middle ground of “good” code.
It might mean that the test coverage is lacking a bit, or the performance isn’t O(1), etc., and that’s totally fine.
Every team’s understanding is different, but there should be standards set and upheld. Without them, you tend to be bound by the lowest common denominator.
It might mean that the test coverage is lacking a bit, or the performance isn’t O(1), etc., and that’s totally fine.
Every team’s understanding is different, but there should be standards set and upheld. Without them, you tend to be bound by the lowest common denominator.
6
About
Public
Software Engineer
Members
79,776
The team was junior, and the early more-senior members were mid (at best).
No code coverage, *no* understanding of Big O, N+1, SOLID, circular dependencies, and most importantly, no (at the “senior” level) desire to learn or implement.
The seniors were PR rubber stamps and, in some cases, would merge other’s PRs, at-will and potentially unfinished.
Sure enough, this led to a bloated front end, poor architecture, performance problems (hardly at scale), no separation of concerns, forced large refactors, and countless bugs experienced by users.
Bugfix Driven Development. Hard, hard pass.
I’m focusing on companies with at least some open-source presence to understand their coding practices. Is it perfect? No, but it’s better than nothing.
I’d love to normalize companies showing rather than just telling.