README

Engineers write READMEs for the things they build. This is one for working with me: how I think, how I collaborate, and what gets the best out of me. My wife helped me write the first version of it, and it has held up well enough that I keep it current.

Who I am

I am a backend and platform engineer. Born in the UK, now living in Sacramento with my wife, who is also an engineer. He/him.

If personality frameworks are your thing, I am an INTP: I love patterns, have a flair for language, and am usually bursting with more ideas than I have time for. Curiosity is the engine. I like exploring how something works far more than I like being told.

I have been in and around tech since 1999, though my software career proper began around 2006. The early years were finance IT and MIS reporting at JPMorgan Chase, then network and call-centre IT at Carelink: a lot of Access, Excel, and VBA, some VB.NET, and a fair amount of physical networking. From 2006 I moved into web development, full-stack at first, going from PHP through Ruby to Python, and over the last decade I specialised into the backend and platform side. Software is as much a hobby as a job. I usually have something half-built at home for the fun of it.

Currently curious about cryptography, AI and ML, and security, especially where security meets AI and user safety. Away from the keyboard: slowly learning Spanish, a nascent interest in calligraphy, gaming both digital and analog, and reading, non-fiction and sword-and-sorcery in roughly equal measure. I care about mentorship, and have spent years in user groups, at conferences, and volunteering with The Collab Lab.

How I approach work

The best code is no code. I like to understand what actually needs doing before I commit to building anything, and I want a fair sense of the final vision before I start. Requirements can come from a sync discussion or a document with feedback cycles; either works, as long as we have thought it through.

I hold a lot of threads at once, and I care about seeing how backend and platform work ladders up to customer value. I do not want to build in a vacuum. I want to know what it is for.

Working with me

I do my best collaborating on planning, design, and problem-solving. That is where I add the most. I prefer to write code alone, or pair only in short bursts, and I love jumping on a call to think through a hard problem together. Small groups and one-to-ones are where I do my clearest thinking.

I am a parent and I flex my schedule around that, often catching up in the evenings. I manage my notifications deliberately, so a message outside your hours is never a demand on your time, and one from me carries no expectation of a reply until you are back at work. That flexibility runs both ways.

Short-notice meetings are fine as long as they carry context. Not "can we chat in an hour," but "can we chat about the ABC migration in an hour." The context is what lets me show up useful.

Feedback

Give me critical feedback privately, not in public. Positive feedback in public is welcome. Thoughtful phrasing is appreciated, but direct is fine too; I would rather hear it plainly than not hear it. And I prefer it promptly, while it still connects to the thing it is about, so I can actually act on it.

What gets the best out of me

I do my best work when I have room to think before acting, and when the reasoning behind a decision is on the table rather than just the conclusion. I can think independently of the group and still take direction well from someone whose judgment I respect. I like structure and initiative in balance: give me the plan and the freedom to work it. I tend to see the shades of grey, weigh consequences, and care about the second-order effects of a decision.

What drains me

Constant group interaction with no time alone or in small groups. Tight deadlines with no space for planning. Being pushed into fast decisions before I have weighed the consequences. Unclear ownership or leadership that will not take a position. Repetitive routine that crowds out initiative. Abrupt schedule changes with no notice.

None of these are dealbreakers. They are just the conditions I watch for, in myself and in a team, because they are where I am at my worst and where I would rather help fix the environment than quietly grind against it.

This README is a living document and a statement of intent: transparent communication, and collaboration that works for everyone involved. Ask me anything it does not cover.