My thought on this as a senior developer who wants the junior developers to become great and amazing developers:
Please ask another person fast!
Don't sit it there and get frustrated and almost tilt.
I ask my juniors probably at least once every 2 hours if they don't have me anything to ask.
Usually, it is easier to talk through the problem with another person. The rubber duck method is excellent but the rubber duck does not calm you down or asks questions back.
I agree with most of this, but I would caution junior devs on not looking to someone else to give them the answer right off the bat. Fighting through a problem yourself, even getting frustrated, is actually a good thing (even though it isn't pleasant). I learn more from those situations than I do from when the answer comes easily. (The frustration itself helps ingrain it in my memory!)
In other words, when you ask for help, you should be ready to tell them What You Have Tried.
I don't tell them just the answer.
I never give them the answer.
At some point, they went the wrong path and I just guide them back to the point where they made the error and then guide them on the right path to the solution.
So I ask them what the problem is and let them explain. This helps them to get the frustration out. Then I ask them what they think is the problem. Then we try their solution together and usually it does not work. So even if I by this point know the solution I will ask them what they will do next and why and so on. I hope you see the pattern.
If they then tell me that they googled for 2 hours and were sitting there for 2 more hours frustrated of course I will help them. At this point, something went wrong completely.
And yeah I tell them that frustration is part of the job also part of the fun to solve the problem :)
Gentoo Linux and VIM worshiper, C developer, network protocol dissector implementer,socket/network programmer, recently entered the embedded world, hater of buzzwords and made up titles
Gentoo Linux and VIM worshiper, C developer, network protocol dissector implementer,socket/network programmer, recently entered the embedded world, hater of buzzwords and made up titles
I was taught the 20 minute rule and it's been really helpful. Basically when you're stuck try everything you can think of for about 20 minutes. Google stuff, try stuff, try to talk it through on your own... and if you're still stuck ask for help. I usually try to spend 5 minutes making sure I can accurately explain the problem to the person I'm asking.
It's been a huge thing because it's easy to just ask for help without trying yourself and it's also easy to sit there feeling like you haven't struggled enough to justify asking for help yet.
My thought on this as a senior developer who wants the junior developers to become great and amazing developers:
Please ask another person fast!
Don't sit it there and get frustrated and almost tilt.
I ask my juniors probably at least once every 2 hours if they don't have me anything to ask.
Usually, it is easier to talk through the problem with another person. The rubber duck method is excellent but the rubber duck does not calm you down or asks questions back.
But another human can do this.
I agree with most of this, but I would caution junior devs on not looking to someone else to give them the answer right off the bat. Fighting through a problem yourself, even getting frustrated, is actually a good thing (even though it isn't pleasant). I learn more from those situations than I do from when the answer comes easily. (The frustration itself helps ingrain it in my memory!)
In other words, when you ask for help, you should be ready to tell them What You Have Tried.
You are 100% right!
I don't tell them just the answer.
I never give them the answer.
At some point, they went the wrong path and I just guide them back to the point where they made the error and then guide them on the right path to the solution.
So I ask them what the problem is and let them explain. This helps them to get the frustration out. Then I ask them what they think is the problem. Then we try their solution together and usually it does not work. So even if I by this point know the solution I will ask them what they will do next and why and so on. I hope you see the pattern.
If they then tell me that they googled for 2 hours and were sitting there for 2 more hours frustrated of course I will help them. At this point, something went wrong completely.
And yeah I tell them that frustration is part of the job also part of the fun to solve the problem :)
Gentoo style 😏
Now I'm thinking what would be Arch Linux style 🤣🤣🤣
Like Gentoo but from a lower hanging branch 😁
Haha yeah your right 🤣
I was taught the 20 minute rule and it's been really helpful. Basically when you're stuck try everything you can think of for about 20 minutes. Google stuff, try stuff, try to talk it through on your own... and if you're still stuck ask for help. I usually try to spend 5 minutes making sure I can accurately explain the problem to the person I'm asking.
It's been a huge thing because it's easy to just ask for help without trying yourself and it's also easy to sit there feeling like you haven't struggled enough to justify asking for help yet.
You are right! You should struggle for a little bit!
Give that brain some work :)
Just don't tilt!
For some people, it is hard to find that line where they tilt.