Ask HN: As a dev coach, how do you handle "expert beginner" behavior?
With some people, it's truelly a great experience. I think these people are mostly curious, eager to learn and are probably smarter than me, when I was their age or had their experience ( they pick it up quicker than me, who spend more time understanding those things).
But I've noticed a pattern with others which I have a hard time coping with.
It seems that sometimes, people forget how many times you helped them to create their current solution ( literally taking over and doing pair programming for the hardest parts).
After a while, some people start to think they know all things better, but it perplexes me since I know which questions they sometimes ask, and it's pretty basic things that were questioned.
Most of the time, they still write horrible code and sometimes they don't understand what they are doing ( eg. Trying to explain known things and their problem with the wrong vocabulary ).
After a while of working on repetitive code, it seems the ego gets bigger so that they want to show authority versus others, while they obviously are still beginners.
Additionally, their behavior is becoming ungrateful and helping them because a burden ( eg. unrespectful).
Is that just me or my character? Or has someone observed similar situations?
Any tips, pointers or books on how to handle these situations better?
25 comments
[ 4.2 ms ] story [ 74.7 ms ] threadWhat struck me each time is how the things you observe are universally centered around people not behaving the way youd want someone to behave given your estimation of their talent and/or experience.
Ex. "They want to show authority even though just beginners" "they are ungrateful and [this makes them a burden to me]"
The mind-reading is also a big warning sign ("some people think they know all things").
I would either A) reflect on whether my mentorship had devolved into an authoritarian need to rank people and enforce behaviors, as well as demand fealty or B) give more specific examples.
As it stands, the general impression is one of navel-gazing and wanting more credit. To be sure, we are all guilty of that.
I'm willing to check if it's my character though, that's why I asked.
> people not behaving the way youd want someone to behave given your estimation of their talent and/or experience.
Yeah. This could be related. I observed it more lately, thanks.
Perhaps I used some wrong terms with "showing authority". What bothered me then was that he started to give wrong dev advice on multiple occasions to other new people onboarding. If it was correct, I wouldn't have "cared".
Note : I'm speaking about only 2 occurrences in the last 6 years. But it's a very frustrating experience.
I thought the situation was more coined like the "expert beginner" though ( https://daedtech.com/how-developers-stop-learning-rise-of-th... )
Have you mentored?
Google was a nightmare for sociological reasons not dissimilar to what you describe.
Quick anecdote attempting to:
- colleague is a server-side engineer, highly sociable and communicative. They transfer to client side work on our team, get about a year experience
- new manager comes in but is quiet and absentee due to parental leave, about 6 months of a 9 month launch cycle
- manager assumes and communicates I'm de facto lead and should be getting people on the project
- colleague sees it more as a competition (residual from new manager coming in and me being de facto lead in between managers). new manager never spelled it out to everyone, so 6 months of hell ensue
- got to the point he went to manager's manager to complain regularly, eventually gets cut off and told to stop giving me a hard time because he's describing me helping him
- 2 weeks past ship deadline, with 2 weeks of work left, he repeatedly insists in a meeting that our work is in Binary A, but it's in Binary B, I let partner team deal with explaining it to him, I tried to avoid anything approaching conflict
- He consistently was a helpful contributor when he sat down and coded, but caused an infernal amount of racket between severe absenteeism and a sense of extreme alarmism when he was present and learning what was going on, because of the gaps like you explain (not knowing what you don't know)
- The bitter lesson I took away from all this was more or less that I did the right thing, I got them involved and was polite.and helpful with them, and there was nothing I could do to keep the abusive side of that from happening without causing a situation where it looked like I was uncharitable and failing at my duty to mentor.
- Didn't matter or help with my performance review. He kicked up enough noise to indicate smoke, so there must be fire, even if managers manager had enough at that one point.
- after launch, i spent the next 6 months carefully building a relationship with the other key team member via everyday things, lunch, cat pictures. That way, my relative formality was obviated, and they began being a good influence (i.e. being blunt with the trouble colleague when they were on another planet, rather than re-enforcing their alarmism)
There is a reason behind my original question, since it's related to reflecting over the mentor role in the current situation.
And I'm trying to find out if if there, with the current situation, are similarities with past annoyances because of my character.
So the following hit right to home, because that's what I'm reflecting about:
> What struck me each time is how the things you observe are universally centered around people not behaving the way youd want someone to behave given your estimation of their talent and/or experience.
I'd appreciate your thoughts about the mentor role on the following situation.
The person I'm mentoring now is a senior with past roles in Amazon, IBM, ...
We are working together for 2 months now, but December is traditionally a low activity month because of holidays and a week off by the company.
I've had a feature that I was originally going to do solo ( my priority was the deadline and now I'm mentally switching to onboarding the senior the right way). This also means that the user stories were less documented.
We have a 7 hour difference in time zone ( he in Canada and I'm from Belgium).
I've almost daily asked if there were any issues/unclarities.
He also started early sometimes, probably to have more overlap and more help from me.
He also worked a Saturday ( for a relatively simple problem that he couldn't fix in 3 days, we did pair programming and I had 2 solutions in 30 minutes).
He couldn't solo implement a feature flag, where the "enabled" route took the new endpoint ( swagger generated) and the old route took the old one. I literally had to take the screen over and did it in 5 minutes.
Personally, this looked like an easy task.
Any advise from the mentor viewpoint? My urge was that this ( and other things) looked like a red flag.
I requested feedback internally and it was mentioned to take character/culture differences into account.
I'm now trying to compare past experiences to reflect on that feedback. But I have a hard time getting over it that someone with 18 years of experience couldn't do that solo.
I was always worried that he would be without work. It's possible that this was viewed as "pushing", while I just tuned in to see if everything was clear and if he had questions.
My current guess is that perhaps because of my handling, he tried to adjust his coding to my way of doing/development and it impaired him ? ( that's the only possible explanation I can find). This guess is related to what was mentioned after feedback internally.
My actual guess is more in the lines of "beginner expert". And my worry is that our team in theory has an additional senior, while that's not the case.
Note: I requested for an additional senior ( full stack) for a while since we can use it. But it seems that the position that was open is not similar to what was fulfilled ( I would say there's even such a big difference that's it's red flag. And i believe it's also my job to signal that).
Any advice / reflections would be greatly appreciated.
IMO it's not your job to teach how to use a framework. But instead of assuming they "should" know things, you could assume they are skilled but at different aspects of development. So from this perspective, a mentor might give additional topics to brush up on to be successful in the job. And still be super open to providing internal career advice, helping with company-specific things, etc.
It sounds like maybe a lot of what you write here is important for mentee success yet not being communicated. You could probably be more upfront about team expectations, and let them know what a typical dev workload will look like.
Hiring is tough, and some people are not able to perform as well as expected. That can be frustrating, but it's not your fault. You may want to clarify how the company evaluates new hires so you know the process.
> For example, you sound extremely hands-on for a mentor. I would not do all of their coding for them.
Well. I guide them through keywords to look up, so they can find more info about their current issue and then ask them to come back when they need to know more or still have further issues ( I do want to see they put in some effort in finding the issue first, depending on the issue ofc).
The problem is after some back and forth. If it takes a relatively long time, I sometimes do the coding for them ( a lot less the last years) and I still think it's a difficult balance.
Once you fix their problem with pair programming, I tend to get into an akward situation, where it's expected to do that more from their side, which I don't want to do.
To the point of the actual request of : "can you take over my screen" or "can you do it for me".
Fyi, that's an example of the current senior situation. I hit the "can you do it for me" feedback loop really fast this time.
I won't belabor the major point, you extracted it well from another comment of mine, re: there's a cost to the mentor in this type of situation, even when the mentee is...someone we don't see much traction with.
`I requested feedback internally and it was mentioned to take character/culture differences into account.`
I hated having to go through this exercise of interpreting statements from my managers, but in retrospect, I always found there was much more nuance to their advice than they were able to communicate: here, I detect subtle understones of "they might not measure up to you, you're excellent technically and thoughtful" via character differences, as well as invoking cultural, to give some breathing room and indicate it might not even be that they have character issues, but might be attributable to outside influences.
Honestly you've handled everything extremely well, even going to the trouble to seek out advice internally, and here, and being very thoughtful in the process. A real outlier.
What I'd say then is, they probably expect you to treat this as a performance management problem. Which is where it gets hairy. I can tell you at G if a manager was in your situation, pre-2020, they'd end up being silently flagged and just never...advance.
That's one extreme. Driven by that it's a _very_ difficult, to impossible, problem to communicate directly with an individual. You'd have to come up with a whole other abstraction layer to not communicate too directly, because you'd incinerate the relationship. Since it's a difficult problem, and they preferred having headcount, you'd just sort of see the relationship grind on over _years_.
The other extreme is 2023 Google, or what you may have seen as a TikTok trend of people videotaping their firings. Because performance management is so difficult, and companies are incentivized to cut right now, very frequently management never says anything _and_ suddenly lets the person go.
You could strike a middle ground and let them get a performance review cycle in with a sanitized version of what you wrote to us (ex. needs guidance from peers too often, etc. etc.) and see what happens.
No worries at all. It's a good thing to reflect about too.
There are certain characters that just don't fit with others and I'm trying to see if that's the case or what is wrong.
For the rest of the comment. I'm still need to reread it a couple of times to see if I get the jest of it and how to apply it.
I asked originally to let me handle the feature alone and get them to get a fresh perspective on it through tag-teaming him with someone else. But that's not possible it seems.
I guess I'll have to accept the fact that the mentor role isn't meant as a performance signal early on and deal with it mentally + don't let it affect my mentoring ( since we could use an additional good senior atm).
Either way, I like your feedback and already got more from it than I expected through a text based medium ;)
Thanks!
On further reflection prompted by your comment, I guess what I'd say is it happens, but nothing useful comes from trying to actively address from a mentor role due to sociological reasons: i.e. unless you're emperor, it looks like a mentor rolling in the mud with a mentee. It actually costs you more than them because theyre supposed to be naive and new, whereas with the mentor, it looks like they're too immature to take on the more advanced role.
This was shaped by 7 years at Google, a very strange place where unsustainably surreal and smiling was preferred over functional and forthright --- I'm being unfair with that, but it's good to share because it's a concrete warning my bias is towards avoiding conflict and sitting and waiting.
That's a good observation and correct, thanks!
- trying to explain things to others, without knowing simpler things related to it
- when given a feature on his own, I practically did all the more difficult time-consuming things ( eg. Doing the logic of product variants to the db, when the Post is done)
- when they get a feature, instead of discussing how it's going to be done before he starts and if it's a good approach. Finding out when they are halfway in and his pr's are getting blocked because of "wtf"
- Starting to spread asking things to people less aware of certain behavior, so it wouldn't be obvious how much time he spend getting something out ( this is a guess behind of the why fyi)
- only claiming that they gave doubts about certain variable names, while an implementation is 4 levels deep of "if/else" ( or similar bad code
- sometimes, I took the entire afternoon to explain things. The day after, it was just like nothing was discussed and the same mistakes that were talked about to avoid, were in the PR. Tried to talk about it again, but started to ignore it more from then on, since it was time consuming
Provided additional examples elsewhere here.
I don't think I "want to be respected", I do want them to consider that it's taking a lot of time from me too, to help them and not just think of of me as "the easy/lazy" fix. Which is similar, but not the same since it's comes across as "disrespectful" sometimes.
I'm always quick to help ( within 5 minutes at most, but mostly immediately) and it creates an uncomfortable feedback loop in some cases after a while. I'm trying to find a root cause and a fix for this.
The only thing that is a bit uncomfortable at first, is when I see mentees start helping others ( and it's just me have to break the habit as a mentor and adapting to see them growing more). With others, the ones I am talking about, I know almost upfront I'll still be requested since the advice was just useless time spend between those 2 people.
The first moments I keep an eye on what's being said and I follow up on that. If their advice is bad, I feel bad too.
On the other hand, I congratulated a mentee last week for handling a situation well and there wasn't a single moment where I had the feeling to jump in until we had a team meeting to discuss and solve the issue together ( the issue was known for a month and was getting more common over a timespan of 2 days, he took it up in those 2 days and handled + investigated it very well).
You’re the problem here.
Don’t be so quick to help. They’ll just keep coming for more help.
Or if you are quick to help, answer with a question that points them in the right direction rather than giving them an answer.
Normally, I reply with keywords to search for and they can dig in.
In some cases, the question becomes literally to do it myself for them and I said yes, then.
Today, I explained that I'm not comfortable with that and I would like to not do that anymore.
The answer here is either a "No." or a "Let's share screens and I'll talk you through it this time."
I tried that and it's a bit of a disappointing walkthrough when you have to say: your parameters/arguments changed, because it's a new method that you created.
Have a look at intellisense suggestion to fill in the correct arguments.
And they don't know what intellisense means ( DotNet development in visual studio. Guy with 18 years "experience" )
Don't pair or do programming work for them. Make them figure it out. They need to get frustrated and figure it out or ask you.
Empower the developer.
Him explaining ideas to others is how many people learn. Let him teach his peers.
Juniors write horrible code. Lucky you are not in a code judging contest. What matters is does it run and does it meet your departments guidelines in terms of coding rules / style. If not don't pass the code review until changes are made.
I think you are providing good knowledge but not giving the person time/space to grow into the role.
That's actually what I did the first month, since we were on holidays in December ( I always replied and tried to follow up).
I carefully explained the complete context of the feature.
Context of this was abstracting away the Azure Cognitive Search specific filter queries in caller applications ( yuk :p ).
Showed a dev branch where the rough work was done on 1 webapp ( it needed more work to verify the filters by entity and create pr's per entity), which creates a new route.
And then a pr with a feature flag in the caller webapp to call the new route with a feature flag, for the caller web apps.
He just couldn't do and I was flabbergasted tbh. On multiple occasions he literally said he was stuck, while they're were multiple pr's already completed by me with an almost exact pr ( the same changes but in different webapps ).
One time, he was stuck to call the new endpoint that was generated, since it had other arguments.
Another time, I gave him advise to check assemblyRedirect to fix an issue. I had 3 feedback loop calls with him about this in particular and he couldn't understand assemblyRedirect's syntax.
At the end, I just did it on my own in a pair programming session and explained the 2 solutions I found. Which was also what he requested, => "can you fix it for me".
The one I mentioned in the op were previous examples in the last years to see if there's an overlap, since I'm already reflecting over the current situation with similar situations from the past.
Or he's in a difficult personal situation and can't think clearly (not sure this is your job to figure out though).
I agree with other commenters: in the end you hired a senior so you wouldn't have to spend time teaching a junior. Be available to explain things he asks but give him time and space to figure out things on his own. Is it the very first month of employment? Maybe the onboarding wasn't great and he is bogged down trying to understand the big picture.
You shouldn't be hand holding seniors with experience. Give him concrete goals, requirements and deadlines so he knows what he needs to deliver and let him do his thing.
Also, review your hiring process.
A lot of it is iterative and there's plenty of transfer learning that makes newer things easier.