Length of Time to become productive

At my first job, it took me four months to learn the in's and out's of the business, to get to know the other coders and to learn their style of coding (i.e. how they wanted things done and how they did them, politics of the place more or less).

My question is, How long does it usually take for a new hire to become productive?  If Fog Creek (let's pick on them) were to hire someone today, how long would it take for them to make a meaningful contribution to the development of their software?  Joel claims that one of his intern wrote the PHP to ASP compiler thingy in 2 - 3 months (correct me if I'm wrong).  That's a major contribution in a short amount of time and I'm sure he (the intern) had some help and guidance.

I would think that it depends on how well the candidate knows the language(s) and development methodologies you are using, how well they know the business you are in and how well they know the theory of the tasks they are assigned.

So what procedures can you use to get a newbie up and running fast?  What is the average time it takes to get the new guy up to speed?

Standard Guy
Sunday, January 18, 2004

It took me about three months to learn how things really worked (who knew what, how we documented things, coding standards, how to get things scheduled (nightly production jobs)).  But I was making contributions within the first few weeks.

I think it probably takes 3-6 months to become an effective team player, but a coder can produce good code in a very quick period of time.  It would appear that Joel's intern was working on a relatively stand-alone project that didn't require a large knowledge base of standards/rules/operating procedures.

I think that bringing new people into a team by making a good 75% of their time be on stand-alone projects is a good way to get results.  The remaining 25% of the time can be spent learning all the ins and outs of how the team/code/business works. Sticking a new guy into a complex/large code base is probably a bad way to proceed.

Lou
Sunday, January 18, 2004

There are too many factors to consider.

Some people learn very quickly.
Some people have had previous experience with similar projects.
Some projects are more complicated than others.
Some projects are more modular than others.
Some projects have significant domain knowledge requirements.

In short, it's going to vary by at least a factor of 10 depending on the project and the person.

Sum Dum Gai
Sunday, January 18, 2004

Many of my projects are 3 months or less, as a contractor if I can't get productive within a couple of days then I have a big problem. Of course in this scenario you have to lean on the other team members quite heavily to get things done.

Tony Edgecombe
Monday, January 19, 2004

I have very different experiences. When I had a contracting job they used me 100% from day one (http://www.holidayhotels.com).

I received small, measurable pieces of work which were exactly in the area of competence I declared. Each piece would take me less than a day to complete, then I would receive next task. Only one small measurable task at a time. No one attempted to involve me with too much business rules, as they new I will take time to learn, instead they used my "technological" common competence.

Source control procedures were dead simple, when I asked them, why couldn't we use better tools I was told: "We try not to spend our time choosing tools." It made sense, since contractors usually paid more for their 5 minutes coffee breaks than many people per hour.

My other (permanent job) took people years to understand logic and rules behind the business. It was "we hire only best scenario", when you want to leave a company next week you joined it. People would work for 12 years and still be competent in very narrow area.

In average it takes half a year to be fluent with company procedures in most environments and more that a year to gain deep understanding of "historical background" :-). Sessions out with co-workers and "document analysis" (everything you can find on network starting from presentations and ending by meeting minutes and past schedules) will give much deeper and quicker overview of the company.

If I were responsible for someone getting up to speed (and I were responsible) I would try to give this person fairly isolated piece of work, which is not critical schedule-wise and relies primarily on persons current expertise. It would allow a person to feel like a contributing member and learn company procedures at the same time. Next step could be integration of this piece with existent product. 

Vlad Gudim
Monday, January 19, 2004

"I would think that it depends on how well the candidate knows the language(s) and development methodologies you are using, how well they know the business you are in and how well they know the theory of the tasks they are assigned"

In my experience it's what is not listed here that is the biggest problem. It's how foobar'd their apps are. The rest is cake.

Steve
Monday, January 19, 2004

  Recent Topics

  Fog Creek Home