Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sometimes you're right. Do you think you're right all the time? Do you think the more senior guy should know when it is one situation (when the more senior guy knows) and when it is the other, where the more junior and more involved guy knows?

You're making a black and white rule. The black and white rule I'm advocating is that the boss should know when it's black (intercede) and when it's white (let their good v. subjectively interpreted better decision stand).

Of course, the counter-argument is that it's better to let the junior person make their own mistake and learn from them. And it is! Some/most of the time. But some some of the mistakes might cost too much and need to be avoided.

If you think my mentality is Dilbertesque, go ask your supervisor what kind of decisions they wouldn't let you make.



"If you think my mentality is Dilbertesque, go ask your supervisor what kind of decisions they wouldn't let you make."

Maybe this is a little too personal for me.

Never been a manager, don't really want to be one. But I have been a developer for a long time, so I often have as much or more experience than my supervisor at this stage of my career.

The anecdotes that stick in my memory, is when I knew the right decision, explained the rationale for the right decision...and my boss made the wrong decision, without being able to explain why his decision was better. I distinctly remember one incident where, several months after going with my boss's decision, which turned into a bug generating maintenance nightmare, my boss ruefully smiling at me and saying "Yea, I think we should have done (jimbokun's original idea)."

Yea, thanks, now we're wasting who knows how many hours on the fallout of the original decision.

I appreciate those who are willing to take on the hard job of management, and OK with them potentially making more than I do. But good managers find and hire people who know how to do their job and let them do it. So if a manager has an inclination to change something, they should first assume they are wrong and their subordinate is right, ask the person doing the work to explain how they made their decision, ask for clarification if the manager still thinks a change should be made, and only then suggest the change if there is something clearly and obviously wrong with the reasoning behind the decision, making sure to explain the reason for the change.


I agree with both late2part and you.

I saw late2part situation happen a lot of times: A junior dev find a quick an elegant way to solve problem X. Senior dev comes and say: It's good but you should do it that way because it <will be more testable / require less maintenance / any advice only someone with more experience on the product's codebase can tell>

If the senior dev is bad / doesn't have time at the moment, he will skip explaining the "because" part, and the junior dev might be frustrated. With good communication a good faith from both parties, the junior would later understand.

The manager anecdote "my boss made the wrong decision, without being able to explain why his decision was better." would be a different situation, and in that case, that manager should definitely have kept his opinion for himself. At least he recognized his mistake later on.

So 2 stories: One where the junior dev is too "know-it-all", one where the supervisor didn't put enough trust in his subordinates.


If it's not important enough for you to explain the rationale, don't bother giving someone the feedback.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: