Good morning. It’s Sunday, I think, but don’t ask me what time it is.

This week has been intensely code-focussed. I’ve done some really good work to tidy up my new codebase – moving things around, refactoring out similar code into something similar, and figuring out abstractions. I’ve also learned a couple of new patterns for manipulating objects, which is a distinct pleasure. I really like learning new things! I go through periods of learning and applying, and right now I’m in sponge-mode.

The team continues to be remarkable. We’re in full swing, and the rhythm of stand-ups, retros, show and tells are all coming together. Our PM is thinking about the people we need to understand, and we’re readying the platform for more cryptographically interesting means of authentication. I suspect I don’t have an audience full of crypto enthusiasts, so for this week there will be a stay. Next week, though…

The ways of working in the team are still bedding in, and I’m finding points of tension where I wasn’t expecting them. Some people write very brief commit messages and then squash them into one change – but do it regularly. Others write extensive commit messages and end up with very beefy changes, where each step makes sense but nonetheless the whole feels somehow riskier. The way we write these commits also changes how we review each other’s code, and this is part of the tension. I’m an extensive-writer, and so when I review code I review it as if it were mine. I expect each commit to make sense as part of a narrative, and struggle when it’s a messy story, with later changes overwriting earlier ones.

For brief-writers, they look at the whole change in one go, ignoring the individual commits. That’s sensible when the entire change is tens of lines, but faced with hundreds of lines…you worry that you can’t grasp the whole thing. So we end up with tension: extensive-writers frustrated with the lack of structure, brief-writers wondering why the hell you can’t just break up your work into smaller units.

We need to get to the bottom of it as quickly as possible because neither way is wrong but they’re happening simultaneously and, I think, without intention. Some part of the solution is getting all of us to switch mindsets when we review the code of a brief-writer/extensive-writer. Some of it is also going to be hideous compromise, and realising that ‘many-commits-and-squash-into-one’ is (looking only at the output) functionally the same as ‘single-structured-commit’. It’ll be a tricky discussion, but I think a good one.

With this renewed focus on building, though, comes the urge to build a thing of my own. Perhaps this is the year that I actually build the solution the Fast Stream needs, after only one two three four five attempts. Or perhaps it’s time to try something else. My public speaking club’s website is functional but perhaps needs a facelift for the modern era, while the backend we use for organising meetings is…a little creaky. There would be significant hoops to jump through, including some work to convince folks everything was safe, and yet…I feel like it might be a fun little exercise/entire dissertation project.

I’m tempted to try out one of these LLM coding assistants for it. The experience I’ve had has been distinctly underwhelming, and I’m not completely convinced that the market’s not going to collapse soon. But while they’re here and cheap, I’m going to see if they’re any good.