Learn the philosophy.

Karate Kid, a.k.a. Daniel, is a young college student who learns Karate from books. When they meet for the first time, Miyagi is delighted to see the kid’s determination to train on his own. Yet, the first thing he asks, much to Daniel’s surprise, is “Learning from the book?”

The problem with learning from the book at the beginning of your career is… you see, books can show you a few tricks, with pictures, or code examples, but it is really hard to grasp the philosophy of why that code works and why you should write it that way, from those limited explanations. Maybe you have a question, or you have a prior experience that needs to be tackled before you can learn or perform that trick. Books are not interactive, they are not tailored to your needs, but training should be.

Unfortunately, school education offers little help in terms of individual care. The software industry is geared towards treating engineer labor as a commodity, expecting faster and faster delivery times. This makes it extremely hard for new graduates (apprentices) to find a good master and even harder for the masters to spare time to train apprentices. In fact, it is so hard that it is almost a luxury. This drives people to teach themselves and as a result, years of experience gathered and distilled in this industry cannot be transferred correctly or in whole to the younger generation. Every apprentice is forced to discover the fallacies and intricacies of the craft on their own.

This is a huge problem that tech companies struggle with. In the end, every apprentice spend a lot more time, in vain, than a master would spend to teach them. I don’t have the exact numbers to back this claim but from my own experience at Startup Kitchen, I can say that it is a lot more efficient to teach apprentices and get them to produce real output than leaving them on their own to figure out the job. It looks like a waste of time in the beginning but it will have saved you a lot by the end of your journey.

The 80-20 rule is also prominent in software. Masters spend 20% of their time developing the crucial concepts for the 80% of the application; and then continue to spend the remaining 80% of their time to finish up the tedious details (this is also why we are terrible at estimation.)

Now the master can teach an apprentice or two in a percentage of that period, and let them finish up those tedious, finer details. The project costs will come down eventually, you will have taught people coding, and finally, keep your sanity by avoiding the tedious work. Next time, you will have better apprentices and the total cost will be lower.

Collaboration is important, but don’t underestimate the value of teaching in a collaborative environment. Oftentimes, pair coding sessions put together two developers from similar experience levels and as a result, very little teaching (and increase in total experience) occurs. This is done in order to avoid various conflicts between a senior and a junior developer. But taking a step back, and looking at the problem from a different perspective produces the optimum results: instead of expecting only an outcome in terms of work done, you should also expect the senior to teach the junior. Again, the final outcome could be lower in terms of completed tasks, but this is a good investment for your future.