Last month I interviewed for another position within the Civil Service, but was ultimately unsuccessful.
As part of the follow-up, I had the opportunity to receive feedback on how I’d done and things I would need to address if I applied for the role again.
The feedback covered all parts of the interview but this post focuses on the technical assessment which was to solve, and more importantly discuss, a programming problem set on the day.
In particular, the feedback motivated me to reflect on the way I work now and how I got here.
Coding
I like test-driven development, it’s a pretty natural way of thinking to me. Plus, who am I to deny the sweet, sweet dopamine hit that results from making a failing test pass?
The biggest influences on my specific coding style are probably Kent Beck’s Limbo and Keith Braithwaite’s TDD as if you meant it.
Sort commits into “couldn’t possibly cause problems” (you’ll be mostly right) and “might cause problems”. Treat them differently. Rearrange your workflow so you have mostly “couldn’t possibly cause problems” commits. - Kent Beck
That is to say:
- Lots of small, test-driven, low-risk changes
- Leverage automated refactoring tools heavily
- Delegate repetitive tasks to IDE and tooling
- Treat test code as production code, and refactor judiciously!
The goal is to have many composable “couldn’t possibly cause problems” changes that can be re-ordered and combined into larger logical groups.
However, code is read far more often than it is written or edited, which leads me to …
Communication
I deliberately err on the side of over-communicating to my collaborators what I’m going to do.
Right, so the next test I’m going to write is […] so we can drive out this part of the feature. It’s going to fail in a particular way because […]. – me, probably
Communicating clear intent is important now more than ever, when distributed working is more common, but I always worry it’s verging on just vocalising my stream of consciousness.
Now why have you done that? – also me, probably
I’m weirdly self-conscious about this, I think I also just don’t like silence. I’ve been told I do the same thing when I cook.
I attribute this partially to my reading of L. David Marquet’s Turn the ship around!, which inspired me to try to create a bit of airtime for questions, comments, or alternative suggestions before I go and execute.
If you’re writing the best code in the world, but not communicating your intent to your collaborators, you’ve probably failed in a way isn’t immediately apparent.
Reflection
You can reflect on your own actions until the cows come home, but it’s interesting to hear other peoples’ perception of the way you work - I believe that we’re rarely afforded the opportunity to set aside time for this as part of a wide(r) feedback loop.
We spend a lot of the day either on pairing/mobbing or per-change reviews like pull requests, but I’ve rarely experienced a deliberate multi-person forum for what you’d probably call something like “code critique” rather than “code review”. This could extend outwards to things like codebase organisation and system design too.
As a long-time advocate of pairing I’d expect many to say this is, or should be, a natural consequence of pairing/mobbing. I disagree.
My experience of these environments is that the focus tends to be on the work rather than a meta-conversation about how you take the next step in the work. I assert that these activities are worth their own dedicated time.
A colleague at my previous job ran a session similar to this, with the ambition of getting a stepped-back view on a piece of code, which seemed to work well.
I’m really interested in what it would take to create a respectful, empathy-driven, and collaborative space dedicated to this purpose - a venue for feedback and reflection on the process of making a change rather than the output itself.