resize images

_posts/2024-11-12-lessions_from_the_RAF.md → _posts/2024-11-12-lessons_from_the_RAF.md

@@ -1,6 +1,6 @@
 ---
 title: What I learnt about software development from the RAF
-date: 2024-11-04 00:00:00 Z
+date: 2024-11-12 00:00:00 Z
 categories:
 - People
 summary: Twenty one years ago today I left home and joined the Royal Air Force. Today I'm a lead software developer at Scott Logic and my career is very different, but I often reflect on my time in the military and the parallels between it and software development. To mark the event I thought I'd share a few thoughts on the subject.
@@ -17,7 +17,7 @@ As you may already be aware, when joining the military in the U.K. the first cha
 
 ## 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 a 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.
+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.
 
 <img src="{{site.baseurl}}/dogle/assets/jets_2_jetbrains/FMJ.jpg" alt="Gunnery Sergeant Hartman" title="Not exactly the same, but not exactly different either" style="display: block; margin: 1rem auto;" />
 
@@ -35,13 +35,13 @@ Going back to those early morning inspections. As I've said, the inspection wasn
 
 ## Always work 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 overlooked issue. This was, of course, deliberate in hindsight. The us vs them competition brought us together as a room and as a team. We no longer worried about just ourselves and our own kit but 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 crucially 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 is 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. 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 in your room (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!
+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 overlooked issue. This was, of course, deliberate in hindsight. The us vs them competition brought us together as a room and as a team. We no longer worried about just ourselves and our own kit but 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 crucially 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 is 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. 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 in your room (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!
 
 <img src="{{site.baseurl}}/dogle/assets/jets_2_jetbrains/bfa.jpg" alt="an ambulance in Kandahar" title="Me stood next to the battle-field ambulance I drove in Kandahar" style="display: block; margin: 1rem auto;" />
 
 ## No plan survives first contact
 
-I'm sure you've heard the old adage of "Adapt, improvise 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 teams 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, it will almost certainly have to change and adapt to a fluid situation. If all this sounds vaguely familiar then it maybe that you have read something like it before. In the [agile manifesto](https://agilemanifesto.org/) one of the core values is:
+I'm sure you've heard the old adage of "Adapt, improvise 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, 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 [agile manifesto](https://agilemanifesto.org/) one of the core values is:
 
 > Responding to change over following a plan.