Why I started writing about technology decisions
This site isn’t another tutorial blog. I want to record decisions: the context, the options, the trade-offs and what came of them. Here I explain where the idea came from.
Who it’s forFor anyone who has landed here for the first time and wants to know what to expect from future pieces.
When I was learning to program, what helped me most wasn’t tutorials. It was conversations with people who explained why they had done something. Not “how to configure a queue,” but “why a queue at all, and not a plain cron job.”
There are surprisingly few conversations like that on the internet. There are countless step-by-step guides and countless opinions about which technology is best. What’s missing is the middle ground: a decision described in a specific context, along with its costs.
What you’ll find here
I’ll write about the decisions I make as a programmer, an architect and someone who runs a technology company. I’ll try to build each piece around a single question and answer it honestly, even when the answer is “it depends.”
Some pieces will be technical: infrastructure, testing, accessibility. Some will be about running a team and a company. All of them will be based on things I’ve done or verified myself.
What you won’t find here
No pieces written to rank for keywords, no news roundups. No promises that reading them will make you a senior engineer. I’ll write less often, but in a way that still makes sense a year from now.
Why I’m doing this
Partly for myself. Writing a decision down forces me to name my assumptions, and named assumptions are easier to check later. Partly for others: for the people I teach, for my team and for anyone facing a similar choice.
If you have a question worth writing about, let me know.