The Boy Wonder’s Induction

Teaching graduates how to do proper problem-solving and research

Just over a year ago, on 10th October 2011 RopeWeaver Business Systems hired its first employee. David (later to earn the nickname “The Boy Wonder”) was 23, and green. Green like most graduates starting their first post-university job; most of the Visual Basic he’d done was VBA behind Microsoft Excel, and at university he’d never been offered the opportunity of a proper semester or two learning .Net. The modicum of .Net he knew was self-taught.

I’ve had my fair share of jobs over the years, so if there’s one thing I know it’s that it’s soul destroying to start a new job and find your first few days void of structure and purpose. Your manager is up against it with his own endeavours, and simply has no time to run you through a few examples of projects, to induct you properly. So you peruse some documentation you’ve found in the IT drive share, you explore the company intranet, and you wait. Each day at work is a dreadful, mind-numbing slog, not from overwork, but from lack of work. The hours drag, and it is awful.

In charge of my own company I vowed I was not going to make this mistake. In advance, firmly lodged in a recess in my mind, I had formulated an induction process for David, I came up with a series of mini ASP.Net test projects for him to complete, each in turn layering up tiers of .Net development skills. He wouldn’t be overwhelmed, he would always be allowed to declare “I’m stuck, please show me how to do this”.

I would begin by explaining to him how to code something, for example a simple Gridview populated with data from a suitably non-overwhelming database table, and the grid would have some row edit, save and delete functionality. I would do this in a pair programming style, essentially sat next to him, telling him exactly what to type for the HTML, the JavaScript, the VB.Net, the SQL, detailing how I wanted classes built, variables named, procedures structured, and comments written. After the example was complete, I would task him with creating something similar by himself, a little more complicated, say creating the functionality to also add a new record to the database table from the Gridview, and then let him loose as I returned to my normal RopeWeaver duties. I’d give him a nominal amount of time to complete the task, maybe 45 minutes, I didn’t explicitly enforce a time limit, and he’d tap me on the shoulder when he was done and then he’d present the working system. I’d then peruse his code and point out any bad habits he should eliminate, and best practices he should introduce. After a few days, with half a dozen of these test projects under his belt, David had a good working knowledge of the sort of ASP.Net coding work I was to expect of him, and he had the confidence to embark on further test projects concentrating on the more troublesome client JavaScript, rather than the relatively easy VB.Net server side code.

Often he would (and still does) ask me questions that I couldn’t answer. I didn’t just delegate the knowledge discovery task to him, nor did I say “I’ll find out and get back to you”. Instead I learned with him, shuffling my chair alongside and once more telling him what I wanted him to type, this time in Google, and we researched it together (“Let’s go see”). At the very least he was able to see and participate in my methods of investigation and problem-solving (everyone has a subtly different Google-Fu, after all).

Once we’d formulated a solution to the problem not only had we both learned something new, but I could see that the whole process had been tremendously satisfying for both of us. In working together to overcome a challenge, feeling involved and empowered, Dave was getting to be a part of the business. And above everything else, making people part of the business is what an induction is all about.