Nadav is a software development group leader. He gained experience in all aspects of software development including requirement analysis, software design and implementation. He has 3 kids and a fish. Nadav is a DZone MVB and is not an employee of DZone and has posted 8 posts at DZone. You can read more from them at their website. View Full User Profile

Taming your new Junior Developer

07.19.2012
| 5627 views |
  • submit to reddit
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 ShuHa and Ri, and roughly translate into learndetach 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.
Published at DZone with permission of Nadav Azaria, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Barry Smith replied on Thu, 2012/07/19 - 12:17pm

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?

With that attitude you are not ready for any form of management.

Loren Kratzke replied on Thu, 2012/07/19 - 1:26pm in response to: Barry Smith

I found much humor in the comment. My 8th grade teacher once said that 7th graders should be in grade school, 9th graders should be in high school, and 8th graders should just be taken out and shot. (it was funnier back in the 70's, but you get his drift) He was a great teacher.

I think that teaching 8th graders has similarities to bringing new developers up to speed. They need to know everything eventually, what little they do know is incomplete, unpracticed, and sometimes downright dangerous, but it is a mistake to think that you can teach them everything all at once or in an order that fits your needs at the particular moment.

And much like 8th graders, new developers are very impressionable. They have more questions than answers. This is a positive thing but if not channeled properly will result in strange solutions that are destined to be the mistakes that the new developer will look back on later in life and shake his or her head. These are usually expensive mistakes and can and should be avoided though proper mentoring.

And anybody who thinks teaching is easy just because they know a subject is badly mistaken. Not only is it difficult, learning good teaching skills takes a lot of practice.

Wal Rus replied on Thu, 2012/07/19 - 1:46pm

 I find the NK statement so insulting!

Loren Kratzke replied on Thu, 2012/07/19 - 3:37pm in response to: Wal Rus

Perhaps if you are from North Korea. But you should be use to this if you are.

Wal Rus replied on Thu, 2012/07/19 - 8:22pm

Perhaps I don't need to get all worked up about this. It's like avoiding shit piles on a trail. The piles are just there and all you need to do is go around them. Have a nice day.

Gordon Milne replied on Thu, 2012/07/19 - 9:53pm in response to: Barry Smith

But he is ready to fork his own open source project, right?

Gordon Milne replied on Thu, 2012/07/19 - 10:09pm

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

It would be wonderful if I only saw this problem with Junior developers but I regularly see exactly the same thing from Intermediates and Seniors. I rarely see if from Leads or Principals.

It would appear that the tendency to solve the most general of problems (http://xkcd.com/974/) is endemic at the lower levels of our profession/craft. Unfortunately, it requires tireless vigilence to keep this sort of cruft from escaping into production. After all, what is wrong with it if it works?

How about it's not effing understandable to any normal human being looking at it?

John Ortiz replied on Thu, 2012/07/19 - 11:32pm

A senior developer or software architect can 'liberate' a beginner developer. The first ones has many responsabilities with team members, not only give orders or show the responsabilities inside the enterprise; they must 'drive' and teach "how to be..." .

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.