Tag: respect

What’s your website’s D&D alignment?

This is the impression – often the first impression – that users of the website get of the organisation.

Cookies and Dungeons and Dragons – a hypothesis

Recent privacy legislation has led organisations to have to adopt ways of allowing their users to register their cookie preference in ways which expose the underlying motivations of the org. I have a related theory, and it goes like this: these different registration options allow you to map organisations to one of the 9 Dungeons and Dragons character alignments.

This may seem like a bit of a leap, but stick with me. First, here’s a a little bit of background for those readers who’ve never dabbled in (or got addicted to -there’s little room between the two extremes) the world of Dungeons and Dragons (or “D&D”). There are two axes used to describe a character: Lawful-Neutral-Chaotic and Good-Neutral-Evil. Each character has a position across each of these axes, so you could have someone who’s Lawful-Good, one who’s Chaotic Neutral or one who’s Neutral-Good, for instance (a “Neutral-Neutral” character is described as “True Neutral”). A Lawful character follows the law – or a strong moral code, whereas a Chaotic one just can’t be bothered. A Neutral character tends to do so when it suits them. The Good-Neutral-Evil axis should be pretty clear.

Second bit of background: I never just accept cookies on a website. I always go through the preferences registration options, and almost always remove permissions for all cookie tracking beyond the “minimum required for functionality”. I know I’m in a tiny minority in this, but I like to pretend that I can safeguard at least some of my private data, so I do it anyway (and so should you). I’ve noticed, over the past few months, that there are a variety of ways that cookie choices are presented to you, and I reckon that we can map several of these to these D&D alignments, giving us a chance to get a glimpse into the underlying motivation of the organisation whose website we’re visiting.

I’ve attempted to map the basic approaches I’ve seen into this table.

Lawful GoodNeutral GoodChaotic Good
Functional cookies only by default.No cookies, and a link to a long and confusing explanation about how the organisation doesn’t believe in them.No cookies at all, no explanation.
Lawful NeutralTrue Neutral Chaotic Neutral
Functional and tracking cookies by default, clear what tracking cookies are; all easy to turn off.Functional and tracking cookies by default, completely unclear what the cookies do.Random selection of cookies, and it’s unclear what they do, but you can at least turn them off.
Lawful EvilNeutral EvilChaotic Evil
All cookies by default: functional, tracking and legitimate uses.  Easy to remove with “reject all” or “object all”.All cookies by default.  “Legitimate uses” need to be deselected individually.All cookies by default, with 100s listed.  You have to deselect them by hand (there’s no “reject all” or “object all”), and there’s a 2 to 5 minute process to complete the registration, which finishes on 100% but never completes.
D&D alignments and website cookie preference approaches

Clearly, this is a tongue-in-cheek post, but there’s an important point here, I think: even if this glimpse isn’t a true representation of the organisation, it’s the impression – often the first impression – that users of the website get. My view of an organisation is formed partly through my interaction with its website, and while design, layout and content are all important, of course, the view that is presented about how much (if at all) the organisation cares about my experience, my data and my privacy should be something that organisations really care about. If they don’t respect me, then why should I respect them?

If I’m trying to attract someone to work for me, partner with me or buy from me, then my marketing department should be aware of the impression that visitors to my website glean from all interactions. At the moment, this seems to be missing, and while it’s not difficult to address, it seems to have escaped the notice of most organisations up to this point.

Acting (and coding) your age

With seniority comes perks, but it also comes with responsibilities.

I dropped a post on LinkedIn a few days ago:

I’m now 50 years old and writing the most complex code in my career (for Enarx) in a language (Rust) that I only started learning 9 months ago and I’ve just finished the first draft of a book (for Wiley). Not sure what’s going on (and I wouldn’t have believed you if you’d told me this 25 years ago). #codingtips #writing #security #confidentialcomputing #rustlang

I’ve never received such attention. Lots of comments, lots of “likes” and other reactions, lots of people wanting to connect. It was supposed to be a throw-away comment, and I certainly had no intention either to boast or elicit sympathy: I am genuinely surprised by all of the facts mentioned – including my age, given that I feel that I’m somewhere between 23 and 31 (both primes, of course).

I remember in my mid- to late-twenties thinking “this business stuff is pretty simple: why don’t the oldies move aside and let talented youngsters[1] take over, or at least provide them some inspired advice?” Even at the time I realised that this was a little naive, and that there is something to be said for breadth of experience and decades of acquired knowledge, but I’m pretty certain that this set of questions has been asked by pretty much every generation since Ogg looked at the failings in his elders’ flint spear-head knapping technique and later got into a huff when his mum wouldn’t let him lead the mammoth hunt that afternoon.

Why expertise matters

Sadly (for young people), there really are benefits associated with praxis (actually doing things), even if you’ve absorbed all of the theory (and you haven’t, which is one of the things you learn with age). Of course, there’s also the Dunning-Kruger effect, which is a cognitive bias (Trust you? I can’t trust myself.) which leads the inexperienced to overestimate their own ability and experts to underestimate theirs.

Given this, there are some interesting and bizarre myths around about software/coding being a “young man’s game”. Leaving aside the glaring gender bias in that statement[2], this is rather odd. I know some extremely talented over-40 and over-50 software engineers, and I’m sure that you can think of quite a few if you try. There are probably a few factors at play here:

  • the lionisation of the “start-ups in the garage” young (mainly white) coders turning their company into “unicorn” trope;
  • the (over-)association of programming with mathematical ability, where a certain set of mathematicians are considered to have done their best work in their twenties;
  • the relative scarcity of roles (particularly in organisations which aren’t tech-specific) of “individual contributor” career tracks with roles where it’s possible to rise in seniority (and pay) without managing other people;
  • a possible tendency (which I’m positing without much evidence) for a sizeable proportion of senior software folks to take a broader view of the discipline and to move into architectural roles which are required by the industry but are difficult to perform without a good grounding in engineering basics.

In my case, I moved away from writing software maybe 15 years ago, and honestly never thought I’d do any serious coding again, only to discover a gap in the project I’m working on (Enarx) which nobody else had the time to fill, but which I felt merited some attention. That, and a continuous desire to learn new things, which had led me to starting to learn Rust, brought me to some serious programming, which I’ve really enjoyed.

We need old coders: people who have been around the block a few times, have made the mistakes and learned from them. People who can look at competing technologies and make reasoned decisions about which is the best fit for a project, rather than just choosing the newest and “coolest”[3].

Why old people should step aside

Having got all of the above out of my system, I’m now going to put forward an extremely important counter-argument. First, some context. I volunteer for the East of England Ambulance Service Trust as a Community First Responder, a role where I attend patients in (possible) emergency situations and work with ambulance staff, paramedics, etc.. I’ve become very interested in some of the theory around patient safety, which it turns out is currently being strongly influenced by lessons learned over the past few decades from transport safety, particularly aviation safety[5].

I need to do more study around this topic, as there are some really interesting lessons that can be applied to our sector (in fact, some are already be learned from our sector, particularly in how DevOps/WebOps respond to incidents), but there are two points that have really hit home for me this week, and which are relevant to the point at hand. They are specifically discussed with relation to high-intensity, stressful situations, but I think there’s broader applicability.

1. With experience comes expectation

While experience is enormously useful – bringing insights and knowledge that others may not have, or will find difficult to synthesise – it can also lead you down paths which are incorrect. If you’ve seen the same thing 99 times, you’re likely to assume that the 100th will be the same: bringing in other voices, including less experienced ones, allows other views to be considered, giving a better chance that the correct conclusion will be met. You increase diversity of opinion and allow alternatives to be brought into the mix. The less experience team members may be wrong, but from time to time, you’ll be wrong, and everyone will benefit from this. By allowing other people a voice, you’re also setting an example that speaking up and offering alternative views is not only acceptable, but valued. You and the team get to learn from each other, whether it’s when you’re wrong, or when you’re right, but you get to discuss with others how you came to your conclusions, and welcome their probing and questions around how you got there.

2. Sometimes you need to step aside to apply yourself elsewhere

Perhaps equally important is that sometimes, tempting as it may be to get your hands dirty and apply your expertise to a particular problem (particularly one which is possibly trivial to you), there are times when it’s best to step aside and let someone less experienced than you do it. Not only because they need the experience themselves, but also because your skills may be better applied at a systems level or dealing with other problems in other contexts (such as funding or resource management). The example sometimes given in healthcare is when a senior clinician arrives on scene at an incident: rather than their taking over the treatment of patients (however skilled the senior clinician may be), their role is to see the larger situation, to prioritise patients for treatment, assess risks to staff on scene, manage transport and the rest. Sometimes they may need to knuckle down and apply their clinical skills directly (much as senior techies may end up coding to meet a demo deadline, for instance), but most of the time, they are best deployed in stepping aside.

Conclusion

With seniority comes perks: getting to do the interesting stuff, taking decisions, having junior folks make the tea and bring the doughnuts in[6]. But it also comes with responsibilities: helping other people learn, seeing the bigger picture, giving less experienced team members the chance to make mistakes, removing barriers imposed by organisational hierarchy and getting the first round in at the pub[7]. Look back at what you were thinking about the beginning of your career, and give your successors (because they will be your successors) the chances that you were so keen for back then. Show them respect, and you (and your organisation) will benefit.

1 – I think that the “like me” is pretty implicit here, yes?

2 – which, sadly, reflects another bias in the market.

3 – there’s an important point here: many of us older folks love new shiny things just as much as the youngsters, and are aware of the problems of the old approaches and languages – but we’re also aware that there are risks and pain points associated with the new, which need to be taken into account[4].

4 – that really made me sound old, didn’t it?

5 – in large part influenced by the work of Martin Bromiley, a civil aviation pilot whose wife Elaine died in a “routine” operation in 2005 and who has worked (and is working) to help the health care sector transition to a no-blame, “just” culture around patient safety.

6 – this is a joke: if you have ever, ever find yourself in an office or team where this is the norm, and hierarchy shows in this sort of way, either get out or change that culture just as soon as you can. It’s toxic.

7 – I’m writing this in the middle of the UK’s second Covid-19 lockdown, and can barely remember what a “pub” or a “round” even is.