My jour­ney from mar­tial arts trainer to soft­ware developer train­ing expert

When I star­ted with my cur­rent pro­gram­ming lan­guage – over 13 years ago – I had already been a soft­ware developer for over a quarter of a cen­tury. How­ever, this was a new lan­guage, dif­fer­ent from the 3GLs I knew and loved. I was for­tu­nate to have 3 excel­lent, kind, and patient tutors to help guide me. And it is with their example that I nowadays pass on the same know­ledge to oth­ers. So here is my per­sonal story of teaching.

From the beginning …

My first role as a teacher came in my early 20s – that ́s over 30 years ago. That was my first time as a senior instructor in my Kung Fu asso­ci­ation. I was by then already well known to most of the par­ents and pupils in the classes as I had been train­ing reg­u­larly for the pre­vi­ous 4 years. Every­one knew and trus­ted me as they knew and trus­ted our „Sen­sei“ (side note: „Sen­sei” and “Sifu” both mean Mas­ter. Our “Sen­sei“ pre­ferred „Sen­sei“ over „Sifu“ due to the nature of the mixed, non-tra­di­tional style he cre­ated, these days it would be called a mixed mar­tial art, but back then any­thing that was not Kar­ate was Kung Fu).

From mar­tial arts to soft­ware development

What does that have to do with teach­ing soft­ware devel­op­ment? Well, the most import­ant part of any teaching/learning is the people and the inter­ac­tion. I have found that the spon­taneity of an inter­act­ive les­son, whether mar­tial arts or soft­ware design is so import­ant because every­one under­stands the same thing slightly dif­fer­ently, and believe me there is noth­ing more spon­tan­eous than a mar­tial arts class. So mar­tial arts and soft­ware devel­op­ment (or any other learn­ing for that mat­ter) are about the same thing: people. This is where our inter­act­ive train­ing ses­sions really make a dif­fer­ence. With that being said, let ́s move on to the soft­ware arena rather than the „Kumite“ (spar­ring).

For the pro­gram­ming lan­guage of my choice, the soft­ware vendor provides train­ing videos and web-based les­sons that give a great intro­duc­tion to pro­gram­ming, but they’re not the same as actual pro­ject work. In my opin­ion, some­thing is miss­ing. Some­thing like an inter­me­di­ate step where you apply what was learned in the­ory before enga­ging with pay­ing cli­ents “out there.”

How we do things

If you have the feel­ing some­thing is miss­ing, maybe you should cre­ate it? This is what we did at Data Insights. We have developed a series of tasks that require the developer to con­sider a set of real­istic require­ments, to bridge the gap between the the­or­et­ical and the more prac­tical training.

Those tasks give a set of “real world” require­ments along with our Data Insights cod­ing stand­ards. The developers are free to develop the res­ults as they see fit and then sub­mit them back for review by experts who will make sure that all designs were fol­lowed accord­ingly. There is no “you didn’t do it my way” mind­set here; we just look at effi­ciency in codes over mul­tiple ways people might think about solv­ing an issue (which can lead us toward new dis­cov­er­ies!)
And who knows? Maybe someone learned some­thing from work­ing on these projects?

A deeper look into the tasks …

We are going to have a lot of work with data cleans­ing. There­fore the first step, as always in this pro­cess is fig­ur­ing out what kind of bad data we’re deal­ing with and how it can be fixed or filtered off depend­ing on the type that’s incom­ing from our cli­ent side (a bunch will never make sense). All errors per record need report­ing back so there aren’t any sur­prises when they hap­pen dur­ing pro­cessing time – which could cost us dearly if someone else has done their job wrong!

The second devel­op­ment task, builds on the first, by mak­ing use of the cleansed data set. This time the data is to be used to gen­er­ate sev­eral reports show­ing the res­ults of a two-week sale period com­pared to the two weeks before. This task requires the developer to be able to fil­ter and sep­ar­ate a large data set effi­ciently as well as get prac­tice with read­ing and under­stand­ing require­ments documentation.

By chal­len­ging our developers to use other pack­ages within the suite of soft­ware avail­able, we give them a real sense of own­er­ship and understanding.

Hand-in-hand

This is an inter­act­ive ses­sion where you can ask ques­tions and get answers from our know­ledge­able team. We want to make sure that every­one learns as much about data insights, so even if a ques­tion can­not be answered imme­di­ately we will find some­body in the com­pany who knows the answer!

We start the inter­act­ive ses­sions after our basic train­ing course is over. This way, developers have some exper­i­ence with the soft­ware rather than everything being new and strange – they can ask ques­tions while see­ing how it’s done in real-time! It’s easier to ask ques­tions as the code is being writ­ten, which is often lack­ing in purely tech­nical lec­tures or demonstrations.

The inter­act­ive ses­sions are an import­ant addi­tion to the over­all train­ing and they provide a deeper under­stand­ing. They help to develop a feel­ing as to why a cer­tain struc­ture is bet­ter than another, or why a part of the cod­ing stand­ard is the way it is.

In the end

As an add-on to the web-based train­ing of the soft­ware vendor, the addi­tional devel­op­ment tasks and the inter­act­ive ses­sions provide the best start­ing point for our col­leagues when they arrive at a cli­ent project.

To return to the begin­ning: Teach­ing is all about inter­ac­tion. Devel­op­ing the pas­sion, fun, and enthu­si­asm for
some­thing new (mar­tial arts or soft­ware). And it’s also about trust, which makes it a delight­ful exper­i­ence for me personally.