Setting the foundations
Platforms. I’m returning from a two-week ‘sabbatical’ which I wrote up here, during which I relaxed and let thoughts settle as much as I could. It’s just that point in life, and it was a good exercise. I remembered that I build things that people rely on, and I’m good with that. Sometimes stability is more important than innovation.
This fed into the idea of “tooling up” I noticed Monday morning, returning to the office. Get the foundations in place, and everything else just falls into position, so much easier. We’re at the start of a new feature development, so I’m firmly embedding myself in the ‘get things ready to rock’ mindset. If you’re chasing your own processes and tools halfway through the work, everything is at risk. Back-pedalling requires a huge amount of overhead sometimes.
A test plan is another platform for building change, so I also focused on that this week. I dug through the code I wrote so many years ago, documenting it line by line, eking out actual functionality rather than assumed. I’m having a push to document our functionality better as we go – it’s a bit silly how often we still refer back to source code to determine system behaviour. This time, I want to make sure the audit ties in with our client-facing knowledge base and our internal automated tests in equal measure.
Food is also a platform – for the brain, but also for communality, so I forced myself to take a break in the afternoon to go the shop. I have an urge to expand our snack repertoire. Disruptive foodstuffs. Bought smoothie and some Nakd bars.
Got my developer VM updated because it’s important to keep up with infrastructure. This is also a kind of review for the changes the team are making to our setup – getting it working once is exciting. Getting the same thing working across the whole team is a different challenge.
Mapping out the abstract is something I really enjoy doing. All decisions come down to understanding the landscape – map out the landscape and how everything is connected, and the decision and the strategy resulting from it simply become a route through from A to B to C to wherever you want to end up. Certain things don’t relate to each other, so you can consider those separately. Certain areas come “before” or “after” other areas, so you can order decisions accordingly..
The difficult part about the abstract is that it’s the wrong side of the eyes – stuff inside you head is tricky to see. Other than our eyeballs being back-to-front, there’s also a whole cruft layer of other thoughts in the way – ongoing deadlines, dinner shopping lists, emails to send. Getting that cruft out of the way is vital, like clearing clouds from below a helicopter to see what’s down there.
One way of doing this is to write everything down somewhere first, so your brain knows it can give up its hold on it. This is generally the first thing I do if I’m getting worked up about many disparate threads – map out the distractions.
Today I noticed another, complementary approach while getting a big board ready to draw my map on. A cup of tea, pen, and board eraser ready to go. You can tell a lot about people by how they write. But you can also tell a lot about them by how they unwrite – the hurried act of scraping the board eraser over a large surface, a frenzied urge to wipe the slate clean, to “get things down” and crack on. But there’s an alternative, my friend. Next time you wipe a board clean, do so deliberately and carefully, in the way that Eastern calligraphers grind ink sticks for an hour. Rub in circles that flow like leaves blowing or kites soaring. Feel the board beneath, and how its stale traces of old, penned ideas catch at your movements. Clear the space like you’re making a nest for a newborn.
The act of unwriting can be that process by which you disregard those distracting ideas. Each swoosh of the elbow is another step towards remembering the question you want to resolve.
Each sprint, an exercise
Almost forgot, but I’m working from home today – #son1 has a singing concert this afternoon. It’s that time of year when schools go crazy – this week has been a (postponed) sports day, a Carribean cafe, a settling session for #son2 and this concert (plus the usual packed lunches, music lessons, etc, etc). Talking to other parents, it’s clear that making it along to everything is often difficult, if not impossible. It’s that re-reminder that flexibility in people’s lives counts for so much – everyone has needs and draws from outside of work. I have an inkling of that for other people in the company, and I wonder if we still paper over all these pressures more than we should.
I’m not greatly set up to develop code from home – I can access code and do reviews, but not really run code to see it in action. I could look into getting a remote desktop connection from Mac to Windows, but to be honest, I enjoy the change of scene as an opportunity to do different things, and do things differently.
I want to use the current work to develop a more standard approach to handling messages, errors and feedback, and jot things down in a Google doc. The question quickly becomes dependent on what our existing code does and what the plans for the current work are. I open up the question to team slack channel, to get their input, but also feel like I may be going down a rabbit hole that’s too far away from the team’s current mindset.
This is a tension I deal with daily – as an apparently experienced software architect, I want to establish rough structures sooner rather than later – my early work happens “on paper” as a way of mapping out relationships and flow. But other developers often prefer a “code-first” approach – get the files in place, and think with the keyboard. I totally understand that approach too – I do use this on personal projects, when I know there’s not much complexity. The delete key is an essential component of software development.
On the one hand, I want to avoid the team getting in a muddle later on. On the other hand, getting into a middle that can be fixed easily is good for learning. It’s like each sprint is actually the opportunity for an exercise; One time, we practice object design. Another time, we practice unit testing. Another, interfaces and invocation, or writing up style guides.
Perhaps I define these team fences subconsciously at the moment – instinctively, yet reactively, I put certain structures in place so that the team can focus on what I think it’s best for them to focus on. But could/should I do this more consciously and clearly? Is it something we can discuss and document at the start of each sprint?
Seizing the “opportunistic”
Something my brain keeps coming back to this week. I heard about an institution who had retweeted someone calling them “opportunistic”, somehow deciding that this word was an endorsement, rather than an indictment (or maybe it was, and the original tweeter didn’t know what it meant either?)
Anyway, I liked the new definition. Coming out of my thoughts on focusing on foundations, that idea of “providing opportunities” stuck with me. Build a stable base to provide opportunities on – I can very much get behind that.