Recently I’ve been catching up on a long held ambition to get my private pilot’s licence.

There’s a lot that’s interesting about flight training and I recommend it if you have the urge (on which subject, a shout out to Cambridge Aero Club who’ve been excellent).

As you might expect, the course goes over some basics of problem solving, risk management, planning and human factors - all things that we (well, I) deal with at work.

I’ve found this rather useful.

Primarily, the pilot training material condenses quite a lot of useful human performance work, useful, I hope, to those who work with or in high performance situations.

But there is also quite a bit of material on risk management and teamwork which puts into words some thoughts I’d been having for a while.

and the conservative, plan-ahead mindset has really helped me to think about my planning in a way that allows projects to run more smoothly.

It’s also been helpful to think again about software engineering from an educational point of view.

A friend of mine used to be fond of saying that software was the act of learning about the problem; the software’s just a side effect.

I have a lot of time for that view, but it implies that learning and teaching are just as much a part of software engineering as practice - aviation texts have the advantage (for me) of describing this in a high-pressure context where limited time, cognitive capacity and limited information make it important to concentrate on the essentials.

That’s a situation I think is pretty common in high performing software teams whose members are often working at the limits of their cognitive capacity and where communication bandwidth is frequently a limiting factor.

I’ll throw in a couple of references here:

• the Human Performance and Limitations section of the Pooleys] manual has quite a lot of good information about fatigue and how to amaintain performance, on how to work in a team effectively, and about how to deal with threats and errors.

• The FAA’s Aviation instructor’s handbook has some good observations on 1-1 interactions and teaching that I’ve found very valuable.

Some particular things I’ve found useful:

• Managing stressful situations - in particular, how to problem solve and remain calm under pressure, and emphasising the old maxim of either removing the cause of stress, or removing yourself from it.

• Identifying and coping with cognitive overload.

• Checklists are a useful way to consistently perform tasks you can’t afford to scale. Checklists let you perform complex deployments (“ship this to AWS, this to GCP, and then take the privkeys from that and send them to the vault”) and test complex, hard to script predicates (“check that the application performs as expected”) without incurring huge automation costs.

• Threat and Error management is a nicely simplified form of risk assessment which lets you (me?) rapidly spot the worst risks without writing endless reams of hard-to-interpret spreadsheets that too often end up as wish fulfilment.

• Bias and how to avoid it.

• Knowing something about the ways people sometimes find to deflect or deny errors helps me (I hope!) to spot when I’m doing this and address the cause of the error rather than wishing it away and making another.

• The emphasis on planning gives me a much more developed feel for the scope of achievement; somehow I’ve got much more used to only planning what I think I can achieve and that discipline helps to bring projects in on time and on spec, rather than letting overambition turn them into a heroics-ridden barely-functional tangle. Beating out of me the temptation to add “just one more feature” has definitely made me (and I hope my teams!) happier.

Last but not least, I think as software engineers - and definitely as students and supervisors - it’s valuable to have some grounding in sleep management, fatigue and alertness - “I’M SAFE” (or “I AM SAFE” if you want the CAA’s version is a pretty good check not just for flying, but for any complex high-performance task; it recalls another quote from the same colleague - “if you’re too tired to be effective, stay at home and drink your own coffee”.

Anyway, after all those human factors, the next post will be technical, I promise!