about
Hi, I'm Muhammad Shahadul.
I'm a software engineer. Python, Go, and TypeScript mostly, though the language matters less to me than it used to.
Most of my attention goes to the layer underneath. Schemas that have to be right, pipelines that can't silently drop a row. Small tools too, the kind you use a hundred times a day without thinking.
The through-line
Ten years in, my resume doesn't look like it has a theme. E-commerce builds, SAP migrations, Kubernetes services, a parser, three terminal apps. It's been the same problem most of the time. Someone needs to express intent, and the machine needs to execute it exactly, every time, without surprises.
A validation rule, or a filter a non-engineer types into a UI. Both
want the same thing, a small safe layer between what a person meant
and what the machine does. Most codebases solve it with eval() or four hundred lines of if. That's
why xpr-lang exists. It's also why I keep ending up
on the platform side of a product. Platform work gets judged on
whether it's still trustworthy in two years, under people who never
met you.
Why I build tools
The env file that drifted between staging and production. The fourteenth time you retype the same request with a slightly different header. The port that's already in use and the minute you spend finding out which process is holding it. None of these are real problems. That's why they never get fixed. Each one is too small to justify a ticket, and together they take a bite out of every working day.
envdiff, ports, and restless all came out of an afternoon of being annoyed by one of those. I still use all three most days.
Opinions I'll defend
- Boring technology, aggressively. Postgres until it hurts, and it rarely hurts. The innovation budget should go on the problem you're actually being paid to solve.
- Duplication is cheaper than the wrong abstraction. Two similar functions cost you some duplication and you can see it sitting there. One abstraction stretched over two cases that aren't quite the same will keep costing you for months before anyone notices.
- Simple beats clever. If a new hire can't follow the code in a week, I wrote it wrong.
- Ship in slices. Get one real request running end to end early. You'll find the integration problems in the first week instead of the sixth, and they're a lot cheaper to fix then.
- Write it down. Decision records, and the comment explaining why the timeout is 8 seconds and not 30. If I can't write down why we're making a decision, I usually don't have a good enough reason yet.
Since I started leading, my own throughput stopped being the useful metric. Some of my better days produce nothing I can point at. A design conversation that stops three weeks of the wrong work counts. So does a decision written down clearly enough that nobody reopens it next quarter.
Away from the keyboard
Most of my non-work hours go to my son, who is much better at asking why than I am at answering. The rest goes to history and politics, usually long books about how large systems fail. Institutions rot for the same reasons codebases do. Decisions nobody wrote down, and everyone assuming somebody else understands the load-bearing part. I've worked remotely for most of the last decade. Writing things out async is the format I'm best in, so that has worked out well.
If any of this lines up with what you're working on, or you think I'm wrong about one of those opinions, I'd like to hear it.