In at the deep end

In my first “real” job I was definitely thrown in at the deep end on my first day and it changed my career.

I left university in 1992 - yes I am that old. The job market was really bad, although probably not quite as bad as it is now, and I managed to get a job as a programmer for a company developing hardware and software for public libraries all over Europe.

I turned up on my first day and was shown my PC and a terminal for running the software. In those days the software was written on a PC and then blown onto a prom pack - a piece of hardware that was slid into the back of the terminal to run the software on it.

My boss introduced me to everyone and then told me to “play” with the software so I could get an idea of what it did. Fairly quickly I found a bug in the software. I went to my boss to tell him and with one simple instruction he had a huge impact on my career.

Instead of asking me to demonstrate the bug to someone so they could fix it he told me to go away and fix it myself - on my first day.

This meant I had to go and speak to the other developers, which took me out of my comfort zone as I was quite introverted. I had to learn very quickly how the code was organised, how to build it, how to burn it to a prom pack and run it on the terminal.

There was no real debugger so it involved lots of print statements to the screen when running - and it took a long time to go through the build release test cycle.

From memory, it took me a couple of weeks to fix the bug, which would have later taken me minutes.

However that didn’t matter.

It taught me how to navigate an unknown code base, it taught me to ask others, it taught me to really understand code (you had to due to the cycle time) and how to debug code with basically no debugger.

I learnt all these things because I was thrown in at the deep end and I have used all these skills throughout my career. Whenever I have to track down a bug I build a model in my head of what is happening, something I had to do all those years ago when debugging was much more manual.

So now when I recruit a new developer I get them to “play” with the application and if they don’t find any problems, I give them a small task with minimal help with the aim that they can get something into production before the end of their first week.

They learn the codebase, they learn to speak to others, they learn how to build, run, debug and deploy the software. Very quickly they are up to speed and see the results of their actions.

Sometimes it is good to be thrown in at the deep end and you never know what impact it will have.