The Mr. Miyagi School of Software Engineering

This is a re-post from a journal entry I originally wrote over on Slashdot in 2004.  I've made some minor changes and updates for this entry.

Background:  This was an concept born out of necessity about 5 years ago.  I needed a way to train someone with very little experience to work with Bridgeworks but I couldn't afford to spend hours and hours of my own time working with him; too many of my own responsibilities and deliverables.  It was very successful and now he is our best Bridgeworks app developer.  Fast-forward to today when I'm interviewing CS students from a local university for a summer internship.  This is a (well) paid position for which I need someone with decent coding skills who is a self-starter.  Unfortunately none of my candidates have any practical skills whatsoever.  (I don't know what the universities are teaching, but it's not what we need in industry.)  With these candidates it would be like starting from square one.  Obviously I'm not going to pay what I'm willing to pay for people who don't have the quals.  I am willing to train such a person as an unpaid intern, but that is not without its catches.  I still don't have the time to spend hours and hours with these folks.  Furthermore, ethically, unpaid internships are intended for the sole benefit of the student.  My company should not benefit in any way from the labor of unpaid interns.  Practically speaking, though, you can't train someone without giving them tasks.  Re-enter the Mr. Miyagi School of Software Engineering.

Lessons on how to train a junior programmer:

Let's call him Danielsan.

Mr. Miyagi was a very wise and clever sensei. His methodology, loosely translated, is perfect for any small software company that is bringing new developers into the system. The reason Mr. Miyagi's method works so well is because it provides intense, immersive exposure to the most important lessons while demanding relatively few additional resources from the instructor(s). Think about it. While Danielsan was busy painting the fence and sanding the deck, Mr. Miyagi was out having the time of his life!

The length of each lesson is to be determined on a case by case basis.

Lesson 1: Write SDK Documentation

Even the best developers can be notorious for not adequately commenting their code. Good documentation of an software includes both programmer's notes and comments for automated documentation (e.g., doxygen). This oft neglected task is perfect for Danielsan. An excellent way for him to learn the software from a developer's perspective is to write the documentation that explains how it all works.

Listen carefully when Danielsan asks questions about the existing code base. Discourage him from asking too many questions, except regarding complex concepts. It is important that Danielsan develop his own understanding of algorithms, relationships, dependencies, etc.

Lesson 2: Build Company Demos

Documenting the code shows Danielsan how the software developer sees things. Danielsan also needs to see the software from users' perspectives. "Users" include programmers who develop applications from the software and end users of the applications that are developed. Ideally, these would be two separate lessons. Knowing that time and money are always issues, these lessons can be condensed into one by having Danielsan build the company demos.

Architects and senior engineers loathe building company demos. While they are often happy to write test apps for in-house use, company demos bring with them a mountain of maintenance headaches and customer support issues. Whether or not your company is big enough to have it's own department(s) for maintenance and support, it's worth putting Danielsan to work on company demos so he can get his hands a little dirty and see first hand the challenges facing maintenance and support team(s).

Lesson 3: Clean House

Many companies have coding standards that must be followed by all code writers. These standards help everyone to write clean, consistent code that everyone can understand. Unless you work at a sterlized laboratory, it's a safe bet that your house always needs cleaning. A great way for Danielsan to learn this important lesson and also develop habits that are consistent with the team is to set him to work checking for adherence to company coding standards, leaks, potential security issues and the like. It's also a convenient way for you to get your code checked by a fresh pair of eyes.

The Successful Sensei

The successful sensei will know that these lessons are not opportunities for him to relax his own standards or to set Danielsan to work unguided. The successful sensei practices what he preaches. He knows which lessons Danielson must learn on his own and which require guidance. Naturally, Danielsan may occasionally bemoan his instruction. Perhaps he will consider that his training is too rote or mundane. Since you can't just throw a bunch of karate maneuvers in his face to show him what he's learned, it's important to sometimes let Danielsan work on things he finds interesting and fun. Ask him to write stand-alone utility apps that your company might need. Give Danielsan isolated new tasks within the SDK, perhaps something that requires he work with others to design interface requirements, resource requirements, etc.

to be cont'd.

Axiom 1: Tooltips are better left on.

If you leave your tooltips on, chances are better that you will learn something new each time you use your application(s). For Danielsan, tooltips are especially useful when they instruct him about fundamental principles of programming, those that transcend applications.


Axiom 1a: Some tooltips are better than others.