zlacker

Sounds like they need education on several of those points. Code review, and automated tests should be table stakes, not gold plating. Linting doesn't even seem to belong in that list because why would it add to development time?

Refactoring is a bit different in my mind. I often discover better ways to write a piece of functionality while I am writing it. Sometimes it's worth essentially starting over, and sometimes it's not. That decision IMO should be heavily influenced by business deadlines. There are times to push back the deadline because of a major refactor, but they damn well better be a rare exception, and you (and your manager) damn well better be able to explain the business reasoning behind it.

Lumping poorly judged refractors, last minute pet features, and optimizations (actual gold plating) in with critical technical practices like testing and review is probably part of the problem in your organization..

>>darker+(OP)
By refactoring, I mean cleaning it up once it works. But in my managers mind, as soon as the code works it’s good enough. Doing anything beyond that like sensible variable names, comments, making the code easier to read and follow is gold plating. So the second your hacked together development code works, you’re supposed to merge it and move on to the next ticket.

The pipeline stuff is gold plating because it takes longer than two minutes to configure and it then blocks merges and PRs when the code doesn’t pass linting etc (which slows us down right now, never mind that it’ll save a lot of time down the line)

I’m mostly just venting with like minded peers though. At that point, I’ve given up on fixing anything. I’ve tried, it burnt me out, and had no effect. Now I just put my 8h in, get my paycheck, and watch as we’re setting piles of money on fire. You can lead a horse to water etc.

>>ornorn+R2
You are free to approach this as you wish. Know that others have been there before, but most of the industry has moved on from where your organization is now. It wasn't done by digging in heels and expressing frustration, and it certainly wasn't done by giving up.

The truth is, your manager's goals are probably more aligned with yours than either of your realize. Part of growing in your career is learning how to make the connection for other people between these unintuitive things that make development faster and the goals they are trying to achieve. I wouldn't give up on finding new ways to share that understanding. It's called working on your leadership skills.

I'll caveat that there are some cases where it doesn't make sense to do the things you described. Maybe you're working on a prototype, or maybe the cash situation of the business is truly precarious. But if you want people to buy in on change, you need to understand their goals and relate to them on that level. Good luck!

>>darker+Zo
Thanks! This business is doing well, it’s just entrenched in its ways, leadership is old and averse to change. I made my peace with the situation, I’m not interested in becoming a lead or anything and I’d rather save my energy for my life outside of work. I understand this doesn’t necessarily work for everyone, and I hope your replies will be useful to others in similar situation but with more desire than me to change things. Anyway, whatever works!

>>ornorn+hX
That's fair. I don't recommend complaining on the internet about it because it normalizes bad behavior that used to be normal but no longer is in functional organizations. There are lots of younger developers on here who don't know any better, and while we oldsters can stick it out until retirement, their careers will be much more fulfilling if they recognize the capacity to change their environments.