My boss hired a new dev right out of CompSci onto a project with a fair amount of technical debt. It will be my task to get this guy up to speed and making a decent contribution ASAP. Any suggestions on how best to do this? Any first hand experience on how precisely not to do it?
My instincts are to do some code reviews on code written by the dev he is replacing, pair programming on new code I'm writing, or working with him on writing unit tests for the code he is to inherit.
When I started my first job, I got thrown right into the fire with some smaller tasks. This included creating minor controls that were auxiliary to the project, but which still required I use some of the more advanced techniques that were in use with the rest of the team (ORM access and so forth). I was also given some database cleanup tasks, which gave me a good understanding of how all of the data the project had to deal with was laid out in the database.
I would advise against having him doing nothing but reading docs or doing extensive code reviews. He's going to get bored, and probably won't remember much of what he's doing in two weeks anyway. Remember, he applied for the job because he wanted to write code. Too much maintenance stuff is going to push him away.
On his first day, sit with him and help him set up his development environment. If he's fresh out of college he may not be familiar with an IDE, using Version Control, whatever application frameworks you are using, etc.
On day two let him fool around with anything that you think is worth learning first. For example you say you want him to do Unit Testing, well if he doesn't done that yet use day 2 to let him get up to speed.
On day three put that boy to work. Learn by doing. Definitely do a code review of every single thing he writes for at least the first couple of weeks, and take it from there.
First hand experience here. Do not just send them off on their own to read documentation. This can be a very overwhelming task, especially if the project is on a very large scale.
The better thing to do would be to have him actually jump right into the code and start working with it.
Give him a task that upgrades some existing code. The task shouldn't be terribly difficult, but it should require knowledge of the code. Be available for questions, but don't tell the hire how to do it. After the fix has been coded, sit down with the programmer and go over the solution.
It's good to allow the programmer to have some freedom in writing code that does the job. This will likely introduce new methods into the system that will help you become a better programmer.
Just be sure to help the new guy learn some of the coding standards for your company. Those are always a pain to learn.
At my current job, my first task was to update the tools used to build and deploy our webapps. It actually turned out to be a great idea for a few reasons:
So yeah, I guess it was a little disappointing that I wasn't working on the real products right away, but I think it was definitely the right way to go.
I'm sure every company out there has some low priority tool or project that no one else has time to work on. Give this project to the new guy, give him a chance to write some new code, and then see how everything works out. At worst the project is a failure but no damage was done to production code.
Peer mentoring is a very good way to bring new hires up to speed, check out the website and the associated book for more information. The technique was developed at Microsoft (I believe) and has been adopted by allot of other firms too.
I'm currently reading the book, which has allot of interesting ideas in it, allot of which are meant to help you think about how you and your apprentice (the new hire) prefer to communicate and to help you set-up a lightweight and simple process to do this.
Edit: I'm not affiliated with the author of the book, I just happen to like his idea and was introduced to it by my current employer.
I would advise against things like reading documentation (unless you have a good short doc giving a solid overview of the system design), code reviews, or my favorite - "getting familiar with the codebase".
All of those things are really tough to keep focused on when you're brand new to a project. The code reviews aren't useful without some prior knowledge of the system.
Ideally, I would give him a very small, localized task that he can just work on by himself and ask questions as needed. This gets him started with your development processes, source control, etc while doing actual code.
It's even better if you already know the solution to the task, that way you already know the answers to any questions he may ask and respond to him quickly.
Writing unit tests for code he will inherit is also a great idea - he will get to write code and get familiar with how the thing is supposed to work.
Bug fixes.
That is by far the best way to learn a codebase. Yes, it sucks, but it's great way to learn.
One of the most helpful things to do is walk thru the program that he is going to maintain and explain how the system works. Make sure that explaining the business process is one of the top things covered in the first day. Regardless of how the code works (or doesn't work), you need to understand what it is supposed to accomplish.
A lot of it is about learning the processes of your organisation. It's not just learning how the code works.
We employed two newbies last year. We made sure we had real tasks for them to perform, which gave them exposure to version control, bug database, wiki and so forth, gave them as much supervision and help as they asked for, and then a little bit more, checked what they did, and by two weeks in we were very happy with them and trusted them to get the job done. As time went on they contributed to our existing processes and improved them.
We took an intern on this year, and gave him much more supervision, including reviewing his first piece of code carefully, and repeatedly until it was right. Three months he still needs some help occasionally, but knows when to ask, and has matured into a useful member of the team.
If you've decided to employ them, you've already made the decision to trust them. Give them a mentor (might be you), exposure them gradually to your systems and the codebase, and work from there.
I agree with many of the answers here, especially Learn by Doing. I've experimented with many different ways by letting the new hire:
I think of it in a way where if I were a new hire to some construction company and was tasked with building a wall in an existing house, but hadn't been there for the previous 6 months of this house being developed, the risk involved with me doing things correctly goes way up. However, if on that first day (and days there after) they paired me up with somebody that knew what to expect I would feel more comfortable and I'm sure the company would feel more comfortable knowing that I was learning from somebody that had done it before... and done it right.
Out of the different things tried nothing has been as successful as Pair Programming. There just seems to be no substitutes for helping somebody learn the ins/outs of the system/tools/language/project/etc. It really doesn't matter what they are working on... be it new features, fixing bugs, side projects, build systems, etc. There is a big difference between somebody actually telling you how things work versus showing you how.
I was recently the new hire in this situation... though I did have previous "real world" experience.
My boss and her surrogates would always say "play with the system" or "read documentation." I found this really annoying. I made up my own tasks, namely setting breakpoints I knew would be hit, and then doing a simple-yet-core operation on the system, and stepping through from cradle to grave.
As I did this, I drew pseudo-design diagrams of who was calling who with what -- basically, reverse engineering the stuff. Then I'd have one of the other devs sit with me and correct me while I dictated back to him/her what I believed each class's responsibility was and what it was doing.
Aside from that, if you don't have any meaty work for the new guy/gal, I'd try to invent short-term projects that aren't trivial busy work, but the experience of which will help when there is real work for him/her to do.
Of course, if there are short-term-yet-meaningful work available, start them on that. The bottom line is to give well-defined tasks with a goal. Otherwise, if they're like me, they'll come up with their own tasks and goals to prevent suicide from boredom.