How to politely communicate that I really can learn well only if I do it myself?

Question

I'm a junior developer. My tech lead is a very smart person.

When I go to him to seek for help on a problem, he usually finds a solution very quickly (he designed the whole system). The problem is that after he finds the solution, he tends to quickly start coding on my computer as he talks about the solution. And often leaves only little for me to finish.

But I really can learn well only if I do it myself.

Ideally, he can just explain the solution verbally and leave the implementation to me. I think it's a good way to check my understanding of the problem and solution. And, hey, how do I learn if I just read a good solution instead of making mistakes myself?

So the question is how do I communicate this politely, without making him feel like his help is not appreciated?

UPDATE: it turned out that I'm not the only one. A senior team member talked to the tech lead about the same problem just before I talked to him. The tech lead is much better now. But people are hard to change. He still tends to jump on the driver's seat most of the time, but at least he tries to explain what he's doing now.

Answer 1

"I hear and I forget. I see and I remember. I do and I understand." -- Confucius. (Yes, really. It's the one legitimate K'ung Fu-tzu quote I know.)

It's true for everyone.

The problem tends to be that experienced developers think of the solution as code. It can actually be additional effort for them to step back and give you a pseudocode/algorithmic/conceptual version of the answer.

So if that's what you need, you really do have to be explicit about it. "Please just get me pointed in the right direction rather than giving me the full solution; I need the practice." Or only ask him about the one corner you're stuck on, so he only gives you those few lines and you can go on with the rest.

By the way: THANK YOU and congratulations for being a self-starter and wanting to learn. We spend too much time on Stack Exchange swatting down folks who expect us to do their assignment for them; it's delightful to see someone who understands that practice makes better.

Answer 2

The best cure for getting answers you don't like is to ask a better question.

My code won't compile, I don't understand what's happening

Gets you "oh yeah, I see it, no worries I just change this, this and this, and then I - oh ha ha, that's a common misconception, just make that a reference - and yup, there you go, all set.

In contrast,

Can you clarify to me when we use pointers and when we use references? I get compiler errors on my first try quite a lot, and I think I need that explained to me again.

Should get you at least the start of an explanation, and you might be able to say "could I type it, so it sticks in my brain better?" when the typing starts.

On a larger scale, you could ask

Now I think I need to send a message over the named pipe, but I haven't done that before...

And get a similar "hm, yeah, let me just [type type type type] there you go

Or

At this point it's just a matter of sending a message over the named pipe, isn't it? Is there some code in the system already that does that, something I can read to make sure I am doing it our way?

Which should get you an acknowledgement that you are following along, and possibly an answer to "where is some code I can learn from" instead of "I need code here" which could lead to typing.

It's also really important to follow along when your colleague starts typing. There's nothing wrong with saying "hang on, let me read that for a sec ... ah, I see, you're using streams, right?" so that you can learn from the experience and your colleague can see that you want to learn from it. If it's clear that you are "getting it" you are more likely to hear "you can take it from here, right?" which is what I believe you want.

Answer 3

If this is an occasional problem, simply bring a notepad with you when you ask this person for assistance and jot down what he says while he is saying it. That he sees that you are interested in seeing the problem for yourself and that he doesn't have to interrupt what he is doing to assist you. Repeat what he tells you back to him after you write it down to ensure that you understood his directions.

If this is more than an occasional problem, my advice would be for you to beginning work harder on your core skills. Having to provide occasional help is part of work process; consistently having to provide it is a sign of a lower skill employee who needs more training or who is unsuited for their current role. If you are asking for assistance daily, multiple times during the week or with relatively minor issues, then you should increase the amount of that you spend studying and test coding while off of work.

In the latter instance, you will be one who needs to improve and not your team lead.

Answer 4

In addition to Mistah Mix's advice about writing down in a notepad I suggest to ask in a place where your team lead will physically not be able to write down the solution himself.

If there is a whiteboard (I'm pretty sure there is one), ask him to draw a diagram or scheme of the solution there. Avoid inviting the team lead to your desk whenever possible.

Before asking questions, try to do some research. If your team lead feels necessary to take his time and write down the solution himself (which should normally take more time than explaining it to someone else), I suspect he isn't sure you'll be able to write it (more or less) correctly by yourself. So when asking questions, try to make them as specific as possible. Avoid asking general questions, which will make you seem clueless about how to solve the problem.

Answer 5

@keshlam 's Confucian quote is great. Can you print that out and put it up in your workspace? Then you can just point to it and smile when he comes to your desk.

Basically, you need to tell him that you want to do it yourself. There are lots of polite ways to do that. Keep it light and humorous; this isn't a threat or insult to you. He's just a little over-enthusiastic about helping.

But it will be beneficial for both of you if you can set the boundary more clearly about where the line is on "helping".

If nothing else, tell him that for your professional development, you would like his help getting unstuck, but want to tackle these problems yourself.

Answer 6

Depending on who you're dealing with, it might not be so easy to communicate this directly. You may try the guy's patience or appear stubborn, etc. But here's something I have done many a time, when in similar situations where I was unable to ask for an explanation:

Copy the code he wrote into a separate file, delete it in place and put back your code, and then rewrite your code again in place, line by line, as you read and digest what he did that was different than what you wanted to do. i.e. Compare and contrast: Analyze where you went wrong and what he did that was different than what you wanted to do that didn't work, and correct your code based on his. Keep it yours, incorporating what he did.

Answer 7

"when I go to seek help" ... so you are initiating the situation which you don't like.

Instead of trying to control your lead's behaviour, try and control your own. Next time you want to go for help think to yourself: have you really exhausted all your avenues of investigation to the point where you genuinely need help or are there attacking options available still to work through?

Once you have tried everything then you should go and ask, but I bet that if you follow this advice you will probably not need to ask for help again.