Skip to content

How to Make Your Developer On-Boarding Process Idiot Proof

Metadata

  • Author: Matt
  • Full Title: How to Make Your Developer On-Boarding Process Idiot Proof
  • Category: #Type/Highlight/Article
  • URL: http://shiporgetoffthepot.com/how-to-make-your-developer-onboarding-process-idiot-proofresistant/

Highlights

  • Use Github for more than just Version Control:
  • Their Wiki and README.md features are what I am praising at the moment. The README.md is a text file using markdown formating that you can place at the root of any project. Here you can put all sorts of useful information about your project. It is used a lot in opensource projects but I don’t see it used enough in private repos.
  • Here are some of the things I put in my README.md file:
  • Setup Instructions: So new developers do not need me holding their hand as they try to get setup. It is also a good test of how resourceful they are.
  • Tags: favorite
  • Code Anatomy Map: This folder holds the css, this one the javascript, this one the routes, etc
  • Common Errors: If you run into a problem everytime a new developer runs your app and its easy to fix you should write that down so new devs don’t need to ask you how to fix it. Remember the goal is to take you, the CTO, out of the equation as much as possible.
  • Resources: These are links to any 3rd party resources you are using. It might be a whole library or just a stack overflow post that would be helpful. Sometimes I put these here more as quick links for myself than for the other devs.
  • Pair them with a senior dev: Pair them with a senior for guidance. The senior dev might see this as a waste of their time but what is worse? Temporarily wasting a fraction of the senior developers time to ensure that the new developer is at least partially efficient Wasting your time instead of the senior devs that could be spent on the big picture. Wasting none of the senior devs time but having a completely inefficient and frustrated new developer that you are still paying that may never become proficient.
  • Break down the architecture into logical pieces.
  • Encourage fixable mistakes:
  • Conclusion: Building a scalable dev team capable of hammering out a functional app at break neck speed is not an easy task. These are just some of my tips and tricks. Please feel free to post/email me your own tips and trick on the topic. Good luck to you, now get back out there and ship your product.