Live data from Hacker News

The hardest part of being a junior developer

rachsmith.com

41–50 of 82 posts

Re: The hardest part of being a junior developer

#41
post #26

I solved this problem, quite well, and still do this all the damn time: 1) try to solve the problem 2) Gee, it's hard. shit. okay think think think 3) okay ask for help. wait... let's write a slack message. First write the problem, explain exactly what you tried, and ideas for next attempts. Explain your confusions. 4) OMG I SOLVED IT or 4a) Hit send. I find that 70% of the time, I don't hit send. 30% of the time it…

I have an additional trick - If you are the person of whom help is frequently asked, employ a nominal delay before you get into it. "Sure - let's get on in 5 minutes" I've found this to work well. "hang on I'm going to try 1 more thing". And, then you don't hear from them until tomorrow.

I found this in a non-development role, this lady would constantly phone me for 'help' and I found that if I just ignored her (in a nice way) she'd fix it herself in a few minutes.

Re: The hardest part of being a junior developer

#42
post #21

Setting explicit time frames is really useful for both the mentor and mentee (or manager and employee etc). If someone is unable to complete a task within a set time, but explains their thought process and what they tried , I consider that to be a completely valid use of their time. Even if they are completely honest and say: "This seemed too hard and I tried for the first 15 minutes and then got bored and procrastin…

Did I miss something? I didn't need excuses to manage my classes or social calendar. I wasn't great at either, maybe I should have used excuses to dodge consequences and get better grades and be more popular?

Re: The hardest part of being a junior developer

#44

I had a mentor at my last job who clearly really didn't want to be one. It was to the point that I would sit paralyzed behind him, loathing turning around to get his help. In all fairness, I had yet to learn a good way to get help without interrupting his hard work. I'm not sure he ever fully knew he was my mentor, but without his help I was completely blocked on making any progress on the deep-end project I was thro…

> "X is your mentor. X's main job is to mentor you and help you swim in this deep end."

I don't think that will ever happen, nor should it. No ones main job should be to mentor someone else. The best teams all help each other. Early and often.

Re: The hardest part of being a junior developer

#45
post #6

This one hits home for me. Early on in my career, I had a "mentor" tell me to try it on my own before asking any questions only to swear under his breath when I messed up. It was a massive source of anxiety balancing between asking a question and the risk of messing up. When working with junior engineers nowadays, I go out of my way to let them know that any question at any time is acceptable. I'll put down what I'm…

>Early on in my career, I had a "mentor" tell me to try it on my own before asking any questions only to swear under his breath when I messed up May I ask how long ago this was? Although shit colleagues and shit workplaces still exist, it feels like these days it would be shut down pretty quick by HR in the average company.

Call me skeptical. In 20 years, I've only seen HR only get involved for hiring and firing. You'll be lucky to hear from them for anything else, maybe for benefits renewal or a DEI seminar.

Re: The hardest part of being a junior developer

#46
post #21

Setting explicit time frames is really useful for both the mentor and mentee (or manager and employee etc). If someone is unable to complete a task within a set time, but explains their thought process and what they tried , I consider that to be a completely valid use of their time. Even if they are completely honest and say: "This seemed too hard and I tried for the first 15 minutes and then got bored and procrastin…

[flagged]

Re: The hardest part of being a junior developer

#47
I'm a junior developer in senior developer's clothing and asking for help is one of the hardest things. That strong feeling of "I should be able to do this by now" often spirals out of control. "I'm stuck" --> "I should ask for help" --> "It's been a week and I've done nothing" --> "This feels so bad I'm just gonna futz around on the internet". It's a hell of a cycle.

Re: The hardest part of being a junior developer

#48

Earlier quoted context omitted.

I have seen HR get involved in situations like this zero time in my career. I wouldn't want them to either.

That depends IMO. Is the "mentor" really the "manager?" If someone with power over your performance evaluations and future at the company is swearing under their breath every time you do something wrong, that's a problem that HR maybe should be involved in.

Someone who needs to be on a performance plan expects HR to force coworkers to be more patient? Sounds about right

Re: The hardest part of being a junior developer

#49
One thing that makes this much harder is the slippery slope that turns standups into status meetings.

I once had to forbid the manager from coming to the standup in order to get my team to start saying "I'm struggling with X" instead of "Look at me, I did Y" where Y is a rephrasing of what they did yesterday.

Re: The hardest part of being a junior developer

#50

I wish developers talked and asked each other for help more. Not just juniors but seniors too. This idea that we're all supposed to solve problems in a shared code base completely independently and we're wasting time helping/asking for help is poisonous. Things get solved lot faster when someone comes in with a different perspective. And it keeps communication going. Of course maybe everyone else is a lone genius and…

Agreed, but this is a cultural issue, which has a lot to do with management constraints. I've worked at places where everyone is teaching everyone else at all times, and therefore where everyone grows, year to year. But in those places, there was very little practical competition among developers. They where either all consultants, or they expected their results to have more to do with team performance vs individual performance.

On the opposite situation, when programmers are stack ranked, or where it's otherwise clear that they should be playing zero sum games, nobody asks questions, and nobody answers them if they are asked. Tasks that are important enough to lead to chances of advancement are fought over. Everyone wants to build infrastructure for other teams, but using other team's infrastructure is admitting that they are going to get the up level and not you. In any of those world, every programmer is an island, and people get better far slower.

Only in the middle, where there are few incentives, one can change a culture from one side to the other. In those cases, it's easier the more senior you are: No better way to get juniors to ask for help when they see seniors asking for help in public. Many a senior engineer is not socially aware enough to try techniques like that though.

Post reply on HN