Technical projects have README files so you know what you're getting into. This page does the same for me.
For feedback, just come and find me. In person if we work together, otherwise on Bluesky or LinkedIn.
TL;DR: there isn't one. It takes a few minutes.
Last reviewed in August 2026.
What success in the job means to me
I work carefully and stay pragmatic. I like continuous improvement, and I like shipping work that holds up against whatever QA and users throw at it. I know when to stop polishing. And I like milestones hit on time without crunch, before or after a launch.
I do my best work when I believe in what we're building. My three years at zolar, on climate tech, pulled more out of me than any job before it. Not every job has to be that. But it's what moves me.
What I'm good at
I build interfaces, and I've done it long enough to care about the layer above them: how a system gets cut up, which decisions get made once so nobody has to make them again, and how a technical choice reads to the people paying for it.
Some of that in practice. A design system used by 40+ product teams at XING. A team of 15 at sum.cumo, including three months of holding it together while the company came apart around us. Six years building and running the platform behind Redezeit für Dich, alone. Right now, a Next.js rebuild of a state lottery – high availability, heavy regulation, real money.
I know React Server Components well, including where the server/client boundary actually belongs. Most of my current work runs through AI agents, which turns out to be a writing problem: the tool is only as good as the spec you give it.
I have a soft spot for internal tooling. The most useful software I ever wrote was back-office tooling for solar installers. When I redesigned another back office, I shipped working code instead of static designs – software answers questions that mockups only raise.
I also move between business and engineering without a translator. I worked in comms, PR and affiliate marketing before I wrote code for money, and saying what something costs and what it buys, in words a non-engineer trusts, is rarer among engineers than it should be.
I go as deep as a problem needs, and sometimes that's very deep: reading the framework's own mechanics until it makes sense, rather than hoping someone has blogged about it. There's an example further down.
What I don't do is collect depth for its own sake. I go to the bottom when something sends me there, and I stay broad the rest of the time. That combination is why I'm useful when a team is stuck: I've usually seen the shape of the problem before, and I'll dig until I understand the specific one in front of me.
And I like CSS enough to chase obscure bugs in it. That hasn't changed.
What I'm like when things go wrong
Calmer, mostly. An emergency is one of the few situations where the priorities are obvious.
Launching a regulated platform is a long campaign, not one bad night. Weeks before go-live I tracked down why our Server Actions were queueing backend calls instead of running them in parallel. Around the launch our own API went down under the volume of requests, so we reworked and cached those same calls under time pressure. After we went live, the auth provider buckled under real traffic, and we fixed that too.
Under pressure I get pedantic about the boring things: what do we know versus what are we assuming, what do the logs actually say, is the basic stuff healthy. That's most of it.
How I communicate
A lot. I share context early and directly, and I write fast, so ask again if a long message left something unclear.
Chat, email, in person – all fine. What I don't like is the unscheduled video call. Even when it's urgent, please send me a topic and a goal before I join.
Fridays I work a half day, so no meetings in the afternoon. When I'm with my daughter I'm offline. Unless someone is dying (which rarely happens when shipping software, I've noticed…), it can wait until tomorrow.
Things that could annoy you about me
Two quotes I keep coming back to:
There is more humor than hate to be found in just about every situation. – Ryan Holiday, The Daily Stoic
When we're miserable, we're miserable. Now what needs doing next? – David K. Reynolds, Constructive Living
I work that way, which means I may react to a bad situation in a way you don't expect. I'm usually in a good mood and meet trouble with "oh, that's interesting" and a grin. Depending on where you are that day, that can grate. Say so and I'll drop it.
Two specifics worth knowing:
- My messages are long, which makes things look more urgent than they are. If you can't tell how to rank something I sent, ask. It's usually less critical than the word count suggests.
- Bring me a frustrating problem and my first move is to take it apart, not to sympathise. If you just need to vent, say that first and I'll shut up.
How you gain or lose my trust
You start with it. I assume you're competent and want to get better.
You keep it by telling me where things stand: when you're stuck, when something slipped, when an estimate has stopped being true. "I don't know" and "I need help" are always fine answers. I use them often. I'd much rather hear about a problem on Tuesday than find it on Friday.
You lose it by hiding things – done that isn't done, a known issue held back until the deadline. Every project has problems. Concealed ones make me wonder what else I'm not hearing.
"When in doubt, play the [person] who makes the fewest mistakes." Not a bad way to think about a lot of things in life. – Dan John, Never Let Go
Steady beats brilliant. That's what I look for, and what I try to be.
Where I want to get better
I get impatient explaining the same thing repeatedly, especially when I think it's simple™ – which it usually isn't. Finding a better explanation instead of a louder one is work I still owe people.
For years this section said I wasn't as good as the JavaScript people I'd learned from. I've stopped believing that. The useful part stuck: I know who to ask about what, and I'd rather ask early than be clever alone.
My default is harmony. I'd sooner smooth over a disagreement than have it. The sharper version of that: I stay productive inside a broken situation for a long time without saying out loud that it's broken. I sat through zolar's slide into insolvency, and at sum.cumo I held a collapsing team together for months before I called it.
But here's the thing I've stopped pretending about: when it counts, I do the hard version anyway. I delivered bad news weekly for months and sat in one-on-ones where I had nothing to offer but the truth. So it isn't that I can't. It's that I won't until something forces me. Force me: if I'm only ever saying nice things, name it, and hold me to it.