21

I've got a senior developer with eight years of .NET experience starting tomorrow to work on a 11,000-lines-of-code application. In the team there's myself and another programmer. We've both got about three years experience each.

It's my first project as a manager (I'm also a developer on the project) and this is the first time I've ever had to introduce someone to an already established code base. Obviously I'll be going over each module, the deployment process, etc., and handing them the location of the source control repository, documentation (which isn't the best), etc.

How long should I give them before they're ready to start writing new features and fixing bugs?

Improve this question
5
  • 1
    It really depends how complicate thosed 11,000 lines of code are. I would expect somebody with 8 years ( that means they started using it in 2003 ) to be able to run at full speed within a week.
    – Ramhound
    May 9, 2012 at 19:02
  • As a data point, a few weeks ago, we reassigned a developer to a project with 13,700 lines of JavaScript code and assumed he'd be productive in a sprint (one week) without even really thinking about it.
    – Gort the Robot
    May 9, 2012 at 20:27
  • @StevenBurnap: I like it :) Light his feet on fire and see if he burns the house down.
    – Joel Etherton
    May 11, 2012 at 17:20
  • Am I really the only one who thinks 11k lines is not much? I'd have given a day, out of the sheer goodness of my heart.
    – Louis Kottmann
    May 16, 2012 at 11:58
  • Part of your choice of assignments may also depend on how late your project is going to be. For some ideas about how to limit the impact of new staff on existing staff, check out programmers.stackexchange.com/questions/164781/…
    – DeveloperDon
    Dec 20, 2012 at 3:57

8 Answers 8

Reset to default
39

I would assign a couple of low priority bugs the first day, that way no one is screaming if they aren't done right away giving the new developer some time to get familiar with the code base.

The most critical thing to do is to have a code review of all of his work the first couple of weeks. You don't want to find out that the guy is going in the wrong direction or not following company coding standards months into things. It is better to make sure he knows what is expected from the start, and code reviews ensures this. Of course I think code reviews are good for all employees (We review 100% of our code before deployment), but they are critical for new employees and should be done in person where you can answer questions and refer them to documentation they may not have seen yet if need be.

What you don't want is a new guy coming in and using a different style from the rest of you. People often try to keep using the code style of their previous job even when it conflicts with the code style used at the new place which can create confusion and annoyance on the part of the other developers.

One thing I have noticed even with experienced developers is that some of them are not as good as they seemed to be in the interview, code review will help you find this out fast, so you can fix it. It will also encourage them to actually get something done, I have seen new employees who are not code reviewed drag out a project without showing what they were doing to anybody and then leave a week before the deadline they knew they were not going to hit because they were in over their heads and had not actually completed any part of the project. Better to check early and often with new people until you are really sure that they are working out.

Also, it is normal for the new guy to be appalled at the state of your legacy project. It's not designed the way he thinks it should have been. Expect this, hear him out and don't automatically dismiss everything he says. In particular, this person appears to have more experience than you or the other developers, he may see things you hadn't considered. However, as a manager, you have to balance the proposed changes against the current workload and deadlines. You all may want to invest some time in learning how to refactor existing code and invest some hours in your time estimates to do that especially if the new guy has some valid concerns. You probably can't support a total re-write (many people who come in new think we should start over and do it better), but you can create a refactoring plan to fix the worst of the problems if there are any that he brings up.

If you have some time where he is not expected to be fully contributing (and fully accounting for his time by client), it might also be a time when he can start on some of those refactoring things that you have wanted to do but haven't had time to do. Sometimes, it is a good thing to use the new person training period to address some things that aren't in the project plan. They can learn the code base and if what they want to do doesn't work, you haven't affected the existing schedules because you hadn't factored them into the existing schedule yet. And if it does work, you might have a big win making future maintenance easier or security better or whatever the problem is.

Improve this answer
5
  • That's a great answer, especially the part about code reviews and the devs opinion on the current state of the project. Fortunately it's a not a legacy project, it's in fact very new, and moving at a very rapid pace.
    – MrBliz
    May 9, 2012 at 14:23
  • 1
    +1 - Lot of good points, but I'd like to reiterate that it is absolutely essential to review all of their work so you can evaluate their skill level and ensure they get on the same page as the team. Unfortunately, this takes a lot longer than the first couple of weeks. Another +1 for not as good as at the interview. What happens to many people between the interview and the day they show up is a mystery to me. Are lobotomies really as common as they seem? That is the only explanation I can come up with.
    – Dunk
    May 9, 2012 at 15:25
  • Yes, review their work to make sure they aren't diverting from established standards. But if they have eight years experience and you have three they probably know more than you do. Make sure you don't force them to do things your way.
    – DJClayworth
    May 9, 2012 at 19:14
  • 2
    @DJClayworth, while I agree that the new person is likely to have more knowledge and the OP should pay close attention to waht he wants to do differently, there are times when your knowledge of the system and the requirements may trump his better general knowledge and you may need to direct him to take a less than optimal path for reasons that are based in the history of the system and the requirements. Sometimes you need to insist that they do things your way for reasons they may not yet be aware of. Of course when you do, you need to explain why, not just we always do it like that.
    – HLGEM
    May 9, 2012 at 19:44
  • @Dunk: in my experience, even the worst people in the world can behave themselves for a few hours during an interview, when they are desperate for a job. That's why contract-to-hire, internships, and code samples are so important with new hires.
    – Jordan
    May 10, 2012 at 5:58
19

Start them up immediately on small tasks - things that don't require the bigger picture.

As they get more confident and familiar with the codebase, graduate them to bigger and bigger tasks. How fast that happens mostly depends on them.

Improve this answer
2
  • This is pretty much what i thinking of.
    – MrBliz
    May 9, 2012 at 14:04
  • +1, this is a no brainer, especially since the code base is small.
    – Louis Kottmann
    May 16, 2012 at 12:04
9

I always like to get tasks assigned to me right of the bat, with the understanding that it will take much longer to dig through the code, and a lot of questions will be asked during the first few days/weeks.

I find that I'm not able to completely get my head wrapped around a project until I have to actually go in and fix or change something.

Also... No matter how well you think you have explained how a project works there is always the 'oh yeah I forgot to tell you', 'we ran into this problem, so we did this' moments that are not teased out until you actually begin work.

Improve this answer
1
  • +1 The sooner the new hire can start sifting through the project, the sooner the new hire will be comfortable (willing to take ownership/accountability) of what they doing.
    – Chad Harrison
    May 9, 2012 at 16:09
3

How long?

How long is a rope?

When he is comfortable: when he fixes his first bug -> he is ready.

Improve this answer
3

In open source community, everyone who wanted to join the project first deals with some tiny problems. If he or she can handle the problem very well, the more important task will be assigned to him or her. In this way, they would become a core developer of the project.

This senior developer has eight years of .NET experience, so you could assign him some simple bugs to fix. If it is easy for him to deal with them, you could assign him complex problems to help him familiar with the whole application. After that, he could start writing new features and analyzing weird problems. Just do it , there has no setup time!

Improve this answer
2

8 years of experience. I would just throw him in. He should be able to swim. As others have noted start with small easy tasks. It will allow him to fumble through the code check-in/check-out process, and any other development processes you have.

I have changed jobs many times and I have been a contributor in all of them within the first week. The toughest took me a week to get the code to compile (100k+ lines of code at least). A full build took 8 hours for that project.

I worked something like 80 hours the first week (project was seriously behind).

Improve this answer
3
  • Interesting that everyone is assuming it's a guy...:)
    – MrBliz
    May 10, 2012 at 12:26
  • 1. I'd say in english the default pronoun is masculine, typing "he or she" all the time would be proper but more effort than most people want to put forth. 2. What percentage of programmers are female? In this case defaulting to masculine has statistics on its side... So I'd imagine its more just using the default simple way to refer to a random individual, not specifically assuming they are male or female.
    – Thymine
    May 10, 2012 at 16:53
  • I'm a guy and so everybody else must be too :-). Just my way of writing, I am not disciplined enough to write he/she all the time.
    – Bill Leeper
    May 10, 2012 at 22:41
1

For an app that small, and a developer that experienced, I'd think a day is enough for basic bugs. Involved bugs or small features closer to a week (once they're clearer on the problem domain and architecture).

Improve this answer
3
  • 2
    I think my standards are probably too high, but yours...1 day...and 1 week to be really productive? IME, that is not very realistic.
    – Dunk
    May 9, 2012 at 15:31
  • @Dunk: to be assigned tasks and be able to approach them without being completely lost? I'm not saying they'll be at full speed, but at that point they should be able to hunt through the code-base, know who to ask to learn more, etc.
    – Telastyn
    May 9, 2012 at 15:36
  • yes, seriously. 11k LoC is not very big. Get him set up so it builds and runs in the debugger and then show him how it works. That should be enough.
    – gbjbaanb
    May 9, 2012 at 16:19
1

The answer is: it depends. If you want him to fix an off by one error on something or change the color of a GUI element, then about 5 minutes (here's where we keep our code), if you want a total redesign of the entire architecture of the app that will require a bit longer.

It really depends upon the task that you expect him to perform.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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