6 ms·

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,

• plutonorm 5y ago
  Get a stress ball. Practise screaming inside your head. Works for me.
  • bacro 5y ago
    I need a punch bag
• mooreds 5y ago
  Two options: * 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.
  • mnsc 5y ago
    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.
    • mooreds 5y ago
      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. 0: https://letterstoanewdeveloper.com/ https://letterstoanewdeveloper.com/
  • hpcjoe 5y ago
    I'd say "both". 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.
  • cameronh90 5y ago
    Who reads though? 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.
    • ahaferburg 5y ago
      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.
    • mooreds 5y ago
      Did they do that once or multiple times?
    • lanstin 5y ago
      You could have a whole career of actually reading the error logs in email chains and then just saying that error as a normal English email.
    • lovecg 5y ago
      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.
      • bacro 5y ago
        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". I need a punch bag urgently...
• thechao 5y ago
  I was the only English-speaking TA (&, thus backup lecturer) to "Intro to C 101" at a major mass-population state university. Class sizes were ~800 students. I had an open-doors/open-lab/open-office policy. By the 4th semester, I remember laying on the floor in front of the class, and yet another bro (blond hair; blue eyes; chiseled jawline; backwards cap) came up to ask me a, frankly, very well thought out question — and I just said "I know I've taught this to you, already". I had; I'd taught it to him & all his bros for years. 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.
  • newsclues 5y ago
    The trick to teaching the same thing over and over, is to use each time as a way to master and refine your understanding of the topic.
    • thechao 5y ago
      I had 6 identical lab (secondary teaching) sessions per week, each 1 hour long. I handled lecture once a week, for two blocks of 400 students. It’s the equivalent of a decade teaching per school year.
      • lanstin 5y ago
        This note makes me again feel industry was the right choice for me. In industry, the value of people asking questions is you get a very accurate way to identify talented people - by which I don’t mean gifted people but people with the understanding, curiosity and confidence to drill thru a brick wall in the way of their goal with the subtle arts reasoning.
      • newsclues 5y ago
        With that kind of opportunity you can: Master your understanding of the topic. Master your ability to communicate the topic. Optimize your explanation to be thoroughly complete and time effective.
  • 5y ago
• dr-detroit 5y ago
  When I worked with a lot of entry level college kids I would pretend I was a swami and I could divine the answer to the question only through supernatural means until they were too shamed to ask because obviously this isn't magic.
• jimlikeslimes 5y ago
  I think this needs to explicitly be handled by a role in the team. A common team might comprise of a project manager, architect, 1 to 4 more senior devs, some representation from a test team, and a number of juniors, interns etc. 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.
• deleted 5y ago
  [deleted]
• drclau 5y ago
  Write a knowledge base, or Wiki, or FAQ, or whatever. A place where they can re-read the same thing 10000 times. Maybe add some examples too, in cases where it makes sense (i.e. code). 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.
  • lanstin 5y ago
    One approach I have been experimenting with is copied from surgeons: see one, do one, teach one. We have documents and so on, but for novel Devops-ish rocedures, I will document it, but then pick some to watch on screen share, then the next time they will drive, and I will watch their screen share, then the next time they will demo to another person. It is great for tasks in between we do it every day” and “we’ve never done it before”. Also it builds confidence (and often the docs are better after the train gets a good writer as the see one person).
• marcus_holmes 5y ago
  Work out what you're doing to make people prefer to lie to you and tell you they've understood when they clearly haven't? If you're having the same communication problem with multiple people, then I'm afraid that's you not them.
  • bacro 5y ago
    Unfortunately, it is not only me that has these problems. But I agree that I am not the best teacher in the world. However, I do believe that they are not trying very much and keep calling me or stopping the team with meetings for small problems. I get it when you are new to the company, but for god's sakes when you have 2 years+ and you still keep asking trivial questions, there is some other problem here.
    • marcus_holmes 5y ago
      We keep telling people "there are no stupid questions - please ask before assuming anything" then get annoyed when they do exactly that ;) 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.
      • bacro 5y ago
        I know :D But, I am only get annoyed when the questions are recurring. I think there should be more effort from the developer to learn by himself if he does not get it from us explaining 100 times, then.
• dkdbejwi383 5y ago
  Stop giving them the full answer and only lead them part way there. They will then (hopefully) learn how to look up documentation for themselves. Essentially "teach a man to fish". They don't necessarily want to know the answer, but they want to know how you know the answer.
  • bacro 5y ago
    That is what I am trying unsuccessfully to do. I made a sugestion the other day and did not write the code. He understood the idea but implemented poorly. When I asked why did he implement it that way, he said "it was your suggestion". I tried very very hard to not explode here...
    • lanstin 5y ago
      That is what code review is for. It shouldn’t be personal, it’s just here these specific changes will make it more robust or easier to understand or whatever.
    • dkdbejwi383 5y ago
      Explain why the implementation is poor, e.g. if there is an unperformant loop that will struggle with large workloads, point that out and ask them to write a test to simulate this, then fix the implementation.
• lanstin 5y ago
  Make your rate of responding be proportional to their demonstrated ability via questions. At my last job, there was one person that would always ask, not simply new questions but new types questions. I would immediately get back to her. There was a group of people that would always ask a new question, generally either due to a lack of understanding of something or it was a real interesting bug. Them I would return to at the next break. Then there are the people that have no interest in learning how to fish and just wanted a fish. I would slow down responses quite a lot; when they escalate they are introduced to the ticketing system or Jira for assigning fishing tasks to the team. 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.