How to help a struggling newbie do a better job?

Question

I have been the only developer and the de-facto "senior developer" on my company's flagship product for a while (a .NET WinForms app, but that is not related). Just recently, they brought in a "newbie" developer with a fresh computer science degree. No experience with source control, unit testing, software maintenance, etc.

I recently assigned him a small chunk of work and made myself fully-available for assistance, only to find his output lacking in a big way, both in terms of speed and quality. I tried not to be too heavy-handed, so the only upfront guidance I gave him is a wiki article describing the task that I update (but he has not), several code samples on new technologies (such as IPC), and I decomposed the tasks into several FogBugz cases (to which he provided no original estimates, actual time, or commentary until I told him what I would put). He rarely asked questions and, when he did, he seemed to follow my suggestions as though they were requirements, often without understanding them and even when they were wrong.

So ... I fully sympathize with his situation where you don't know what to do and are afraid to ask questions. I know it is my responsibility to do a better job, but no one gave me any guidance so I have no experience with what a better job looks like. Luckily, he is on vacation for a week, so I have some time to think about how to improve the process. Here are some of the items that occur to me, but I am open to suggestions and criticism:

1. Ask what part of the last iteration was most difficult. Ask what part took much more time than he expected.
2. Do some pair programming. I already suggested this and he seemed open to the idea, but each time we started I tended to take over because he wasn't typing fast enough. Something I have to work on.
3. Have a code review before checking the work in. (We did not this time because of his vacation.) The code review would highlight the following items.
4. Require comments on all public members. (None of his code is commented.)
5. Require him to remove all unused code. (A cursory review shows he did not.)
6. Require him to commit code to each FogBugz Case as he completes it and/or revise cases where they differ from what he discovers while coding.
7. Require him to enter original estimates into FogBugz and toggle the "working on" flag to keep him on task.

While the code review stuff is specific and technical, I am more concerned with his ability to be a self-starter and to ask-for/get guidance where he needs it. I don't think of the FogBugz requirements (6 and 7) as hard rules, but it seems like he needs to follow them to keep him on track.

Also, I know I need to improve my mentoring/training skills as much as he needs to improve his coding skills. Any suggestions on where to start when the "senior developer" has not participated in a formal code review or made it through a pair programming session without taking over?

My impulse is to update the stuff he already checked in, but I know I should save that for a code review. I wanted him to check the work in so I could begin coding the part that uses what he checks in. So should I use what he checked in even though I don't think it is satisfactory?

Answer 1

Do some pair programming. I already suggested this and he seemed open to the idea, but each time we started I tended to take over because he wasn't typing fast enough:

That's definitely not OK. That probably won't help him think he's got space to learn.

Don't make lots of changes to his work whilst he's away. That'll make him feel terrible. Instead, work on refactoring it with him when he gets back (and at all costs avoid the urge to take over typing).

Highlight the things he's done well (he's just made his first change - that's a huge achievement worth celebrating), and only once you've done that talk to him about where he can improve, and do so whilst reinforcing what things were good about his change.

In future, it might be a good idea not to let people check in code that hasn't been reviewed first (per your point 3), and only allow changes to be checked in once all problems highlighted in the review have been resolved.

_{NB. I've never done any management, so this is just describing how I'd like you to deal with this situation if I was the other guy.}

Answer 2

Well, you deserve a medal for putting that much time into this issue.

I'd suggest these things:

1. Make him read Code Complete.
2. Treat him like a senior programmer, but check every step he makes until you see good results.
3. Don't take over or he won't learn. Let him make mistakes, but then make him fix it.
4. He should always make estimates. Then have him acknowledge when his estimation is wrong.
5. Always encourage him to think. Fresh CS students hardly think; they code like robots.

Give him some ground rules, like: never write the same code twice, and if you do so, check your design, etc.

Also remember that he is afraid from you as much as he wants to learn from you. You may have forgotten things that he is learning, so you need to push him to ask questions and make sure he doesn't feel stupid in doing so.

In six months he will be good and ready! (to leave and look for a better paid job :-) )

Answer 3

Maybe you should develop a "checklist" of what is acceptable coding standards for your company. For example, you could include some things like this:

1. Every method is documented and follows C#/Java/ standards. You can enforce this by providing relevant links to those standards so he knows where to look.
2. Each method is clear and efficient. This is a bit subjective, but it's a checklist item that gives you talking points to go over with him as you review his code, and it will help him see where he needs to improve.
3. Each method throws the proper exceptions. If you define custom exceptions in your designs (a good practice in general) make sure he's using them properly.
4. There is no code redundancy. Make sure common code is factored out into helper methods, etc.
5. The technologies are used properly. For example, if you see him writing a "substring" method for a string, he should know to use the substring method in the string class itself rather than reinventing the wheel.

The point is, by having a checklist/scorecard, it gives you a way to review his code a bit more subjectively and gives him valuable feedback on how to improve.

And I think it'll help you "keep your hands off the keyboard" :).

Good luck.

Answer 4

• Don't put pressure on him with time.
• Break up tasks as much as possible - in fact break down things into the smallest steps you can think of
• Don't expect him to give useful time estimates
• Be SURE TO HAVE CODE REVIEWS. Review the code and give good feedback.

Encourage him when you can.

Kudos to you for wanting to mentor.

Kids coming out of school have no useful group development skills and have never had to work on code that needed to be maintained. This is a big step, but one that should and can be overcome within a month or less.

The main issue is setting expectations for the work that he is to produce. If he knows he will be checked on everything and you are consistent with the quality then he should eventually fall in line.

If he doesn't then there are other problems you have to address.

Good luck

Answer 5

I would have this person only do very limited, well-defined things for a while. For example, have them implement some methods in classes that you have already defined and for which you already have unit tests implemented.

Once they can do one very limited thing acceptably, move them on to another type of task. After a while, they will be able to to 5 things well, then 10, and so on.

I have to ask - what was your involvement in this person's hiring process? Did you interview them? Were you allowed to register an opinion regarding the skill level of the hire?

For a two-person development team, I would avoid hiring either team member directly out of school. There is just not enough slack on such a small team to support the amount of on-the-job learning they will need.

Answer 6

Sounds like the new guy's problems might be getting detected far too late in the process.

In addition to reviewing his work-in-progress and the code he's written, emphasize up-front analysis and planning. When giving him a task, have him sketch out the problem definition, algorithms and schedule on a whiteboard. Discuss it with him at length, and fix any problems you see at that stage, rather than waiting until time has passed and the damage is done.

It's my experience that the earlier a problem is detected, the quicker and cheaper it is to fix.

Answer 7

This is a difficult question and there won't be a single "correct" answer, but here a few comments and suggestions:

So should I use what he checked in even though I don't think it is satisfactory?

Definitely not, IMHO. You need to do a review together first. Otherwise, how is he to believe you that the code is not satisfactory if you are using it?

Require comments on all public members. (None of his code is commented.)

That should be a simple one. There is no excuse for no comments. If you are following a coding convention, show him this convention. If not, maybe it's time to write a small one. You can incorporate this in the code reviews as well.

One thing I see missing from your ideas is asking him what HE thinks he can do or you can do to make it easier for both of you. Does HE think his code is satisfactory? etc. You might be surprised at what he has to say.

Answer 8

Very rarely does a computer science degree actually deal with real world programming tasks like source control, bug tracking, project (self) management, or even programming beyond the basics. It's probably a scary thing to him to be in his first job. One thing that is worrying is his slow typing speed, indicating either a lack of confidence programming (a big worry, but can be overcome if he's got the right idea), or that he did CS because he was thinking of the money, not that ability is required (major worry that indicates failing probation).

Encourage him to design solutions logically on paper first - see how his thought processes are without the stress of actually coding with you watching.

Never take over the keyboard when pair programming; otherwise this is a good idea. Also let him sit in on your programming too.

Ask him about the tools that you are using and his prior experience. If none, it might be best to give him some training until he is confident.

Answer 9

You want to bring him up to your professional standards? Great. You need to teach him what they are. From a mentoring viewpoint, don't drop all the rules on him at the same time. Work a new one in every day. Over time he will get there, or get rid of him.

One thing that is missing from your list is code reviews. Yes, you should review all of his code, but.... He should review all of your code as well. The learning goes in both directions that way. It will make him feel like part of the team.

Answer 10

What you're doing is great and you have recognised the points where you yourself need to improve.

My process is to try and keep newcomers as motivated as possible. Currently I have a colleague which I give little quizzes and "fun" tasks that she can do in her spare time to keep her motivated. When working on actual projects I make her start her own branch and tell her to go for gold and reassure that "she can't break anything". Once complete she will let me know the task set out is complete and I will then perform a code review, making suggestions or showing her alternate ways of achieving the task set out, this is often done together.

I think it's an extremely bad idea to take the keyboard off someone, while they might be slow, you need to understand that it could be felt as degrading.

From what I've said my best feeling is to keep them enthusiastic and hungry for challenges, this will motivate and encourage better practices.

If you're finding they don't provide sufficient results then you should indeed request them to update their code, and ensure the code is documented sufficiently (and not overdone as sometimes is the case).

Treat them as a friend who you always encourage and they will go a long way.

Answer 11

My suggestion is to ask him how he thinks he is doing. If he thinks he is doing awesome and is the greatest thing in the universe, then you may have a bigger problem. On the other hand, though if he thinks he is just getting by, then it may not be so bad to try to show him some of the ropes. I'd suggest giving him smaller tasks and reviewing parts of what he writes so that he isn't so off track that it is a wonder he ever got to that point.

Another part to this is the question of what kind of relationship is there between you and the new guy? Are you his boss, a co-worker, or something else? I suspect if you have a talk with him about a few things, it may help straighten things out. I remember on my first job having to have a little hand holding to get through an initial trial by fire assignment. If you can, try to have a couple of times a day where there is a sort of check-in in terms of where he is and what he is doing.

Answer 12

Great question, and some great responses!

Another suggestion I would add is: when you are doing paired programming, don't be too quick to correct his errors. Make note of them yourself, but let him continue and see if he can resolve his own bugs/issues. Of course, provide a helping hand if it takes him too long (you'll have to decide how long that is), but some of the best learning experiences come from correcting your own mistakes.

Answer 13

Wasn't too long ago that I was a newbie, and I remember how it feels and the things that help me and things that I wasn't too fond of.

Tips:

1. Don't put him on a project where he is the sole programmer on that project. Put him under a lead developer and assign him small tasks that can be completed in a short length of time. It'll be easier for him to estimate something that might take 16 hours of work rather than something that might take 80 hours. Right now he's probably scared of giving estimates because he don't want to give you a "wrong answer". He's afraid he'll tell you 32hrs when you expected 8 or something. lol I was always afraid of that.

2. Reviewing the code before check in is good, but have him fix the problems himself. If you make significate changes to his code for him, it may make him feel bad.

3. I wouldn't recommend pair programming. I always wanted to figure things out on my own that way when I get it right I get all the credit. But rather be available for him anytime so he can ask questions. Being in the same room with the other coders on the project is very important, especially for a newbie programmer. Pair programming may be good later, but as a newbie I'd want to work on my own.

4. Knowing when to ask questions is a skill in itself in my opinion. You don't want to pester the guy behind you too much, but then again you don't want to search google for half a day and end up spinning you're wheels all day when the guy behind you knows the answser immediately. Encourage him to find answers on his own, but don't be afraid to ask for help if he can't find it easily.

5. He definitly needs to learn to comment code. Reviewing other peoples code will teach him the importance of that. He needs to learn to write "self documenting code". The "What" should pretty much be documented automatically by using good variable names and well thought out, easy to read, coding techniques. Sometimes comments are needed for telling "Why" code is written a certain way.

6. Having him do code reviews is good. Maybe you pair with him and you and him can review someone elses code with him.

7. Don't take over the keyboard too often. For a min is ok, but if he'll be a programmer he better learn to type as soon as possible, and practice is the only way.

8. As someone else mentioned above, he'll love to hear that he's doing a good job, so be sure to tell him when you see something he done that you like!

Answer 14

I appreciate your efforts to be a good mentor. Here is my 2 cents. I once had a Sr.Developer who used estimates just to check if the developers are using a right approach for a feature(no time pressure). You definitely know something is wrong if the developer estimates 10hrs for something which could be done in say 2 hrs.

He would then occasionally drop by my desk (not micro manage) to check if things are good and give some new tips or better ideas if I am struck. I felt his approach building more confidence in me and making me a better programmer. I would definitely say that this "Occasional dropbys with subtle checks" are more powerful and agile than a weekly code reviews because the longer a Jr. Programmer sits without much clue the faster he loses his/her confidence. Keeping it simple at the start will help newcomers adapt faster.

Answer 15

Congratulations on your attitude towards mentoring. The simple fact that you are asking if you are doing it right, and how you could do it better, means you are doing it right!
I think the issue is that you can be in 2 situations:
1) he/she just needs time and guidance to understand what the game is but will get there
2) he/she is not a team player, and doesn't care.
Obviously, if you are in situation (2), mentoring won't help. If this is the case, your best strategy is to limit the damage the person can do, and try to get him/her off the team. But you won't do that without giving the person a chance, which is what you are doing.
Lots of good advice has been given already. Assuming you are working with someone you can mentor, my 2 pieces of general advice are:
1) help the person understand what is expected form him/her. Give the person small tasks, say what you will look for (code duplication...), and look together upon completion for these. Be encouraging, but stick to the rules: if you agreed together that one thing had to be done and is not done, don't let it slide, this is disrespect to the team. Don't fix the code, send the code back for fixing if something has not been done as agreed. This will help him/her get on track - and if repeatedly the same issues occur, sorry but you have a dead weight on your team.
2) build trust. College should give a good understanding of theory, but usually is poor preparation for working in a team, on large pieces of software. Get the person to understand that poor commits impact the whole team. Get him/her to understand that asking questions is good, and that everyone does mistakes. I found pair programming great for this, because it shows that no one is a god (but don't take over the keyboard, ever!). Ask the person to assess what they did good and where they had problems with a feature, and tell them your assessment of what was good and not so good, or where you see improvement. Also to encourage questions, go ask questions, too, if you can - or thoughts on a problem you are working on.

Answer 16

I would start implementing test driven development. Then you could give him a list of requirements, or if you're feeling really nice, a list of tests to write to and then let him rip it up.

I'd also remove the "Require comments on all public members." because he's probably trying to think of something intelligent to say in the comments instead of actually coding. Pretty soon you're going to start having comments on your public members that say something when the code does something else.

I think pair programming also tends to be lop sided in these cases. You need more of a peer (someone at around the same level) to do pair programming as you're just going to end up giving him lessons in coding. With pair programming both people should be getting a benefit.

Answer 17

There is a lot of excellent advice being put forward here, and it might be difficult to impart all of this information to your employee directly. Have you considered introducing him to StackOverflow and letting him read this question and its answers? Of course, you should talk to him first, so that the criticisms that you identify will not come as a painful surprise.

I see several benefits to this approach:

1. He may become involved in StackOverflow, which is an excellent way to improve your programming style and learn the ropes
2. He can see things from your point of view
3. He can see all of the advice first-hand, and know that we have all been there before
4. It will open the door to a very honest and up-front employer/employee relationship

Answer 18

Lots of good points here already so i'll just add a little.

I'm a big fan of code reviews but when you're dealing with a rookie coder the amount of "issues" you find in the code can be overwhelming. I tend to review the code and then go through the notes with the other developer. I am very careful to separate out the real problems and the "pedantic crap" (which I label so and put at the end, i.e. no comments here, the naming style of this is wrong, find a better name for this etc).

Also be willing to make the odd trade-off. Citizenship is important, so if the rookie adds a classname that is only okay but you can think of a much better one consider letting them keep their name so they feel like they "own" a part of the system.

Oh and if you're reviewing HIS code, get him to review yours too. ;)

Answer 19

1. Give them individual, well defined, bite-sized chunks of work.
2. Let them know why each chunk is necessary.
3. Start them with two chunks, so they can choose which to work on next. As they learn to handle multitasking, give them more than that, and give them priorities and rough deadlines on each. Make sure they have buy-in; they need to feel every deadline is reasonable.
4. Personally, I tend to also give all new devs a copy of The Pragmatic Programmer.

Every once in awhile, I try hard, they try hard, and it just doesn't work. Which everyone would agree sucks, but statistically, it happens; at some point, learn when to cut the cord and look for a new dev. I tend to wait too long, which results in more stress for everyone involved.

Answer 20

How are you assigning the new developer tasks? Are you expecting him to just pull things out of your iteration and go to town on them? If so, it would probably be helpful to not do that for the time being. Pick out a small, somewhat interesting task to do - either as part of a task in your iteration, or a sub-task in your iteration. Provide him every piece of information he'll need to implement - including stubbing out the methods and (if you're using them) unit tests to ensure its working. Make sure everything is written up, and meet with him to go over what he needs to do.

Be available on a daily basis to answer questions, if he has them. Don't press him immediately on deadlines for this thing - just keep track of the progress he's making on the task.

Once done, review what he's done. Suggest changes that he needs to make.

Once past this, slowly start to increase the complexity of the task you're giving. Perhaps the next task will tackle more than one layer, or will involve adding a more involved feature - your specific environment will dictate this, as will your experiences.

There's definitely a learning curve here. Every person will tackle that curve differently, you're job is to (a) keep him on that curve and (b) to recommend upwards if he's going to be able to keep up at all.

Answer 21

Here is some advice from the way this is handled in Japan.

First of all have him setup his working environment (give him a week to do it), then tell him who is who and give him a list of the mailing addresses of his co-workers. 1 week won't put much pressure on him, and he'll achieve something tangible in his first 5 days

On his first Friday take the new-commer out with the team for a few drinks, go-carts, or disneyland (it's about an hour away). It depends on your tastes and what the new-commer prefers. This will help him understand the team, and see them interacting at a personal level, and it'll help him feel like one of the family. This way he will feel much more confident about approaching others for help.

Next have him do some basic coding for 2-3 weeks. Give him say 5 really small assignments a day on his first week. Basic fizz-buzz level stuff. And do a code review at the end of each day.

During his 2nd-3rd week have him work on a toy project (with a real deadline). In the same field as his future work, but not part of the actual project. This way he has a sandbox to work on without fear of breaking other people's work. Review the code with him twice a week. And have him present his work to the team after it is done. This will give him invaluable confidence.

Now after his first 3 weeks of basic training, go for drinks or fun with the team again.

He has passed the initiation rite (very important psychologically).

Now put him to work on the real project, but give him a week to read up on code and ask questions. At mid week and the end of the week setup meetings so he can ask questions to the team, without feeling like he has to interrupt anyone.

Now that you have a happy, inquisitive and confident new-comer, do all the stuff that everyone else is suggesting here :)

Answer 22

Here is my view Please, correct me If i am wrong.. As a starter the student expects a certain level of training... This is so because he would have had heard that his friends are getting trained in other companies and are performing better..... In this case you need to make him feel that web is his only guide.... And u need to help him a bit and understanding few things... Because as soon out of college its a bit tough to digest Repository tools,frameworks and other things...Since he is not trained on this now and u put him on a project directly it is tough for him to understand things..... Give him some time and make him understand things ....until he realizes he is responsible then i think things will become smoother........

Answer 23

Code reviews and pair programming (let him type!!) are definitely a good idea and an excellent time to impart your preferred coding style / go over language features that he may not be as familiar with / change all his keybindings. You should also take these opportunities to go on tours around your codebase to show him helpful classes or patterns that relate to what he is working on.

I would also suggest having whiteboarding conversations with him when you assign new features / bugs. Try to ask him questions about how he would satisfy the various requirements or whether he thinks there are any missing requirements / non-requirements. Make a point of having him come up with as much of the design as possible, even if you have already thought of a good design. This way, you can gauge his ability to think independently while still providing design guidance, and he will get more comfortable with the process.

Answer 24

I've got a similar issue at my work at the moment. I'm doing the following

1. Emailing him links to useful online videos (eg Google's clean code).
2. Peer reviewing everything he does.
3. I've recently started making sure he's commenting methods and classes with what their responsibilities are prior to starting to code, to help him think about what it is he's trying to do, and to ensure each method and class only has the one responsibility.
4. Offering him books to read (eg Code Complete sitting on my shelf)
5. Offering complements and not putting him down, and where I need to point out how something is wrong, being constructive. We were all young and experienced once...

Answer 25

First of all he should read a complete tutorial of the language being used and a good software book like 'Code Complete'.. another important aspect is that he has to know what the job is about, why is he doing the job and what is the big picture there. then he must be given the impression that he could ask anything and also search it himself.

Answer 26

I would certainly drop the time estimate requirements.

It's nigh impossible for a newbie not experienced with the technologies at hand, not experienced with development in general, nor with the system hes helping building to priovide any kind of reasonable estimates. He needs training and experience in the "real" world before that's even sensible.

Answer 27

You mentioned FogBugz. If you're using EBS then asking him for estimates should work out in the not-so-long run. I'd like to add my vote to the "give him small pieces of discreet work" option.

I had one developer that really struggled to stay on track with the requirements and avoid adding "bonus" features. I know it's not quite the same issue, but I think the solution might help. We got together for 15 minutes every two hours to review what he had done, how he'd done it, what he was plannign on doing next and how he was planning on doing it. It worked very quickly and after a small number of weeks we were able to start extending the intervals to four hours then daily and eventually after each multi-day task.

I think the main thing is, as others have said, that you're aware there's an issue on both sides and are here looking for help to address both sides :-)

Answer 28

You have to find a way to motivate a newbie in the team ,to me motivation is the difference between the ones who are performing and the ones who are not performing and motivation comes from objective , objective of the company ,team or individuals and you have to keep reinforce your self and your other team mates your goal daily, and their is something certainly wrong in your communication mate , make him comfortable so tell him that he can ask just any thing from you , you have to made him learn quickly by all the good suggestions suggested above like read code compelete ,code review etc

Answer 29

I really appreciate your effort. I also worked as a newbie recently, luckily with good mentors. The learning curve and adaptation to the company, work, working environment, and getting used to people and their working style is at least 3 months or more for me, of course if the business is very complex it may take longer. Here are my suggestions:

1- I guess, since you are the only developer, the training period is also your responsibility. Give him/her some orientation about the people, business, technologies with samples and be sure if he/she gets the big picture.

2- I think(and prefer) the best way for adaptation is fixing small bugs, adding small features, reading some books and tutorials about the technologies used and trying to understand the project during this period.

3- Code reviewing with a proper tool, like Crucible is one of the best ways. You can also encourage commenting at your reviews.

4- Pair programming would be nice, but please do not be so strict and picky, I remember after a weekend of pair programming, my mentor just removed all my code and started all over the project, without asking me, it was really very difficult for me. If you are not patient enough to let him type, pair programming would be worse for both of you.

And last, he/she may find asking questions difficult, the reasons may be not bothering you with lot's of questions, or being afraid to ask stupid questions to one and only senior. I also agree with the too late detected problems, you may get together frequently and talk about the current task, possible solutions and difficulties and encourage him/her to ask more questions. And yes, I agree with the others it is just too early to expect him giving estimations :)

Answer 30

This is very general in nature, and can be used with others suggestions on specifics.

While this might sound obvious, confront the person (in a nice way, but with enough frankness to enlighten). First, ask if they wish to have input and share ideas on improvement, (it goes both ways) if they do not, you are done. If they do, you are off to the positive side, you KNOW what you see, let them know up front frankly what you observe, and ask if they wish specific input on/within each of those areas. ALWAYS let them know that everyone started at the beginning and this industry is ALWAYS about learning - try to find some positive that THEY can share with YOU very early on - you will find this will put the emphasis on "sharing and communication" and not be dictatorial and autocratic in style and you get to learn stuff also!

Keep in mind always that opening up communication is the real goal here, which in turn leads to the product and performance quality state improvement you desire. And this is an industry with a large number of personality types where this is challenging.

Answer 31

This has worked for me.

1. Give him a task that is measurable. If it's not measurable then he won't know when he's done and probably spin his wheels. The best metric to stick him on: Code Coverage
2. His job is to get the code coverage of the existing code base to 100%, no less. Start with one module and then expand his scope.

I think this works because it quantifiable. Code Coverage increases or not. It also forces him to understand the code base. Reading code is a great way to learn. Getting that nested class with an exception clause to execute to get 100% coverage requires some effort and when he gets there, it'll be time to celebrate.

Give him this work until he asks for something else. At that point, you can evaluate whether he's ready for something more substantial. This should be around the 3 month mark.

Answer 32

As a soon-to-be computer engineer (and junior engineer), I can sympathize with the newbie.

One of the most important things to make clear to him is that the he won't get in trouble (or get fired) for making mistakes early on. Encourage him to try, even if he doesn't think his code is perfect.

In my first job, my tasks took a lot longer than I wanted because I was afraid I would miss something or make a simple mistake that would make me look like an idiot, so I spent more time checking to make sure everything I did was right.

Answer 33

I recommend you watch Developing Expertise: Herding Racehorses, Racing Sheep by Dave Thomas it is all about varying levels of expertise and how to deal with the situation. You'll find the best way to deal with a newbie is to give him very specific instructions.

Answer 34

Pretty much everything that needs to be said has been said - lots of good advice.

I'd add just one thing: He may not realise fully realise the scope of his job - that estimating, writing tests, bug tracking etc. are actually part of the task and fully his responsibility. Perhaps a non-confrontational talk where you explicitly make this clear - and make it clear that he needs to be self directing - could clear up some confusion about what's expected of him.

Full marks for trying so hard to do the right thing.

Answer 35

One thing I have noticed through the years is that people never improve their performance if you fix their mistakes. (Most of the time they won't even realize you changed it because something was wrong; they will think you are just a control freak who can't let anyone else's work stand unchanged.) Identify the problem and ask him to fix it. Do as many iterations of this as it takes.

Make it clear that a question asked early is far better than a missed deadline because he didn't understand something. Don't get snippy and snappy when he asks a question either. If he thinks he is bothering you, he won't ask.

Take some time at first when you give him a new task to sit down and discuss possible solutions. You can save a whole lot of time by directing his design process rather than waiting for a final result to check.

Code review his stuff and have him code review yours. Seeing better code will help imporve his process. His questions when trying to understand your code will help you better understand his thought process.