Merce

Training processes

  • How far can it go?

    The Indian Army, with its traditions and processes stretching back about 150 years, prides itself in being able to recruit raw boys from rural India and train them to become fighting machines who will handle sophisticated weapons and follow orders without hesitation under enemy fire. This achievement is, by corporate standards, nothing short of fantastic.

    The Indian software industry has similar claims. They regularly issue offers of employment to thousands of engineering students in the fifth and sixth semesters of their undergraduate programmes, without much filtering or evaluation. Then they pick up these students after they finish their bachelor's degrees and put them through a training programme which, it is claimed, can turn any starry-eyed young recruit into a lean, mean, programming machine.

    We find such claims entertaining.

    We have one of the best training programmes in the Indian software industry. Yet, we have realised that training only scratches the surface of the individual. The raw material of a twenty-one-year old is already fairly well-formed. If the individual does not have the mental orientation and aptitude to translate a problem into a logical flow of programmable actions, training will not make him get it. We cannot do what the Indian Army can, partly because we do not train in an environment even remotely like a young soldier's immersive environment and years of training.

  • Our approach

    We abandoned classroom training in Dec 2000, after we put a batch of young engineers through a rigorous full-time classroom training programme and came out croppers. Since then, we have changed our approach radically. We believe that the student learns; the teacher does not teach.

    Assisted learning Our entire training programme is not a training programme at all. It is an assisted learning programme. We put the recruit in the driver's seat and give him a realistic assignment on Day 1. This gives her a clear objective to aim for. We then arrange brief lectures to cover the skeleton of the goal he needs to work towards. We never cover things like language syntax in our lectures -- we believe that such things must be self-taught, supplemented with experiments and toy programs in a real development environment.

    Hands-on We provide the new engineer a development environment which matches what our experienced developers use in live projects. We also give the engineer lectures or tutorials to teach her what to do with that environment, which standards and procedures to follow. We then allow her as much time as may be needed to let her find her way around with her assignment. We clearly communicate that we expect her to take much more time than an experienced programmer, and we expect her to make stupid mistakes.

    Mentors The key communication the new engineer receives starts once she begins work on her assignments. The new engineer checks in her code every day into a version control system, and experienced mentors are assigned the task of checking out the code and reviewing it. These mentors have a few years of experience in customer projects and are chosen from among our best software engineers. Their reviews begin to guide the new engineer's work practically on a daily basis for the few weeks of the assignment. When the new engineer gets stuck, the mentors pitch in with actual code fragments if needed. Laxity in basic standards and processes is ruthlessly criticised -- badly indented code is thrown back immediately.

    Friends We try to group new engineers into small groups, and give them parts of a common software application to build in their assignments. We encourage them to talk to each other and ensure that their code fits into each other's code correctly. We encourage them to help each other. In real life, no programmer works in splendid isolation to create masterpieces -- they work in teams. We inculcate this mindset from the beginning.

    No trainers A trained and experienced trainer may be very skilled in some areas of training, course preparation, lecture delivery, designing evaluation exercises, etc. However, we do not believe that using full-time trainers is a good idea for something as hands-on as software. Software is, at a junior level, a craft. We believe the skills of any craft are best learned through apprenticeship, working in a group with other senior craftsmen, where both junior and senior are placed in front of a common goal -- the final deliverable. This helps the seniors by reminding them of their apprenticeship days, and helps the juniors by displaying to them that their seniors are "just like them". Programmers need to work in teams, and need to feel comfortable letting colleagues see the problems in the code they write. This is best imbibed through a mentoring environment, not a teacher-student approach.

  • Learning, down the years

    Learning is required all through a technical professional's career. In our work environment, learning often stops after a few years if care is not taken. We try to ensure this does not happen with our team.

    We keep track of the profile of each officer as he grows from assignment to assignment. Every six months or so, we take an internal review of all officers we find promising, and explore new assignments for them. We deliberately pull them out of assignments where they were performing satisfactorily, and persuade them to shift gears to some different project team which may be doing something quite different. We explain why this will add value to him. In some rare cases, the engineer declines, and we disturb him no further. In other cases, we put him on the new course.

    After the reassignment, we start doing brief, frequent review meetings with him, almost like chats around the water cooler, to gauge how he is faring. We try to allocate a suitable mentor for him in the new assignment, and we guide him in handling the technical obstacles he faces. We note how he handles the challenges, e.g. the need to read, the need to handle clients, the difficulties in solving technical problems on his own, etc. In many cases, over a few months, we succeed in adding a new chapter to his technical growth and we get a more mature team member for new challenges.

  • What we have learned

    A wizard programmer may appear to be extremely valuable at first, but he is not half as valuable as an excellent programmer who can groom and guide juniors. This is an attitude and personality issue -- some seniors have this humility and commitment and others do not.

    No amount of assignments and training can make a mediocre programmer as good as a really good one. This craft calls for a passion, something which a clerical and cautious officer will never be able to imitate.

    Personal attention beats process-driven "training" hands down, every time. The most unlikely officers have blossomed under personal attention. This is completely non-scalable, however.

    Our assisted learning programme can let us evaluate young recruits more effectively than almost any other mechanism. Within the first three months of a young engineer's first live assignment, we can get a pretty detailed picture of how effective he will be even a couple of years later. No classroom test or interview can beat this for effectiveness. This is one of the main reasons why we like our approach.

RELATED READING

  • Case studies

    Work we have done for other customers in various engagement models