Most of my work is on systems that are already running

How I think about engineering

The hard part is almost never writing the code. It is understanding why an operation works the way it does, including the workarounds, which usually exist for a reason nobody wrote down.

So I start by asking how things are done today, not what someone wants to build. The smallest change that actually solves the problem is usually smaller than the one imagined at the start.

The same applies to delivery. I would rather put something verifiable in front of people early than go quiet for weeks and come back with a claim.

Things I argue against

• Do not replace an ERP because it does not do everything. None of them do. Do not build from scratch what can be integrated. Do not buy a system to fix what is really a process problem.
• Do not automate a broken process either. That only makes the error happen faster.
• And do not start a large project without a verifiable delivery along the way. If the first thing anyone can check is the last thing, nobody knows where the project stands until it is late.

How I work

Directly with whoever owns the problem, without a layer in between passing the context along. Explicit scope, deliveries you can check yourself, and an agreement about what happens after handover, made before the work starts.

When something needs more capacity than I have, I say so early rather than late.

I am based in Maranhão, Brazil, and I work remotely.

What I work with