4

Recently my manager has made me more of a lead role in helping shape some of the new devs on the team. I have a lot of experience with the codebase they are dealing with and so he sometimes simply lets me assign issues out.

Most of the time there are some issues of various complexity. I have no problem giving out ones that are extremely simple, but for ones that require understanding more parts of the codebase I will generally add some thoughts onto the ticket to give them a better understanding of what might be going on.

Recently for some issues, some of the new devs will naturally ask a lot of questions. I have a really bad habit of inevitably telling them what the fix should be.

What is a good balance for this? While I do want them to figure the issue out on their own, I also feel weird withholding information from them. At the same time, I think there is value to letting them figure it out on their own even if it means they might take a while to understand what's going on. Also what is the right way to respond to someone who asks a very basic question that I feel they should be able to figure out on their own?

3
  • 2
    "Also what is the right way to respond to someone who asks a very basic question that I feel they should be able to figure out on their own?" "What have you tried so far?" That should really be a separate question though.
    – Lilienthal
    Feb 10, 2016 at 23:51
  • Did the extra babysitting duties come with a pay rise?
    – Kilisi
    Feb 11, 2016 at 7:38
  • @Kilisi I did get a raise but I do not think it's because of the babysitting -- it was because of a reorganization but that's a separate thing. I have talked about becoming more of a lead role because, well, I do the baby sitting already so they are testing the waters with this.
    – Kevin Xu
    Feb 11, 2016 at 22:22

2 Answers 2

11

Do you have documentation, or are you the docs? If the latter - too bad, they're going to refer to the docs as much as they can and you're going to have to answer. Of course, you could start writing down all you know and then referring them to that so in time you'll be less necessary.

In the other case, refer them to the docs, and refer them to the areas of code they need to look in. If you add in some architectural knowledge that will help but then, once you've shown them where to look, leave them to it.

Another thing that helps is code reviews. Tell them to come up with whatever solution they think is best but to bring it to you for checking before any coding starts. That helps them gain confidence in that they've worked it out correctly before making a mess. When they get better at knowing the system, move your code review focus to actual code after they solution is coded, and use the opportunity to explain any areas they got wrong or (more likely) could be done better or more in keeping with the codebase.

In time they'll get more confident and autonomous.

3
  • Code reviews are definitely a better approach than spoon feeding them the answer.
    – AndreiROM
    Feb 10, 2016 at 23:14
  • 2
    This is good advice, and I would add one thing. Don't provide a lot of information up front when you are assigning the task. Give enough to understand what needs to be done, and save the rest for when they come and ask. It saves you time, and some folks might get the impression you don't trust them to figure it out if you give too much help right away.
    – ColleenV
    Feb 11, 2016 at 16:00
  • 1
    +1 - In general, good teachers are willing to let students make mistakes.
    – user8365
    Feb 11, 2016 at 16:46
2

It sounds like you have natural educator tendencies. But it also sounds like you are either a little new to applying them, or lack encouragement to stick to your principles. Being an educator (or team leader--which has many similarities) requires persistence on your part to not give answers. There are several positive educative approaches you can use:

-Act as a sounding board to those who are expressing problems. In this case you may not even need to actively react but simply passively receive.

-Discuss the problem presented to you by your colleagues. Either pretending to seek clarification on it, or genuinely confirming what the problem is. Through this indirectly the answer may arise.

-When posed with a question, mention that you are "not sure" and they might want to try or check such and such a location, then excuse yourself from the situation and tell them you will return shortly; when you return ask them if they got anywhere with their seeking.

-Final point--and this one is gold. I almost feel like not revealing it here. Vocalize your own internal thinking processes when you are at work. Your colleagues will overhear what you say and learn to be more independent.

1
  • I love that final point (more because I totally listen in on what other engineers are saying and I have learned a lot from that)
    – Kevin Xu
    Mar 4, 2017 at 9:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .