How to train junior programmers for today's (complicated) web environment?

Question

Currently our company develops applications consisting, most of the time, in Ruby on Rails web servers and a bunch of different REST clients, from kiosk systems in Java to embedded devices in C/C++ (besides the interfaces for standard web browsers). We need to expand our team and, having failed at finding good senior programmers, we decided to put some effort into training junior programmers who would grow together with the company.

We've already given them some Ruby and Rails books and asked them to build some toy programs, but I'm now realizing how steep the learning curve for the current state of web programming is.

When I started programming 15 years ago I used only Delphi and Source Safe and was able to produce usable software right from the beginning. They were both simple tools and it was easy to delve into the inner workings of the environment. Slowly I started using third-party frameworks, have switched to CVS, SVN and finally Git, learned the pieces which make today's web, like HTTP, JavaScript, CSS, REST etc. Today, even after years of experience, I don't know as much about how Ruby on Rails works inside as I did in the past about Delphi, and for me that was important so I could connect the basic learning blocks to the tools I was using.

It seems to me that the programmers I'm hiring will take a long time to integrate with the team and produce something usable, because there's so many things to learn to use a single framework (Rails): Ruby, HTML, CSS, JavaScript, REST, test-cases, database access (with SQL magically built inside the framework!), MVC, three different package managers (apt for Ubuntu, gem and bundler for Ruby), ssh, git, Apache and Phusion Passenger for deploying, etc.

I'm feeling lost since it's the first time I need to deal directly with junior programmers. What is the best way to train junior programmers in today's best practices for web development when there are so many choices?

Answer 1

Many people won't like this idea, but I am advocating this wherever I can: regardless of the programming language and environment, if they don't have any experience and if there are maintenance tasks which come up from real world bug reports of customers of yours, try to make sure they get assigned to that kind of task at least for 30-40% (+) of their time. "Here's the bug report, have a look at it, solve it. If you don't know what it's all about, communicate with experienced colleagues, google it, whatever". Real work on real problems, no toys, at least: not only toys. Make sure, too, that someone with lots of experience has a look at what they were doing before it gets released and shipped to the customer, of course. Make sure the new colleague gets honest feedback on what he did from colleagues and customers. Choose these tasks carefully in order to not overburden them, but keep in mind that some day you want them to do their work independently.

Doing bug fixing is learning on the job which lets them work on code which get's actually executed and has some relevance (otherwise there would be no bug reports) and will show them in many examples how to not do it.

The focus is automatically put on pain points. They'll start learning those details which are actually causing trouble. It also puts real responsibility onto their shoulders right from the beginning, which (while maintenance as such is not really attractive) can be rather motivating if they get it done to the satisfaction of the customer/end user. Going through what they did will be taken more seriously by your seniors cause they know the impact if things go wrong, and that way it will also simplify integration into the team, cause it will make them talk to each other automatically, as well.

The point is not to set them productive from the first moment (as it might look like). The point is to make sure that they know they are supposed to do something valuable right from the first moment, and to put a focus on what matters most without the need to actually create a list.

I do have some years of experience working every now and then with people coming directly from college into their new developer job, and the worst results I got to see was usually when someone without at least some experience in maintenance was asked to do new application development. Just make sure they always have someone they can ask for support if they feel lost.

Answer 2

Let's assume first of all that you've hired junior programmers that are actually competent. This is not necessarily a safe assumption, especially since senior programmers interviewing "someone less experienced than me" is likely to overlook basic incompetence.

But, assuming they're competent, the first step is to send them to a class. A one-week class will cost you $2,000-$3,000 (US). However, it will give them hands-on experience, with an instructor who (hopefully) understands the material, and a lesson plan designed to bring them up to speed. Sending someone off with a book and the directive to "learn this" isn't going to be anywhere near as valuable, and is likely to cost more (the cost of the class is about equal to one wasted programmer-week).

After they have the baseline knowledge, work with them. Sit at an adjacent desk, and give up at least half of your time to making sure that they understand your business, and your way of doing things. Yes, it will decrease your productivity, at least initially, but in the long term in makes your team as a whole more productive. And if you think, again, about costs, if a junior person wastes a month doing the wrong thing, that's probably about equal to a half month of your salary.

Answer 3

The toy applications you're asking them to do should implement some basic CRUD functionality, and each developer should write their own code. But you can discuss the application in code reviews, and offer tips. They will need to understand the overall architecture of an MVC application first, if any reasonable expectation of productivity is possible.

From there, each developer should be able to strike out on their own into the associated subjects like Javascript, CSS, DAL's, template generators, routing and so forth. You can give them guidance on which topics to study (it can be based on your company's most pressing needs), mentor them, and monitor their progress. Move developers one at a time to simple projects that produce functionality that will move your actual development effort forward, the moment they demonstrate a grasp of the necessary skills.

You can pair some of your experienced developers with an apprentice as a sort of mentoring program. There should be guidelines available for the junior developers so that they know when they can interrupt their mentor, and for how long. Their mentor can supervise their work when they start writing real code.

You will have a better time of it if you can find young people who are very smart, intellectually curious, and self-starters. I've seen this process work; it was my prior employer's approach, since he didn't want to pay the big bucks for experts, although it was more of a "sink or swim" kind of thing (there was no formal training program as such). His biggest challenge was getting them to stay long enough to recoup his investment; there was always the lure of better pay somewhere else.