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 procrastinated" that is also ok. We're all humans after all.
Its when someone spends their time on excuses and fobs that is really annoying and unproductive. Generally: most people will invent excuses. People that went to college (I went to college!) get really good at this since you need to invent excuses all the time to get past annoying social activities and classes.
In most cases, providing the space to fail and proceed allows developers to gain the confidence to be upfront. Of course there will always be those that don't get the message, or try to game the system. But they tend to fall really really far behind and it becomes pretty obvious that they're not doing well.
You can bang your head against the latter forever without making progress, especially if it's un/semi-documented, mostly tribal knowledge.
And the best way you're able to guess at it is by prior experience at other companies, which junior developers don't have.
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 was worth asking.
"Sure - let's get on <conference line> 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 also usually give them a starting point.
"Hey I'm in the middle of something. I can chat in 15 minutes or so. In the meantime if you haven't yet, try X, Y, Z"
This helps push them to at least try something so when I ask later "Did you try X Y or Z?" They can have some kind of answer.
The last 10% was simply a theory issue. The reviewer wanted things his way, which would have taken an inordinate amount of time for the feature. I told him that it was unnecessary, and would increase dev time. I was thinking about the entire product process, while he was focusing on how the code should look -- which was purely arbitrary.
He wouldn't waver, and delayed my PR. It eventually was escalated to the head of engineering, who sided with me. It was a trivial feature, and my code was tested and worked -- it just wasn't the reviewer's way of doing things.
Anyway, it got merged as is. But, I can only wonder about how a junior dev may have handled it. Wasting hours of time to conform to a particular senior engineer's arbitrary "way" of doing things -- correctness be damned. As for my own code reviews, I follow a simple process: 1. Can I parse it in 10 seconds? 2. Does it fit the specs? 3. Is it tested? 4. Is it extensible?
What are the useful techniques to deal with such people? Many times, it is just easier to comply to their vague requirements rather than engage in prolonged discussions, as they usually don't have the ability or will to look at things from the other side. I consider escalation to a higher management the last resort.
Does anyone produced some successful strategies to deal with that?
It's just a quirk of his without malice I think, but it does get to me depending on who its in front of. I think he just wanted to be seen as the teacher.
Fairly often, you gotta show confidence and show boundaries.
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 doing and help them through a problem and then celebrate the solution with them. I never want them to feel the fear of work and failure that I did.
I go even further than that. I tell juniors there's literally no way you can screw anything up so badly that we can't deal with it. If they write code that doesn't do what it's supposed to do, and it's not caught in code review, the reviewers are more to blame than they are, because they're supposed to know better. A junior shouldn't have the access level necessary to do something like drop the production database -- that's on their more experienced colleagues to set up those guard rails.
For me, if somebody swore about something I was doing, I’d likely laugh and challenge them to either ask how I’d fucked up or how they’d recommend doing it.
I make sure that anyone in my office who is new or is my junior knows that I’m the person they can always interrupt. People never interrupt too much.
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.
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 I'm the problem. Maybe. But I kind of doubt it.
In one of my previous jobs I had a great relationship with one developer in particular. We've both seen great work from each other so knew we weren't just coasting but it took one of us to just say, hey dude any idea why this isn't building? I took one look and it was something obvious - easy fix and he could move on. That didn't make me feel like a genius, it just made me happy to know there was such trust. He knew I wouldn't judge him and since then the back and forth was super simple. Greatly improved both our work, since now it's also way simpler to ask eachother for input on other things.
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.
I think once you spend enough time in the industry, you learn that even younger/more "inexperienced" people could have better skills or knowledge of certain things (certain types of message queues, certain parts of a network stack, React, etc etc) than someone with more time. It's important to figure out how to balance that. But many people kind of gloss over it or frame it as "well why _don't_ you know this??"
It always feels bad not getting anywhere or even worse having to scrap past work, but not checking with others wastests everybodies time. Other people are waiting on your results even if you never meet them. And if nobody is able to help you can either try to plow through or accept defeat.
What we both needed was the company setting very clear, explicit expectations. "X is your mentor. X's main job is to mentor you and help you swim in this deep end." Though I think the entire company was learning a ton of stuff at that phase.
Thanks X for all your tolerance over those years. You have no idea how much you saved me, despite my loathing to bother you yet again.
It's been a while since I've mentored someone, but that was always one of the things I made sure to mention in my first conversation with any interns/new grads I'd mentor: "While you're here, mentoring you is the highest priority thing for me to do. If there are ever any times when I have something so time sensitive that it would take priority over answering your questions, I will explicitly let you know. Otherwise, always assume that it's okay to ask me something, because if for some reason I can't answer and you don't know that, it's my fault for not telling you." It helped that the company where I worked at the time had very explicit time periods where someone was considered a "new grad" versus a full team member (since they actually would rotate on 3 teams before ending up on one of them full time), so this strategy might not work as well in places where the expectations for mentors are not laid out as well, but I honestly think that it will almost always be the best strategy to just be open and communicative with anyone you're mentoring. Mentees are just people like anyone else, and them being inexperienced as engineers doesn't make them any less able to understand clearly communicated guidelines, and if you need to adjust the guidelines as you go, there's no reason they can't understand that too.
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.
I’ve seen a lot of bad engineers and most of them undervalue helping others. Good engineering leads know that they can write more code by supporting everyone than by writing code themselves. Definitely a form of mentorship. I’ve seen some that are almost 100% mentors.
When I ask for something that I have no idea how long it should take, I'll say something like, "don't spend more than half a day trying to get this to work. If we can do it that amount of time then it's worth it to the business, otherwise it's not worth the effort".
If they can't get it done, no problem. I just ask them to document what they tried so that if someone tries it again later they have a starting point.
Setting the context let's them know how much effort to put in regardless of junior or senior, it's just for a junior employee the context is less "value to the business" and more "here are my expectations".
On the one hand interruption is expensive: https://heeris.id.au/trinkets/ProgrammerInterrupted.png
On the other hand, spinning your wheels trying to figure out something for an hour is expensive.
I've never really found a solution to maximizing my "interruption budget". Inevitably I end up both spinning my wheels too long sometimes and interrupting too much at other times.
Meanwhile trying to solve this problem also consumes way too many brain CPU cycles.
Could you expound on this?
The incident always stuck with me because this problem was literally un-Googleable. It was an internal system that required a super specific method of interaction you’d never discover by accident. The only way to use it was to ask for help.
So yeah, I agree with the author. Timeboxing tasks for juniors is a good way to teach them when to ask for help or clarify requirements.
The major difference from what I remember 5+ years ago is I try to ask early and often (like the vote early, vote often adage) when I need help.
Something that I think is missed in this industry, though, is that everyone has different backgrounds.
I started this job late last year and sometimes I'll have a lot of questions or get blocked on something I have zero experience in. It can be frustrating because I don't want to over-ask, and know how to timebox myself, but team members, or relevant engineers on other teams, may have less years of experience with more contextual knowledge/experience and occasionally don't want to be bothered to share it. We can get into the nitty-gritty of team culture and all that, but I think it really in this case just boils down to recognizing that someone may not know everything and they could be higher or lower level; it's just important to find the right method to get them up to speed.
We're having difficulty on people wheel spinning and taking too long to reach out when there's problems but it's not because they can't but there's a sense you develop as you gain more experience on what that "red line" is when you need to reach out.
It's a combination of experience with the task (language, codebase, etc), agile point values (or just "level of effort") and how easy it is to approach those with the answers. As they're continuing to do work, evaluate where the time you've currently spent matches up to each of those three things. If you've hit that red line, time to start sounding alarm bells (relatively).
It really is a learned skill and takes time, juniors shouldn't feel bad and seniors/leads shouldn't make them feel bad. Seniors/leads should also be planning for learning this skill into their estimates to stakeholders.
If it would take me N hours to do something, I expect them to take no more N*M hours to finish the task, and if at any point they feel that estimate is wrong they should let me know.
Usually it takes them 2-3 tries to realize that this system is in place to help ensure:
1. They understand the scope of the task
2. They don't spin their wheels too long on any one thing.
When hiring juniors (mostly interns to direct hire), the two biggest things I look at are:
1. Do you do things outside of your coursework to enrich yourself?
2. Do you ask a ton of questions in the interview?
The best intern we ever had (he is at Apple now) asked so many questions during the usually 45 min interview that I think it went to almost 2 hours. He was a phenomenally conscientious hire and managed his own time impeccably well.
Also, I am very up front with all of them that I am here to keep them challenged, but they have a ripcord they can pull at anytime if things get too stressful or if things get too easy.
I am very conscious to say 'If things get too stressful' and NOT 'if things get too hard'. A stressed out engineer is no good to anyone.
[0] https://www.pearlleff.com/seven-tips-for-a-junior-developer
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.
The best formulae I've found is to gently prod jrs towards a solution, but to also keep an eye on their progress and then, if things are taking too long, to reach out and suggest that even though the task isn't complete, to go ahead and open a WIP pr for the team to look at. This encourages them to "let go" of the hangup and to put the work out there, effectively making things a team effort. The sooner they learn that code isn't personal (which is admittedly hard), the sooner they're on their way to more senior levels.
I know some fairly senior devs who are afraid to say “I don’t know” or admit they are stuck. Particularly when they are working on someone else’s legacy code that may be of dubious quality. It is a shame, because in many cases just a little humility and admission they are human would make them much stronger developers.