Vrftjkry

I started out in tech support. I would have loved to have your friend's job, but tech support was the closest I could get. They put me in my first coding job because I was horrible and unmotivated at tech support. They were unable to restrain me from goofing off and writing code all day instead of doing what I should've been, so they changed my job title. It turned out OK.

"He drives, we navigate" sounds right to me, as long as you're not over-navigating. He needs enough rope to make his own mistakes and find out for himself why all those brilliant new-programmer ideas are so terrible.

But he's not straining at the leash to make those mistakes. Therefore he doesn't like programming. He's not going to be a programmer. He likely has nearly all of the necessary cognitive traits, but he's missing by far the most important one: He doesn't love programming. He doesn't even like it enough to bother doing it when he's paid to. There's only one way to test for that. You ran that test, and you're here to say you didn't find it.

I've heard from somebody who says he doesn't love programming, yet does it for a living. Well, if you're successful at doing it for a living, you must at least be able to tolerate doing it most of the day, most days. OP's junior colleague can't even tolerate that.

I've known stellar software developers who were poor at symbolic math (I'm not quite sure what it is, myself) and nothing special in other areas considered important. What they did excel at was love of writing code, which matured over the years into love of software development. If you ever find that you're just sick of code, it might be time to go into management. The early honeymoon period will have faded somewhat as they got older, but to do it at a professional level, you have to start out in a place where you find it intensely absorbing. Or at least a heck of a lot more interesting than Farmville. At your friend's early stage, if <figurative-language>anything far short of two armed guards in front of his desk can keep him off the compiler</figurative-language>, he just doesn't like programming.

True, I waste some time at work too (like, right at this moment). So has every decent developer I've worked with in 20+ years. But they also didn't mind spending enough time writing code to get their job done, and not miss too many deadlines too badly.

It's remotely possible that he'd be happy if you let him run amok and work on code that grabs his interest. Maybe. But he could be doing that already, and it seems that he isn't.

This 'Enry 'Iggins stuff is always doomed to failure because people aren't blobs of clay waiting passively to be molded. Not everybody even thinks of trying programming, but once they've been exposed to it, either they like it or they don't. Maybe he'll come back to it in a few years (I barely eked out a gentleman's C in CS101 for non-majors; it seemed like boring garble to me. Five years later I fell in love with ANSI C). He's not into it now.

How do you motivate somebody? You can't. You can't motivate somebody. You hire somebody motivated, and you avoid demotivating him. Or you take your unmotivated guy and put him in the job he's motivated to do well, if you can find out what, and if that chair is open in your organization. I got pretty lucky; I'd been unmotivated in a string of previous jobs that I just had to quit, or got fired from.

Very few people want to be programmers, and even fewer still want it when they see what it's really like. Don't suggest that there is something "wrong" with somebody who happens not to enjoy some peculiar specialized trade such as dentistry, luthiery, or algorithms and data structures. One of the least savory traits of many devs is the noxious idea that they're at the top of some Great Chain of Cognitive Being, so it's just an awful unthinkable insult to say somebody's not going to be a programmer. Nonsense. It's a weird trade that a very few people enjoy and most others find deeply boring.

Talk to the guy. He's not enjoying this either. Nobody likes failing. He needs to be in a role where he'll succeed.

Give him permission to say "I'm not happy and this is not working out."

What you have done is failed as a manager. You have taken someone with no experience and let him flounder around on his own and not said anything when no progress was being made. You had no plan and thus he had no plan.

It's ok to want to hire smart people and they train them up as developers, but in no case should you expect that person to just learn on his own through videos and books. That is creating an unfair situation. If you want these types of hires, you need an actual in-house training program where they do the training in front of someone experienced who can provide the information in a structured manner, guide them and answer questions, and insist on doing exercises and taking tests so that you can evaluate if they are making enough progress to remain in the program.

You need a training course structured to the very things you need to get them up to speed on so they can work in your particular environment. So if you don't use functional programming for instance, don't let them spin their wheels for three weeks pretending to learn that when they don't yet know what they need to know in the language set you use and the techniques necessary to solve the kinds of problems you do have (a web dev will have a different set of problems than a database dev or an embedded systems dev or a mobile app dev).

Then you have a progression of the types of tasks you expect them to do. Make specific assignments and let them flounder for a couple of hours/days (or whatever is appropriate to the problem) and then sit with them and ask them specifically what they tried and didn't try and then, never touching the keyboard yourself, you lead them through how to solve the problem through the Socratic method of asking leading questions. Then give them another similar problem and see if they learned anything.

Frankly if you or someone working for you didn't spend at least 100 hours of prep time (probably more) developing a program for training before hiring this person, you failed them.

Then once they can solve some simple problems, you add in code review of 100% of all their work and if they need to fix something, they have to fix it, you never do. Once they are doing training tasks at a level that could go into production, start assigning real tasks. Again, 100% code review is the rule and no matter how close the deadline, they have to fix it themselves.

Even if you don't have a specific trainer (which you really should if this is your hiring plan), you should have had a specific plan for what you want them to learn in what order and question them about (or have them demonstrate) what they learned every single day. They will need to do something similar with daily SCRUM meetings, so get them use to showing daily progress from the beginning from the beginning. They need to know that their training is work and you expect daily progress and that they will put in the hours to make it so. Give them specific problems to solve in a training environment that you can refresh to the original state if they mess up (Old bugs you fixed is a great place to start for getting exercises.)

The phone thing you should have talked to him about the first day it happened. Now you need to tell him, that his phone use is inappropriate and then explain teh limits on it.

As far as incentivizing? At this point keeping his job and his paycheck is the incentive, you don't reward bad behavior with new incentives.

Frankly at this point, the guy sounds like he is clearly not interested. BUt to be fair (since you failed as a manager) you should have a heart to heart talk with him about what is expected as a dev and does he really want to put in the time to get up to speed. Then tell him what you expect and how you will measure his progress and that his job is at risk if he does not make progress. (It's amazing how many poor performers have no idea their jobs are at risk, a manager need to explicitly tell them when it is.) And if he has made no significant progress after two weeks, I would start the HR process to let him go.

You share the blame for this problem

• He needs to step up to the plate and show you he is serious about this career path.


• You need to be clear and upfront when discussing his performance.


• His problem is a combination of:
  
  
  
  
  • You didn't set clear expectations.
  
  
  • He hasn't put forth the required effort.
  
  
  
  

About the resources:

If he says he hasn't used the resources you provided, ask him why. Did he not think he needed them? Did he think they were too hard or too easy?

If he says he has used the resources you provided, ask him why it isn't showing in his work. Has he not put forth enough time to benefit from them? Has he been using them for topics other than the ones related to his job?

Let's pretend he is a Jr Java developer and your company's flagship product is an enterprise ERP. Has he been spending him time learning another language using those resources? Does he see this job as a stepping stone necessary for him to get experience and work in some other industry?

Talk to him about his career goals. Tell him about how he can reach those goals inside your organization.

Ask him how he feels about the work he's doing. Does he think it's not challenging enough? Does he have real expectations about what "being a software engineer" is all about? Does he think he is going to come in as a Jr dev and spend most of his time implementing new features as opposed to fixing small bugs and receiving honest feedback on the quality of his work/code?

Friends and business should be separate

Friends should be friends, but inside of a professional working environment you must always act in the company's best interest -- even if this strains friendships.

I ended up hiring a junior (our second) who is acquainted/friends with some members of our department (myself included) who met all of our requirements [...]

I suspect that you have been walking on eggshells and have not been clear enough when discussing his performance. Perhaps this is because you were already acquainted with him and you don't want to hurt his feels. Maybe you don't want to give him negative feedback and so you subtly try and encourage him. It doesn't seem like this is working very well for you or for him.

[...] he drops his attention much easier and starts messing around with his phone or otherwise getting distracted, either while we're "driving" during a pair to show something complex [...]

When this happens, you should advise him that he cannot play on his phone while you are pairing. Maybe he thinks that pair programming means "one person works, the other takes a break". To somebody who hasn't worked in software development before, he may share this misconception.

Explain to him that he is supposed to pay attention even when he is not driving, and that he needs to be listening to you as part of his job.

You need to outright ask him if he has been using the resources you gave him.

It sounds like you believe this hire isn't working out, and if he doesn't change he may be let go rather than "not promoted". Have a 1:1 with him and lay out all his performance issues. Be clear in your criticisms and offer ways that he can improve his performance.

Be careful when you give him this feedback to give him good feedback as well. When I give feedback, I try to avoid using the word "but". This word is almost always followed by a criticism and likewise negates the affirmation precedes it.

Replace the word "but" with "and" -- I affirms that you are being sincere regarding the criticism and the affirmation.

Consider this example:

[Name], I want you to know that I see great potential in you but you're not making the progress [company] expected of you when you were hired. We believe you are capable of coming up to speed but you need to focus on developing your skills. When we hired you, I recommended sites that provide tutorials but you haven't followed through with using these resources.

We really enjoy having you on the team but your performance has to improve. If we don't see those improvements, the next step will be a PIP. I wanted to talk to you in advance, in case you were unaware, so that a PIP won't be necessary.

We're willing to do as much as we can to support you, but you need to learn how to find answers on your own. If you're still struggling with a problem after researching possible solutions, come ask us for help. Explaining what you've done to find the answer yourself will make it much easier for us to help you learn how to tackle similar problems in the future.

Nobody picks these skills up overnight. Learning and developing these skills in your free time may seem difficult, but, you're expected to make the effort.

[Name], I want you to know that I see great potential in you and you're not making the progress [company] expected of you when you were hired. We believe you are capable of coming up to speed and you need to focus on developing your skills. When we hired you, I recommended sites that provide tutorials and you haven't followed through with using these resources.

We really enjoy having you on the team and your performance has to improve. If we don't see those improvements, the next step will be a PIP. I wanted to talk to you in advance, in case you were unaware, so that a PIP won't be necessary.

We're willing to do as much as we can to support you, and you need to learn how to find answers on your own. If you're still struggling with a problem after researching possible solutions, come ask us for help. Explaining what you've done to find the answer yourself will make it much easier for us to help you learn how to tackle similar problems in the future.

Nobody picks these skills up overnight. Learning and developing these skills in your free time may seem difficult, and, you're expected to make the effort.

I guess my question is this - what are you doing?

You ask how to incentivize this guy - but then effectively say "and i have to incentivize him to be a developer".

And now you're wondering what goodies to throw at him to make him excited. This is just poor form on your part. You don't - you cannot, really - incentivize someone to be good at something they dislike. You can throw money at it - and maybe even a lot of money (although, hahah, developer, so we're not talking a life-changing lot) at it.

But that just means you have someone with a lot of money doing something they don't want to do.

You say this person is smart - that means you should want to keep them. Smart people are worth more than well-trained or experienced people.

Now the trick is to find out what this person actually wants to do. Why not ask them? And ask them honestly - try and find something for them to do that matches what they want. Does this person want a leadership position, or a client-facing role? Offer that - offer it a day a week, anyway - on the condition that they have to learn whatever it is (because, you know, they will need it for the presentation or the leading).

Learning by teaching is also massively underused - I blame our school system - so why not ask him if he wants to make a presentation on something. And then help him make it, and then watch him flounder - but also learn.

There is more to a functional member of a software team than coding - there is leadership, planning, co-ordination. Or perhaps this person has some health issues or out-of-work issue that is causing all this?

You need to find out. Most people understand that the phone ringing all the time isn't cool, so this is either showing

1. something is wrong outside of work


2. the individual is struggling with work

From what you say it could be either.

Telling this person that they are underperforming is fair advice, but also useless. It's like having a subordinate tell you a problem - you generally want to hear "this is the problem, here are some proposed solutions". You are the leader here, so you need to come up with some leadership to help this person out. Because that is what leadership is, really.

Your question has tons of answers, the one that works for me the most is: challenge this person.

Now focusing on your situation, this is already a dead end, the guy has lost interest in the job so if you really want to bring your Jr. back into the game be clear to him and put the dots in the i's: "you catch up or you're gone".

After the scolding, the best you can do is to explain why all you try to explain is relevant and drop some challenges, even if he sucks at solving them, he will end up either learning or giving you a starting point for assessing his job.

Although, if the guy is just not willing to push himself then just move on. I know it sucks to fail as a lead, even when this is out of your control, but you both will end up learning.

Does your company use anything like Gallup's strengths finder? I don't believe any of it but if you matched tasks to his strengths, he may have an increased response- even if due to a placebo effect. For example, pair programming for someone who likes people, or a todo list for an achiever (he doesn't sound like an achiever).

I'd raise an eyebrow to anyone who claimed to have a motivation technique that worked acroas the board.

I am a junior developer and I was in a situation where is that guy/kid. I have got a job as mobile developer to develop android and ios apps in xamarin(c#). Since I have been surrounded with people that are in open source world and use Java, Python, etc. I have accepted the job as the only way to become a developer. I hated C# because it has things that I couldn't overcome and sintax is different from Java's.

Soon after I was bored, burned out and stopped to think because of that. I couldn't google for an error message, I have chat all the time on work. Couldn't read simple text for 10 mins without loosing my attention.

Also I have to mention that my team leader wasn't there when I was really in problem. He put me in production to write featueres that will be announced in a 2 weeks. That was frustrating for me.

The conclusion:
Joung people needs something interesting to work on, big corporatios are stopping them to find what they want to become. I was scared and after some time I realise that my team leader is not the leader but just figure.

The solution:

Try to talk to him and explain if a project is boring he needs to say that. Also he needs to learn how to use google :)
Maybe this sounds stupid and silly but it is true. Especially if English is not his native language. Junior developers need good leader and leader needs to be patient. Imagine that you need to learn how to perform heart transplantation. And some guy who is specialist at that tells you that you need to know trivial opening and closig chests for that performance :)
You got the point?
Gl hf

specifically focusing on candidates with other real-world experience looking to make a career change into software development but with no experience in software development

Well, sorry but that's what you get for hiring someone that wasn't formed to be developper. We don't do years of study (school or self taught) to be replaced that easily by some weeks of self formation.

Developping is not about only some training, it takes pratices to stop only to see brute force solution and seeing others alternatives. 90% of developping is thinking and learn technologies/method of coding (aka pattern), raw coding is 10%, and I'm very generous with that number.

If you want to persist : get them practices and review them.