* 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.
About that first point, that to me seem like a genuine and emphatic thing to do but I want to flag that this has the potential to go into the "soft" areas where feelings exist. For a crash course in "feelings and needs" read non-violent communication to be appropriately humbled by how hard (but important) this skill is.
I agree. I have a whole blog[0] about what I wish I had known when I was a new developer. Those "soft skills" (which are actually pretty hard) come up again and again as something I wish I'd known earlier.
It seems trivial to you, but only because _you know to trust the message and what’s written in the wiki already_. The hardest thing about documentation is establishing this chain of trust. By coming to you and getting a verbal confirmation they establish one tiny link in that chain.
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.
Just now, one of the junior develops contacted me about a problem trying to start an application we are developing. I asked: "Did you follow the instructions in README.md file?". He said: "Yes". Then when I asked for him to show me the error, I could see he clearly had not made one of the steps in README to start the app. Just to confirm I asked if he had done it and he said: "No, maybe this is why I am getting this error then".
The problem is not reading, it's trust in the information. You telling them that the information is up-to-date and valid and useful is the reason why they read it.
