Schauderhaft

When I was about 14 I got a really interesting present from my uncle: A construction set for a ship. Not one of those plastic thingies that I often glued together in an hour at that time, but a wooden one, which meant I had to cut out every single piece with a saw, file it until all the edges had exactly the right shape and then glue it together. This way attaching a single piece easily became half an hour or an hour of very concentrated work. I did this together with my uncle who learned in his youth the profession of a cartwright and is a perfectionist, so he knew how to do this right and wasn’t willing to accept anything less.

I learned a lot of stuff during my work on that ship model, but I remember one lesson especially well: How to use file.

You might think using a file can’t be that hard, but trust me you still need quite some advice and practice to do it well.

If you just use it without such practice, you will file of some wood.

The surface will become smooth.

But it won’t become straight.

And you won’t get perpendicular, sharp edges.

You might be able to replace the advice with more practice and maybe some books. But the advice will make progress much faster (and also more frustrating in the beginning because you’ll hear over and over again: “No, you are doing it wrong”).

So my question is who is teaching how to use a file to junior software developers? “File” doesn’t stand in for things like the usage of design patterns or practices like Baby Steps. I’m talking about very basic things that many people consider easy:

• Always start work with a fresh and clean checkout from version control.
• What to do before checking in your code.
• What to write into a commit comment.
• How to write a bug report. 
• …

Most developers learn this kind of stuff at some point in their career, but we as an industry waste a lot of time be forcing them to learn that really slowly. Most teams I have seen do discuss difficult stuff, like design questions and how to use version control to best support the teams work flow. But often there is very little done for teaching the very junior developers.

Often they only get a quick introduction into a tool and then they are left alone with their task.  They work along, do some stuff and only hours or days later they might get some feedback. That feedback often is unspecific and not very helpful like: “Who wrote this stupid commit comment?”

Basically this is a workflow that looks like this:

give task to junior that he might master -> junior works on task -> time goes by -> if lucky junior gets feedback -> repeat with possible adjustment of task difficulty

This might be comfortable for the junior, because he doesn’t get criticized very often, but it slows down learning and this is something we just cannot afford in IT. It also leaves traces of the failures in the results.

I therefore propose to a different approach:

give the simplest task to the junior that you can think of  that he hasn’t proven yet to perform well -> watch him doing it -> stopping him whenever he does something you don’t want to end up in the end result -> explain what is wrong, why it is wrong and how to do it better -> let him try again.

The obvious way of doing this is pair programming, but pair programming for this purpose has some problems. When two developers of very different skill levels work together the senior developer easily ends up doing the work while the junior is watching her. Not helpful. This kind of stuff is about learning, not so much about producing results.

Also with pair programming you have one senior training one junior. While this is awesome for the junior, it is also very expensive. With a little practice on the side of the senior it should be possible to supervise easily six juniors, maybe more.

This again might sound like the typical workshop or tutorial and it is indeed similar. But a typical workshop often stays on the surface of things, because it tries to cover as much as possible. What I propose is an intense training that goes slowly, but strives for perfection.

What do you think? Does this make sense? Is it already happening somewhere?