Hacker News Reader

Comment by lumost | Hacker News Reader

TBH this is a double edge sword. It's easy to end up creating the illusion of value by helping many devs when they could have just tried N more things.

As a curious counterpoint, try taking the opposite approach for a bit and only get involved when it is absolutely apparent that no one else can do the job/guide people through decisions. Have junior folks write down what they are about to do in a design, or what they've tried before to help build documentation, design, and debug muscle. You may find that people are more able to run the show than you give them credit for.

View on HN

I feel like many in this thread misunderstand me. Our company follows pretty standard practices. Before anything is worked on, everyone has to write in pretty excruciating detail what is being done, from juniors all the way to our marketing department. Everyone works on the documentation including the juniors.

98% of the questions I get are not about the basics, they are very high-level problem solving questions coming from people that just need clarification or 2nd pair of eyes on something. I mean even I need that quite often and I am very grateful for the help.

> I want you to interrupt me as soon as you need help.

> 98% of the questions I get are not about the basic

How do you know your advice is being followed/ is valuable? I don't think that statistic is relevant. I don't think people are misinterpreting what you said. Its either 1. a tautology: because when they need help, they'll ask. 2. It can be misinterpreted: Ask for help whenever something challenging happens.

Contrary to popular belief, many junior developers are too shy about asking.

or too worried of looking like an imposter!

Life doesn't tend to churn out as a clearly distinguishable statistic. It's messy, and nuanced. So to counter your argument, I don't think that focusing on statistics is a meaningful pursuit in this regard. I think it would be more productive to acknowledge that humans are fallible, and require assistance when working alone. Humans are part of a system, and that system changes. Sometimes it is absolutely necessary to query those making the changes, because those changes have not yet been documented, or the available documentation is lacking.

In a senior role it's important to prioritize your time. If you are dedicating a lot of time to improve a junior's design while they ignore your guidance... you aren't their manager. This problem is compounded when you are a resource for 3+ dev teams, at any given time there will be projects which teams want to go their own way and it's not possible to right the ship without breaking eggs.

> Our company follows pretty standard practices. Before anything is worked on, everyone has to write in pretty excruciating detail what is being done, from juniors all the way to our marketing department.

That's not at all standard, at least not if you're talking about documentation that's actually available in a useful fashion.

Standardized, but not standard

If you don’t hear the weird things your team is trying to do with the code, you don’t know where the holes are or about the giant performance regression they’re working on.

Reply on news.ycombinator.com