S12E04: Fatigue

A lot’s happening all at once. On the 20th I need a draft literature review ready as a dry-run for my thesis. At this point, my advisor will tell me if there’s enough in my project, or if I’ll need to pivot to something else. The musical I’m helping with is getting stronger all the time. The characters we’ve been focussing on are leaping off the page, their desires and their priorities now so clear that the story spins itself. At work, I’m digging into authentication and authorisation, and rolled out the metaphor I used last week. It seemed to work. And other little corporate things are picking up too.

But I’m still getting over a lingering illness, and so is my partner; and so it means sleepness nights and fuzziness of the brain and being awake at 2am, cuddled under a blanket with a cat, and thinking about the great wide sky.

There’s a lot of technical stuff this week, and no clear thread. Just a feeling of pressure and impending deadlines.

Work’s getting hectic. We’re getting in some folks on short-term contracts, and so much of the work this week has been emotional and mental. The mental is about chunking up pieces of work so that they’re small enough to do quickly and still offer value to our users. That in turn means thinking about how well the work is documented, what permissions are needed, etc etc. The emotional part is coming to the understanding that I won’t be doing the work I’m planning. I don’t love that feeling. Part of me knows that it’s not efficient, for a specific value of efficient. That is: of my week, I’ll put 20% of my effort into preparing this piece of work. And then someone else will come on and put 100% of their effort into it, and as a result it’ll be complete in 2 weeks, having cost – let’s say – 6 days of staff time.

But I could have done it in three. It’s taken twice as long to deliver this piece of functionality. That’s the individual, selfish, ‘rational’ view.

The management view is: if there are five pieces of work, it will take me three weeks. If I spend a week prepping five pieces of work, they can be done in parallel by four other developers. And then five pieces of work only take two weeks. It costs five people, rather than one, but that’s a price we can accept paying for things happening a week early.

(There is a Marxist argument about alienation from labour here, and there is a process argument that information is lost at every handover. I’m not going to consider those for now.)

I’m still trying to get myself into that management headspace. We’ll see.


In fun little corporate project, I had cause to look at the code I wrote for the mentoring project way back in, goodness, season 8. And it’s still good! And it only took a few minutes to identify the lines I needed to change, which I think means I designed it pretty well. In fact, even better than that: I’ve been able to change it so that it used an environment variable. That means we could deploy exactly the same logic and code to a totally different customer with slightly different configurations, and keep their data completely separate. This is in line with the 12-factor app: a way of building software that’s loosely coupled to the underlying infrastructure.

Turns out if you do actually practice what you preach and build the thing right it’s easier to come along later and change it.


I’m still trying to get the scope of my thesis right. At the moment I’m concerned it’s gone a little bit too narrow. I think if I can get 1,000 words of literature review out of it in the next week I’ll be happy, but if it comes up short perhaps it’ll be time to expand the scope. I can’t post any of the review here because it’ll be flagged a plagiarism, and then I’ll be hauled up in front of the academic board to explain why I’ve been copying text from a blog about hyperactive commas. Still, I think I can get away with sharing a draft title:

Can automated SBOM generation and centralisation reduce mean time to resolve (MTTR) in the UK Public Sector?

Me, obviously

I think that’s everything. I’m going to go and have brunch now and try not to think technical thoughts.

Leave a comment