How do you train someone to be a programmer fast? (No not like a 'learn to code in a weekend' thing.) Books? Throw them in the deep end? Work with them side by side for a while?

We will be hiring a guy as a programmer. He is very tech/computer savvy, but literally 0 school or work experience programming. I've known him for a little while and honestly trust he'll try to learn but I feel with as little as he knows he is going to get overwhelmed fast. He is not technically under me but it's going to be my responsibility to train him.

I'm worried he's going to get completely overwhelmed and burn out quickly.

Throwing them at the deep end is what will burn him out.

Show him the basics, let him get comfortable with the syntax and help him look at the task at hand as a problem that needs a solution.

Once he gets that and you feel he's ready, start by giving him really simple tasks, like bug fixes or something.

Did he make a mistake? Don't tell him, instead show him a better solution.

And most importantly, always be patient with him, even when he asks stupid questions.

1. make time machine
2. travel back in time
3. tell person to start programming
4. go back to future and see world burn

Maybe don't throw him in the deep end, walk him down there at a gradual pace, tie his legs with a chain and weight and let him find his way to the surface 😉

As for how to teach someone quickly, it depends on the individual, most people will learn by doing rather then feeding them an endless supply of docs / books ect.

Start with some basic stuff and work upwards to the chain and weights.

Just be available.

Give him enough to get the work done, but encourage him to ask questions and go deeper if he is interested.

Don't forget the basics like the IDE setup, add-ons/extensions which make coding more pleasent.

Give him cheat sheets with most used commands so he does not have to look through documentation and all the possible arguments (git).

Would you hire an "aviation-savvy" person to fly a plane?

Start with a book or the internet and practice problems, then once he's comfortable with the basics, move on to real projects

As a guy who had trained quite a few programmers and non programmers (like a 40 year old hairdresser) I can say that all advice here is bullshit.

Everyone learns in a different way and thus recommending something without knowing him is impossible...

Everyone seems to say "not the deep", though that's how I learn the best. That is why teaching is difficult, everyone is different. For a group of twenty interns I once prepared three presentations on the same subject, and I told who had to watch which presentation because otherwise I knew some would get bored (and demotivated because its "easy") while others would stop paying attention because they lost you after the second slide.
Ive seen people from my class almost giving up the study because it was to complicated. When I explained the same in different words they understood it and finished their education.

So since you know the guy I think the best solution for it is with you.

Owh and offtopic I share 327 regularly so I know the ID of the top of my head. I approve your name.

Want a programmer? Hire a fucking programmer, it's that easy.

Mentor him. Learn how he learns most effectively and use this knowledge. Keep providing him with problems to solve that look reachable for him. Like, he 80% knows how to do that so he feels confident, but has to learn remaining 20%. Make those problems interesting, leave little gotchas. If you see some part is more exciting for him, leverage it to expand his knowledge. Teach him how to effectively use tools (IDE, VCS), how to read documentation, how to search for solutions - this doesn't immediately make him a better programmer, but makes him learn faster.

I strongly suggest pairing him with a patient senior. Expect a loss of productivity in the first month.
Steps to do:
1. Spot syntax errors when writing.
2. Spot small semantic errors.
3. Write small self-contained functions/modules according to specifics of his tutor.
4. Spot more complex errors (including emerging bugs due to integration).
5. Collect simple specifics from a client or a document.

And now you've got a junior.
Of course all the while he has to work just like the senior does.
And be aware that the lost time is an investment and that it costs money. It's a risk but at least the new junior will be prepared just like you need him.

@beegC0de @Fast-Nop Easier said than done. There are quite a few other factors that played into the hiring process. I'm not going to say it was a bad decision to hire him, just very non-optimal.

Throw him to the deep end, this is not uni anymore. I’m doing the same thing to a college friend of mine that we recently hired, so far we are really not impressed with his performance.

@BobbyTables well yeah that's what nepotism gets you. Same effect for quota shit.

@Fast-Nop No nepotism at all. In this area it is hard to find qualified people to fill technical roles. So instead of leaving the role unfilled for who knows how long, sometimes management sees the risk of hiring underqualified people as acceptable.

@BobbyTables Ah ok. Hiring remote working devs could have been an alternative. Though not always possible, especially if custom hardware and stuff is involved.