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?
Best Answer
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.