Iyfjky

Question

Background: I was an intern at my current place of work for a year, until May when I was hired in full time. I am a programmer and I develop mostly mobile apps, but some web apps as well. Since then, we've hired several interns, and 2 of them are under my command. The reasoning here being that my boss wants me to learn to delegate and to solidify what I've learned by teaching it to another person.

So, the context is I gave my intern an important, but small task. He was to program something in the project I'm working on. Either he misunderstood the task or I did not do a well enough job explaining it, but he did it wrong. His work is so far incomplete, but I can tell from what he has written that it wont work and that he misinterpreted the task (or, it was not explained well enough) and the way he went about completing the incorrect task is not good. In his defense, he's in his second year of college and I am graduated, so I've a few years of education and a whole year of work experience ahead of him. I want to scrap his code, write my own, and explain to him how and why I coded it that way, but I don't want him to feel dumb or feel defeated about the failure. The reason I am worried he may feel dumb is because I have no idea how he intended it to work and also because to me it feels like a dumb way to do it, but I am acutely aware of the fact that I also wrote dumb stuff during my internship and I am still writing dumb stuff compared to many many other people. Yet, he failed. We all fail at some time or another.

So, how do I take over his task and explain how to do it right without him feeling defeated about the failure?

Have you tried test driven development? If he can code against a set of tests, then there is very little chance of miscommunicating the task. — Jun 24 '15 at 2:32
@Davor One common way is for developers to write unit tests, but the product owner/boss/customer to write acceptance tests. The code has to pass these to be considered "done." — Jun 24 '15 at 7:38
"I want to scrap his code, write my own, and explain to him how and why I coded it that way" : the worst possible way for him to learn coding and for you to learn delegating. Please avoid. — Jun 24 '15 at 8:42
When working with less skilled individuals, it's best to shorten the feedback loop. Review their work often and make sure they're on the right track. At the end of the day you're responsible for their work. If they're coding the wrong thing, it's only going to slow you down. — Jun 24 '15 at 14:46
@TomSterkenburg I am happy it went well, you seem to have taken a good approach. I was worried you would start patronizing the intern and micromanage him (yes, I tend to be pessimistic). Glad it worked for you. — Jun 24 '15 at 20:22

Myles 25.4k658104 · Accepted Answer · 2015-06-23 19:19:50Z

up vote
82
down vote

accepted

Best to ask him about it "Let's see what you've done for feature X. What was your overall plan? How were you collecting input, processing it, producing output? Why did you do ABC this way?". As a supervisor this doesn't have to be accusatory. It creates a dialog by which you can see what their plan is and let's you ask them about their solution to obstacles they will encounter.

Maybe they have a brilliant solution that you can't see, maybe they don't realize the upcoming obsticle. You can't know until you talk to them.

If they don't have a satisfactory solution for the given time frame then it doesn't have to be harsh. "Our timeframe is tight so I'm going to take this on myself. It was a good try, I made a similar mistake when I was an intern. Please (instruct some other task)."

answered Jun 23 '15 at 19:19

Myles

25.4k658104

2

Ultimately chose this answer because it was more in line with the question and my time-frame. He's in 2 days a week and 'd rather he spent his final day of this week doing a different task. In code, it's often wise to start over rather than working with a broken system and I think this is one of those times. Better he start a new task fresh after I explain how and why i scrapped his current task than we waste time trying to manage his current code into what I actually meant. We'll definitely work on communication.
â€“Â Premier Bromanov
Jun 24 '15 at 4:11

12

@TomSterkenburg Do note that delegating work also comes with releasing control. The only point is that the code has to actually do what it's supposed to do (miscommunicating that is probably a fault on your part, but don't worry, delegating properly is quite a complex skill, it takes time to learn). Adding additional constraints is also fine, but you need to see the line between "an important constraint" and "I wouldn't do it this way". Otherwise delegation is simply a waste of time.
â€“Â Luaan
Jun 24 '15 at 9:35

14

@TomSterkenburg You have stated that you've only been a full time developer since May. I think it's too early in your career to be making broad generalisations like "In code, it's often wise to start over rather than working with a broken system..." What you'll find is that, often, you will not be working in greenfield projects, but rather working with old systems and old code, which might in fact be broken. You will not get to simply ditch the old code and write it from scratch.
â€“Â Moss
Jun 24 '15 at 12:46

5

@Falco Most of the time ditching it would be better still? Right. Try telling that to a company with a large, complex, established system with many users who depend on it. If it's your pet project you've been working on at home, fine. Where actual companies and budgets and finances and reputations are concerned, it's not an easy thing to do. Also, deciding to do it might be catastrophic.
â€“Â Moss
Jun 24 '15 at 16:43

5

Try Pair Programming. You still get to do it right, and he gets to learn as you do it step by step.
â€“Â scord
Jun 24 '15 at 16:58

Â |Â
show 2 more comments

GreenMatt 15.6k1465109 · Answer 2 · 2015-06-23 19:31:56Z

In a word ... don't. (Yeah, okay that's a contraction.)

You stated that you oversee these interns because your boss wants you to learn to delegate. There's more to that than just "Here's some work, go do it." If you take over the intern's work now, it seems to me that you haven't learned what your boss wanted you to learn.

You've acknowledged that there were communication problems. To learn delegation, you're going to need to learn to communicate more effectively. The communication cycle involves telling, listening, feedback, and correcting/re-telling; in this last part the cycle begins anew and continues as long as needed. It seems that so far you've tried to use just the first two parts. However, you need the second two parts to ensure accurate communications.

My suggestion is to go back to the intern and let him know that the two of you miscommunicated. Review what the project is supposed to be, and make sure the intern has a good understanding of it; don't just let him say "Yeah, I understand." Ask him to re-state (in his own words) what he is supposed to do, and make corrections as needed. Then ask him to put together a plan and go over that before he starts coding. Also, keep an open mind; his approach isn't necessarily wrong, just because it isn't what you would have done; of course, it is possible his approach won't work, but it's your job to guide him to a working solution, not to do it yourself.

The only thing I'd add to this answer is: In the future, don't delegate important tasks to interns. Interns should only be working on things that it's no big deal if they don't pan out. — Jun 23 '15 at 19:36
@NotMe I'd disagree with that sentiment, at least for how my place of work handles interns. They are paid and they are here to get valuable experience, I'm trying to make sure they get it. There really is no task I can give them that isn't important — Jun 23 '15 at 21:09
@TomSterkenburg, it sounds like your company culture is inclined to give interns a bit more responsibility than usual (I'm currently in a similar environment). Such an environment probably accepts the fact that intern work may not pan out and understands the risk this could have to projects. I think the project owner should have input on whether you coach your intern to get the task back on track or take it over for them. I didn't post as an answer because this doesn't give advice on your actual question. :) — Jun 23 '15 at 22:24
@TomSterkenburg If you really want them to learn, you could ask them to rewrite their code - this time according to your standards. I never learned from people who wrote code for me, I did learn from people who told me in what direction to go (use a list to loop through, use technique-x, etc.). Also, don't tell any pitfalls, like "check for null here". Those are most valuable. Also, you said you have client interaction. Include the interns in that part, if possible. I always enjoyed moments like those. — Jun 24 '15 at 10:02
This. If the intern hasn't understood the task, and you don't make a second attempt at communicating it better, then how are you not going to feel defeated? Interns do things slower than experienced employees, but you should still follow through all stages of the task if at all possible, and "scrap it and start again" is a stage of any task where the first attempt is completely useless. — Jun 25 '15 at 7:30

score 3 · Answer 3 · 2015-09-10 21:38:49Z

Never just scrap and rewrite the code for someone else. If the person works for you, sit down and explain what was wrong and what exactly you want and then force them to do the rewrite until they get it correct.

Otherwise you will be doing both your job and theirs and they will remain not competent. Many people get frustrated when this happens because they don't see why it was rewritten and just assume that everything they do will be rewritten because Joe is a control freak, not because it has problems.

They don't get any better when you do this and it does them a great disservice. It also means you aren't delegating correctly and that you will be overwhelmed and they will coast along happily thinking they are great and you are a jerk. It is harder to train someone than it is to rewrite. But once you have taken the time a couple of times. then you will get improvement because very few people enjoy having to redo their work.

Now it might be that you need to sit with this person and pair program if they really have very little knowledge. But in this specific case, you make them come up with a solution and you just stop the intern when he starts to go in the wrong direction. You keep asking questions like "Why did you choose this method? Have you considered...library? What do you think the impact over time of doing this would be?", etc.

And remember this is not just the intern's fault. If you were not clear in what you were asking for and if you didn't check on them every day and look at interim pieces of their code, then you were as much to blame as the intern. So don't make this a blame session, make it a productive, constructive criticism.

panoptical 3,5761538 · Answer 4 · 2015-06-23 19:20:05Z

In short, sit down with the intern and have him/her watch as you code the project, explaining to him/her why you're coding the project the way you are, teaching the intern good coding practices along the way. Instead of reflecting on the intern's failure, you can make it a teaching experience. Failure is really one of the best ways to learn what doesn't work, and while you shouldn't be rude in bashing the intern over the head with their bad code, you do need to illustrate why their code won't work, and why the best plan at this point is to start over.

Whether the intern feels defeated or not is up to that intern. They'll need to be able to learn to deal with failure anyway, if they haven't already. However, if you treat the situation right, at the least the intern should come away with having learned something. In this situation, that's much more important than worrying about them feeling offended or humiliated.

I would definitely code with him if he were available today, but there are time constraints and I need to get it done today, unfortunately. — Jun 23 '15 at 19:34
If its a time issue, this is another reminder to yourself to make sure he knows time expectations. I assume you're working late and he already left? Theres not much to do in this case then do it yourself. He will lose the opportunity to see you code it. — Jun 25 '15 at 0:53
@TomSterkenburg: if the deadline is today and the intern hasn't completed the task and isn't in the office today, then it sounds as though you didn't give the intern enough time to complete the task, and/or you didn't catch the intern's mistake early enough for them to recover. This is all part of your education, of course, you have to allow time for interns to be slow. These things happen. — Jun 25 '15 at 7:33
Under no circumstances should code the task. You should have him code the task while you watch and provide verbal guidance. He will never get any better if you redo his work. — Sep 10 '15 at 21:37

score 1 · Answer 5 · 2015-09-10 21:41:31Z

Consider Pair Programming with the intern. Either pair program walk thru their incorrect code and try to fix it, or walk thru their code, explain its flaws, and discuss and Pair Program new, better code. Pair Programming is the best learning tool, knowledge transfer, code review, QA, all wrapped in one!

Sometimes, with time constraints, you may need to just scrap their stuff and get the job done. Have done this before, and it was with a senior developer. You could tell they felt slightly defeated, but they knew, we needed to get a job done.

if time permits, take the chance to learn together. they will learn how to program better, you will learn where the miscommunication happened. You will learn how to explain and write stories for tasks much better if you see how others interpreted the request.

Pair programming is great but if you do it, the intern must be the person who actually handles the keyboard. — Sep 10 '15 at 21:39

user8365 · Answer 6 · 2016-04-15 21:08:27Z

In the future, you need to let interns know that they are taking on a critical task, but if you are not able to approve their work by a certain time, it will get done by someone else. This is fair, open and honest. This doesn't mean they shouldn't take it seriously because you want to be able to give them a good recommendation. Interns shouldn't be burdened with mission-critical pressure.

Try to do some sort of debriefing so you can understand where you failed in explaining this problem to the intern or what assumptions you made about their skill level. There's no reason not to make this a learning experiences for you and your company as well.

Since you didn't do that, I would start with this explanation and apologize for not stating this in the first place. My guess is the intern will understand. Keep them in the loop about your approach. Take the time to explain as much as possible. If possible, don't redo everything. Hopefully there is some redeemable code there.

Give the intern something to so as soon as possible. Let them get back on the horse after they fall off. Maybe they can rewrite this project with your latest suggestions.

I just think if you approach it calmly and professionally, the intern won't beat himself up too much. It's important they understand that you want to stretch their skill set and there should be some realistic level of failure but not total failure. Sometimes you just run out of time.

TOOGAM 2,356512 · Answer 7 · 2016-04-15 03:01:37Z

I want to scrap his code, write my own, and explain to him how and why I coded it that way

Yes! Do it!

Err, maybe.

I've read the very sensible objections to this approach. Now that I just dumped a barrel full of gasoline onto this fire, I know I have some explaining to do. My quick summary is that this approach does have potential to be quite useful.

A widely quoted example is the U.S. Government training people how to detect counterfeit money. People have been taught this skill by becoming very familiar with what is right, rather than studying what is wrong. If the code created by your co-worker is sufficiently dismal, the best option may be to eliminate what is useless and demonstrate what is good, and discuss what is good and make sure that he can do what is good.

So, despite the objections other people have brought up, I would suggest that your plan may have merit, and might even be the best plan. However, it also might not be. When my career took on the role of being a college instructor, I got to see the quality of work that a bunch of students created. I also saw just how effectively people were learning some things, and not other things. I began to really see how different teaching styles are effective for different people.

I've also learned that delegating successfully involves giving someone a task that they can do successfully, and that involves determining their skill level. Case in point: some people are reluctant to make decisions, but they do know how things ought to be done. You could ask them, "Well, what do you think should be done?" By prodding them into taking the needed action, you may cause them to start to realize the power they could be utilizing, and may thrive. Yet if you ask the same question to a person who just joined an organization, and this person doesn't know enough details to have a basis to make a sensible decision, identical prodding may only have the effect of being disastrous.

If you're trying to train somebody, be sure to ask questions (early in a process) to verify understanding and determine what approach is helpfully working, and what approaches are not. Focus on giving them the structure that they need, with clearly defined desired results and maybe even clearly defined approaches, and then leave them to the task of accomplishing the simple-to-achieve goal you laid out. As for providing examples (made by you, and made by him), and providing instructions, the usefulness of a specific approach will vary by individual.

Myles 25.4k658104 · Accepted Answer · 2015-06-23 19:19:50Z

up vote
82
down vote

accepted

Best to ask him about it "Let's see what you've done for feature X. What was your overall plan? How were you collecting input, processing it, producing output? Why did you do ABC this way?". As a supervisor this doesn't have to be accusatory. It creates a dialog by which you can see what their plan is and let's you ask them about their solution to obstacles they will encounter.

Maybe they have a brilliant solution that you can't see, maybe they don't realize the upcoming obsticle. You can't know until you talk to them.

If they don't have a satisfactory solution for the given time frame then it doesn't have to be harsh. "Our timeframe is tight so I'm going to take this on myself. It was a good try, I made a similar mistake when I was an intern. Please (instruct some other task)."

answered Jun 23 '15 at 19:19

Myles

25.4k658104

2

Ultimately chose this answer because it was more in line with the question and my time-frame. He's in 2 days a week and 'd rather he spent his final day of this week doing a different task. In code, it's often wise to start over rather than working with a broken system and I think this is one of those times. Better he start a new task fresh after I explain how and why i scrapped his current task than we waste time trying to manage his current code into what I actually meant. We'll definitely work on communication.
â€“Â Premier Bromanov
Jun 24 '15 at 4:11

12

@TomSterkenburg Do note that delegating work also comes with releasing control. The only point is that the code has to actually do what it's supposed to do (miscommunicating that is probably a fault on your part, but don't worry, delegating properly is quite a complex skill, it takes time to learn). Adding additional constraints is also fine, but you need to see the line between "an important constraint" and "I wouldn't do it this way". Otherwise delegation is simply a waste of time.
â€“Â Luaan
Jun 24 '15 at 9:35

14

@TomSterkenburg You have stated that you've only been a full time developer since May. I think it's too early in your career to be making broad generalisations like "In code, it's often wise to start over rather than working with a broken system..." What you'll find is that, often, you will not be working in greenfield projects, but rather working with old systems and old code, which might in fact be broken. You will not get to simply ditch the old code and write it from scratch.
â€“Â Moss
Jun 24 '15 at 12:46

5

@Falco Most of the time ditching it would be better still? Right. Try telling that to a company with a large, complex, established system with many users who depend on it. If it's your pet project you've been working on at home, fine. Where actual companies and budgets and finances and reputations are concerned, it's not an easy thing to do. Also, deciding to do it might be catastrophic.
â€“Â Moss
Jun 24 '15 at 16:43

5

Try Pair Programming. You still get to do it right, and he gets to learn as you do it step by step.
â€“Â scord
Jun 24 '15 at 16:58

Â |Â
show 2 more comments

GreenMatt 15.6k1465109 · Answer 9 · 2015-06-23 19:31:56Z

In a word ... don't. (Yeah, okay that's a contraction.)

You stated that you oversee these interns because your boss wants you to learn to delegate. There's more to that than just "Here's some work, go do it." If you take over the intern's work now, it seems to me that you haven't learned what your boss wanted you to learn.

You've acknowledged that there were communication problems. To learn delegation, you're going to need to learn to communicate more effectively. The communication cycle involves telling, listening, feedback, and correcting/re-telling; in this last part the cycle begins anew and continues as long as needed. It seems that so far you've tried to use just the first two parts. However, you need the second two parts to ensure accurate communications.

My suggestion is to go back to the intern and let him know that the two of you miscommunicated. Review what the project is supposed to be, and make sure the intern has a good understanding of it; don't just let him say "Yeah, I understand." Ask him to re-state (in his own words) what he is supposed to do, and make corrections as needed. Then ask him to put together a plan and go over that before he starts coding. Also, keep an open mind; his approach isn't necessarily wrong, just because it isn't what you would have done; of course, it is possible his approach won't work, but it's your job to guide him to a working solution, not to do it yourself.

The only thing I'd add to this answer is: In the future, don't delegate important tasks to interns. Interns should only be working on things that it's no big deal if they don't pan out. — Jun 23 '15 at 19:36
@NotMe I'd disagree with that sentiment, at least for how my place of work handles interns. They are paid and they are here to get valuable experience, I'm trying to make sure they get it. There really is no task I can give them that isn't important — Jun 23 '15 at 21:09
@TomSterkenburg, it sounds like your company culture is inclined to give interns a bit more responsibility than usual (I'm currently in a similar environment). Such an environment probably accepts the fact that intern work may not pan out and understands the risk this could have to projects. I think the project owner should have input on whether you coach your intern to get the task back on track or take it over for them. I didn't post as an answer because this doesn't give advice on your actual question. :) — Jun 23 '15 at 22:24
@TomSterkenburg If you really want them to learn, you could ask them to rewrite their code - this time according to your standards. I never learned from people who wrote code for me, I did learn from people who told me in what direction to go (use a list to loop through, use technique-x, etc.). Also, don't tell any pitfalls, like "check for null here". Those are most valuable. Also, you said you have client interaction. Include the interns in that part, if possible. I always enjoyed moments like those. — Jun 24 '15 at 10:02
This. If the intern hasn't understood the task, and you don't make a second attempt at communicating it better, then how are you not going to feel defeated? Interns do things slower than experienced employees, but you should still follow through all stages of the task if at all possible, and "scrap it and start again" is a stage of any task where the first attempt is completely useless. — Jun 25 '15 at 7:30

score 3 · Answer 10 · 2015-09-10 21:38:49Z

Never just scrap and rewrite the code for someone else. If the person works for you, sit down and explain what was wrong and what exactly you want and then force them to do the rewrite until they get it correct.

Otherwise you will be doing both your job and theirs and they will remain not competent. Many people get frustrated when this happens because they don't see why it was rewritten and just assume that everything they do will be rewritten because Joe is a control freak, not because it has problems.

They don't get any better when you do this and it does them a great disservice. It also means you aren't delegating correctly and that you will be overwhelmed and they will coast along happily thinking they are great and you are a jerk. It is harder to train someone than it is to rewrite. But once you have taken the time a couple of times. then you will get improvement because very few people enjoy having to redo their work.

Now it might be that you need to sit with this person and pair program if they really have very little knowledge. But in this specific case, you make them come up with a solution and you just stop the intern when he starts to go in the wrong direction. You keep asking questions like "Why did you choose this method? Have you considered...library? What do you think the impact over time of doing this would be?", etc.

And remember this is not just the intern's fault. If you were not clear in what you were asking for and if you didn't check on them every day and look at interim pieces of their code, then you were as much to blame as the intern. So don't make this a blame session, make it a productive, constructive criticism.

panoptical 3,5761538 · Answer 11 · 2015-06-23 19:20:05Z

In short, sit down with the intern and have him/her watch as you code the project, explaining to him/her why you're coding the project the way you are, teaching the intern good coding practices along the way. Instead of reflecting on the intern's failure, you can make it a teaching experience. Failure is really one of the best ways to learn what doesn't work, and while you shouldn't be rude in bashing the intern over the head with their bad code, you do need to illustrate why their code won't work, and why the best plan at this point is to start over.

Whether the intern feels defeated or not is up to that intern. They'll need to be able to learn to deal with failure anyway, if they haven't already. However, if you treat the situation right, at the least the intern should come away with having learned something. In this situation, that's much more important than worrying about them feeling offended or humiliated.

I would definitely code with him if he were available today, but there are time constraints and I need to get it done today, unfortunately. — Jun 23 '15 at 19:34
If its a time issue, this is another reminder to yourself to make sure he knows time expectations. I assume you're working late and he already left? Theres not much to do in this case then do it yourself. He will lose the opportunity to see you code it. — Jun 25 '15 at 0:53
@TomSterkenburg: if the deadline is today and the intern hasn't completed the task and isn't in the office today, then it sounds as though you didn't give the intern enough time to complete the task, and/or you didn't catch the intern's mistake early enough for them to recover. This is all part of your education, of course, you have to allow time for interns to be slow. These things happen. — Jun 25 '15 at 7:33
Under no circumstances should code the task. You should have him code the task while you watch and provide verbal guidance. He will never get any better if you redo his work. — Sep 10 '15 at 21:37

score 1 · Answer 12 · 2015-09-10 21:41:31Z

Consider Pair Programming with the intern. Either pair program walk thru their incorrect code and try to fix it, or walk thru their code, explain its flaws, and discuss and Pair Program new, better code. Pair Programming is the best learning tool, knowledge transfer, code review, QA, all wrapped in one!

Sometimes, with time constraints, you may need to just scrap their stuff and get the job done. Have done this before, and it was with a senior developer. You could tell they felt slightly defeated, but they knew, we needed to get a job done.

if time permits, take the chance to learn together. they will learn how to program better, you will learn where the miscommunication happened. You will learn how to explain and write stories for tasks much better if you see how others interpreted the request.

Pair programming is great but if you do it, the intern must be the person who actually handles the keyboard. — Sep 10 '15 at 21:39

user8365 · Answer 13 · 2016-04-15 21:08:27Z

In the future, you need to let interns know that they are taking on a critical task, but if you are not able to approve their work by a certain time, it will get done by someone else. This is fair, open and honest. This doesn't mean they shouldn't take it seriously because you want to be able to give them a good recommendation. Interns shouldn't be burdened with mission-critical pressure.

Try to do some sort of debriefing so you can understand where you failed in explaining this problem to the intern or what assumptions you made about their skill level. There's no reason not to make this a learning experiences for you and your company as well.

Since you didn't do that, I would start with this explanation and apologize for not stating this in the first place. My guess is the intern will understand. Keep them in the loop about your approach. Take the time to explain as much as possible. If possible, don't redo everything. Hopefully there is some redeemable code there.

Give the intern something to so as soon as possible. Let them get back on the horse after they fall off. Maybe they can rewrite this project with your latest suggestions.

I just think if you approach it calmly and professionally, the intern won't beat himself up too much. It's important they understand that you want to stretch their skill set and there should be some realistic level of failure but not total failure. Sometimes you just run out of time.

TOOGAM 2,356512 · Answer 14 · 2016-04-15 03:01:37Z

I want to scrap his code, write my own, and explain to him how and why I coded it that way

Yes! Do it!

Err, maybe.

I've read the very sensible objections to this approach. Now that I just dumped a barrel full of gasoline onto this fire, I know I have some explaining to do. My quick summary is that this approach does have potential to be quite useful.

A widely quoted example is the U.S. Government training people how to detect counterfeit money. People have been taught this skill by becoming very familiar with what is right, rather than studying what is wrong. If the code created by your co-worker is sufficiently dismal, the best option may be to eliminate what is useless and demonstrate what is good, and discuss what is good and make sure that he can do what is good.

So, despite the objections other people have brought up, I would suggest that your plan may have merit, and might even be the best plan. However, it also might not be. When my career took on the role of being a college instructor, I got to see the quality of work that a bunch of students created. I also saw just how effectively people were learning some things, and not other things. I began to really see how different teaching styles are effective for different people.

I've also learned that delegating successfully involves giving someone a task that they can do successfully, and that involves determining their skill level. Case in point: some people are reluctant to make decisions, but they do know how things ought to be done. You could ask them, "Well, what do you think should be done?" By prodding them into taking the needed action, you may cause them to start to realize the power they could be utilizing, and may thrive. Yet if you ask the same question to a person who just joined an organization, and this person doesn't know enough details to have a basis to make a sensible decision, identical prodding may only have the effect of being disastrous.

If you're trying to train somebody, be sure to ask questions (early in a process) to verify understanding and determine what approach is helpfully working, and what approaches are not. Focus on giving them the structure that they need, with clearly defined desired results and maybe even clearly defined approaches, and then leave them to the task of accomplishing the simple-to-achieve goal you laid out. As for providing examples (made by you, and made by him), and providing instructions, the usefulness of a specific approach will vary by individual.

Search This Blog

Iyfjky

How to take over an intern's task without him feeling defeated?

7 Answers
7

Your Answer

Post as a guest

7 Answers
7

7 Answers
7

Post as a guest

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

Category

Random preview

How to take over an intern's task without him feeling defeated?

7 Answers 7

Your Answer

Sign up or log in

Post as a guest

Post as a guest

7 Answers 7

7 Answers 7

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

7 Answers
7

7 Answers
7

7 Answers
7

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor