Tilting at windmills

The other day I was accused of having a quixotic attitude to issues of workplace culture. Aside from having never been accused of being an idealist in my life, this has irritated me enough to stick with me, so I'm going to write something about it.

First of all, in British English, "quixotic" means:

"preoccupied with an unrealistically optimistic or chivalrous approach to life; impractically idealistic"

This is by the Collins dictionary definition.

For me, the emotional component of the word comes from its origins in the novel Don Quixote where it refers to the protagonist. Depending on your reading, he's on a noble quest to bring back the better ideals of times gone by, or he's hopelessly deluded. Either way, he repeatedly fails to achieve anything - usually while being mocked (and beaten) by those around him.

So it is in this context that I can't say I was thrilled by the comment. I've written many times about my overriding feeling that I'm not really achieving anything in an attempt to show myself that it's not actually true. To have this combined with the suggestion that the reason I do what I do is deluded definitely hurt.

Passed through my emotional filter, the rough translation of all the above is "what you talk about is insane, you don't know what you're doing and you're failing at it".

We were talking about toxic culture in the tech industry and whether it can be "fixed". My position is that, even if all we're doing is only creating bright spots in an otherwise toxic swamp, things can change. Since I'm now in a position of senior leadership in this industry it's partially up to me to do something where I can.

Example the first: I know many technologists who invest heavily of themselves in their work and work excessively long hours. Often this behaviour is encouraged, despite the cost to the individual and these people are treated as disposable by the organisations they have enriched when they do reach the point of burnout. Economically sound, but not right.

Example the second: I have a friend who is looking for a new job. She's a talented developer who should have her choice of places to work, but because she doesn't want to work in a toxic bro-culture she's struggling to find places to even apply.

This is the reality of the tech industry and I reject the idea that we can't do better. Idealistic? Yes, of course. But if I think it's utterly impractical to change the culture around me then I need to get out of this industry. More than that, the whole thing needs burning down and the earth salting to prevent re-growth.

The other part of my summary is that I don't know what I'm doing and I'm failing. This is something I take very personally as, for better or worse, I always try to have a clear plan. I know what I'm doing and why, and I feel working without a plan is failing. In my time in technical leadership I've had ideas, created strategies and seen positive change on the back of it. Of course, I don't know everything but I am very aware of that - I'm not deluded. I have good people to talk to, and I'm adding to that list all the time. What I do have - and this is more important than any of my own input - is enough influence to enable and empower others and create an environment for real cultural change. It is only in my area, of course, but people in my area have a habit of going elsewhere and taking our culture with them...

Now, the title of this post is a deliberate nod towards my writing a whole post aimed at an offhand comment I'm quite sure was not intended as I've written here. In American English, the Cambridge dictionary definition of "quixotic" is:

"having intentions or ideas that are admirable but not practical"

While this is not where my brain goes, for various reasons I suspect this (and without the additional layers of meaning drawn from linking the word back to the novel) was more the intended definition and to be honest I mostly agree. If my goal is to "fix" the technology industry then I'm clearly going to fail - it is not a practical goal.

However. To roughly paraphrase something I remember from a film (or TV show?) "striving for the impossible does not mean toiling in vain". The point (aside from my amazing citation ability) being that pushing for unreachable goals is not ridiculous as it brings you closer to where you want to be, even if you never reach it - asymptotic behaviour for those of a mathematical persuasion.

While failing to source that, I found this relevant quote from Mikhail Bakunin:

"By striving to do the impossible, man has always achieved what is possible. Those who have cautiously done no more than they believed possible have never taken a single step forward."

I'm not sure what it means that I'm now quoting a revolutionary anarchist.

The Newsroom uses the story of Don Quixote as a major theme for the show. It links it to the Greater Fool theory.

"The greater fool is actually an economic term. It’s a patsy. For the rest of us to profit, we need a greater fool - someone who will buy long and sell short. Most people spend their life trying not to be the greater fool; we toss him the hot potato, we dive for his seat when the music stops. The greater fool is someone with the perfect blend of self-delusion and ego to think that he can succeed where others have failed. This whole country [America] was made by greater fools."

Sloan Sabbith, The Newsroom

Do I think I know better than those who came before me? No. But I do know I can make a difference and I intend to do so. It's why I do what I do and I have the original commenter to thank for getting under my skin enough to analyse my thinking and reaffirm that important point. That is mostly why I write this blog.

We should always be seeking to improve, whether it is through evolution or revolution. We should always be seeking to build that rose-tinted version of the world that could exist (quote paraphrased from some wonderful folk at work). Personally, I hate the idea of stagnation. I need to be moving towards a better future - and by that I mean actually improving things and not simply maintaining or (in many ways worse) just fighting a rearguard action. Anything less does feel like failure.

Oh my goodness. Have I become an idealist?!

Why am I feeling bad?

This is a reflection on where I feel I am right now. It's helpful to me to write this down.

A while ago I wrote about being proactive in work. I looked at the balance between reacting to what is going on around me and taking the time to look ahead. At the moment I'm not getting that balance right.

I really hate not having the time to think around problems and last week I had to cancel some 1-1s to reduce my own cognitive load. I've written before about making time for people and this is a big deal (in a bad way) for me.

So I feel like I'm failing right now. The question is - what can I do about it?

First of all, I should put "right now" into context for myself. The nature of my job has changed. I've taken on a new role, with a whole world of new things to learn. Now I need to be clever and insightful in conversations that feel like they've been happening for months when I have maybe a week's worth of context. To catch up, I'm basically constantly cramming for the next big test. There is a constant feeling of my brain being an over-saturated sponge and I'm looking at half a bucket of water left to absorb. It's overwhelming at times, despite my colleagues being very supportive.

This is a particularly busy time. There is a lot to do, and a lot of decisions to be made and it all needs addressing immediately. Both of these will definitely pass.

Secondly, I need to recognise what I'm doing right. As I cram information and react to the current situations, I'm putting in place the building blocks for the future. I'm taking the opportunity to restructure the software engineering community so it will be in a better place as we go forwards. I'm pushing some of my colleagues outside of their comfort zone, and I'm already seeing them really growing which is good for them as individuals and us as a department. We are using the current challenges as an opportunity to bring some important work to the fore and ask the right questions to take us in the right direction.

I may be thinking on the back foot, but that doesn't mean this is short-term thinking. I'm still managing to work in support of my longer-term goals and, while I'm not necessarily delivering in exactly the way I want to, I should recognise that I'm keeping myself more or less on track despite the new pressures.

As I write this down, I realise that I'm juggling an awful lot at the moment and not dropping too many balls. Overall, I should stop kicking myself.

Buying code

TL;DR - I found this old post about outsourcing and found reading it again interesting.

EDIT - for reasons I choose not to speculate on, the original post has been archived and must be seen via the Wayback machine.

The magic bullet that is outsourcing rears its head every so often. Why worry about organisational capability and capacity when you can commoditize the process? Push some money at the problem and it goes away, right?

Well, no. Not even close. There are many problems fundamental with this way of thinking and for me they boil down to two key things:

1. Code is never finished
2. Effective and sustainable outsourcing is really hard

I'm going to write a separate post about the first point. Probably more than one - every time I sit down to write something it grows by a frightening amount. The short version is that written code is the start of the journey, not the end. It's why we have entire frameworks (such as ITIL) to manage the services created. You may have paid someone to create the software - but then what?

I was going to write a series of thoughts to cover the second point. But then I discovered something fun - I've been writing on the internet long enough to be repeating myself. So here is me, nearly six years ago, writing about the pitfalls of outsourcing on my old work blog. It's worth a click - if only so they see a weird spike in traffic on an older post.

I find the thoughts there interesting for a few reasons. Firstly, the world hasn't really changed. At all. The fact that I'm writing this post is due to this approach still being seen as an easy solution, and still having some very dangerous long-term effects. The only point in there I think has improved is that Agile working with a supplier is a bit easier these days - although that might be a reflection of the difference in agencies operating in London and Bath.

Secondly, I find it interesting that I felt strongly enough back then to write a post about it. I was a developer, writing code and helping shape a university department. I saw problems with outsourcing, raised them, and when things happened anyway (and, despite the glib phrasing, I should make it clear that my concerns were addressed in the context of the department's priorities) I was one of the people who was saddled with the fixing and learning to make everything work.

These days I'm the Head of Software Engineering for GDS (for the moment at least) and I get to inflict that fun on other people. Or, more accurately, I get significant input into the operating model for the department - which means I need to make sure we're taking into account the points past-me made and ensure we're effectively taking them into account when considering how we build things. Because otherwise, I'm inflicting that fun on other people.

It's dangerous to go alone

I've played Dungeons & Dragons, alongside other roleplaying games, for most of my life. In the last few years I've been telling people that the skills learned from playing (and especially running) this game are incredibly useful in the office. And people think I'm mad.

Time to explain.

Firstly, for those who don't know, a roleplaying game is a co-operative game focussed around collaborative storytelling. There are hundreds of different rulesets and different ways of playing those games but essentially the Games Master (GM) tells a story. Everyone else takes the role of a single character (the player character, PC) and describes what that character is doing, and how they are responding the challenges of the world. Imagine telling someone the story Lord of the Rings, but instead of passively listening the audience has control of the behaviour of Aragon, Gimli and Legolas (or, if you don't want to imagine it you can read this happening at DM of the Rings). The GM provides context in the setting and the reactions of other characters. The rules define what the characters can do and gives a framework for testing for success.

There are some obvious skills which are gained by playing. Most of the systems involve some basic maths that needs to be done quickly on the fly, which helps with arithmetic. There are social skills from playing in a group, and needing to work together. There is the creativity of thinking up the details of your character, including their motivations and history and some basic acting involved in their portrayal. In fact, Dungeons & Dragons (D&D) was used as a learning tool in schools before it was deemed Evil for reasons which are too tiresome to explain here.

However, I think there is a lot more to it than this.

Consider a job interview. A very common question is along the lines of "imagine you're working here - how would you respond to X happening?". I've had many conversations with people who find it very difficult to put themselves in a fictional situation, understand the limits of their choices in that scenario, and decide on their actions within that context. It's a pretty unnatural thing to do and something of a niche skill, but is definitely a barrier to getting many jobs. It's also exactly what you are doing almost all of the time in a roleplaying game. Pulling out your dice and declaring you're going to stab the manager probably wont help you in interview, but having the confidence to think clearly and quickly in that environment definitely will.

At the heart of many roleplaying games are the challenges. How do we cross this ravine? Can we get the gem from the sleeping dragon? The realm is being invaded, what can we do? These all boil down to "how do I solve problem X with resources Y?" My career has been in technical delivery and management and this has been the question posed by work every single day for over a decade. Like in the games, the answers have varied enormously, and often involve multiple steps to grow Y or redefine X. Practising these thought processes in a safe environment has been very beneficial to me.

Solving problems in D&D often involves communicating with other people (played by the GM) and that involves thinking about their needs and desires. And now we're practising empathy and understanding - in higher stake scenarios and closer to actual conflict than many of us will ever encounter in real life.

When one is the GM and running the game, all the above is dialled to 11. Instead of a single character to track, there are potentially dozens and you have to remember exactly who knows what and how those people might communicate. This starts to sound like the communication that happens in an office which is very important at times of change, or any time information needs to be passed around.

A large part of running the game involves describing the scenario and keeping the story moving. This involves a myriad of narrative and communication skills, learning when to focus on details and when to skip over for the sake of pace. What's important? What makes things come alive? Being able to tell a story is important at interview, and important for talking about your latest great idea in the office and convincing others of its greatness.

Taking a step back a little, being a good GM involves keeping the game itself moving forward. That means taking a group of people, listening to their thoughts and discussions, providing information where required but also helping them come to a set of decisions. All the while, you need one eye on the clock (unless you really like playing to the small hours and getting nothing done) and to keep monitoring the room to make sure that everyone is included. These are key skills required to run a successful meeting.

I can go on, and probably will at some point in the future. For instance, I haven't mentioned anything about teamwork (D&D is usually impossible if the players aren't working together). I look forward to the day when management training is a group of candidates running through the Tomb of Annihilation.

I think playing roleplaying games has the potential to teach some very positive skills. But if nothing else, it is a good excuse to own a lot of pretty dice.

HTTPS for a small site - redux

A few years ago I set up LetsEncrypt for my sites, so I could create certificates, do HTTPS and blah blah security. Anyway, it all worked well until, nearly three years later...

Balls

Still, an automated process that has been running unattended for three years suddenly stopping working has never caused a problem, right?

It turns out some things have changed with LetsEncrypt in the last three years. Like, everything. Everything. Even the name. Now the thing I want is called Certbot. Fortunately (and against the trend in modern days) it has improved with time. Now there are packages and guides! Sadly, migration is going to be worse than setting things up in the first place. It's installing new software then making sure it's renewing certs generated in the old way, in the old place.

Sigh, here we go.

So I followed the install section of this guide then ran:

sudo certbot renew

And it ... just worked?! I don't understand. This is not computing.

Ok, I need to fix the cron too. That'll cause problems.

Starting as:

export PATH=<boring path stuff> && /another/path/letsencrypt/letsencrypt-auto renew >> /path/to/logs/renew.log

Change to:

/usr/bin/certbot renew >> /path/to/logs/renew.log

And ... that appears to just work too?!

Amazing. It looks like some things do get better.

Giving nice feedback

For a work environment to be successful, there needs to be trust among the people working there. Scrum echoes this in the main rule of the retrospective - everyone did the best that they could with the resources they had available at the time. Blame culture is being stamped out by progressive companies. People want to be able to approach senior management without fear (and senior managers want to be seen as humans). Everyone should feel comfortable in their workplace at all times.

All of this is a really good thing, of course. But it seems to me we are also in danger losing something important when it comes to personal feedback. Individual development often involves confronting uncomfortable truths about ourselves before deciding what to do about them, and a part of doing that is knowing what to look at. I've had too many conversations recently with people complaining that they don't get critical feedback. They know they are doing a good job - they are getting plenty of positive feedback - but they know they aren't perfect and want to know what to look at to develop.

So are we being too nice? If we don't give critical feedback when asked, is it because we don't see a problem? We don't want to upset people? Or is it we want to spare ourselves an awkward conversation? Speaking for myself, I very deliberately lean into being supportive over critical (yay me) but if I'm honest I can also see some of the last in my behaviour. Since people have been asking for more feedback, I've tried to change my own behaviour and be more open and offer more (constructive) criticism.

Initial findings are good. Firstly, I've had very positive feedback from people who've been pleased to have something pointed out. I've seen pennies drop and cogs start turning in people's brains. It feels like I'm helping people think, which is the object of feedback regardless of the context. Secondly, it has helped my own development. The first time I gave some properly honest feedback I could feel my own fear and anxiety welling up. But the person wasn't upset or horrified and they still talk to me. Over time, having awkward conversations has gotten a lot easier - and this is a really important skill to develop when moving into management. I'm really grateful to this person for making me think a bit differently about all this and one day I might find the courage to tell her.

Clearly, honest feedback is something to be given sensitively. Although the above might read like it, I haven't been walking round giving the benefits of my "wisdom" to anyone unlucky enough to be within shouting distance. I'm still very careful about who I talk to and when, and it's only people who are asking for it and I trust to have a sensible conversation.

How feedback is delivered is also important. For me, the classic "shit sandwich" technique misses the point somewhat here. We are not talking about problems, we are talking about development opportunities. We are not looking backwards at everything that was "bad", we're acknowledging the past and looking forward at how things could be in the future.

It's also important to ground the conversation in a concrete reality. That means talking about the impact - some of which might not have been noticed at all. For instance, "you are very smart, but are naturally quite blunt" is feedback but invites a "so what?" response. "You are very smart, but are naturally quite blunt and this means people who work with you can find you intimidating" is rather more significant. It speaks to a real (unintended) problem and also leads to a useful discussion about communicating ideas, bringing people along, working with people from other disciplines, and so on. This is all good stuff and it also gives the person enough to kick-start some positive self-analysis.

Of course all this must come with the caveat that it's aimed at helping good people be better. It's important to work with each individual in a way that suits them.

What's the conclusion here? Giving feedback is important, and I think it's very easy to make it meaningless by avoiding the difficult conversation. This does a disservice to those around us. Being too nice doesn't help anyone grow.

Tagging documents in Google Drive

I use the Google suite for various types of writing, including D&D. Google Drive will let me organise files by folder, which is very early 1990s. What I'd like is some kind of tagging system, so I can find the docs I have scattered all over the place. While it seems like something Google should probably support, while we are waiting for a miracle I can roll my own system using Google Scripts which is apparently mostly ES3, with some enhancement from ES5. So that's ... late 1990s. I guess that's an improvement?

Anyway, language hell is ahead of me and I'm sure at some point I'll convert it to use a proper API in a proper language. Right now, I need a simple way to do tags. Since I don't use the description metadata field (or indeed really acknowledge its existence until I started this) I think I'll use that. Adding something like #npc #story to the field is the level of work I'm willing to do - what I want is something that will pull these tags and list my files using them.

First things first - how on earth do I start writing Google Scripts? Obviously as a lovingly maintained part of the Google suite it'll be tightly integrated so all I have to do is ... add what it claims is a plugin to Drive and I can start creating script files which open in an in-browser editor (I hate in-browser editors, but here we are). Then I need an index file and something to call it. It seems that when loading, the doGet method in the Code.gs file is called and that needs to hit the HTML file. This all needs accessing via a URL to the dev or published version. Ok:

Carefully not thinking about what will happen if a user isn't using Javascript, let us push forwards. Templating seems pretty simple so an HTML file can be put together. I can also drag in a CSS file from somewhere else so I can reuse my awesome styling.

All I'm looking to do here is create some lists, so I just need to get the filenames and links and put them on the screen. Specifically, I'm getting a list of tags then creating a list of files per tag.

Google Scripts provides a load of objects to poke and since it's taking care of the authentication (the main reason I'm doing it this way rather than using the api) this should be pretty straightforward. I mean the only way this could go wrong is if the scripting is using Javascript from before the dawn of time and I have to do absolutely everything myself?

Argh.
To be fair it's not too bad once I've got my head out of Ruby and back into Javascript and then removed all the ES6 goodness I've come to expect in the years since it became commonplace. I can actually craft exactly what I'm looking for:

Under the hood ... eugh. It's pretty ugly - and not just because I've used two different forms of a forEach loop in a single short script. To generate this page, I'm looking at each file to get a list of unique tags then reversing the process - looking at each file to figure out if it has the tag I'm interested in. This is not Efficient Code^TM. On the other hand, it is Working Code^TM so it'll do as a proof of concept. I'll make it less awful when it gets too slow or I translate it all over to the API.

In the meantime, I have a document tagging system, and I can still use my favourite online text editor, even if I had to write the code in my less than favourite online code editor. And here is the code all in one place. One day I'll get tagging and Markdown support from Google itself...