Indeed, I keep being a jerk to junior developers that constantly comes to me with the same questions after I explained to them 10000 times and they say "Yeaah, I got it now". It is so hard to avoid being a jerk. What should I do?
* Ask why they keep coming? Maybe you aren't understanding their question, they want to build the relationship, or it's a really risky operation and they don't want to undertake it alone. This might be worth digging into.
* Write the answer down to the questions (wiki, internal doc, whatever). When they ask, point them to what you've written down. Will still take some time and interrupt you, but hopefully they will learn they can just go to the doc.1st, you need to help them get the RCA on why this question, and what context (that isn't often brought up). Its often that framing the question in context elucidates the actual problem they are working on solving, and they are seeing a misfit in concepts with the solution you've gone over with them. This is one (of many) areas where being a senior (experienced) dev/manager/leader is so critical in developing the less senior folks.
2nd, curation of notes, experiences, techniques is absolutely critical for team capability growth. Capture the problems, explain the use case/back story, explain the problems in explicit detail, explain the thought processes around the solution, and the solution. Cut-n-paste examples help. I did this when I ran my company, and found that it was quite helpful to the team. And they followed the example, and documented their own efforts.
Please don't be snide or dismissive with the less experienced. One of the reasons I see many orgs hire older/senior folks is to provide a calming, thoughtful, intentional influence on other team members.
As others have pointed out here, you need to continuously grow, learn new skills, add new capability. This should be a given. I don't want to bring "lifers" (people who hide in a company, doing only one thing, never interested in developing). I want to bring curious, intelligent people, with capability, and experience. Or if lacking experience, then a strong attitude of wanting to get their hands dirty.
Age doesn't factor into this.
We had a build prerequisite check that output "error: package xxx is out of date, run sudo apt upgrade - see wiki.local/XXX for more details"
They still copied the error to me and asked what to do. I said follow the instructions in the message. They said cool thanks and did so.
Edit: just thinking out loud here. These error messages are equivalent to a random passerby without any skin in the game saying “oh just run this command” — how would one trust them when their job is on the line? I can think of a few common approaches: - “oh just run this command because paragraph 1.2.3 in the universal code we all agreed to says so” (easy to confirm) - “oh just run this command because senior engineer X said it’s safe” (assuming you believe that they did say that) So maybe the error messages should include some equivalent of those.
I need a punch bag urgently...
What's the quote? "Every year I get older, but the junior devs stay the same age."
That's when I knew I couldn't teach undergrads.
Is there a nuance to this I’m missing? If my professor suddenly decided to lie down in front of the class I would not casualy amble up and ask a question, I’d be more likely to call an ambulance or burst out laughing.
Master your understanding of the topic.
Master your ability to communicate the topic.
Optimize your explanation to be thoroughly complete and time effective.
Even better, make them write it, and you just review it. It'll help them learn faster.
If you have a junior who already understand problem X, ask them to explain it to someone else too. It'll help solidify the knowledge, and at the same time offload you too.
Take my comment as wisdom that came with age and experience, if you will :). I don't think the above would have been my first thought 10 or 15 years back.
There are people with such interesting questions I am happy to hear them and talk them they even from three jobs ago. I cultivate them, as these questions extend my detailed knowledge farther than it otherwise would extend.
One of the senior devs needs to handle onboarding new people and communicating the ideas of the architects and seniors over and over again to juniors. This is tiresome and boring to some. You need patience and empathy. It can be fun though as you get to meet lots of people and help them when they need it most. Most importantly you give the other seniors the time to work, without them getting involved in yeah just "make clean build" that away type issues.
I actually like the role and if the team doesn't have too much churn, you're just another senior dev.
If you're having the same communication problem with multiple people, then I'm afraid that's you not them.
Though I do get the frustration. I had similar with one of my juniors, and it took me ages to work out that his learning style didn't match with my teaching style. I ended up having to go right back to basics and walk him through everything painstakingly slowly.