Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

First day at work for a new programmer.

Assuming that the company has covered all the usual corporate stuff (benefits, paperwork, health and safety and so on), What are the things you should be talking a new developer through to get them up to speed and productive as soon as possible?

In additional what are the key things in making this process a success? What have you seen work particularly well?

(Edit: Added a bounty. The current top answer is fine but I'm still thinking there is more that can be done to make a programmers first week as useful to them as possible. Really hoping for insights from good and bad starts to jobs people have had).

share|improve this question

closed as too broad by Ixrec, MichaelT, durron597, GlenH7, Snowman May 28 '15 at 18:57

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Good question that every existing Team Member and new Joinee should know – Tech Jerk Dec 7 '10 at 13:14

12 Answers 12

up vote 7 down vote accepted

First make sure the week before the person reports on board that everything is set up at their desk (And that they have a desk assigned). It gives a very negative impression to get to a new job and they haven't thought about where you will be sitting or what equipment you will use. Make sure it has a chair - amazing how often chairs seem to dissapear from empty spaces. Have the PC loaded with the software the person will need. Nobody really wants to spend their first day loading software.

Make sure that the person is given the rights they need to databases, source control, etc. Make sure they have been given an email_address. Make sure they understand IT policies such as what can be loaded on their PC, what cannot be loaded, what Internet access they have and what they should not do with the Internet (we don't allow streaming video for instance), who is responsible for fixing PC problems, the contact for the help desk if you have one, etc. Talk about how you use source control, how you do the build, how you deploy etc. Talk about testing, unit testing, QA, etc. Make sure they know how you expect them to test. Talk about code review.

Introduce the person to everyone on their team and any people they will be expected to work with regularly. Make sure they know where all key things are - boss's cubicle, coffee,restrooms, copy machine, server room (if need be) etc. Make the person feel welcome and that you are happy to have him.

If your application is data intensive, give them a couple hour presentation on the database structure. Use diagrams that show relationships. This is a good opportunity to also talk about the business domain and why you need certain things.

Show them where the code is and do an overview of the code structure. Open the application and show them how it works. Go through several of the main tasks including, if possible, the area you want them to start working in. Again spend some of this time talking about the business domain, the experience of the people who use the application, etc.

Give them at least a little time to poke around through the code base and database on their own with no particular task assigned. This might make your previous explanations clearer and help them understand the whole faster than giving a small task to do the first day.

If possible, assign a mentor - someone who will be the source for questions. Try to make it someone who will actually answer questions. Have the mentor and the new person pair program for a period of time. For an experienced guy this might even be a very short time - just long enough to give him some familiarity with how your team works. But for entry level, you might want to do this for longer.

Assign a relatively straightforward first task to all but the most experienced. Check progress daily. Make sure they are not only doing the work in the way you need it done but committing their code to the source control system according to your policies. It seems intrusive, but the least successful new hires I've ever seen are the ones that nobody watched the first couple of weeks to make sure they knew what they were doing. Everyone's work should be coded reviewed, but even if you don't normally do so, code review all new people's work for at least three months. It is very possible that the person interviews well but doesn't work well. Make sure you take the time to know that he is working well. It's a lot easier to correct the person who forgets to save to source control the first week, than three months down the line. And for someone who doesn't learn or won't do things they way you need them done, the sooner you get them out of your team the better for everyone else.

One big mistake I've seen is assigning new people to the complex new task that will require a good understanding of the system, while leaving the old people (who understand the system as it is currently built) doing maintenance. I have never in practice seen this work out well.

First, the old employees resent the new person because they got the interesting task. They will often be passively unhelpful. Second, the new guy is out of his depth because he doesn't understand the systems yet. Third, because he is working on his own (or only with other new people), the work is often not checked until it is too late.

Now you can assign to those tasks if you also have some experienced people working on them as well, but all new people, all new task, that requires you understand the current system (such as a redesign), bad bad choice. Even if you hired him specifically to do the new task, give him a couple of weeks of maintenance of the old system first, just to give him the understanding he needs.

After the person has been working on his own for a couple of weeks, sit down with him and ask him what he thinks the organization could do better. Listen carefully - you don't have to implement everything he says, but new people often see problems that the old people are so used to working around that they no longer notice them. The perspective of the new person to an organization is critically valuable - don't forget to get it. If you are the type who will catgorically dismiss everything he says, then this step is of course counterproductive. But new people are often eager to make changes and to show how valuable they can be. This is useful energy and can help the organization move to be better.

share|improve this answer
"we don't allow streaming video" -- so I assume you've done the cost-benefit analaysis of how much you save on your internet bill by disallowing streaming video versus the cost of your developers not being able to watch training / educational videos that would make them more effective? I'm surprised your "analysis" came out the way it did... you must have some pretty expensive internet and/or some pretty cheap developers. – JoelFan Dec 10 '10 at 1:53
@SpashHit, the people who make these policies are not programmers. We have over a 1000 people only a small percentage are programmers. – HLGEM Dec 10 '10 at 14:21
And every policy in the company applies exactly equally to every kind of employee? – JoelFan Dec 10 '10 at 15:06
Yes, in our case, all the other employees use Internet based applications all day long, running streaming video slows down the actual work, no one is going to let you do that. This is the real world, not programmer lala land. It's a good policy for our company and I only brought it up as an example of what policies you might need to explain. And in truth the vast majority of streaming video is people looking at stuff they shouldn't be looking at from work not training videos. – HLGEM Dec 10 '10 at 17:06
I prefer our programmers to watch lolcats (and keyboard cat obviously) if that makes them happy. at the end of the day if they don't deliver what they supposed to deliver because of lolcats then fire them. It's easier then installing a corporate wide proxy. I guess our programmers living in a "programmer lala land" :) – dr. evil Jul 21 '11 at 12:44

Some things I would expect:

  • Quick introduction to everyone on the team.
  • Making sure they are comfortable with the source control system.
  • Making sure they are familiar with the development process for instance if you use SCRUM, do they know what a stand-up is?
  • Email address is set up.
  • A trip to the pub at lunch to socialise with the team :-)
  • Pair programming with team members for a couple of weeks
share|improve this answer
+1 for the trip to the pub :D – user281377 Dec 7 '10 at 10:52
The pub trip is a very European / UK thing. In one place I worked the Boston office thought we were all borderline alcoholics we spent so much time in the pub but by UK standards we were pretty restrained. Their team building tended to be mountain biking and the like - all very healthy. – Jon Hopkins Dec 7 '10 at 10:56
Why not add in the list: pair programming in rotation with the whole team for a week or two – user2567 Dec 7 '10 at 11:24
Thanks for the suggestion, added – rmx Dec 7 '10 at 11:30
+1 for the pair programming. – Fanatic23 Dec 7 '10 at 13:53

Make sure they have a frickin PC. I started a contract at a nameless (cough Capital One cough) company and had to wait 2 weeks before I had a PC to work with. Now reading source documentation for a product is never fun, but imagine doing that almost 8 hours a day for 2 weeks...

share|improve this answer
HAd the same thing happen to me. I was replacing someone but between when he left and I came they gave his pc to someone else whose PC broke. They didn't think to order a new one (government work, they couldn't just go down to the store to buy, had to use the procurement process) until the day I reported on board. For two weeks I worked on the PC of whoever was out on vacation or sick leave or out of the office that day – HLGEM Dec 9 '10 at 14:57
+1 since I had a similar experience. Had to use my own laptop and my office in the "printers cube" for about a week at my previous job. – Dillie-O Dec 9 '10 at 16:00
@Dillie-O: I feel for you, I did the same except that it lasted for 6 months. – Steve Evers Dec 10 '10 at 1:25
Wow...that seems as though it should be too obvious to mention. My condolences. – Stargazer712 Dec 10 '10 at 22:40

I read an article somewhere where the first day on the job a programmer makes a small, and still relevant, change to an application they support, while having an existing employee there as a mentor. In doing this, they are exposed to the following things:

  • Their workstation and some of the software installed on it.
  • The coding structure/format of their applications there.
  • The source control system their are using.
  • The process one goes about migrating a change up to production (do they do it all themselves, do they contact a couple administrators, do they process a ticket, etc.
  • The satisfaction of actually DOING something on their first day to better their work environment, even if it was simple.

If I were to start a new job, I would love to have a first day like this. You get the conceptual and the practical knowledge that will apply to your day to day duties and you have somebody there to answer any questions the new employee might have about the process.

share|improve this answer

Not sure exactly what you are asking. Hope you are not asking for the new comers to be productive from day 1.

Let them understand the development setup, source control. Give the access to the important architecture level documents. Then start giving small testing assignments. Let them test the bugs fixed by the seniors. Also slowly give them small, minor bugs to fix. Introduce them to library and let them read some good books.

EDIT:- I forgot the most important thing. If possible assign one senior to each to mentor them and answer their doubts.

share|improve this answer
I'm asking what you should do with a new developer when they arrive to make them productive as soon as possible. – Jon Hopkins Dec 7 '10 at 10:59
Then I hope I have done right thing answering this. – Manoj R Dec 7 '10 at 11:00
+1 for start small – rmx Dec 7 '10 at 11:14

This would be my suggestions from a high level perspective:

  1. Make sure you know what kind of work you have for them to do initially -> Is it building out a new system, fixing bugs, handling support requests, creating documentation, gathering requirements or testing? I did have one place where initially I was helping to test on a project that was going out in the first few weeks I was there that was a nice starting point as that let me make a contribution without having to do days of work to get up to speed. Just adding a new body and not having a plan for what they'll be doing is dangerous.

  2. Ask the developer how they prefer to take in information -> Do they like to pair program, read documents, watch videos of users doing things, just have someone they could IM with questions, etc. The key here being what communication style and format works can vary from person to person though some may have a better handle on this than others.

  3. Talk them through the regular work procedures in terms of process steps. If they are fixing bugs, what are the steps in the process in your company's case? What systems are to be touched, are there e-mails to be sent, etc.? If they are putting in new features, how is this done in general? What kinds of batch files exist to automate some of the work that is done,e.g. where I work now I have nAnt scripts to build and test code while in previous places I had scripts to get binaries and other stuff that was needed for the sites we built. There are various ways to merge code, handle commits and other changes so don't assume too much here.

  4. On the general level of working there, cover the basics here. What hours do people generally work? Is there a need for extra time when they joined,e.g. a project has to be done in 2 months and we need new people to work an extra 10-15 hours a week to meet that deadline despite what the Mythical Man Month says about adding new people? Are there times where everyone goes for lunch? What kinds of social dynamics could one expect,e.g. are there a group of smokers that flock together or a group that will usually go to a local pub after work most nights? Note that while some of this may seem general this is team specific in a sense as if all of the developers come in at 10 and the new guy(s) are there at 7, what are there to do for those first few hours alone?

I have had a few snags that I hope to never repeat:

  1. In university on a co-op placement, I had a position at a bank where for my first week was rather bizarre. First, after the first day my supervisor was on holidays for the rest of that week which made it hard to know what to do from his view. Second, the co-op student I was replacing was still around for that week but spent most of his time goofing off as he didn't have much to do at that time. That alone would be bad but then I didn't realize that getting paid and timesheets weren't properly handled until 6 weeks into the job which lead to more than a little melt-down. While this may be more of an HR point, do be sure that the new hire is set up correctly.

  2. In my first job in Calgary, where I worked spent 6 hours getting me a PC and setting it up initially. This meant I got to spend that time reading books I brought as I was paid by the hour and I couldn't pair with my co-workers as that was thought to be a bad idea at the time. Nothing like reading a book while waiting for stuff.

  3. Another time I was coming back to work after having taken a break and was going to be working from home. This meant calling the help desk for how to get the VPN set up, how to get to my box, and a few other things that just made for some brutal days on my end. I spent the first couple of hours just trying to get to my work PC that was shut off and so someone had to turn it on so I could get to it. I also had to adjust to a single monitor which wasn't fun.

Some other ideas:

  1. Befriend the new person by sharing meals with them. This may mean taking them out for lunch or dinner as a gesture of, "Let's get to know each other." This has often helped me get more comfortable in various jobs in my life. This can be more important for the manager of the new person to do as this can help a little with productivity at least in my experience. I know that I'll work a little harder for someone that I view as a friend than for someone where I'm just working to not get fired, which is very similar to an "Office Space" line that seems all too eerie now.

  2. Be prepared for social stuff to take some time to work itself out. People aren't friends overnight and so bonds make take time to form.

share|improve this answer

I have always felt that you need a good getting started document that details how to set up the development environment. I think that the new person should have to go through and set everything up on their own mainly so that they get a better understanding of the tool set.

I have also always wanted to have a few predefined exercises that every new person would have to go through. I would want these to be designed such that they would enable a new developer to quickly get exposure to different parts of the system. I would think that there should be several that they would need to go through each taking a day or less. The hope would be that they gain some very real experience on how the system works. The more quality experience a developer has the better they are going to do.

share|improve this answer

On top of all things said here, for a Junior profile, I think it's fundamentals let him doing pair programming with several other programmers of the team.

For an Senior profile, put him soon on trial with something hard so that the team can easily accept his authority.

The most important thing is for him to accept the team and for the team accept him.

As P.Drucker said: "look for strength in hiring, not on weakness". So our team is build on good programmers, but some devs are really "peculiar". So also for the new dev entering the team could be challenging for some days. So it's important for the TeamLeader to make sure the novice will accepted soon.

share|improve this answer

By the time you've hired someone, you already know they've got the where-with-all to do the technical stuff - what's going to help them get meaningful results, is understanding WHO their customers are (internal or external), and what the customers expectations are.

Once your new hire understands how the team delivers to the customer, all the processes and tools you show them will be understood in context.

share|improve this answer

Make a slight change in the GUI design standards, and assign the new employee to implement those GUI changes for you existing programs. This way he/she will get a practical introduction to the products you develop.

share|improve this answer

I've found the single most important thing is where to find things. In general, but specifically in the source control system. Are there common libraries and tools that they should know about? Are tools in one area and products in another? How is the code for large project X broken up? That sort of thing. Without this it can sometimes take months for a developer to find something, and they often don't ask because they have no reason to assume something particular is in the system.

share|improve this answer

Unless this is an entry level job I would presume that the technology is understood (Java, .NET, HTML/CSS/JS), the process in use for the most part is understood (Scrum, Waterfall, Kanban) and the only need at that point is a comfort level.

Becoming productive over the long haul is often a sign of being comfortable in the atmosphere. Can you be productive in an uncomfortable atmosphere? Absolutely...but a comfortable atmosphere will significantly increase the likelihood of being productive.

The way I believe to achieve this is through ownership. Start small...and increase that ownership as the individuals key talents begin to surface. Once the talents are noticed amongst peers; comfort will ensue. Once comfort ensues the team begins to formalize and strengthen; leading to productive team members across the board.

It's like a pack of dogs in a raw a new dog is introduced you must make that dog feel comfortable to become part of the pack and to keep the pack strong and productive.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.