Jump to content
  • Advertisement
Sign in to follow this  
Martin H Hollstein

Training New Programmers on Your Project

This topic is 547 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So, I just received news that I have to train current developers on our current code base and architecture to bolster our ranks and make products faster. Problem is, I know I am not a good teacher and both of these programmers are current employees but with more experience than I (however, different projects, frameworks, and languages). I am working with my Architect on this, but I was wondering if there were a few tips for on-boarding new members on a project?

 

I know I usually just jump in and learn as I go after reading the documentation on the current design/etc. But, these programmers are a bit "set in their ways" if you will.

 

Again, any tips on how to train other programmers? Topics I should hit and stress? How I should present it?

Share this post


Link to post
Share on other sites
Advertisement

The answer is unfortunately dependant on the code base, the type of work they're going to be doing, etc.

 

Generally, when I'm training a new developer, I will walk them through a few critical code paths, showing the major components/subsystems and how they interact. 

 

For a more experienced developer, I'll probably spend less time explaining the basics (they can figure that out themselves) and more on the "gotchas" in the system ("X must be initialised before doing Y"). 

 

As frob said, giving them a few simple, low risk tasks is the best way to let them familiarise themselves with the system.

 

Another option is to get them to refactor that thing that is pretty hideous, but you never get time to fix.

Share this post


Link to post
Share on other sites

Another option is to get them to refactor that thing that is pretty hideous, but you never get time to fix.


Those usually go like this:

- Find nasty code.
- Think "Dear god! This is terrible! I'll clean this up."
- Everything is going well for a few hours.
- Run into unexplainable section which is obviously critical but looks completely wrong.
- Ask the rest of the team about it.
- Nobody has a clue.
- There's no documentation or automated test coverage.
- "Fix" the unexplainable code.
- Everything works great until QA gets ahold of your new build and starts finding really weird bugs.
- "git log" and "git blame" the file to try to figure out who you should ask.
- The git history for that file consists of a single commit that just says "initial commit" in its commit message.
-- OR: The author you find via git blame no longer works at the company.
- Look at your bug list in JIRA, which is a mile long.
- Realize you don't have time to unravel this spaghetti any further.
- REVERT! REVERT! REVERT!
- Add a "TODO: Figure out what the fuck this does" comment to the file and give up. Edited by Nypyren

Share this post


Link to post
Share on other sites

You want to find a balance between tasks that give the developers opportunities to learn about the codebase, and those that they can complete in a reasonable amount of time.

 

It's difficult to put new developers on refactoring tasks because they generally require a lot of intimate knowledge of the code being refactored and how it interacts with everything as a whole. It's often also difficult to make the case for refactoring to the customer because they might not see the tangible benefit, so if it's going to happen at all you want it done by someone who can do it in a timely fashion. It's asking a lot of a developer to refactor code they don't have much (or any) experience with, learn everything they need to as they go along, make sure they do it correctly and not break any existing functionality, actually *improve* upon what's already there, *and* not take too long with it because there are other critical issues to address. At the same time, if you just give them menial labor like "change debug message X to Y", then they won't learn much about the particulars of your codebase, or be adding much value to the product.

 

Whenever I transition onto a new project, I like to start by looking at all the nice-to-have features. Requests that have been made by customers throughout development, but have sat in the backlog because there were always higher-priority issues to address, or other workarounds keeping them from becoming major/critical requirements. If the scope is small enough, you'll not only learn a bit about the code, but you'll also make some customers happy out of the gate, which is always an advantageous position to be in.

Share this post


Link to post
Share on other sites
It's difficult to put new developers on refactoring tasks because they generally require a lot of intimate knowledge of the code being refactored and how it interacts with everything as a whole. It's often also difficult to make the case for refactoring to the customer because they might not see the tangible benefit, so if it's going to happen at all you want it done by someone who can do it in a timely fashion. It's asking a lot of a developer to refactor code they don't have much (or any) experience with, learn everything they need to as they go along, make sure they do it correctly and not break any existing functionality, actually *improve* upon what's already there, *and* not take too long with it because there are other critical issues to address. At the same time, if you just give them menial labor like "change debug message X to Y", then they won't learn much about the particulars of your codebase, or be adding much value to the product.

 

That's why I would only do that in the case of experienced developers. And the whole point is that because it is generally non-billable work, you can get it done while the developer is learning the system (a time when they are generally not very productive anyway).

 

Addtionally, I wouldn't put them on a system critical path, and in an ideal world, there would either be a suite of unit tests around said functionality or I would ask the devs to write a wrapper around the existing functionality, unit test that and then do the refactoring work.

 

But again, it depends on the codebase and the type of product being worked on.

Edited by ChaosEngine

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!