How long does it take to start doing productive work for a developer new to the job

Question

He will be a developer inheriting a 6-year-old java+spring code base, and will be part of a 4-person development team. The code has threading components and messaging components. The code is messy and complex, with both client/server components, and overly structured with all kinds of interfaces, abstract classes, multiple branches from trunk, etc. Checking out all the source code from SVN on a T1 line takes about 5 minutes.

And there's no documentation and little comment in the code, the only help he'll get is through "question and answer" type things from other developers, who may not be familiar with all the details themselves, as many parts of the code are written by people who already left and are left untouched for a while.

For this kind of situation, is it reasonable to expect a junior developer, on his first day, to independently build, study, test and understand this entire code with minimal guidance and help? Or is it better to walk him through the initial build, give him detailed overview of the code's architecture? And how long should it be before he is expected to know the code base well enough to independently make changes, add features, create new branches, etc?

Answer 1

On his first day!?!? Wow! I'd say that at some places I've worked it can take more than a day just to fill out the forms that let me in the door and figure out where to get the coffee.

It often takes people more than a day just to get the damn tools set up at several places I've work (not because of the new guy, but because there's a lot of admin stuff and poorly documented process).

So you have a codebase that's complex, undocumented (not just under documented), and experienced people at your outfit don't fully understand it. And you believe it might be possible for a junior dev to get up to speed in a day?

I don't know how long it'll take, but don't expect it to be a day - or even a week.

Answer 2

No. It is not reasonable to expect this. It may not even be reasonable to expect it from more experienced programmers. For junior programmers just out of school it takes about 6 months to become really useful to a team. And that is on teams that may be more organized than what you described.

Answer 3

Having done this a few times (although with code that doesn't sound quite as bad), I would expect a couple days just to get his local environment up and running, unless the setup instructions and scripts are really good. If you use virtual machines to share dev environments between developers, this can take the setup time down to a couple hours or less.

As far as making meaningful changes, I wouldn't expect anyone to be able to make ANY changes without a week or so of ramp-up (maybe more). A good experienced developer might be able to make simpler changes within a few days, but that's optimistic. Adding features and creating branches is harder, I'd think it would take a few weeks (or maybe a few months) for most people to get in deep enough to do that correctly.

Given that, I'd take the following steps:

1. Get the developer's environment set up and completely working
2. Have someone with knowledge personally give the developer a high-level overview of the system
3. Give the developer all the documentation that exists and is correct
4. Let the developer just read the code and step through it until they have an idea of what's going on
5. Have someone available to answer any and all questions that the developer may have about the project

Answer 4

I'll address each question:

For this kind of situation, is it reasonable to expect a junior developer, on his first day, to independently build, study, test and understand this entire code with minimal guidance and help?

No - hah, are you kidding? "entire codebase?" haha - you'll be lucky if he gets through AND UNDERSTANDS 15% of the codebase on his first day.

Or is it better to walk him through the initial build, give him detailed overview of the code's architecture?

Maybe point them in the direction of the areas they'll be working with first (what's the first business requirements they'll have to address), let them take a wack at it, then have them explain it back to you.

And how long should it be before he is expected to know the code base well enough to independently make changes, add features, create new branches, etc?

I would say months. Months before you can rest relatively easy that they will do more harm than good. Fixing a display related bug VS fixing a threading/concurrency issue. I mean come on, it really depends on what they're expected to tackle.

Bottom line - it takes time to come into a 4+ year code base that's not documented (shame on you) and is messy/engineered for the sake of engineering (overly structured, again shame on you) and be productive. time. it. takes. time.

EDIT: Oh and don't think you can just drop the developer in and they'll magically be productive. They need guidance. They need direction. You've got to get down in the trenches.

I cannot stand managers that think they can move programmers around like chess pieces and we will all perform equally well. Across languages, IDE's, projects, etc. Yeah, we can get it done, but use the right tool the job damnit.

EDIT:

Also, is it a sign of incompetence that he constantly needs to ask questions about which class/method/code piece corresponds to which function in the application?

Hell no! If you're on your grind working the code and you have questions - don't goto the team leader first. Goto another junior dev, then the next, then the senior, then the PM. Work your way up the ladder with your questions. But don't ever stop asking questions man.

Answer 5

Usually it takes about two days to set up your workstation and one day to a week to get your project-specific build environment fully functional.

After that I'd give it a month of working on the project before I made any structural changes without consulting team-members with more experience.

That said, if your environment was already set up, you might be able to analyze and fix a bug the first day if it's trivial.

Answer 6

In a day he can probably get the code up and running with the teams help. During that time you should give him a high level overview (sounds like your devs cant do much more than that anyway). Explain important packages and things like that. Then, let him start on some defects. Defects are a nice way for developer to get his feet wet in some new code.

Make sure the experienced devs review his code and during these reviews/discussions he will learn a lot about how the code is structured, and what is expected of him. I feel this is a more natural progression than just trying to give him a "detailed overview of the code's architecture" as you said. This kind of lecture is often too hard to digest in any meaningful way.

So, in summary, give him a brief overview and let him learn the code via fixing and discussing defects.

Best of luck in this tough situation :)

Answer 7

If you expect someone to be self-guided, they would have to have solid experience under their belt, and not just from a technical standpoint.

They'd have to have decent time management skills (work efficiently and independently) and (judging by the solution you described) experience on large or complicated projects. I seriously doubt you'll be able to hire that kind of person as a Junior Developer.

I'd suggest if you want a new person up to speed as quickly as possible, you will have to invest at least a full week with them, because introducing a new person is more than simply sitting them in front of source code. You'd have to introduce them to the work environment, a whole batch of new people and, probably, a new work environment.

Given the lack of documentation, I'd suggest a positive task to give them would be to document the architecture. This would be a great learning exercise for them, and would produce something valuable for your team as well. It would also give you a good idea how much experience they have and how fast they are at comprehending technical concepts.

With regards to how soon you could expect their full participation in day-to-day development? It would really depend on how much help you give them initially.

It could be anywhere between 1-4 weeks - a lot depends on how much help you give them and how quick they are at picking up concepts. It also would depend on how much prior experience they've had.

If anything, you should always review a new person's contributions carefully (initially) until you are satisfied that they have a good enough handle on "how things are done" in your workplace. So there's not really an accurate way to measure when the new person is ready to contribute with minimal supervision. "it depends".

Answer 8

There's a reason why The Mythical Man Month is such a classic.

New developers take time to come up to speed. Expect weeks or months for experienced developers. Perhaps only a bit more for junior developers, but only because you expect so much less of them. A code base that took 4 years to write will probably take 4 years to fully master. In general code is harder to read than it is to write. Especially bad code.

During the first few months of coming up to speed, your existing developers will be less productive because they have to spend some of their time guiding the newcomer. This should hopefully be less disruptive if the newcomer is experienced, but everyone will take some time.

Remember. Adding more developers to a late project makes it later.

Answer 9

In my limited experience with software development jobs, for the first week you basically don't write a single line of code (it's all training). The rest of the month they put you to code, but don't expect you to to have serious work done because you are still familiarizing yourself.

Answer 10

Even though this guy is a good programmer, it will take some time to him to ge used to the code;

There are some clues to help him to get used to it.

1. First of all, he needs an overview of the problem and the solution (in this case, the program)

2. Try to ask him to do small changes in different packages of the program to get familiar to the project.

3. As it is stored in a version control server, let him commit mistakes without guilty.

Answer 11

It is not reasonable to expect a junior developer to build that code on the first day. Depending on his skill level, I would give him 1-3 months to get up to speed.

Answer 12

I seriously doubt any developer regardless of skill will be productive the first week they are on the job with a system like you described, however he/she should have no problem reviewing the code, running the build, and executing the test suite (you do have tests don't you?). On my team, I expect new developers to spend at least a sprint pairing with different team members so they get a firm grasp of the code base, learn our work process, and to get to know the other people he/she will be working with.

Like others have said, you get what you pay for. You hired a junior level developer so expect to spend a great deal of time mentoring him/her. If you want someone that already knows everything about eclipse, everything about concurrency, and everything about complex architectures, you are going to have to hire a senior level guy which will probably cost double what the junior guy cost.

With that said, there are several things you can do to reduce ramp up time. First, make sure your build process is automated so developers run a single script to build the code and run the unit tests. New team members can study this script to learn the build process. Next, have an existing team member setup the new developers environment before his/her start day. If all your developer's machines look the same, clone an existing machine (Norton Ghost). And finally, do some pair programming with the new team member. IMO, there really is no better way to spread knowledge than to pairing.

Answer 13

After you get him set up with the code, give him a project adding javadoc / documenting the code - I have found this a good way to understand a new, unfamiliar code base. That, and it will be documented for the next recruit.

Answer 14

Understand it on the first day?? 5 minutes on a t1, let's guess 1000 - 5000 classes. You couldn't even read through that in a day, or even a week. It could take you a week to read it if it were prose.

On top of that even your current staff, who've been living with this blighted codebase, doesn't understand parts of it. But a junior guy is going to come in and understand it in a day. I hope you hired someone who can psychically assimilate code by pressing the hard drive to his forehead.

This is why people use things like documentation. But you didn't do that. So it will take even longer to understand. This is the cost you pay (and your new developer will pay) for the time you thought you saved in the past by not writing documentation, refactoring, structuring your code clearly, etc.etc.

Sorry to be so harsh, but this drives me crazy. A new developer comes in somewhere with massive technical debt because they've exercised no control over code quality or standards and the new developer ends up paying for it. I wouldn't be at all surprised if the build system was in similar shape, so it might take days just to get running.

Months to be useful. On a positive note, since you now have the opportunity of someone seeing your code with fresh eyes, you should have him keep track of what parts of the system are most opaque, it can serve as a guide to what you most urgently need to clarify/document.

Answer 15

If this guy did manage to get it all sorted out on day one, clone him and fire the other useless layabout developers. And promote him. And he can probably do your job too.