Ashab Hussan

About — Ashab Hussan

Nine years of being the person who asks what happens when it fails.

I'm a software engineer working on backend systems and internal platforms — the queues, the migrations, the deploy pipeline, the alert that wakes somebody up. I've spent most of my career on teams of five to fifty, usually at the point where a product has outgrown the way it was first built.

Work with me See the work
Ashab Hussan
Working since
2016
Based
London, GMT+0
Mostly writes
Go, TypeScript
Languages
English, Bengali

How I got here

A support inbox, then everything after it

My first job in software wasn't writing it. I answered support tickets for a logistics tool, and spent most of my shifts explaining to drivers why the app had lost the last hour of their route. After the fourth week of writing the same apology I asked for read access to the database, and the pattern was obvious within a day: a retry that wasn't idempotent, firing every time a phone dropped signal in a tunnel.

That fix was eleven lines. It taught me the thing I still work from — that most production pain is small, specific and findable, and that the people nearest the complaint usually know where it lives. I moved onto the backend team that quarter and never really left.

“The interesting question is never can we build it. It's who has to live with it in eighteen months, and will they understand why we did it this way.”

Since then: an analytics company where I learned what a billion events a month actually feels like on a Tuesday; a platform team where I found out that a paved road nobody adopts is just a road; and a stretch of contract work with small teams who needed one experienced pair of hands rather than a department.

The common thread is unglamorous. I like systems that start fast, fail loudly, and read clearly to a tired person. I like deleting code. I like the moment a team stops holding its breath during a deploy.

A whiteboard mid-design-discussion
The desk most of this happens at

The route so far

Roles, in order, with what each one actually taught me

2016 → now

  1. 2016 — 18

    Support, then backend — logistics tool

    Read every complaint before I read the code. Learned that an error message is a product surface and that offline-first is a promise you have to keep on the server too.

  2. 2018 — 21

    Senior engineer — analytics product

    Four years inside an ingestion path that grew faster than its design. Learned schema evolution the hard way, and that replayability is cheaper to build on day one than to retrofit on day four hundred.

  3. 2021 — 23

    Platform engineer — twelve product teams

    Built the internal deploy path and then spent as long again on adoption: office hours, migration PRs, one good README. A platform is a product whose users sit three desks away and can refuse it.

  4. 2023 — now

    Independent — contract & advisory

    Three-to-six month engagements with teams who have a specific system to build or rescue, plus standing advisory days. Enough variety to stay honest about what generalises and what doesn't.

The projects behind these years

What I believe

Six opinions I've held long enough to defend

Most of these started as something I got wrong once, expensively, in front of other people.

Measure before you rewrite

A rewrite proposed without numbers is a preference. With numbers it's a plan, and usually a smaller one than anybody expected.

Fail loudly, early, once

Swallowed errors are debt with compound interest. I'd rather a service refuse to start than run in a shape nobody chose.

Writing is part of engineering

If the design note doesn't fit on a page, I don't understand the problem yet. Writing it is how I find that out before the code does.

Review is teaching, not gatekeeping

A comment that only says no costs the same as one that says why. The second one compounds across every PR that follows.

Reversible beats clever

Flags, migrations that run both ways, deploys you can undo in a minute. Confidence comes from the exit, not the entrance.

The best PR removes things

Every abstraction kept "just in case" is a future reader's hour. Delete the branch nobody has taken since the launch.

A user manual

What I'm like to have on the team

Written for the person deciding whether to introduce me to their codebase. It's shorter and more useful than a list of adjectives.

Pairing over a design question

I ask a lot of questions in week one

Not as a stall. I want the history — the thing you tried in 2022, the constraint that looks arbitrary and isn't. Assume I'll read the old incident threads.

I write things down, probably too much

Short notes after decisions, a page before big ones. If you prefer a call, we can have the call — I'll still send the paragraph afterwards.

I'd rather disagree early than quietly

If I think the plan is wrong I'll say so once, clearly, with an alternative. Then I'll commit to whatever the team decides and stop relitigating it.

I'm slow to add dependencies

Every library is a thing someone will have to upgrade at an inconvenient moment. Standard library first, boring tools second, novelty last.

I protect handover time

Runbooks and pairing go in the plan at the start, not the last week. The goal is that you stop needing me on schedule.

Away from the keyboard

The rest of it, briefly

Good engineering decisions tend to arrive somewhere other than the desk. Mine show up on a canal path at seven in the morning.

A canal towpath at sunrise

Early runs

Five mornings a week along the water. Half the architecture problems I've solved were solved somewhere around kilometre four.

Bread dough on a kitchen counter

Slow cooking

Weekend bread and my mother's recipes, mostly unmeasured. A process with a long feedback loop is good practice for patience.

A shelf of well-used books

Reading sideways

Infrastructure history, aviation incident reports, and anything about how large organisations fail slowly. It all turns out to be about systems.

Outside the day job

Talking, mentoring, and the odd open repo

None of it is a business. It's how I stay in contact with problems that aren't mine, which is the only reliable way I've found to keep learning.

  • Local meetups

    A handful of talks a year at backend and SRE meetups — usually some version of "the migration you keep postponing".

  • Mentoring

    Two standing hours a month with career changers moving into backend work. Free, and booked a few weeks ahead.

  • Small open tools

    A migration linter and a log-replay CLI, both extracted from client work with permission and kept deliberately tiny.

  • Notes, monthly-ish

    Short essays on things I got wrong recently. Written slowly, published when they stop embarrassing me.

Two days a week free from next quarter

That's the background. The interesting part is your system.

If any of the above sounds like the help you need, send a paragraph about what's breaking. If it isn't something I should take on, I'll say so and point you somewhere better.

Start a conversation Selected work
Typical reply
2 working days
Engagements
3–6 months
Advisory
By the day
Overlap
09:00–18:00 GMT