About

I am a software engineer. I have been one for more than twenty years, which is long enough to have changed my mind about a fair number of things I used to state confidently.

Most of that time was spent on backend and distributed systems: messaging infrastructure, integration between systems that were never designed to talk to each other, a calculation-heavy planning system built against a hard latency budget, and the unglamorous work of keeping large codebases changeable. A recurring pattern runs through it that I mostly noticed in retrospect. Given a problem, I tend to build the thing that makes the problem cheaper to solve the next twenty times: frameworks, platforms, abstractions, internal tooling. Sometimes that is exactly right. Sometimes it is a more elaborate way of avoiding the simpler thing, and telling the two apart in advance is harder than it sounds.

Some of that work was done as a consultant, in a small number of organizations over long engagements. That is a useful vantage point, though not the one people assume. You do not get breadth from it so much as contrast: you see which practices survived being moved into a different organization, and which ones had been load-bearing only because of who was in the room. It makes you suspicious of advice that does not name its context, including your own.

Then I spent about five years as a director of technology, responsible for programs, delivery areas, recruiting, training and internal tooling, before deciding to go back to an individual contributor track on purpose. That decision is the subject of one of these essays, so I will not relitigate it here. The short version is that I wanted to find out which of my influence was mine and which belonged to the org chart, and there is no way to learn that from inside the role.

What this is

One essay a week for a year, on the work that starts where the job description ends.

The material comes from two places. The first is the literature on architecture, distributed systems, reliability, organizational design, and the Staff+ role itself. Each essay names the books it draws on, and where two respected sources contradict each other I say so and take a position rather than presenting a balanced summary that helps nobody.

The second is twenty years of doing this, including the parts that went badly. I try to be specific about which is which. When I am reporting something I have watched happen, I say so. When I am arguing from a book, I say that instead.

I write in English. I am Brazilian and I work in both English and Portuguese, which is a steady reminder that a sentence which cannot survive translation was usually carrying less than it appeared to.

Some things I believe

Trade-off analysis is the whole job, and everything else is an instrument for doing it better.

Most disagreements about architecture are disagreements about which failure the participants have personally survived.

A decision that was not written down will be made again, at full price, by people who do not know it was already made.

The books are worth reading and the books disagree, and pretending otherwise is how a field accumulates dogma.

Elsewhere

You can find me on LinkedIn. If something here is wrong, I would genuinely like to know, and I will correct it in place and say what changed.