On the 12th of November 2003 I joined the Royal Air Force and it’s safe to say I had no idea what lay in store for me. I left my home in North Wales and headed south to undertake recruit basic training at RAF Halton in Buckinghamshire. Nine years later I left the air force, headed for university to study for a career in software development. Today I’m a lead software developer here at Scott Logic and a lot of things are very different as I’m sure you can imagine, but not everything, there are still a few things I learnt early on in life which are as valuable today in my current role as they ever were.
From fast jets to JetBrains
As you may already be aware, when joining the military in the U.K. the first challenge to overcome is basic training, or as the Americans call it, boot camp. When I joined this was a nine week intensive training course incorporating everything from classroom work to fitness to field craft. A lot of the skills I learnt were explicitly taught, such as how to strip and clean a rifle or how to iron a shirt. I very much viewed it at the time as simply a challenge to get through and in many ways it was. The goal was to learn the drills as best you could, keep your head down and make it through to the coveted pass out parade or graduation. Until that point there was no guarantee you were going to be allowed to progress through into the real RAF. There was however another, more subtle layer of training happening at the same time, a layer I wasn’t really aware of until much later upon reflection. The explicit training in weapons, field craft etc, perhaps unsurprisingly hasn’t been particularly useful to me during my career as a software developer. I have, thankfully, never found myself needing to clear a path through a minefield or secure a parameter whilst working in software. There are however a whole range of other skills I learnt in those early days of my first career which I still use almost every day.
Be prepared
Early each morning (and I do mean early!) whilst at basic training we would have a room inspection. The corporal in charge would come into our 8 man room, we would be expected to be stood to attention, in clean, neatly pressed uniform next to a bed made to exacting standards and a wardrobe full of neatly pressed clothes. The corporals would be relentless in hunting out the smallest imperfection and upon finding any defect would bawl out the individual responsible, the whole room and in some cases throw the offending items out the window, bedding included. As I’ve said, at the time this seemed to be just another hoop to jump through and another challenge designed to encourage you to give up and quit, and partially it was. What we learned fairly quickly however was that there simply wasn’t enough time in the morning to get everything ready for inspection, not unless you were willing to sacrifice what little sleep you were getting already and wake up your room mates in the process. The solution was to spend time each evening ironing your kit and polishing your shoes, some even went as far as to make their bed the night before and spend the night on the floor in order to get a head start in the morning. What we had learnt then, without an explicit lesson was two-fold. First was the importance of being prepared, of not being caught out without enough time to complete the task. Secondly was the importance of problem solving issues under your own initiative. No-one was going to tell us how to get it right, we would simply accumulate more and more punishment as a room until we fixed the problem for ourselves. It’s clear to see then how these things are useful in the software world. As both a developer and a leader it’s important to be prepared, to give yourself the time you need to successfully complete tasks, either in terms of setting expectations or else taking the time to prepare things the day before so that you aren’t caught out. It’s also hugely important to be able to problem solve solutions under your own initiative both individually and as a team, the ability to craft workable solutions to problems as they arise and adapt them to scenarios as needed is a major part of successful teamwork and software development.
Be early
On one of our first days at Halton we were told to be at a given location for one o’clock (or thirteen-hundred hours). We all turned up, as commanded, on time only to be given a push-up punishment for being late! We were then informed that if we are on time, then we are late and from then on we would be expected to be at a location at least five minutes before the given time. Again, at the time, this seemed to be just one more arbitrary rule, designed to catch us out. It is however, a rule I still follow and a practice which has served me well in all aspects of my life, from catching a train to job interviews. In software it’s equally good advice, how many meetings have you sat in, waiting for people to arrive while you could have been getting on with other things? How many hours are wasted each week? There’s other considerations here, being late, regardless of what excuse you have, looks unprofessional, especially to clients and those outside your team and being just in time is, at best, a risky strategy. How often have you gone to join a call only to discover some problem connecting or issues with your hardware which holds you up for five minutes. Outside of that, we all need some amount of time to context switch, if you join a call and thirty seconds ago you were trying to solve some issue with your code, chances are that for the first five minutes of the call, that’s all you’re really thinking about. A five minute buffer gives you chance to focus on the new task, to resolve any unexpected issues and to still be on time and not hold up the rest of your team.
Attention to detail
Going back to those early morning inspections. As I’ve said, the inspection wasn’t just a cursory look over, you were expected to be able to pass a thorough, detailed inspection at 0600 in the morning. Why? Well, because what the instructors were trying to instil in us was excellence as a default or standard and highlight the importance of attention to detail. The inspecting corporal would don the stereotypical white glove and run it over the top of all the surfaces looking for dust, they would comb over each item of uniform looking for unironed or badly ironed patches which ultimately evolved into a competition between us and the instructors (more on that later). The point is that attention to detail breeds excellence, there’s a saying in the british military: “button today, safety-catch tomorrow”. It’s used when someone has forgotten to fasten a button on their shirt or bag and the basic meaning is that if you don’t keep on top of the little things today you might miss something bigger (such as forgetting to apply the safety-catch on your rifle) tomorrow. In software that attention is just as important, we all know the fallacy of thought that suggests writing tests or peer review is a waste of development time and slows things down. In reality it is far more costly to cut corners and move too fast as it sacrifices attention to detail. Getting something out the door fast is no use if it’s full of bugs or even worse, doesn’t work at all. Doing it right upfront and paying attention to the details as a standard is the fastest way to deliver quality software. Baking excellence into everything you do, from unit testing to release, ensures that those little oversights don’t stack up or snowball into bigger issues later on.
Working as a team
I mentioned above that those morning inspections ultimately turned into a competition between those sharing a room and the corporal instructors inspecting us. It felt like a major victory if we got through an inspection without the corporal finding a single issue. As time went on and we improved our game, the instructors would find it harder and harder to find issues and there was almost a sigh of relief when they did at last discover some dusty surface or unpolished shoe. This was, of course, deliberate in hindsight as the us versus them competition brought us together as a room and as a team. We no longer worried about just ourselves and our own kit, but rather worked together to ensure every person in the room was up to the same standard, after all, we would all be punished as a team if any issues were found. This aspect of teamwork is hugely valuable outside of the military as well, most crucial is the lesson of “leave your ego at the door”. It may seem, on the face of it that a viable approach to working as a team could be for each person to sort their own area of responsibility. If we split the work equally and each person completes their part, then the work gets done and the team succeeds right? What we learnt from basic training is you’re not done until everyone is done. The problem with the above approach is that if you have an individual on your team who is struggling, they may not complete their portion of the work, in which case you all still fail the inspection as a room. Even if you all get your area of responsibility done in time. The lights can’t go off until everyone is done preparing their space, therefore, should you finish earlier than others, it’s in your own interests to go help out anyone else who is still working (after all, what else are you going to do?). Teams work faster and more effectively when individuals help each other out. The task is given to the team, not the individual and as such no individual should consider themselves “done” until the whole task is completed. This is as true in software as anywhere else, consider for example a typical sprint in a Scrum-like setting. If most of the devs finish what they were working on but there are still tickets in development at the end of a sprint, the sprint wasn’t completed. The team has still failed to complete the work it set out to do, regardless of how quick individuals might have been to close off tickets. Unless people work together to help out other developers and to help out the test effort, they will never be going as fast and efficiently as they could be. There’s another saying in the military, “Don’t be Jack”. Jack is a hypothetical character who looks after only himself. When making a cup of tea he makes one for himself without asking his mates. When he’s done with a job, he puts his feet up and watches everyone else work. Being Jack is about the worse thing you can be in the RAF, don’t be Jack!
No plan survives first contact
I’m sure you’ve heard the old slogan of “improvise, adapt and overcome”. It’s a common saying in the military, referring to the need to problem solve on the fly. Back in basic training (and in most military exercises), there was often an unexpected element thrown into the training. This could be in the form of an ambush, roadblock, minefield or other wildcard placed to make a straightforward scenario a bit more interesting and more importantly to test the team’s response to such challenges. In a military context, the word “contact” refers to engaging or being engaged by an enemy. The saying “No plan survives first contact” then basically means that the plan will most likely go straight out the window as soon as someone starts shooting at you. Even if that’s not true and being shot at was part of the plan (which it sometimes is), it will almost certainly have to change and adapt to a fluid situation. If all this sounds vaguely familiar then it may be that you have read something like it before. In the manifesto for agile software development one of the core values is:
Responding to change over following a plan.
I’d never heard of agile development when I was in the military of course, but the overall concept is the same. Having a plan is important, we need to have a plan regardless of if we’re building a defensive parameter or building a web application. It’s more important however to acknowledge that the plan is just that, a plan, it’s an idea of how we’ll proceed given our best guess at what the future holds. When things change (and they will), we need to be willing and able to change the plan or even ditch it entirely and make a new one or else we risk stubbornly following a plan which no longer matches up with reality.
Final thoughts
So that’s it then, over two decades and two careers later it turns out I’m still practising some of those basic lessons I learned as a teenager, lessons which at the time, I didn’t even realise I was learning for the most part. Basic training is designed to encourage you to give up, it’s intentionally hard to discourage, not only those who don’t really have the enthusiasm or perseverance for it in the first place, but also those who refuse to work as a team. The underlying truth is that it’s almost impossible to get through basic training on your own, the only way through is to work together with those around you as a team. Developing software isn’t an intentional test in the same way and there are a world of differences between the two things, but there is also a common truth which is this:
When it gets hard, you can make things a whole lot easier by being prepared, paying attention to the details, working as a team with those around you and being flexible in your approach by improvising solutions and adapting to change in order to overcome obstacles.
