Junior Developers – Anthropological Review

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 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.

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 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…)

Reference: Junior Developers – Anthropological Review from our JCG partners Nadav Azaria & Roi Gamliel at the DeveloperLife blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


× eight = 40



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close