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 which 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.
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 then 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 the mood of "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 to much complexity at once might generate the exact opposite.
Embracing new technologies is a good practice – depends when and where. Google-Guice 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 section and ‘synchronize’ is ancient history - STM (software transactional memory) is buzzing. The Junior will believe them all. One day he will call you all excited for a simple dialog 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 weird syntax of embedded Scala code... you get the idea. So please don't let a Junior embrace new technologies without your review.
The Junior only recently graduated from the University. He already gain experience in problem solving. In the University solutions are always elegant yet complicated where in the real world most chances 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 are desperately trying 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 cant ignore the benefits of Juniors. Their ability to adopt new technologies, highly motivated and hard working (usually they don't have 3 mouths to feed...)
