It’s been an interesting couple of weeks, so I’ve gone back to form and bashed out some weeknotes for the last hour. The first two parts touch on some aspects of software engineering which might be of interest to senior developers, and people managing engineers. The third part describes what we’re up to around Coronavirus preparations and remote working, but is more about how to deal with information in a crisis.

Oh yeah, here’s my personal intro in case you’re interested.

Engineering is cartography

It’s been a code heavy week, down in the bowels of the codebase. Last week I’d expected half-expected to be managing the work for the team bringing together a new, complex release, but the team have stepped up and sorted this out. It’s actually been really nice to get my teeth into some proper engineering. Headphones on, Slack out the way, IDE in full force. There are moments when software engineering is that odd cross between the Matrix and an artist’s studio, and one can absorb oneself not in code, per se, but in a system. The joy is not the code, but in the flow of information that the code allows, how the assembled parts work together to make something elegantly smooth, and what I now think of as the ch’i of circuitry emerges into something stable, formed, useful.

Specifically (here comes the science bit) I’ve been adding a cache file to the code that runs every time a page is loaded, and have naturally hit two of the chief tenets of software engineering, namely:

1. Cache invalidation is always harder than you figured, and
2. Developers (yeah, yeah, including me) always expect things to be easy.

There were a couple of hitches – the first was a foreseeable one (wow, different sites use different folders, duh), while the other was less so (Linux folders are case sensitive, but Windows ones aren’t, riiiight). Still, both fairly minor, and when you have the problem space “loaded into your head”, a good developer should know where to hit it.

I think of this as “interjection points”. A good software engineer will, I believe, not give you a time estimate to fix something, but a time estimate to map a system out in order to understand it. If the estimate to fix it doesn’t fall naturally out of that, then the engineer needs more sketching experience, or your codebase is about to be unmaintainable realllllly soon. Pray it’s the former.

Agile development requires continual balancing

After the caching was committed and tested, I fixed up some other fundamental code which was breaking our unit tests. While the code structure itself was ok, our outdated phpunit version wasn’t happy with it, so it was a mix of a bad stack, dodgy unit testing, and slightly whiffy software engineering. Each, any and all of these three are quite hard to explain, it turns out. “Upgrading some software” is the easiest, but led to a big story-point estimate during sprint meeting, but I managed to set out a day to look into it, to see if we could get a quicker fix through Re-Engineering the code.

In the end, yes upgrading phpunit is the right thing to do, but this was the wrong moment. A ‘workable fudge’ was put in that half-hit all 3 of the requirements (code works; unit tests run; engineering is sane), with the caveat that it would be taken out with the upgrade, expected in a few months.

This has taught me a few things:

1. Acknowledging a bigger issue and having a timescale for fixing it allows you to have more authority when putting the problem off in the short term.
2. Sometimes you just have to ask for time, instead of trying to explain yourself. I’m pretty sure I said that recently too.
3. Software development is always a balance, and always has a context of delivery. This constant act of balance is fundamental to agile development on short timescales. FUNDAMENTAL.

Anyway, we’ve saved ourselves the huge upgrade for now, so it was a good morning’s work.

Reacting as management to a crisis

Those two coding tasks were basically my commit for the sprit, which freed me up a bit. I had (or have, still) varioius admin things to do. But Wednesday-leading-into-Thursday started the government and media ramping up on taking the Covid-19 pandemic more seriously, and it became clear that we needed to ramp up our own precautions and efforts to match. As a company, you need to follow the course of the news sometimes. Is it a “crisis”? I don’t know, but I do think that if people are worried, you should treat it as one, but you should desperately try not to panic yourself.

In general, we’re lucky to be a digital company (whereas others are not so – most of us can and do already work remotely, so we have a lot of infrastructure in place, and had cobbled together some general thoughts on remote working more some months ago.

However, the current scenario throws in a few extra challenges, namely:

• Information updates fast, in both the wider world and inside the team
• We may be ‘hyperdisrupted’, in that nobody may be allowed into the office at any time
• People are personally, individually more aware and anxious, for good reason

I’ve learned (sometimes the hard way) that a crisis needs clarity, not vagueness, and the best thing you can do to help people get a sense of psychological safety is to let people raise concerns, get clear actions in place, and be transparent. I’ve not done these in previous times, and it tends to end up pretty badly. Things might ‘survive’ in a holding pattern for a while, but it leads to a lack of trust, and ineffective collaboration, even before the illness actually hits.

(I do wonder if some mentalities prefer the vagueness of an ongoing crisis, the idea that there is a situation or an “enemy” to feel like there is a purpose, but that there is no real will or skill to turn that into something more progressive and real. Ah well, I enjoyed a day of contingency planning anyway.)

As per software engineering, I’ve been thinking through information flow and how the structures that get set up support and/or hinder that. My overall strategy has been along the lines of:

1. Gather concerns and blockers: Start a Slack channel. Ask initial questions about basic challenges, like working from home. Send out a survey using Google Forms. The key thing here is to start a pipeline for information, not to capture every single possible problem.

2. Capture everything clearly: Started a new Google Doc to cover guidance, decisions, questions, ongoing actions – half for me to keep track of things, but half as an instant information-publishing route. Put the important stuff to the top, and don’t be afraid to remove or move it once it’s no longer important – for instance, washing hands and getting anti-bacterial gel started off as the top priority, but now it’s a matter of course.

3. Work out how to make decisions quickly: This is not something we have an assigned role for. We adopted a ‘rule of 3’ among the (4) senior management team members, taken from Rick Falkvinge and the Pirate Party as an approach to avoid hierarchical bottlenecks.

4. Capture decisions relentlessly: People are away a lot, which is a real challenge if things are moving fast. I’ve taken to adding all decisions into the single Google Doc as appropriate as well as adding a comment to note which day the decision was made on, as well as including the decision in a separate “update log” at the bottom of the doc. Hopefully this way I can just point people at these if/when they want to catch up. And then use Slack and daily stand-ups to communicate important (team-wide decisions out. Otherwise, make sure relevant people are told individually.

5. Address actions quickly: Ultimately, trust in management comes down to whether concerns are listened to, risks are seen to be understood, and both are addressed proactively. (Unforeseen events are OK to be addressed reactively, but only if they were truly unforesee_able_. As a kicker, events are always more foreseeable a) if you’re not already responding to a dozen other things, and b) in hindsight. Tchah.)

So, that’s been fun. My main disappointment so far is not being able to think up a decent codename for the day for trialling everyone being remote, except for ‘TOTAL REMOTE’. I’m sure something will come along to best that though. I can feel hubris in my bones. Til next time.

Up-front meta

This note from Warren Ellis at LTD struck a chord:

The day after my birthday, I started keeping a written log of what I do every day. Even after only a week, it exposes that even on the days I don’t think I’ve done much, I do a lot. It’s just that slews of emails and AV and document processing and calls don’t feel like the actual work. I need to remind myself that, these days, it is in fact a big part of the actual work.

"I need to remind myself that, these days, it is in fact a big part of the actual work." – this sums up so much of what I tell myself, and have increasingly told myself as I’ve done less on direct deliverable, and more on support and leading. Still feels like a constant reminder, which also feels a bit daft. Remember when ‘housewife’ became ‘home-maker’ in the 80s and 90s, like we were struggling to square the ‘productivity’ of family life? Yeah, don’t feel we – as a nation – have figured that out yet, either.

ᛤ

Current weeknoting self-imposed workflow is now:

• Reading: I’ve started subscribing to particular people’s feeds via RSS, rather than drinking from the weeknot.es firehose, for two reasons – firstly, it just means I’m not feeling like I have a bunch of random notes to catch up with, and secondly the medium.com domain seems to open directly in the Medium app better. The reading experience feels a lot more … ‘focused’ this way, and I can always browse the weeknot.es site if I want more people to follow.

• Writing: Take notes in open-source app Diary – one line per note, tagged with #weeknotes. Rsync plaintext/Markdown files to laptop. Grep on ‘#weeknotes’ to separate notes from all my other daft ideas. Collect relevant notes together and re-edit into something more or less coherent. Email Markdown to WordPress, then tidy it up after publishing. This is getting closer to the balance between slapdash-chaos and sensible-output that I’d like.

ᛤ

Ambient music to write weeknotes to:

• alliceffekt: 19th month, from Saharaphorest to Duomo

• Tim Rowe: Immersive Recursive Vol 2

Not quite Spring

The Sun has been out slightly this week, which – after being cooped up in the house and the car for a few days, has put a bit of a fresh spring back in my step. My senses must have picked up because I took some photos without really thinking. Got bought a free coffee by a random stranger which I will also pay forward. Pick up some second hand books for my ‘computing history’ collection which is my new mid-life crisis retro collecting brain thing, alongside (the more obvious) retro-gaming kick.

Alongside this, I started out feeling quite productive this week, helped oddly by being leftover-ill and tired, and so working from home on Monday. I seemed to spend a lot of time writing up thoughts into shared documents, as a way of kickstarting discussions and providing a space to assemble thoughts.

Structure is Power

I’m drawn to ‘document structure’ more than I realise – as, I suspect, is everyone, especially in this modern era of shared and collaborative documents. The real power of thinking-on-paper (which shared documents are a form of) is the ability to move thoughts into 2-dimensional space – beyond the single, serial, linear dimension that internal thought, and simple textual writing offer. In other words, a surface (such as paper) allows us create a structure or map which, in turn, allows us to move in (duh) 2 directions instead of 1.

People say writing was a gamechanger 8,000 years ago as writing allowed transmission of thought. I think mapping – of any sort – is just as fundamental to collaboration, as it transmits the relationships between ideas. Not just “Hey! A then B then C”, but “Hey, A then B, but also C can relate to both!” This extension of thought into space means we can navigate between connected ideas more fluidly, but also explore the actual relationships being mapped more easily.

So I’ve probably said the words “structure” and “shared documents” about a brillion times this week. But the aim is to force, uh, encourage others to think along the same lines once they head off by themselves to think through and fill in the information. There is a momentum to this process – and once information starts going into the structure, and others follow suit, it does get harder to change tat momentum. So structure is a form of power, especially if you fill in ‘example’ information. Whoever creates the document defines the outcome.

Image: Advanced Google Sheets usage:

ᛤ

The flipside of settingout a structure is that one can focus on space instead of substance. I am making more concerted efforts to speak less, and am biting my tongue and resisting the urge to see a solution and jump in with it. I think there is something about time-bound conversations (like crammed meetings) that pushes people to THINK FAST and REACH A DECISION, but also to feel like they’re not wasting time on “frivolous” conversations – finding a solution quickly can be seen as more important than listening to diverse opinions and viewpoints, or even just being respectful. This is generally not so good.

But what’s the alternative? Lengthier meetings? Deliberate quiet/thinking time? Splitting meetings up into context/problem vs solutions and decisions?

Miscellanea

Using Zoom from home for a video call, I have a quick scramble on connection to a) change my on-screen name from “Scribe” to something more professional*, and b) hide the giant anteater soft toy lurking behind my head. The dangers of working from home that no-one warns you about…

( * For reference, I’ve used “scribe” as an online name since about 2000 or ‘ancient past’. It stuck with me at the time, and it seems right to mention this fact in the context of writing weeknotes all these years later. )

ᛤ

I finished my week by taking some time to whittle my “response”-labelled inbox down to 1, and the “all action” inbox down to 50 or so from 100+. Most of that was outdated or unnecessary. The inbox labeller in me is very much the optimist.

ᛤ

I am sorting out a better flow for reading things. There are some work- and data-related articles which I would like to highlight, but I think I might keep them separate to my actual weeknotes. I’m not on Twitter so much and links always feel lost there. Maybe I will try collating them into a separate post on the blog, like post a curation every 5 links or something.

Notes taken, synced, grepped and woven into a single file like a
patchwork quilt formed of half-formed thoughts. I’m getting odd scraps
of notions feeding into these weeknotes at the moment, probably from
being divided between deliverables, people stuff, bigger pictures,
half-term holiday and time off and time with kids. This post is an
attempt to cobble some coherence together? It’s a good time to write,
and even better time to hold off posting until a second read-through.

What’s happening, G?

Lots I can’t really post, or don’t want to. Lots of thinking going on,
navigation – sensing, processing, letting scenarios play out. Not great
practice for sleeping, especially when you get woken up at 4 or 5am.
Probably explains why I’ve been feeling grotty for at least a week.
That, and storms always seem to blow in grot these days. I should
probably do some private note-taking, but I’m reading some Chuang Tzu again which
is helping me out.

Scaling up: Show, don’t tell?

Lots of scaling and optimisation work going on this month. It’s a nice
problem to have and I’m secretly proud of nursing our tech to this
point. Optimisation is a double-edged sword, though – on the one hand, I
really enjoy it; it’s challenging, something to sink the teeth into and
inherently complex, as in there are no easy or direct answers. I like
complex – it takes coding and technical engineering to a much more …
organic level.

But on the other hand, it’s really hard to explain that complexity to
people that want results but aren’t involved, or that don’t understand
the complexities and interactions – even within the tech team. It makes
it hard to fit into sprints, to set out clear and tidy plans, to handle
multiple ongoing but parallel work. In my head, I’m pretty sure that a)
we’ll be ok, and b) the proof will be in delivering the work. Waaaaait a
minute. Agile principle number7, ‘Working software is the
primary measure of progress.’ Do I just need to remind people of that,
rather than spending hours trying to explain the intricacies of complex
sofware management which will be obsolete in 2 weeks?

I need to finish off some work to make our testing stats clearer, but
it’s time to get back on the case and push through some incremental
improvements to show off what the team have been working on.

Grumpy programmer

Some arcane infusion of the common cold, central heating, and the
lifting of the dark is making me a bit grumpy lately, I think. I’ve been
feeling disjointed, tetchy. Little frustrations have been getting to me
a bit more. The fresh sunlight has kicked me into getting back into
running 1-1s though. It’s important time to work through some of those
niggles and reactions – in both directions.

My notes reference a book I had when I was a kid. It had an article on
‘How to be a Chess Grandmaster’, which basically consisted of playing 8
games of chess at the same time, and winning half – by ferrying moves
between pairs of tables, effectively becoming a pure medium. I’m feeling
like that a lot of the time. The downside is you only win half the matches.

Probably time to lift the foot off the throttle a bit, let the world
play out for a little while.

The week ahead

I’m mostly on support duties for the tech team as they dig into various
ideas, with a few little tasks to keep my hand in alongside that. The
longer term other stuff will continue to need some attention and phone
calls, so need to make sure I’m properly prepped for these. Attention in
the right place and at the right time, goes a long way.

Meta note: Posting via email/markdown partially working now. Excuse the line breaks though.

HI BLOG. There, that feels good. Sooo, following on my first post, here are my initial "rules of engagement" for me and this blog. And this is a very personal set of rules. This blog is for Me, capital M. If that’s not working out, then it’s not A Right Thing.

Rules of blogging engagement

1. I can post via EMAIL, using MARKDOWN. (This is currently in very experimental stages. procmail is involved.) This may mean less GIFs, boooo.
2. I can post whenever I like. Sorry #weeknotes crew – Friday just doesn’t work for me 😉 Since October, I’ve moved to not working on Fridays – but, as it’s not quite the weekend, there’s a limbo zone between finishing ‘Head of Tech’ duties for the weekend, and actually relaxing.
3. Posts should pick up on things I am finding either a) interesting, or b) challenging. Probably both, but not always.
4. Writing must be fun.

That’s it for now.

RSS fan? I’m not sure if I’ll post these on Medium in the future, but the best source feed is probably this Atom feed on the original blog. Go easy, it’s hosted right next to my front door, under the phone and coats. Yes, I’ll post a picture soon.

Where am I at?

Context is everything, so here’s a bit of a recap. Oh yeah, I did a plain-text intro dint I?

1. I have gone 3 days a week since October, split over 4 days, with Fridays off. Did this mainly to cover school runs, and take the stress off my partner who has an appreciated, flexible job, but this also meant she was doing more share of the school dashes, which is no good. It also means I get a chance to do more house stuff, and more of my own personal side-lines, because these things are Important too.
2. Back in Sept/Oct, I set out a bunch of aims for the Tech side of things for the company. Broadly speaking, these lined up some work on … actually, maybe that’s a whole separate post?
3. I’m now looking back over the last 5 months to see how all this has worked out, as well as the ongoing day-to-day stuff.

What one thing should I mention here, to make it look like an Actual Weeknote?

Looking back over my hastily-diarised notes (this is also another post…), the main exciting thing which has happened is clearly:

• "Broke a door"
• "The door got fixed"

Needless to say, I’m a little concerned about our building. Not to mention the flies over winter.

In the background, I’m really trying to figure out where the best place to involve myself is, in a lot of work. If you have junior staff, then you know you need to direct and support them quite directly. If you have senior staff, then you know you can (should) hand over a lot of responsibility to them. And honestly, I don’t know if I’m struggling to give up some control as the tech team have got more capable over teh years, or if I do still have a much … keener? sense of risk and awareness of Things What Can Go Wrong.

I think it is always better to keep people advancing, which does tend towards keeping them out of their Comfort Zone ™, which has its own tensions – even if you agree the "right" levels of support up front, I think it’s easy to collectively miss things in hindsight. I don’t want to get into a position where my own ‘step back’ approach, confirmed with one team member, has unconfirmed knock-on effects for others. That’s a tricky conflict,and I hadn’t really appreciated that before. Thanks, weeknoting practice.

I also keep coming back to a phrase in the Tao Te Ching: "People are difficult to govern, because they are very clever." Hmmmmm, so true.

What else is in my notes?

Warren Ellis on notebook processing: "It’s always worth running tests on the way you work."

Which bits of my work process should I test out?