33

We have a new Junior developer on our team. I think it was a mistake to hire him. This is a career switch for him - he was a System admin, and has been learning Ruby on Rails for the past two months, but he seems to mostly copy-paste code from tutorials without understanding what it's doing.

His approach to solving a problem is to keep trying random things until something works - no matter how many times we recommend it, he never wants to just take the time to read through the existing code to understand how it works.

He also lacks some general skills that would really go a long way:

  • ability to follow instructions - we often have to remind him multiple times to do a sub-task or implement feedback we've given him on a pull request
  • ability to retain information - a lot of time spent explaining things to him feels like it was a waste, because he doesn't seem to retain the information and repeats the mistakes. He either isn't paying attention, is pretending to understand when he doesn't, or is very forgetful: he keeps writing code with the same bad practices that we've been trying to explain why he shouldn't use.

I find myself dreading work on Sundays now - something that never happened before with this job!

The amount of time and frustration that's going into teaching him would be much better spent building new features for our app. We could probably actually save money by paying for him to attend a Ruby on Rails bootcamp, compared to how much of our time (and patience!) it's going to take to train him to the level of competent Junior developer.

How do I deal with this junior dev?

closed as off-topic by IDrinkandIKnowThings, panoptical, gnat, mcknz, scaaahu Nov 3 '15 at 2:35

This question appears to be off-topic. The users who voted to close gave these specific reasons:

  • "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – mcknz, scaaahu
  • "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – IDrinkandIKnowThings, panoptical, gnat
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 23
    Sounds like your company is hiring raw juniors without a satisfactory plan of what to do with them? Even for candidates you do consider to have potential, this kind of slapdash approach is going to cause trouble. – Nathan Cooper Nov 1 '15 at 20:09
  • 51
    You and your team, it appears, are not equipped to train juniors. TWO MONTHS from sysadmin to developer is a very, very short time yet you are expecting that everything you say will be understood? And you think he should get straight to business without getting confused and trying out a lot stuff randomly? – teego1967 Nov 1 '15 at 20:57
  • 21
    How are you "training" this person? – Pepone Nov 1 '15 at 23:28
  • 2
    I'll just put in a personal perspective. I'm a relatively new programmer myself (3 years and about 8 months), I'm primarily a T-SQL developer, but also use Javascript/PHP from time to time amongst other smaller languages. I was brand new to programming with no experience and very little knowledge of anything technical. I kept making the same mistakes until I was at least into my 2nd year of employment until I had everything put down in front of me in paper. Every job. Now I rarely make mistakes, but you can't expect someone to become a flawless programmer in just two months. – John Bell Nov 2 '15 at 12:57
  • 2
    From statistical point of view, trying just completely random things till something works should take ages. If he can do something that way, maybe the things he is trying are not completely random. – eee Nov 2 '15 at 13:21

12 Answers 12

49

What would you do in this situation?

Discuss the problem with your manager, it's his/her job to make sure your time is being spent productively. It's also his/her job to monitor staff.

If it's decided that training the non trainable is your task, then you're stuck with it, but most managers would understand that you're either not suited to training, or the junior has issues learning and will do something constructive about it.

  • 1
    I've been in this situation, and you're right, there's not much you can do. – Aaron Hall Nov 2 '15 at 19:09
34

The problem might not be with the intern, but with you.

Ruby is a very different language from everything else he might have encountered so far and even though I have some experience with it now, I still struggle with it more than with other languages.

If you can, yes, send him to a bootcamp. He needs to hear about the language from someone experienced in teaching it, not other developers who just use it.

How many junior developers did you have so far? How fast did they learn stuff? How fast did they adapt to your way of coding? Btw, these are two different things.

How complex are the tasks you give him? Do you add instructions how he can achieve them? How do you give the tasks to him? In writing would be good, also the additional information. Some people just work better when they can open the mail and look up stuff instead of memorizing everything. I know it's a common thing along people coming from theoretical computer science, but normal people just don't have that much storage in their head.

So start with giving him all the information in writing, then switch to him writing everything down slowly. Let him use a ticketing system to keep track of his tasks.

Someone is under the impression that he would be a good fit for the job, maybe even because he is working different than you. What you need to do is to figure out how to work with him efficiently. If you fail to do that, report to your manager and ask for help and insight what to do different. If the manager considers it relevant one day, he will let go of the junior.

For you the tasks is "program junior developer", so you have to use the "junior developer language" for a while until you have established subroutines for every command you would use in another language. And the IDE might not be so smooth like you are used to, but it might give you some insight into other areas. Ask him for help whenever you are stuck on a system problem for example.

  • 8
    The OP describes him as a junior hire, not an intern,,, – S. Kolassa - Reinstate Monica Nov 2 '15 at 8:51
  • 6
    OP makes clear that the junior hire is already getting far more help than anybody with "programmer" in his job title should need. I was once in OP's shoes, and we demoted our hopeless junior guy to testing. He was marginal at that as well, and eventually moved on to a much larger company that just needed cube meat to walk through checklists. This junior hire is cube meat and should be moved into a job he can handle, for everybody's sake, including his own. It's no kindness to let somebody flounder helplessly in a job they can't hope to master. – Ed Plunkett Nov 2 '15 at 15:42
  • 2
    If you need to spend that much work to make your junior devs somewhat bearable you're hiring the wrong people. As someone who's still not that far away from starting his first job I can say that "junior" doesn't mean "idiot that needs handholding the whole time". It means someone who has less experience and hence has to spend more time researching technology and needs extra guidance and checks in place. Yes let him explain to you how he plans to approach a problem and then point out possible problems, but don't give him a low-level check-list of things he should do - that's a disservice. – Voo Nov 2 '15 at 17:36
  • 2
    We've had a couple junior hires at our place that sound just like this. Turns out it was us and not them... Once set free, they've thrived at the new places they've landed. – Brian Knoblauch Nov 2 '15 at 18:14
  • 2
    @Ed Plunkett: +25 for "Cube meat"!! – Nolo Problemo Nov 2 '15 at 21:43
18

I would not expect a junior totally inexperience dev to be good by the end of two months, but I would expect him to be better than the start. From what you describe, he is not. If I were his boss, I would sit him down and explain what you just explained here, the problems, how he is not retaining information and what is actually expected and put him on a performance improvement plan. I would make it clear to him that if I don't see improvement in another month, he will be let go.

If you are not his boss, the most you can do is let his boss know exactly how little progress he is making. Specifically write up what you have done, what he has ignored and how you have repeatedly given the same directions and then set up a meeting to talk this out. You are a good dev that your boss wants to keep, make sure that he is aware of how frustrating this is for you. You don't have to threaten to leave, but letting him know that he is creating problems for the more experienced should be enough of a signal to him that this guy needs to go and go soon.

17

I'd like to give a bit of background for this answer first: I'm from Germany, where you can learn software development as an apprenticeship1 in a company and at school over a time of three years while being paid. This is the usual way to enter the industry, while studying CS is less common for devs. I have been working as a trainer on the company side for several year, with apprentices in an age range of 20 to 25, mostly without former training.

I will therefore focus on the training part. Whether you should invest a lot of time or not is not part of this answer. Talk to your manager for that.


Let me first look at what you have written and give some feedback. I will pick up on it afterwards.

[...] but he seems to mostly copy-paste code from tutorials without understanding what it's doing. [...] His approach to solving a problem is to keep trying random things until something works [...]

There are a lot of people that get their job done like this, especially if it's just the operations side of a sysadmin. Simply doing step-by-step stuff is a good way to operate, if you don't need to plan ahead. In professional software development of course that approach doesn't work. You know that, but he might not have understood it yet. It is hard to learn, but harder to unlearn behavior.

we often have to remind him multiple times to do a sub-task or implement feedback we've given him on a pull request ability to retain information

It might be that his tasks are too complex. He is junior without formal training in development, and the working environment might well be quite different from what he is used to.

a lot of time spent explaining things to him feels like it was a waste, because he doesn't seem to retain the information and repeats the mistakes.

That sounds like he gets too much information at the same time and is not able to remember it all. As has already been said in other answers, he needs stuff to be written down. He should be taking notes if you are telling him stuff, but if he doesn't maybe giving him a nudge in that direction might help. Alternatively, you can do the advice in writing. If you want to make that a bit more official, cc your manager in those emails.

He either isn't paying attention, is pretending to understand when he doesn't, or is very forgetful: he keeps writing code with the same bad practices that we've been trying to explain why he shouldn't use.

Now we are getting to the core. He is insecure and knows that he is lacking skill. Maybe he is intimidated by your or your teams knowledge nad the way you treat problems that seem overly complex and hard for him. You have a lot of experience, so many things are easy for you.

Depending on the way your team is structured, I would like to suggest a few things. Let's call the junior Bob for the time being.

  • Whoever is assigning tickets to Bob should make sure that those are small enough to be done in a day.

    If you're doing scrum, that might be the product owner or product manager. It might also be you as a senior dev or team lead. This way, Bob will feel like he has achieved something every day. Nothing is more frustrating and demotivating than being overwhelmed by a task.

    Work with him, split it up, but don't use subtasks if he tends to forget them. Simply make smaller tickets. In time, he will get better and can have larger chunks of work. Begin with assigning very easy stuff. It might sound like you can do it in five minutes, but he will need a day. But if it's done at the end of the day that's fine. He will feel like he got something done, and be happy about it.

  • Don't just review Bob's pull requests and write back feedback. Have a regular code review session every day or whenever a ticket is done. Sit down with him and let him explain the code he wrote. That way you can identify if he is lacking basic skills, like what loop to use for what, or how data structures work. If you don't have time for that, take turns with other senior devs. This will help unlearn the "copy and try stuff until it works" mentality, as it is now required to understand.

  • Pair-program with him, or let him do pair-programming with other juniors (or people that have recently been junior). That way he will pick up things from others, because it's not just talking. He will see that those things work, so he can adapt and learn them better.

  • Assign him a part of existing code to read and analyse. Afterwards, sit down with him and let him explain the code. A good way is to couple that with writing documentation or tests for existing code. But only use this sparringly as it can be very boring and also frustrating.

  • Make him feel part of the team! If you go for a beer with the guys after work, take Bob along. He will not feel comfortable to ask you questions if he only knows you as the senior guy who knows everything and is always disappointed.

  • Make use of his sys-admin knowledge. Your computer doesn't work? Ask for his help! He will feel appreciated and open up more towards you.

  • If Bob doesn't understand the ticket structure, try letting him write his own tickets. You can sit down with him and let him define the desired outcome. Write down a few acceptance criteria for the ticket, what test coverage there should be and so on. He will feel more secure if it's clear what he needs to do.

  • Always tell him where to find you if he needs your help. If you're in an open plan office, he will know you're at your desk, but he might be afraid to approach you. "If you need anything, just come to my desk or drop me a chat message" can go a long way. "Oh and if I'm wearing headphones that's just because the guy next to me is using this loud mechanical keyboard. Just come over anyway if you have a question". Encouragement is important. Try to incorporate that kind of thing into every new task. Remind him he is not on his own, and asking is not bad.


1) This is called Ausbildung zum Fachinformatiker/Anwendungsentwicklung in German

  • 1
    "This is the usual way to enter the industry, while studying CS is less common for devs" - I think your particular job colors your expectations there, because that's certainly not my experience working in Austria/Germany. The only area where I see lots of non-degree people working is in smaller companies usually doing web development. Would be interesting to find hard numbers on that (because clearly my experience is just as subjective there). – Voo Nov 2 '15 at 20:23
  • 1
    @Voo: I'm also from Germany, and I'd say both academic degrees (CS, but also engineering, mathematics, physics etc.) and Fachinformatiker are fairly common. According to this brochure by the German Employment agency, in 2014, 41% of IT employees had an academic degree, and 41% had a vocational degree (Fachinformatiker would count among those) - so a fairly even split. Interestingly, 7% had no formal degree. – sleske Nov 27 '15 at 8:01
  • A honest good approach., As you said its upto management to decide on the efforts. The question and this answer pretty much covers more problem,expectations,efforts on both sides for manager to decide and estimate. – Downey_HUff Dec 6 '15 at 8:00
11

Who is actually responsible?

It sounds like you're stuck in a mentoring position, with someone you don't want to mentor, and perhaps no real experience or interest in doing so.
Perhaps you're simply the person he ended up being sat next to, and as such the role fell on you.

Your post however screams out that you don't want to train this person, and don't even believe that training is possible.
This makes you the wrong person to be responsible.

Escalate to your manager.
Ask what the plan is for training this person.
Ask who is responsible for the training.
If it's you, and you don't feel like it's possible or you don't feel like you're qualified, then communicate this clearly.

Keep in mind though, that a person coming from a different job in the same sector, will not pick up a programming language in a few weeks.
As a sysadmin who had a few jobs that required programming in C# as a contractor, I can tell you that he's probably just as frustrated as you.
If he's not adequately taught, and his objectives aren't clear, he might be extremely frustrated in his lack of support.

Ask him if he feels like he needs more in terms of formal training.
He might just be your best ally in talking to your manager about getting him enrolled in a course.

6

If what you are currently doing is not working then maybe time to try a different approach.

I have had to train many junior devs straight off the bus from college and what works for one will almost definitely not work for others. Development is like art, every one has their own style. It is not like gymnastics where form and routine and specifics and set in stone.

Put all instructions in an email, this way the resource always has access to them. Make sure the instructions are clear and well defined.

Do not give the resource the answers, rather rephrase a sentence into a question where you can lead the resource to give you an answer, this ensures the resources is listening and has an understanding of what is going on.

If there are fixed coding practices defined by your company and he does not abide by them then you have grounds on which you can discipline the resource and worst case terminate the employment. If possible a demonstration of why it shouldn't be done like that, some people will only learn via demonstrations(like touching a hot cooking plate after telling them a hundred times be careful that is hot)

I would also mention to 'boss' that this is the issues you are experiencing and these are the multiple steps you have taken in attempt to resolve the issues you are experiencing.

  • 5
    documenting what you do is important for both of you. The learner can refer to it, and you can say to your boss "I did this" more easily. – Móż Nov 2 '15 at 0:57
  • 18
    please, stop calling human beings 'resources'. – gbjbaanb Nov 2 '15 at 9:59
  • Also sometimes it's completely unnecessary to remember things, like remembering where files are being copied, or which business workflow was executed - just put this information into a log file, with which you are working. – Neolisk Nov 2 '15 at 13:00
2

There has to be some sort of relationship between the skill level of new hires and the amount of time, energy and effort required to get this person to the desired level.

So first, establish a level of how good you want this person to be by a certain time. Maybe you've done this in your head, but hasn't been formally communicated between management and the mentor and/or team. Are you sure management isn't expecting you to make more of an effort to train this person? The fact that you have no communication with management nor a plan to monitor and provide any type of formal evaluation after 2 months leads me to believe you don't.

Let's face it, you're flying by the seat of your pants and that's exactly how you'll crash. It's very simple, if your boss wants you to spend more time mentoring this person, then ask what other duties/tasks do you put aside? Of course, this assumes you had a full workload before hiring this person.

You are not communicating and setting objective achievement levels for this candidate. They need to understand that they will NEVER put any code into production, until they can pass several code reviews. If the company won't pay for training (and you should ask), find something online for free. Review the coursework and set some expectations for level of completion and time.

Does this person even know how to read code? Take some time to teach this. It's something that probably came natural to the rest of the team. There has to be some sort of intermediate translation of how the code is written and how that matches what it actually does. You have to have at least some competency level in another language before you can understand code just by reading it.

Not everyone is cut out to be a programmer and many programmers are not capable teachers. Someone in charge, should establish a timeline of competence and if a new candidate doesn't meet it, they have to be let go. We can argue all day long that the person was not taught properly, but it is moot when the resources aren't there and programmers with a full load of tasks can't be expected to be the miracle worker.

  • 1
    The part with deciding how important the task of training is is crucial, as is the fact of putting aside other duties. You cannot do everything at once. – simbabque Nov 2 '15 at 14:10
  • @simbabque - Programmers take a lot of pride in building things and helping the development community, but sometimes they take it too far to their own detriment. – user8365 Nov 2 '15 at 15:27
1

One thing I haven't seen mentioned in any of the answers is that the new hire could have a serious inferiority complex brewing. I actually see it currently on my client site with an older developer who they are trying to transition from maintenance work on a 15-year-old application to the new development in C#.

I'm assuming since your team interviewed and vetted this developer, s/he has competency to do the work. You're unhappy with the progress (and I bet the new hire is too).

Your question demonstrates you are frustrated--are you showing this frustration towards the new hire in either tone, words, or body language? You may be exacerbating his/her problem by not seeming accessible to questions or problems that s/he may otherwise be seeking you for.

While it is time-consuming, if you think the dev is capable, this time is well-spent and only spent until the dev is up to speed and able to self-solve issues as they arise.

First, I would make sure you are coming across as positive and open to help in your interactions with this developer.

Second, spend time to pair program with him/her after you explain the task to be done/bug to be fixed so that you can watch. If the dev is apprehensive, state that you are merely there to help when s/he has questions--it's not a test--and that pair programming is highly regarded in the software development industry.

Third, if you feel like the dev is dismissive/"ok"ing a lot as you are talking (signs that s/he wants to show understanding, but doesn't really), be more deliberate in your discussion. Try to make it a back-and-forth, let the dev finish your thoughts (correcting where wrong) so that s/he can demonstrate understanding.

Finally, if you feel like you are doing the above, and the dev still demonstrates an inferiority complex/isn't getting the job done satisfactorily, talk to your manager and set up some time to discuss this together face-to-face. As a team, you should be committed to each others' success. It makes life easier (as you have noticed with your Sunday-night dread) if everyone is performing at their best.

0

Put your new junior programmer in his own little paddock. Create a GIT branch for him, and relegate him there. Don't bother to even WONDER if his code is production-ready. It isn't. Just keep him parked.

Do constant code reviews...one every week, and just keep deleting his code, until that magical day that it actually comes up clean and mean.

  • The management will allow you to play like this for long as people cost money. If they cannot work in the team, should be fired. Most likely this applies to that another developer first but may also apply to you in some extent. – eee Nov 3 '15 at 7:24
  • This seems like horrible advice. Nothing is more demotivating than having your work destroyed every time. Your approach reminds me of movies where new recruit soldiers get their bed or closet completely turned over for not folding something correctly, every day, until they are broken and do exactly as they are told. It will make him feel inferior, undervalued, and helpless. He is going to hate you, and like will quit. Unless that's the desired result, his is bad advice. – simbabque Nov 18 '17 at 16:46
-2

Some your assumptions seem very doubtful:

  • ... copy pasting code from tutorials - this just cannot work, code from tutorials will not compile and run "as is" and requires adaptation to be used in other context. Maybe he is just trying some new and possibly better approaches, described in the literature you do not want to read?
  • ... trying random things until something works - if just completely random, it is possible to try till the end of the Universe without getting anything working. If he has success with this approach, maybe the things he try are not completely random? Maybe they reflect some different experience that yours?
  • From your talk appears that the company has hired a non-programming person to develop a software, really? Maybe you have missed something in his CV?

In general, you seem confident that the only way how this new developer could and should learn and progress is by following your instructions without much thinking, and without using other sources of knowledge. I have seen such masters, proud of they homegrown re-implementations of Spring, JavaCC, Hibernate, Ehcache and whatsoever; insisting that all newcomers should learn without end and invoke they spaghetti junk instead of using industrial standards.

You are more experienced or at least know your local code base better. Still, the question could be anyway - are you actually always right?

-4

Escalate. This is totally unfair to you, and you need to stand up for yourself. It is clear to me that the junior dev you are talking about is incompetent, since you tried to make it work multiple times.

EDIT: All I'm trying to say is that I have complete sympathy towards the OP, and I believe that the situation is more serious than it looks. It's totally unfair towards him. I knew this answer was going to get negative comments, but so be it. I bet it's from people who would be the first ones to whine about unfair work treatment and bullying, rather than standing up for themselves.

  • 1
    The OP is not working on Sundays. On Sunday the OP is beginning to dread going to work on Monday. – David K Nov 2 '15 at 21:21
  • @DavidK my bad, misread! – Elchin Nov 2 '15 at 22:44
-6

You cannot "train" a computer programmer. Programming is a complex art that takes talent and years of hard work to become competent. Programming languages are similar to real languages: you can't just pick them up when you are 25 years old and expect to speak like a native.

Hiring a former admin as a programmer was just dumb. Not consulting you before assigning him to you was even dumber.

I would suggest looking for a different job, because a management team that does such a dumb thing will make other serious errors that you do not want to be on the receiving end of. Your best move is to get out of there before things get worse (and they will).

  • 8
    Nobody involved in the situation was necessarily "dumb". The fact is there are all kinds of programming and people have to start somewhere. While it is true that talent and aptitude are factors for success, having a supportive environment is critical for newbies. – teego1967 Nov 2 '15 at 1:26
  • 2
    I think it's unfair to say that a sysadmin could not learn programming, or that anyone under twenty five is wasting his time. I make about 30k a year through programs I wrote in my spare time in a couple of years and maintain. And I started at 41. Could a programmer with 30 years experience do a better and faster job? Probably. But did anyone think of it before me? No. Bottom line is it's a nice piece of pocket money for me. – Kilisi Nov 2 '15 at 4:34
  • 4
    I agree that the sysadmin in question seems to be a waste of space, but I know plenty of people who have no formal programming training doing a great job. I'm old, in many countries there was no formal training available, and in my country there still isn't. It's a skill that can be acquired just like any other, nothing magical about it. – Kilisi Nov 2 '15 at 4:54
  • 5
    @Socrates, aside from the fact that universities are not really optimal for vocational training, there are NOT enough traditional computer science grads coming out of schools to meet the demand of ruby on rails developers out there, let alone every other past, existing, and upcoming development platform. Employers are forced to choose people who are changing careers or who have non-traditional backgrounds. That's just the way it is. And to be fair,the reason programming is so hard is not because of its intrinsic complexity,it is because of attitudes like yours and the OP who block newcomers. – teego1967 Nov 2 '15 at 11:04
  • 16
    This answer gives of a major air of elitism. The idea that programming is art and sysadmins can't learn it is borderline offensive. As a sysadmin who's spent a lot of time in C# code creating SSIS packages without actually ever having attended school since I was 16 years old I would like to posit myself as your opposite career path. Every person is different, and generalities such as Hiring a former admin as a programmer was just dumb. come off shallow. – Reaces Nov 2 '15 at 12:26

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