• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

bringing someone new into a project

 
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've been working on an open-ended project for about 2 years now, and up until this point, I've been the only developer.
I take the specs from my boss and translate them into code. I did my best to document everything I did with JavaDoc comments and such, but sometimes when I'm feeling really creative, I can't take the time to break my train of thought to properly comment.
Now, I've got a new guy coming in who will probably be replacing me when I leave in a few months. What is the best way to bring him up to speed on how things work in the project?
I've tried to modularize things so that he will only have to look at small, independent chunks instead of the entire project, but each chunk is still pretty sizeable.
Any thoughts? Any books been written about this?
Thanks,
Micah
 
Author
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We're facing a similar problem here where I work. I have been developing a program for about 6 months, and now I have to turn it over to a couple of less experienced developers.
My approach will be:
1) Schedule code reviews - spend several hours (break it up over a 2 or 3 days) going through the code line by line. "This function does this" "Why didn't you do it this way?" "Because this way is more flexible..." and so on.
2) Have the new developer do all support and coding while you're still around. If a problem happens in production, get the new guy to investigate before you get involved. Of course, anything he does has to go through you first, but one of the fastest ways to learn an application is to debug a problem.
And that's pretty much it. Simply telling him where the source code / documentation is kept is usually not enough. Have him actually start to make changes to the code -- that's the fastest way to learn.
Scott
 
reply
    Bookmark Topic Watch Topic
  • New Topic