Role
Backend engineer, for the parts that have to be correct
Finance says the reported figure is wrong. Engineering says the query is correct. Both are right, which means the disagreement is not about the query at all, it is about which definition is the real one.
How I fit
I work on the parts where approximately right is the same as wrong. Money, balances, state machines, anything that has to reconcile. That work rewards a specific temperament, which is a willingness to be slow at the start in exchange for never having to conduct an archaeology project later.
A challenge from this role
Finance reports that a figure on a dashboard does not match their own records. Engineering checks the query and it is correct. Both are right, because the two are answering slightly different questions and neither definition was ever written down. It has probably been diverging for months.
How I approach it
Do not touch the query. Write down both definitions in the language the business uses, in full, including what each does with partial payments, credits and adjustments. That step usually ends the argument on its own, because seeing them side by side makes it obvious that one is answering a question nobody asked. Then pick one owner for the figure and make everything else read from it, rather than making the two agree, because agreement is a truce and truces expire. Migrate by computing both and logging the difference before changing any behaviour, so every divergence is explained before it is removed.
What proves it
Replaced four independent calculations of the same figure with a single owner, across a live system, without a rewrite.
Payment posting that is safe under provider retries, with a sweep that assumes the worker died and a daily pass that catches events which never arrived.
Ten million future jobs held on flat memory, sub second dispatch, zero losses.
Isolation treated as a structural property rather than a filter somebody remembers to apply.
Sole engineer, on call, migrations against live data while customers are using the system.
Why definitions come before code
Almost every serious correctness dispute I have seen turned out to be two definitions that were never written down, rather than a bug in either implementation.
Once both are on paper in the language the business uses, the argument usually ends without anybody opening an editor, because the difference becomes visible and one of them is obviously answering a question nobody asked.
Writing them down is also the only way to make the eventual code reviewable. A query can be checked against a definition. It cannot be checked against somebody’s understanding.
The temperament this needs
Being slow at the beginning. Establishing what is true before changing anything is unsatisfying, it looks like inaction to anybody watching, and it is the entire difference between a repair and an archaeology project.
Questions people actually ask
- How do you keep a correctness focus from becoming slowness?
- By being selective about where it applies. Money and state get the full treatment. A preferences screen does not. Applying the same rigour everywhere is its own failure and it teaches a team to ignore the rigour where it matters.
- What is your first move on an unfamiliar financial system?
- Find the number the business trusts least and follow it end to end. That single trace teaches more about the real architecture than any diagram, because it crosses every boundary that matters.