Working with Me¶
This is a personal README — a map for people who work with me regularly. It covers how I prefer to communicate, how I engage with feedback, and what I find energising. It's not a contract; it's context.
I'm a senior full-stack engineer based in Sheffield, UK. I've been writing software professionally for 14 years, mostly across .NET Core backends, React frontends, and Azure infrastructure. I spend a lot of time thinking about how systems hold together under pressure and how teams stay effective as complexity grows.
Communication preferences¶
I default to async and written. If something can be a document, a GitHub comment, or a Slack message, I'd rather it be that than a meeting. Written communication forces clarity on the writer and gives the reader time to think before responding. I produce better input to decisions in writing than I do on the spot in a room.
I prefer written proposals over long discussion. If you're proposing something non-trivial — a technical direction, a process change, a design — write it down first. Even a rough page. It moves the conversation forward faster because we're reacting to a concrete position rather than building one in real time. I'll do the same.
I'm reliable over Slack during core hours (Sheffield time). I don't expect instant replies and I don't interpret slow responses as disengagement. I extend the same assumption to others. If something is genuinely urgent, say so explicitly — I won't infer urgency from tone.
Meetings work best when they have a clear goal. I'm fully present in meetings when I understand what decision or output we're working toward. If I'm in a meeting and it's unclear, I'll ask. If a meeting ends without a clear outcome, I'll send a written summary to create one.
How I give feedback¶
Direct, specific, and in context. Vague feedback doesn't help anyone improve. I try to be precise about what I observed, why it matters, and what I'd suggest instead. I aim for the kind of feedback I'd want to receive — honest without being harsh.
Privately first for anything sensitive. If feedback touches on judgement, approach, or anything that might feel personal, I give it in private before (or instead of) saying it in a group setting. Public correction is rarely necessary and usually counterproductive.
I separate observation from interpretation. I try to say what I saw — the code, the decision, the communication — before I offer an opinion about it. This keeps feedback factual rather than attributional.
How I receive feedback¶
I want direct feedback. If something I did created a problem, or if my communication landed badly, I'd rather know clearly than have it managed around me.
The best time to give me feedback is close to the event, in writing if it's complex, and framed around the specific thing rather than a general pattern. I'll ask questions to understand rather than to push back, and I'll follow up once I've had time to think.
I don't always agree with feedback immediately. I'll say so if that's the case, and I'll explain why. Disagreement is fine; what matters is that both positions are articulated clearly.
Code review philosophy¶
I teach through questions, not instructions. Rather than "change this to X", I tend to ask "what happens if the service is unavailable here?" or "have you considered how this behaves under concurrent load?" The goal is for the author to reason through the tradeoff, not just accept a correction.
I distinguish between must-fix and worth-considering. Not all comments carry the same weight. I label things clearly: a blocking concern is a blocking concern. An observation about style or an alternative approach is flagged as optional — I don't expect every suggestion to become a change.
I review for understanding, not coverage. I'm less interested in whether a PR passes the checklist and more interested in whether I understand what it does and why. If I can't follow the logic, that's a signal the code needs more clarity — regardless of whether the tests pass.
I try to acknowledge what's good. Code review has a negativity bias because the job is to find problems. I try to counteract that by calling out decisions I think are well-made.
What energises me¶
Hard architectural problems. The kind where there's no clean answer, only a set of tradeoffs you have to reason through carefully and commit to. I find this genuinely interesting rather than stressful.
Mentoring engineers who are levelling up. Watching someone move from following patterns to forming their own opinions about system design is one of the more rewarding things about this job. I invest in it willingly.
Clean systems. I get disproportionate satisfaction from systems that are well-understood, well-instrumented, and boring to operate. Complexity that exists for a reason is fine. Complexity that accreted over time without intention is something I'll want to address.
Working with people who've thought about their craft. I don't mean people who know the most frameworks or the most algorithms. I mean people who've reflected on what makes software good and have opinions about it.
What drains me¶
Meetings that could have been a document. Decisions made by consensus-erosion rather than reasoning. Rework caused by unclear requirements that were known to be unclear. I try to address these things directly rather than absorb them quietly.
If you've read this far: thank you. I wrote it because I find this kind of context genuinely useful when I'm working with someone new, and I hope it's useful to you too.