Hacker News Reader

Comment by bongodongobob | Hacker News Reader

Knowing when to go down the rabbit hole is probably more about experience/age than anything. I work with a very intelligent junior that is constantly going down rabbit holes. His heart is in the right spot but sometimes you just need to make things work/get things done.

I used to do it a lot too and I kind of had a "shit, I'm getting old" moment the other day when I was telling him something along the lines of "yeah, we could probably fix that deeper but it's going to take 6 weeks of meetings and 3 departments to approve this. Is that really what you want to spend your time on?"

Like you said, it's definitely a balancing act and the older I get, the less I care about "doing things the right way" when no one actually cares or will know.

I get paid to knock out tickets, so that's what I'm going to do. I'll let the juniors spin their wheels and burn mental CPU on the deep dives and I'm around to lend a hand when they need it.

View on HN

However, you have to overdo it a sufficient number of times when you’re still inexperienced, in order to gain the experience of when it’s worth it and when it’s not. You have to make mistakes in order to learn from them.

When it's worth it and when it's not seems to be more of a business question for the product owner. It's all opinion.

I've been on a where I had 2 weeks left and they didn't want me working on anything high priority during that time so it wouldn't be half finished when I left. I had a couple small stories I was assigned. Then I decide to cherrypick the backlog to see how much tech debt I could close for the team before I left. I cleared something like 11 stories out of 100. I was then chewed out by the product owner because she "would have assigned [me] other higher priority stories". But the whole point was that I wasn't suppose dto be on high priority tasks because I'm leaving...

Why product owner? (Perhaps rather not say team lead?)

Are these deeply technical product owners? Which ones would be best to make this decision and which less?

In a non-technical company with IT being a cost center, it seems that the product owner gets the final say. My TL supported me, but the PO was still upset.

The product owner often isn’t technical enough, or into the technical weeds enough, to be able to asses how long it might take. You need the technical experience to have a feeling of the effort/risk/benefit profile. You also may have to start going down the hole to assess the situation in the first place.

The product owner can decide how much time would be worth it given a probable timeline, risks and benefits, but the experienced developer is needed to provide that input information. The developer has to present the case to the product owner, who can then make the decision about if, when, and how to proceed. Or, if the developer has sufficient slack and leeway, they can make the decision themselves within the latitude they’ve been given.

Yeah. The team agreed I should just do the two stories, which was what was committed to in that sprint. I got that done and then ripped through those other 11 stories in the slack time before I left the team. My TL supported that I didn't do anything wrong in picking up the stories. The PO still didn't like it.

Regardless, these deep dives are so valuable in teaching yourself, they can be worth it just for that.

Have you been asked "why do we never have the time to do it right, but always time to do it twice?"

His response is likely something like "I am hourly contractor, I have howevermuch time time they want", or something with the same no long gives a shit energy.

But their manager likely believes that deeper fixes aren't possible or useful for some shortsighted bean-counter reason. Not that bean counting isn't important, but they are often cout ed early and wrong.

Yeah don't get me wrong, I'm not saying "don't care about anything and do a shitty job" but sometimes the extra effort just isn't worth it. I'm a perfectionist at heart but I have to weigh the cost of meeting my manager's goals or getting behind because I want it to be perfect. Then 6 months later my perfect thing gets hacked apart by a new request/change. Knowing when and where to go deeper and when to polish things is a learned skill and has more to do with politics and the internal workings of your company more than some ideal. Everything is in constant flux and having insight into smart deep dives isn't some black and white general issue. It's completely context dependant.

"yeah, we could probably fix that deeper but it's going to take 6 weeks of meetings and 3 departments to approve this. Is that really what you want to spend your time on?"

This is where a developer goes from junior to serior.

Reply on news.ycombinator.com