I'm in a bit of a precarious position.

I'm working remotely for a client that has recently brought in a junior developer straight out of college into the project. He works physically at their office. I believe he studied computer science (although I can't recall 100% at the moment).

He has been with the company a couple months now and was started, by the project manager, on testing and getting familiar with the app and for about the past month, has been assigned small bugs and features.

The thing is, in that time, he has only committed code once and it was code that I basically walked him through and wrote out for him. (I thought it would be beneficial for him to see the working solution after he had spent days trying to get it to work).

I have had a few calls with him and some pair programming sessions but he is spending days getting frustrated at simple JavaScript code that should really not be that difficult even for a junior developer. I am beginning to think that maybe programming is not a good path for him but want to make as much effort as I can to helping him find solutions on his own and help him improve.

This is the first time I have been in a position of having to provide training and mentoring. Being remote probably makes this much more difficult as well.

What can I do to help him improve and to get him going?

  • 3
    Have you discussed this with the project manager? It is a company problem that this goes well.
    – user1249
    Commented May 21, 2011 at 8:45
  • 5
    If he studied CS, he may have spent a lot of time doing things like mathematics and logic, but rather little time actually programming. I don't see any reason why he would be unfit for programming. He is probably just inexperienced.
    – lala
    Commented May 21, 2011 at 9:34
  • 5
    Remember to go farther than usual to put him/her at ease and be extra friendly. When you are remote, it's a lot easier for your help and assistance to be misconstrued and for the programmer to develop unnecessarily negative reactions to your help. Also, you'll need to rely a lot more on the programmer self-reporting problems, s/he'll have to be very comfortable talking with you about what's bugging them before they can do that Commented May 21, 2011 at 22:21

8 Answers 8


Depending on where he went to school he may not have more than a few months experience doing very trivial things in one language. That can be fixed, but make certain it is worth the effort.

It sounds like you need to tell if he can be salvaged or not.

  1. put the code away for a little while
  2. explain a small to medium sized problem that exists in the project
  3. have him explain to you how he would solve it - no code, no patterns, to practices, just native tongue or diagrams explaining what needs to happen at a base level.

If he can come up with a half reasonable solution or even a bad solution, but by thinking through the right problem solving process he can learn the code. If he cannot think through the process of coming up with a solution correctly you probably cannot teach him how to think better.

Also make certain your management understands the situation or you are going to be doing two people's work before too long until your new guy catches up.

  • I'm marking this as the accepted answer. Although the other answers all offered great advice which I have tried, Bill's answer really gets to the bottom of whether programming is something he can do. I believe a person that is unable to think about the steps involved in solving a problem and come up with pseudo-code (in English) is not going to be a good fit for programming. Commented Jun 1, 2011 at 22:19

Give them the chance to shine

I've actually had a very similar position for some time but now I think I'm making some progress with the developer. I think in the end it will only be a case of commit shyness but I just told him "I need you to commit and push to the server so I can help you better if you get stuck, and you can help me better to oversee the project", and then he started committing.

Give them responsibilities they can deal with (i.e. below their level) to improve morale.

Give them the chance to fail

It is also important to let them take decisions and fail, it's called learning. Give them the power to take little architectural or design decisions and see how they perform. Once they fail, tell them how they can do better and then sit with them.

Don't get impatient because you know you will do in 5 minutes the job they will do in five hours. Let them do it.

Smaller assignments

Having smaller assignments and clearer objectives will make them feel less lost and attack better the problems at hand; baby steps if you will.

Not all people have enough initiative, sadly, but initiative can be taught.

Be there by not being there

Partly continuing the "let them fail" argument, but always stay in reach (e.g. IM) but not physically. If you stay connected with them by IM, you can sometimes answer them with the correct answer, but other times you can just leave them hanging and pretend you are busy (cruel, I know *evil grin*), and just tell them "brb, google XHR and ActiveX" or "google the compiler error", or "google "... by doing this you are partly making them feel stupid in a good way and progressively loose the fear of researching stuff by themselves.

Provide them with the tools

Do they know about Firebug or Chrome Dev Tools?. How about common js pitfalls?. Are they using a good javascript framework? (e.g. MooTools). You really need to give them the weapons to make his work as fun and productive as possible.

Think of them as your past self

You weren't always a pro, right?. How did you learn?, remember that and try to put them on the same path.

If they are not actually cut for the job...

Ask them if they are having trouble with anything, and let them know their performance is not good enough. Personally I like to be direct with people, and I do tell them that beforehand so there is the least resentment.

They might not know there is a problem if you don't tell them.


I had an experience like this with a junior programmer. I'll give you the anecdote, along with the obvious warning that what worked for her wouldn't necessarily work for anyone else.

Her problem was that she had never had to deal with anything in college that wasn't a toy system you could reasonably be asked to do in a homework set. And so when she faced a real problem in a real code base that had been evolving for decades, she really had no idea where to begin.

Our manager gave her a realistically difficult problem, which didn't have too many dependencies on other things, that I would have finished in a few days. I saw her getting stuck on it. After a while I began going over to her regularly and asking her, "Do you want a suggestion?" After a month or two she finally broke down and was willing to take my help.

My "help" consisted of getting her to break the problem down into small pieces. Every day I'd come in, talk to her, and ask her what her goals for the day were. Invariably she carved out some poorly defined and too big piece. I would tell her that that sounded too big to me, and I'd get her to whittle it down and commit to something she could realistically do by lunch if she encountered no serious problems. After lunch I'd check in on how it was going.

In a week she was making good progress and had figured out the rhythm. After another week she delivered a perfectly acceptable solution to the problem she was given. She did fine on her next problem and went on to do perfectly well.

It turned out that our manager actually expected her initial poor performance. I suspect that he would have eventually stepped in, but he saw what I was doing and figured that it would be more effective coming from a peer than a manager.

  • Many problems like this can be more easily detected and solved in person; the OP is remote - when remote it's worth being extra careful that useful information is not missed (you might not be able to notice the junior programmer is frustrated or tired or distracted, for example) Commented May 21, 2011 at 22:19

Find out more about his background and what he is familiar with. If he has a computer science degree, presumably he has done some coding (maybe not Javascript though). Whatever language he is familiar with, see if you can explain problems/solutions in terms of that language. If he can see the similarities, maybe things will start to click.

People learn in different ways, try to figure out how he learns best. You could ask this as a direct question, or again as part of probing about his background, find out what kind of projects he enjoyed and did well on in school and see if he can explain how they were structured. Some people learn best by being asked to solve a problem with little direction and doing experimentation/trial and error, while others will want to be shown step by step...

Another benefit to asking about his background is that you will be able to better determine if he really isn't a good fit for a programming job. Obviously he should be given some time and help to improve but if he eventually doesn't it is bad for both of you if he continues to try and work in a job that he just isn't good at.

It sounds like you are trying to do the right thing by helping him.

(Also: is it possible to arrange to work on site with him for a week or so?)

  • 1
    No, I am physically too far away. Your answer is good though. I should find out more about his background to find what way he enjoys learning. Commented May 21, 2011 at 4:54

it he's incompetent, do not protect him - you're doing your client no favors by stringing along someone who cannot perform

sorry to be harsh, but that's business; not everyone with a degree makes a good programmer

that said, if you want to help him improve suggest that he participate in code katas, join a local user group, try coding competitions, and in general keep coding and coding and coding until it makes sense or he realizes he chose the wrong profession

do not, under any circumstances, let this person become your responsibility - unless that is actually your job

  • 3
    I agree but with a junior developer straight out of college, I believe it is important to give a little leeway. Obviously, if this was a "senior developer" who was hired and couldn't commit anything within a month, I wouldn't be willing to hand hold him through things. I guess a follow up question is, how much effort does it normally take to get junior developers going on their own? Commented May 21, 2011 at 6:49
  • 1
    a CS graduate should be capable of completing simple assignments on a daily basis. how much time is he/she actually spending BIC* doing actual programming work? (* BIC = Butt In Chair) Commented May 21, 2011 at 7:00

Tough one.

Unfortunately, some people get through their programming courses by the skin of their teeth, and often on the help (and code) of others, so it is inevitable that someone comes straight out of college without having the first clue as to where to begin. (I could go on and blame the educational system a bit, here, as I think there is the tendency to rely too much on cookie-cutter code, as well as the tendency to abstract any of the low level programming away -- something I find fundamental to the process of programming, i.e., logic.)

Here goes:

  • Understand that he is totally new at this and has never had to deal with anything larger than a couple thousand lines of code (if that). When faced with a large-scale application with real-life consequences, he's going to be more than a bit tentative, and is unlikely to also understand the forest, let alone the trees and how they all interrelate.
  • Encourage where possible. If part of the code was usable, or if you could see the direction the code was going was a good one, then encourage, even if the end result isn't so hot. At that point, guide him to the solution, without spelling it out word-for-word. (I tell people that I google for everything. Amazing the people who ignore me, though.)
  • Allow failure. Let him see what happens when things completely and utterly break if at all possible. If it isn't possible, tell me this isn't going straight to production? Test environments rule.) One learns more from failure than they do from success. (I say this because I can write code that works, without understanding why it works. If the code breaks, I have to work through what it is supposed to do, why what part of it works works, and why the part that fails isn't working.)
  • Get into the background a little. This programmer may have a totally different method of learning and may not be able to make the same logical leaps in the same manner you do. (I'm a good example. I can make great, big, huge logical leaps that look simple to me. And then I wonder why everyone else is wondering how to get from point A->B while I'm already at point D. And then I remind myself, I'm naturally logical. Not everyone is.)
  • Give it time. Not time whilst doing nothing; no, but over time the individual should start picking things up. If they don't, however, it may be time to...
  • Admit defeat. Gracefully. And not really. By this I mean that you may need to have a frank discussion with the manager, but also realize that you are essentially being paid to help him. If you want to continue a good relationship with your client, gritting your teeth or dropping the client may be your only final options.

There are obviously a lot of variables at play here (and some other good answers), but here are some questions to ask yourself and some thoughts:

  • What is the management expectation of his position? Was he hired with the intent of being mentored? If so, how much mentoring is expected? This is important to help determine how much effort to expend on helping him get up to speed and be proficient, even if it is for small tasks.
  • Does he spend any "free time" self-learning about what he is working on? For example, if he's struggling with JavaScript, is he spending any time on his own to get up to speed?
  • Does he approach his peers when he gets stuck or is he biding his time? I've worked with a few developers who would sooner sit and stare at the screen than ask for help.
  • As mentioned in another answer, what is his background? Did he do any coding prior to college? Does he contribute to open source projects in any capacity? This is to help gauge interest and passion for the role.
  • When you work with him, do you allow him to "lead" and discuss his thought process? Do you help him reach a correct solution through discussion?
  • Does he show any signs of improvement as you work with him? Remember where he was when he started and how far he has come since then. Is the rate of competency growth acceptable?
  • Does he listen to you or others when giving advice? Some people will take advice and either ignore it or not understand it, but instead continue to do their own thing. This includes constructive criticism.
  • Does he actually cause more work for others? This is where it gets a little dangerous to keep stringing someone along for the ride. If someone is having a negative impact on a project, a re-evaluation may be necessary to determine if it's best to keep mentoring or not. You want a positive contribution, no matter how small to start with.
  • Does he have a positive attitude towards programming? A poor attitude can be detrimental not only to his own performance, but that of others as well.
  • Realize that not everyone is the same. This should go without saying, but there it is. Everyone learns and performs their tasks a little differently, but there should also be limits as to what is acceptable or not. This can vary from company to company and project to project.

So really, this should come down to expectations, attitude, aptitude, and contributions. If he shows he is capable of learning and picking up what he needs to know, then he may be worth keeping if he also has a good attitude.

The important thing is that he shows progress and growth and does not stagnate or get easily frustrated. This is a role that requires patience and some self-motivation.


Tough call. Try to identify the underlying basics he is missing.

To help you locate the area where the trouble is, ask him when was the last time he was doing well, the last time he really understood what he was doing, just before he got confused. It could be something he studied before he ever got in the company.

You will find that somewhere in that area, in the stuff that he believes he understand, is the real cause for his confusion. It could be something as basic as never having understood what a variable was or even what programming means. Repeat that a few times and he should start getting "brighter".

Another approach would be to look at the various things that he is stuck with. Then "triangulate" and find what the common denominators are. Note anything he does that make no sense whatsoever. Then try to understand how these fit together. If you can find a pattern, it should give you a pretty good idea of what it is that he really doesn't understand.

Another possible situation is that he doesn't understand what the application is supposed to do and why. A demo of the application and some context from the user's pov could really help there.

Once you know what he doesn't understand, you can help him effectively. Until then, you are just messing around and hoping to get lucky.

However, keep in mind that debugging him might not be what your customer is paying for, so unless you have an understanding with your customer, don't drop behind on your own targets.

Good luck.

Not the answer you're looking for? Browse other questions tagged or ask your own question.