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

> I think you learn the most when you steam train into something and get stuck - then figure out how to get out of it.

Warning: Please don't apply this to _other_ people who say they need help with something. If someone comes to you with a problem they say that they are stuck on and can't figure out, please don't respond solely by giving them encouragement to just keep plugging along. Either encourage them to find someone else with time to listen or give your time to listen.

1. It feels incredibly _isolating_ to be told something like, "Thats just imposter syndrome. I'm sure you'll figure it out."

2. It is much harder to focus and succeed when you're trying to push yourself down a path you think is probably fruitless.

3. It is much harder to solve problems when you don't have a sounding board. When you can have conversational space to teach someone else about the problem space, paths open up.



Yeah, the first question I ask is usually :

"Describe me what you did."

Which allows one to judge whether they are truly stuck or just need to plug at it some more... not to mention all those times when they realize the mistake they made while explaining the problem to you !


I agree. It also filters out all those people who didn't put in effort and want to use you as their personal "Google".

I love to help people. I esp. appreciate the ones that up front tell me what they already did and tried. I had a great colleague once - I loved to help her, because I always knew that she came to me, when she was truly stuck and did not know what to do after trying everything that she could think of.

And she was able to succinctly tell what she did so that I was able to narrow down potential causes/solutions quite efficiently.

Contrast that with another former colleague who when getting stuck alawys came to me first thing to ask me, if he could just ask a short question. Even in moments when I was clearly deep in concentration and clearly signaling that state. It was always urgent and he never put in any effort to solve the problem himself first.


Indeed!

"What" questions that calmly ask for a list are often really good because they are easy to answer if you know the information. And if someone doesn't know the answer, it prompts them into the good habits of:

1. Doing some work before interrupting someone with a question.

2. Writing down their steps as they do so.

Other good ones are: "What are some questions that come to mind" and "What are some paths forward that seem plausible?" to help those who are

1. At a crossroads.

2. Having trouble articulating that they are afraid of going down a rabbit hole.

I'm still looking for a good question for helping those who are totally lost without a mental model that lets them put words to the domain.


My first 'real job' as a developer at MSFT. My manager would respond to any problem I was having with 'What have you tried'. Internalizing that question has made me a much better developer that gets 'stuck' much less.


I've had some good experiences encouraging people to push on, especially when i suspected that they suffer from imposter syndrome. Probably there is no absolute truth here.


It's nice that your experience was great.

> no absolute truth here

Correct, which is why listening is important.

It is how to know the experience _of the person you encouraged_.


> 2. It is much harder to focus and succeed when you're trying to push yourself down a path you think is probably fruitless.

This is actually the big one. Validation that they are making progress allows people to go back to banging on a problem.

If one of my senior engineers claims to be stuck on some technical problems and comes to me asking for extra technical advice, we're probably going to spend some time digging at things. That's the realm of sounding board.

However, I may have given an assignment to an intern specifically so that they will go learn something that I think they need to learn by working it out. If they come to me, I'll give them some limited advice, validate their progress to this point, but I'm probably going to send them back and tell them to bang their head on it some more. One of the lessons junior engineers need to learn is "Sometimes the senior guys don't actually know the answer and part of your work is actually figuring it out."

And sometimes the task really is just a slog. Too many junior engineers think everything can be made "easy and quick" like a textbook question. However, if someone is slogging via brute force and comes to me I'll look at it and say something like: "Yup, you seem to be going the right way. And it looks like you're about 10% done. Keep going."

The validation that they're not going down a blind path is the most important thing.


> One of the lessons junior engineers need to learn is "Sometimes the senior guys don't actually know the answer and part of your work is actually figuring it out."

100% agreed on this.

I just think we should be doing more to put 'how and when to start a sounding-board conversation' in the toolbox of Junior Engineers.

> "Yup, you seem to be going the right way. And it looks like you're about 10% done. Keep going."

Agreed.

On top of that: "Here are signs of progress to look for" or "Here are ways to detect signs of progress".


As you mention, this is for a person to apply themselves and my original comment is not meant to be applied to others.

Regarding your points:

> "Thats just imposter syndrome. I'm sure you'll figure it

> out."

But they should be encouraged to at least try to find a solution (depending on the scenario). If it's simply "I do not know how to do X" and I ask "have you looked at Y", if the answer is no then this is something they should do. Maybe there is no solution there either, but it is something they should explore so we can have a discussion about that.

> It is much harder to focus and succeed when you're trying

> to push yourself down a path you think is probably

> fruitless.

Well, that is also where the maximum reward exists - when you think something is impossible and then you discover you are able to do it. If nothing else, you gain a better ability to judge what 'fruitless' looks like when considering problems.

> It is much harder to solve problems when you don't have a

> sounding board.

Sure, but it also robs you of a learning experience if you are always relying on other people to guide you through solving problems - and it can be exhausting for the person that has to guide you. So it should be something that is not used common place.

For example, you could ask "off the top of you head, do you know how to do X? If not I'll consult Y...". Maybe they have some pointers for solving X, but you're also saying that you're willing to investigate using method Y.

Ultimately, if you have little risk, you have little reward. You can easily setup a scenario where they try to solve their problem, but don't get stuck for too long. For example, send them off and check up on them half hour later: "any luck solving X yet?", "have you considered looking at Z?".

Another point to consider when you agree to always help somebody solve problems they make little to no effort to solve themselves is that they are robbed of the learning experience, they have a path where they never have to become self-dependent and you are distracted from some other task.


> If it's simply "I do not know how to do X" and I ask "have you looked at Y"

This is helpful, sometimes enormously so. It may be that the only way they could have heard of Y within 2 years of facing the problem is through conversation. But once they hear the name of Y, they have something to punch into google.

> they should be encouraged to at least try to find a solution

Note that having someone _assume_ you did not try after you've spent hours of effort is also quite isolating.

People who do not first try are indeed frustrating. There is a judgement for junior engineers to learn to exercise here.

------------------------------------------

> it also robs you of a learning experience if you are always relying on other people to guide you through solving problems

Which is why this is a matter of judgement and balance, where extremes like "always" rarely apply.

> it can be exhausting for the person that has to guide you.

Very yes. This is why it's crucial to deny without justification some honest requests from those who need help.

1) So you do not exhaust yourself.

2) So that fear of exhausting yourself doesn't push you to assume a request for help is an excuse and treat another person as if they are lazy.

------------------------------------------

> Well, that is also where the maximum reward exists - when you think something is impossible and then you discover you are able to do it.

1) If.

2) We should aim to recognise the difference between "impossible" and "unimaginably hard".

Impossible problems are a waste of time and we should not encourage people to solve them but instead to be skeptical of impossibility.

Landing a man on was impossible _until_ congress allocated money to have a lot more engineers collaborate. Then it was no longer impossible but did come with many easy, moderate, hard, and unimaginably hard problems.

3) Unimaginably hard problems don't just require focus. They also require de-focus to see odd connections. We should aim to help junior engineers recognise the difference so they wisely decide when to keep banging away and when to go for a random walk.




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

Search: