Technology & Development
I’ve been working in software for almost 20 years, which mostly means I’ve had enough time to make mistakes in several different architectures.
I still enjoy it, unfortunately.
Not because I believe technology will save us, but because I like solving problems, making things slightly less annoying, and occasionally building systems that continue to function after I stop looking at them.
What This Usually Means
Most of my work lives somewhere between product, systems, and practical survival.
- building features people actually use
- untangling systems that grew in emotionally unstable directions
- making internal tools so repetitive work dies quietly
- fixing things that were “just a small change”
- trying to leave codebases in a better mood than I found them
The Part I Actually Like
I’m less interested in shiny tech theatre and more interested in work that holds up on a random Tuesday.
That usually means:
- interfaces that make sense
- APIs that don’t feel passive-aggressive
- code that can still be read after six months
- automation that saves real time instead of creating new rituals
- documentation written for the future version of me, who will be older and even less forgiving
Tools, More or Less
I’ve spent enough years around software to collect languages, frameworks, habits, and a healthy distrust of anything described as “simple.”
Depending on the year, team, and level of collective optimism, that has included:
- JavaScript / TypeScript for much of modern life
- Java from earlier chapters and still perfectly capable of causing feelings
- Node.js, NestJS, Express, and the usual backend plumbing
- React and related frontend ecosystems
- React Native when the web alone wasn’t suffering enough
- Spring Boot in previous lives
- PostgreSQL, MongoDB, and the usual database negotiations
- Jest, JUnit, and the ceremonial act of pretending tests will save us all
- Docker, CI/CD pipelines, release flows, and other invisible machinery
- Markdown, docs, notes, and writing things down because memory is a scam
The Kind of Things I Build
Product work
A lot of what I do is ordinary in the best possible way: product features, backend services, APIs, UI flows, integrations, internal tools.
The kind of work that looks simple from the outside and somehow becomes a six-meeting discussion with edge cases.
Small systems that reduce daily suffering
I have a soft spot for automation, guardrails, cleanup scripts, and little tools that remove friction.
Nothing glamorous. Just useful.
Which, in my experience, is rarer than glamorous.
Things that age without becoming cursed
I don’t really care if code looks clever.
I care if it:
- still works
- can be understood
- can be changed safely
- doesn’t ruin someone else’s week
- fails in a way that at least leaves clues
That feels like a more respectable ambition.
Side Projects, GitHub, and Other Evidence
My GitHub is mostly a mix of experiments, utilities, half-finished ideas, over-finished ideas, and the occasional thing that solved a real problem because I was too annoyed to do it manually twice.
Some projects are practical.
Some are educational.
Some were built because I thought, “this should be easy,” which is historically one of the dumbest sentences in software.
This Site Counts Too
Even this site is part of the same instinct.
It’s simple on purpose: content in Markdown, minimal ceremony, easy to maintain, easy to extend, not trying too hard to become a platform with feelings.
I like systems that remain understandable.
That alone already puts us in a minority.
If There Is A Philosophy Here
After long enough in software, the magic wears off, but the craft doesn’t.
I still like:
- clear thinking
- boring reliability
- useful abstractions
- good naming
- fewer moving parts
- tools that help people do their work without inventing new problems
In other words, I still believe in writing software that behaves.
A surprisingly radical position.