Apr 142014
 

I looked at the way that the corporate training happens in technology areas and I find them wanting in several respects. This is my attempt at a bringing some best practices to corporate or institutional training.

Most corporations have training programs, especially the ones that deal with IT technologies. The goal of these trainings is to train people so that they can be useful, productive members of a project.  This is meant for training competent engineers, craftsmen who can support delivery of projects.

A typical company gets two kinds of people to train:

  1. People fresh out of college: They went through latent learning, without clear goals. They learnt different subjects in college, without clear understanding of how that knowledge is meant to be used. They tried to understand concepts without real practice.
  2. People with a little experience: They worked on few projects, churning out code. Conditions in the industry is such that they were not exposed to quality code. Most of them do not understand the value of quality not do they understand what quality is.

Current training methodology: What is wrong with it?

Typically any corporate training follows a standard process: they get nominations on who to train. They hire or get instructors, who are experts in that area. They put all of them in a room, sometimes away from all the distractions. Over the course of a day or two, the instructors will take them through (with the aid of power point), the nuances and the details of the material. For example, if the training is on Java, the students will go though the static methods, public, and annotations etc. If the training is advanced, they might even cover some patterns of usage as a way of best practices. are

Typical evaluation of students are carried out through multiple choice questions which will test the users on the intricate details of the language. These questions cover a lot of trick questions to test the understanding of the language.

What are the problems with this approach? Let me count the ways:

  1. It doesn’t train the students for what they encounter in the job. It doesn’t make them a better developer or project manager or whatever.
  2. It only tests the book knowledge, which is almost one Google query away. It is that much cheaper to invest in a good quality internet connection.
  3. After a few days of training, they forget the knowledge. Of course, they can always look up a book when they need to – but that was the situation they were in, to start with, anyways.

Even if we train them using actual small projects, these problems will continue to exist.

New way of training: What we want to achieve

The education market in the US is being continually disrupted. I am going to list a few lessons from those disruptions and later describe how to apply those lessons to our training process.

image

Let us see each of these lessons in turn.

Inversion of classroom and home

Known as Flip-teaching, this method of teaching became popular because of Khan Academy. The problem with class room training is that the teachers are going at lecturing at the same pace for everybody. When the students need help with homework, they are on their own.

image

(Image via: http://www.washington.edu/teaching/teaching-resources/flipping-the-classroom/)

In the flipped learning, the instructor doesn’t teach via lecture. There are enough number of books and videos that can teach the subject. Instead, the instructor, in the classroom setting, works with the group to solve problems.

Practicing for muscle memory

Here is a quote from the book, Art & Fear:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot -albeit a perfect one – to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

If you want to learn JavaScript, write lot of code. Through writing the code, you keep improving. None of those “Learn X in 10 easy steps” can get you to this level of deep learning.

Hacking community realizes this aspect of learning well. Look at the following approach to learning by coding a lot: LxTHW (Learn X the hard way). The approach started with a popular book on Python, called Learn Python the Hard Way. If you follow that book, you don’t endlessly learn syntax and nuances of the language. Instead, you will code, and you will code a lot. It starts out this way:

  1. Do not cut and paste. Type the code as is.
  2. Make the code run.
  3. Now, modify the code to solve slightly different problems. And, make that code run.
  4. Keep repeating till you internalize all the concepts through practice.

In fact, this kind of learning through practice is applied by several people successfully. An example that I found very impressive was the case of Jennifer Dewalt. On April 1st, 2013, she started on a project to develop 180 websites in 180 days – one each per day. All these websites are simple enough to be coded in a day. With practice she got better and better; you can see the progress of her websites for yourself.

Even more experienced programmers like the inventor of JQuery, John Resig, feels that writing code everyday helps him keep his skils. Here is the famous blog post that he wrote: http://ejohn.org/blog/write-code-every-day/

In summary, our courses should not be teaching tricks and nuances of languages, libraries, or tools; they should be teaching the people practicing the craft.

Attention to basics

The big obstacle is coding or practicing the craft is not having the right basics. Even when two people are practicing equally, the one with the better basic tools will win.

image

Unfortunately, most colleges do not teach the tools of the trade. They focus, rightly on the fundamentals. Yet, there is no part of the education that covers the good use of tools and ways of working.

If practicing is the way to teach, the students need to have the right infrastructure to practice. In fact, practicing on that kind of infrastructure teaches them on how to use such infrastructure. These days, the basic infrastructure should be:

  1. Making use of the cloud
  2. Making use of the right OS, editors, and IDE
  3. Making use of the right tools for version control, bug tracking, requirements etc

Even for small projects, it is best to have at least a cloud based setup to try the code, a version control to keep the code history, and the right editor to train your muscles to use the right key strokes.

Quality through osmosis

We can get people to practice on the right infrastructure and churn out finished goods fast. But, will the output reach world-class quality?

While we made the argument that quality comes from quantity (through long practice), a more important ingredient is having right role models. That is where right mentorship can help. This is where intervention by a teacher that give feedback on quality of the output can help.

There are multiple ways we can bring this to practice – say if you are learning programming in JavaScript:

image

Especially, in the third step, and to lesser extent other two steps, good mentors can help. They can point out what the best practices are, idioms are, and why some practice is good.

Assessment through real-life tests

The current crop of testing, because of automation, is focused on multiple choice questions. Unfortunately, it only focuses on the nuances of the programming language or system. The world is far more complex; there is no single correct answer. Even if your problems were to come in the form of these questions, you could always find out answers from the internet.

In contrast, in real life, you will have to produce code or an artifact. Why not prepare you for that, during training? Here is an approach that works:

  1. Pick a large enough problem that we encounter during our work. Lot of these problems require “programming in the large”.
  2. Abstract it sufficiently so that it can be solved in limited time. For instance, you can choose only one module (say, adding new users to the system).
  3. Write a full fledged system that solves that sub-problem.
  4. If multiple people choose different parts of the system, then, we can have a fully functioning system at some point.

Training process

If you were to subscribe to this approach of corporate training, how would you start? Here is the approach I suggest.

  1. Start with a clear statement of what you want the students to be able to do.
    This part is surprisingly difficult. For instance, do not say “I want my students to learn Java”. That does not give them a new capability. Instead say “I want them to solve the following kinds of problems”. Now, these problems can be your way of assessing their status after the training.
  2. Create a pre-conditions for the material: Not just only for assessment, but as a way of setting expectations, you could ask the participants to do some tasks. For instance, if they are going to be doing JavaScript programming, they should know how to use Firefox or Chrome extensions. You could test for that.
  3. Create a curated content of the material: Since there is so much of material online, create an annotated list of material. For instance, you could give a link to the articles, books, slideshare entries or Youtube videos, with some notes about what the expectations from that videos are. You could construct them as a series of lessons.
  4. For each lesson, create a set of problems they should solve: In fact, more problems they practice, the better it is. If there is an entity like LxTHW, we could just follow that. If not, create a set of problems for them to solve so that the lessons really sink in.
  5. Create a basic infrastructure with tools: Even before they start solving problems, provide them an infrastructure such that:
    1. They can use the tools to develop the solutions
    2. They can use the infrastructure to collaborate with others
    3. They can use it to show the mentors
    4. They can test their solutions
  6. Provide the mentors: This part is tough. Just as we mentioned earlier, at the minimum, show them (embed in the curated content), what you consider as good quality to achieve.
  7. Create a post-training evaluation: Crate a large enough problem for the people to choose a part of the problem to solve. Using the mentors see
    1. how fast they are developing the solution (it indicates how they internalized the solution – practice makes for speed).
    2. how good a solution they are developing (it indicates how well they learnt from the masters)
  8. Create a community so that they can interact with each other post training: A training is not complete unless it is followed up. Since resources are difficult to get, use the power of community. Create a social space where people can discuss what they learnt even after they graduated from the course.

Concluding Remarks

image

I am no fan of corporate training; but I realize that not all people are self-motivated to learn and learn well. I think corporate training can be reformed to take advantage of the modern best practices such as incorporating internet material, using repetitive training, and intentional techniques in training, especially for acquiring technical capabilities. This note is an attempt towards that direction.

 Posted by at 1:12 pm

  One Response to “Intentional training: Learning with a purpose”

  1. Seriously Good

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)