6 ms·
Ask HN: As a dev coach, how do you handle "expert beginner" behavior?
I spend a lot of time helping collegues and onboarding others.
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?
- refulgentis 3y agoFrankly: it does sound like your character. I read it once, then more slowly twice, with charity at the forefront of my mind. 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. 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.
- NicoJuicy 3y agoThanks. 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-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th... ) Have you mentored?
- refulgentis 3y agoYes, to an extent, first had my startup where that was extremely easy (people love to suck up to you when you're in charge). Then Google. 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)
- zero-sharp 3y agoI've definitely been in workplace situations where one person's language creates an impression of egotism (to me). For example coworkers making extravagant comparisons in aptitude (in relation to senior coworkers). I can definitely relate to that aspect of the OP and I would want more examples.
- refulgentis 3y agoThat's fair and true: I wrote a long comment on a sibling with a similar conflict that might rhyme 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.
- NicoJuicy 3y ago> 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 without. That's a good observation and correct, thanks!
- NicoJuicy 3y agoEg: - 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
- lulznews 3y agoSounds like you want to be respected more than you want to help them.
- NicoJuicy 3y agoThese were only 2 occasions in the last 6 years, there are plenty of other counter examples. 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).
- paulcole 3y ago> I'm always quick to help ( within 5 minutes at most, but mostly immediately) 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.
- NicoJuicy 3y agoYep. Explained that today during a face to face meeting, that I'm not comfortable with just taking over. 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.
- ipaddr 3y agoI would take the opposite approach. Treat the person as a senior and leave them by and let them ask you for help. Then give them bit sized advise on how you would do it and maybe throw in others do this or that but it's up to you. 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.
- NicoJuicy 3y ago> Treat the person as a senior and leave them by and let them ask you for help. Then give them bit sized advise on how you would do it and maybe throw in others do this or that but it's up to you. 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".
- NicoJuicy 3y agoNote: this is about the current mentorship onboarding a senior. 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.
- cranberryturkey 3y agoits hard to become a master at anything anymore in tech because its obsolete as soon as you master it.
- NicoJuicy 3y agoThat's not really true. A lot of it is iterative and there's plenty of transfer learning that makes newer things easier.