Taming your new Junior Developer

Junior Developers...You can't live with them and it is illegal to shoot them. Well, except maybe for our North Korean readers. So how the hell can you pass software development knowledge to someone who thinks that Maven is a city in Eastern Europe?

In his book 'Software Development as a Cooperative Game,' Alistair Cockburn describes the three levels of learning in Aikido. They are Shu, Ha and Ri, and roughly translate into learn, detach and transcend.

• A worrier in the Shu level learns techniques from his master and copies them. This level is also called ‘Follow the Master,’
• In the Ha level the worrier learns the strengths and limitations of a technique. He learns other techniques and can now choose which one to use according to his position. 
• In the last level Ri the worrier creates a blend of techniques he knows, while also inventing new ones.

These three levels of learning exist in any craft, software development included. The Junior is naturally at Shu level in most aspects of software development. Consider Object-Oriented Design, for example. A Junior will adequately follow the rules he just learned at the CRC Object-Oriented Design course. He is the one saying "We should use smaller cards. In the course they told us to use 6-inch cards...”

Let’s consider the communication between two people in different levels. If we deduce it to our world then it is between a Senior and a 'Shu' level worrier/developer. A Junior will always prefer to receive a set of instructions/rules for every task he needs to accomplish.

A Junior joining a software development team has a lot of catching up to do. He doesn't know the product. He doesn't know the business domain. He might not know all the tools and technologies you are using. He definitely has no familiarity with software development idioms such as Dependency Injections, Continues Build, etc. Make sure his assigned tasks are with no more than one unknown domain. Moreover, make sure he understands that one of the task goals is to better understand that unknown domain. Taking a different approach will lead the Junior to believe that the world is too complicated to understand, rushing to you with problem descriptions like "That red thing is not talking to the green part of my screen anymore. I tried to restart it but it doesn't help." Remember that a software developer must be inspired to understand what is happening under the hood. Throwing too much complexity at once might generate the exact opposite. 

Embracing new technologies is a good practice, but it depends on when and where such embracing takes place. Google-Guice's home page describes how using the ‘new’ operator is old-school. In the Git home page they tell you that using a client-server source control is old news - Distributed Source Control is Da - Bomb. When visiting the Scala home page they will convince you that using critical sections ‘synchronize’ is ancient history - STM (software transactional memory) that is buzzing. The Junior will believe them all. One day he will call you all excited for a simple dialogue-application demo. It will be on a Git branch, while all objects will be created using Guice, and instances will only communicate using an inner event bus that uses a weird syntax of embedded Scala code. You get the idea. So please don't let a Junior embrace new technologies without your review.

Remember that the Junior only recently graduated from the University. He already gained experience in problem solving. In the University, solutions were always elegant yet complicated where in the real world, chances are that the best solution is naive yet simple. Once more he will come to you showing off his latest coding. He was instructed to read some configuration from a database and save it in-memory. You desperately try to keep up with his explanation on why he had to use a red-black tree (something about reducing the complexity from O(nlogn) to O(lognlogn)) while also trying  to overcome the sharp pain you suddenly feel in the chest. So stop mumbling "...but there were only 20 rows in that table..." and remember that you must change his approach to the well-known "keep it simple."

Stating the above, we can't ignore the benefits of Juniors. Their ability to adopt new technologies while staying highly motivated and hard working (usually they don't have 3 mouths to feed) can't be disregarded. With patience, us senior developers can get these Juniors to the Ha and Ri levels sooner rather than later.