undefined | Better HN

0 pointsIshKebab1y ago0 comments

Yeah.. I think the problem is when product dictates what is going to be implemented without asking developers if it's feasible. It happens.

At the other end of the scale there are many programmers who are in the habit of making up bullshit technical reasons why something can't (or shouldn't!) be done when the real reason is they just don't want to have to do it.

Often they'll resist doing a useful feature because it can't be done perfectly. For example we can't report browser tab memory usage because some memory is shared between tabs so the numbers wouldn't make sense. I used to do that until I had a manager that changed my view.

0 comments

friendzis1y ago

> I think the problem is when product dictates what is going to be implemented

I don't think of that as a problem, that's one of the primary goals of product. Problems (yuuge problems) arise when product also gets to dictate cost/timelines. Sorry, that breaks basic management principles.

> I used to do that until I had a manager that changed my view.

Small, young teams (e.g. startups) can easily do without management, because communication is unhindered and ad-hoc. The more organization expands and matures, the more communication suffers. That's the primary goal of engineering management - facilitate conversations. When I have a request that is tad too technical I always try to backtrack and ask what's the business goal. I am 99% certain "display memory usage per tab" is not the business goal. "Find resource hungry tabs" sounds like a good candidate for a business problem.

"Customers" (e.g. product) tend to be "helpful" and provide technical implementation details, diluting the business problem, while engineering tend to fixate on those implementation hints as if they were technical requirements. Ever noticed how technically inept product managers/owners sometimes tend to be good managers? Well, they are either aware of their technical ineptitude or are inept so much that they can't even express technical details and form their requirements as business questions which leaves implementation details open and allows engineering to implement things "correctly". It's magical how simply communicating on appropriate abstraction level can lead to awesome results as each team can focus on what they are strongest at.

pjc501y ago

Some of this is what stackoverflow calls an X/Y problem; someone has a problem, got halfway down a route to a solution, and now is talking to you. It can be quite difficult to dig down into what the actual original problem was, then persuade them to back up and pursue what is in your opinion a better solution.

hackernewds1y ago

How and what did your manager change your view to?

IshKebabOP1y ago

Very briefly, I resisted implemented features that wouldn't work perfectly. The memory use example was a real one (I was working on a profiler of some complex AI hardware). My boss would say things like "can we report how much memory this operation uses", and I would say "no because some of it is shared with other operations or only live for part of the program run etc.".

He didn't really say anything to change my mind, he just kept asking for things that would be useful to customers and eventually I realised that even if we can't give an answer that makes perfect sense or doesn't work all the time, we can still do better than nothing. Very often something that is roughly right and can be shown some of the time is better than something that doesn't exist at all.

It kind of sounds obvious when I put it like this, but you'd be surprised how often you see "we can't do this very useful thing because <minor flaw that means it won't always work perfectly>".

j / k navigate · click thread line to collapse