Mentoring Junior Developers

The most important skill of senior developers, working in teams, is to be able to pass down skills to junior developers.

The best way to pass skills is by using pair programming. Pair programming is a practice with many benefits, one of them passing knowledge with direct interaction.

While pair programming should be the main tool used to pass skills to other developers, different techniques should be used in different scenarios. The scenarios present themselves at different stages depending on the project and its maturity.

There are many adversities in passing skills to new developers, depending on the type of project, and the stage of the project:

  • Business rules (domain)
  • New technologies (R&D)
  • Cryptic code bases (legacy code)


When complexity in projects comes from complex domains, the best way to catch up the new people with the project is to talk to the business analysts about the project. The business analysts and developers can come in a consensus of what is the common language in the project, ubiquitous language. Then they can start to build new behavior based tests. Behavior based tests check that the basic operational rules are not violated. Therefore, all changes passing tests will be in-line with the business vision. The behavioral tests will prevent the new developers from altering logic that will affect any stakeholders.

When dealing with R&D, one of the biggest challenges is bringing people up to speed on proprietary, cutting edge or obscure technologies. The best way is to build materials for them to learn on their own, just the basics. This is of course complementary to shadowing senior developers, because this way they will be able to also learn debugging patterns and undocumented parts of unusual technologies.

For cryptic code, the only thing that helps are a large time commitments and pairing based refactoring. They are required to help the new people whenever they have questions. Whenever they find something they do not understand, make them write it on the project documentation so the next person will have an easier time getting accustomed to the code.

General best practices:

Do not have them shoulder surfing for days. Let them drive in pair programming. In shoulder surfing lessons it is possible to get the big picture but the details are lost. Without writing code people have a hard time learning keyboard shortcuts, locations of functions and they miss kinesthetic learning.

The most important thing to remember. Be professional, honest and approachable. I have worked in several teams where developers are afraid to ask other developers for assistance because they are treated as ‘n00bs’. By being professional you become a role model. By being honest people will trust when you point out their flaws or strengths. Finally, by being approachable, when they make a bad mistake, they will let you know right away. Then the error can corrected as soon as possible.
Don’t copy-and-paste code. Don’t use debug driven development!

Don’t copy-and-paste code. Don’t use debug driven development!

I see a common copy-and-paste trend specially with junior developers. Many of them just copy-and-paste random internet code into their projects. After a while I ask them about their implementation… very few understand what they copy-and-paste and the implications of that implementation!

I inquired further and it was clear that many used debug driven development to get the copy-and-paste code to work. Debug driven development is basically 90% random changes and 10% thinking. This is a popular trend within .NET developers with visual studio because the IDE is amazing…very little planning is required to get things to work.

After a few weeks of seeing this trend I did the following:

If they asked me a question that I believe is due to copy-and-paste or debug driven development I reply with the following questions

  1. Did you google the problem? (some  of them didn’t google the problem!)
  2. Did you copy and paste code? Is that code giving you the error? If you did copy and paste, what does the code do?
  3. What are 2 different approaches to this implementation and why did you choose this implementation?

After answering the questions above, they were able to solve the problems themselves. That makes them happy and it makes me happy!

The build process

The build process

  • Ensure Binary Integrity of your build:
    • The build either works or it does not work. This way it is easier to rule out errors in different layers of the project like database or logic
  • Builds are obtained from files under source control:
    • This means that if a problem happens the error can be linked to a specific commit or tag under version control
  • Build can happen remotely (production) or locally:
    • This allows for the same local configuration to be tested on different environments remotely (production)
    • It can also allow specific special configuration (ex: a tag under version control) to be propagated to production
    • Basically helps prevent configuration errors by removing as much as possible the human aspect
  • All builds should contain a database script (under version control) that creates/restores the database  from scratch
    • This way each database change is linked to a version under version control and errors can be linked to each build
    • Also this makes finding bugs a lot easier as they are easier to reproduce