A Journey to Get Things Done And Understand Why

Mentoring Junior Developers – Part 1 (Technology)

Published a couple of months ago in Leadership , Management - 0 Comments

Here’s the situation. You’re a Software Engineer at ABC Corp. You’re on the widgets team and you can’t possibly do all the work that you’ve been assigned. Even if you are the greatest developer ever known, you still can’t split yourself in half and those 18 hour days are starting to slow you down. So what do you do? Tell your boss you need to hire another developer. They say, sure, do what you need to do.

Ignoring all the hairy details and the terrible applicants, you’ve hired a very intelligent developer who recently graduated, has a bit of internship experience and is ready to work. Now what do you do so that you aren’t still spending 15 hours with 1/3 of those of rejecting pull requests?

Here are a couple suggestions that have served me very well:

Technology-based Suggestions:

1. Make sure they understand how version control (git, svn, perforce) and code reviews work

Most junior developers don’t understand how to properly use a typical branch-merge-pull flow. Get them to create a branch, solve a simple problem and push up to the main repository. Give them their first code review. Look it over on your own and then go through the issues together. Create a back and forth conversation. This serves as a foundation for the conversation that should take place within your version control interface. Nothing will feel more defeating than having them push up a change only to have it picked apart and rejected without proper explanation.

Important Topics to Cover:

  • git pull and git fetch – Understanding the difference between pull’s automatic merging and fetch just retrieving is vital
  • git branch – Keeping everyone from pushing master and allowing for proper pull requests great for collaboration
  • git rebase –interactive – Being able to squash or remove commits keeps your git history clean and legible (and required for open source contribs)
  • git revert – Failing builds will happen and being able to undo those failures until further review is required. Another reason why squashing commits is important
  • Resolving git merge conflicts – Simply fear-inducing for juniors. Help them understand how to use git diff, remove conflict headers, and commit properly
  • Code review comments – Simple comments that are to the point, based on standards, and no pejoratives
  • Code review requirements – How many people need to give their approval and what form must it come in to be merged

2. Make sure they know how to use a visual debugger and a command line debugger

Nothing is more depressing than seeing someone decorate their code with output statements in hopes that maybe, just maybe they can deduce the right state from which an error was caused. This process lies the way to madness and despair. Many juniors have difficulty with the idea of using a visual debugger in something like IntelliJ or Visual Studio to properly interrogate the state of their program. Bug fixes are the most common project for a junior dev. When they come to you stumped, use a debugger to diagnose the problem.

Important Topics to Cover:

  • Conditional Breakpoints – Saves a lot of time and pain attempting to unsuccessfully find edge cases
  • Stack Frame Traversal – Going up and down the stack can help understanding of how methods are being called
  • Assembly Instructions – (if applicable) Stepping through asm instructions can give fine grain detail to what is happening
  • Remote Debugging – Being able to connect to and debug a remote process (while sometimes unreliable) can be a huge boon to understanding a problem
  • Command Line – Not having a GUI is a strong possibility. Show how to start processes in debug mode, attach to that process, and debug via keyboard shortcuts

3. Teach them to RTFM

It is a harsh acronym but it belies a simple truth. Documentation can sometimes be hard to parse but it is a skill like any other. In the same way you learn to comb stack overflow for a useful answer, juniors must be able to delve into language or api documentation or internal wiki to devise how to proceed. This is a “teach a person to fish” sort of situation. Don’t respond harshly or critically. Simply help them find the resources they need and (more importantly) how to use it efficiently. Don’t just send them a link and say good luck.

Important Sources to Cover:

  • Unix Command Line Manuals – The sources that started it all. Being able to call man on a binary in unix is almost always a fantastic resource. Point out that the examples are at the bottom.
  • Language Documentation – Almost all JDK’s are quite well documented and readable. Being able to understand under the covers what your util methods helps people understand tradeoffs.
  • Good Project Documentation – SQLite or Python’s Request module are examples of great documentation to absorb and emulate
  • Internal Wiki – It’s quite likely you have internal (or even external) wikis about projects and API’s via services like Confluence. Guidance on navigation and contribution are incredibly important

4. Impart the importance of proper testing

While not everyone subscribes to or even considers test driven development as viable, tests will always be an important part of being a developer. (I once knew a developer who went a step further and included full proofs of the superiority of his code in method comments…). Depending on your industry this could mean something as simple as appropriately placed assert statements or full on test suites for every layer of the project. Either way, the best way to be sure that code works (and more importantly) continues to work is by having tests. Most junior devs will have had little experience with tests (heck, many mid-level devs I’ve seen have had little experience with writing tests).

Important Sources to Cover:

  • Documentation of the Framework Used- Not being introduced to the frameworks used can stifle any attempt to do testing. Unlike most parts of programming, if someone simply forgets to include tests, the software works “better” (no pesky failures).
  • Common Test Uses In the Codebase – Common examples of how testing is used really helps speed understanding. Great examples are past bug fixes and the tests applied to prevent them.
  • Unit Tests – Highlight the isolation and simplicity aspects of unit tests. They should be quick to run and test common edge cases but do not need to be exhaustive.
  • Integration Tests – Highlight the testing of flows for correct and incorrect input. They should verify whether the right interfaces and services were called and if it was done properly.
  • End-To-End Tests – Highlight proper delivery of payloads. It should return what a customer would expect (either the proper data or easily decipherable reasons for failure)
  • Using Mocks/Stubs/Spies – Subtle differences between these can cause confusion. Explain the differences and how they both prevent unintended side effects as well as confirm proper program flow
  • How to Execute and Debug Tests – Tests you can only run on a CI/CD server are pretty useless. Make sure your junior knows knows how to start tests locally and dive into them if needed. It’s a great way to isolate the part of the system they are working on.

No comments yet