Hacker News Reader

Comment by tomschlick | Hacker News Reader

That's why you stop asking permission to make quick fixes and just submit the PR. Obviously there is a balance here but if you can't "steal" a few hours in a week from the product driven roadmap to do so then there is something wrong in the engineering culture.

View on HN

Absolutely. If something is oddly slow, I run the profiler to see what's going on. If the profiler shows me something boneheaded like this that is a big win to fix, I fix it. Obviously I make sure the tests still pass, but then I check it in. If someone is going to give me shit for improving the product, that is not somewhere I want to work.

The boy scout "leave it better than you found it" mantra has always served me well. Hell, sometimes that small fix can lead you down a rabbit hole that uncovers fixes to larger problems that have been plaguing an app for an eternity.

What of those odd stories where somewhere else in the code another dev realized the segment of code was doing strange things and create a work around that now breaks because of the cowboy anything goes attitude changes? Usually with comments talking about it "being very weird to do this, but it works"

If the tests dont fail thats not my problem.

Do any orgs explicitly ask the engineers themselves decide how to allocate a certain percentage of story points in a given sprint?

Product people are great for selecting which features to build out and which bugs to address, but are poorly equipped to decide how to prioritize things like: performance optimizations, bugfixes that haven't (yet) been reported by the end users, code refactoring, paying down tech debt, modernizing tooling, misc quality of life improvements for the engineering team, etc.

My last org did exactly that. The team lead that runs sprint planning was always an engineer. Product management is still there for direction and context, but the decision maker was always an engineer. I don't think this is particularly special way to do it, but I might be wrong.

My first job worked like that. We explicitly had a 25% stream of technical improvements. It worked pretty well.

Same. When I was a team lead I always pushed for 30% of all story points being for maintenance / tech debt that product couldn't touch.

Ask for forgiveness not for permission. Whole heartedly agree.

>That's why you stop asking permission to make quick fixes and just submit the PR.

If the company pays me to close tickets and Jira stories, why should I care about improving its products?

If the company pays me to actually improve its products, then sure, I would do that.

Because the existence of the problem bothers you implicitly. Or because it’s usually a good way to a promo

Usually for perf issues like this, you and your colleagues also suffer. It is not just the time you lose waiting, but you also drop out of flow/get distracted and your productivity suffers more. The end user gains are just a side benefit.

The solution is for ICs to stick their necks out, go over the product manager's head, and ignore the org chart? Not get a new product manager who cares about the product?

The product manager shouldnt be the boss of an engineer. Thats what engineering managers are for. Product / Eng managers work together to set goals of what they want done, it shouldnt include how they want it done, and exclude potential side fixes. Thats how you kill the morale of an engineering team.

I agree with Tom: a well functioning eng org allows engineers to fix critical bugs without going through a bureaucracy. This empowers the engineers and makes them a product owner as well, though you need good engineers who care.

If you force every little bug to go through the product manager, you take time away from the PM to do big picture things by forcing them to track every little thing that's broken, and create a lot of friction for even the littlest bug to be squashed. This fosters an eng culture of "not my problem," which leads to bugs slipping through the cracks for years.

Reply on news.ycombinator.com