What the Best Engineers Actually Do

When I joined the OpenMRS community as a volunteer in June 2023, I assumed the strongest contributors would be the fastest. I had it backwards. The people whose work everyone trusted were, without exception, the slowest to start and the hardest to rush.

Three years later, having contributed to that community, deployed electronic medical records for facilities in four countries, and built systems for a farmer-owned cooperative, a church and an engineering firm, I have stopped believing that excellent engineering is a matter of talent. It is a small set of habits, repeated when nobody is watching. Here are the ones I have actually seen work.

They read before they write

My first serious contribution to OpenMRS was to the community Billing module. I wanted to open a pull request within the week. What I did instead, on the advice of somebody more patient than me, was read the module. Not skim it. Read it, for several days, including the parts I had no intention of changing.

By the time I wrote anything, I understood that the change I had originally planned would have broken two implementations I had never heard of. The pull request that eventually landed was smaller than my first idea and it survived.

That habit has become the most reliable predictor I know. The engineers I trust arrive at a codebase and ask what it is trying to do before asking what is wrong with it. The ones I do not trust arrive with a refactor already in mind. This matters more now than it did in 2023, because an agent will happily write the refactor for you before you have understood anything, and the resulting change will compile.

They ship slices you can check

Labwor Fleet King, the telematics system I am building, has twenty-five database migrations and not one of them is destructive. That is not fastidiousness. It is the only way I can move fast in a system that stores vehicle telemetry, because a migration that drops a column is a decision I cannot take back on a Friday evening in Kampala with a client waiting.

The same discipline shaped how the product got built. The first milestone was one narrow thing carried all the way to the end: detect fuel theft, from device registration through drain detection through a cost report a fleet manager can actually read. Only when that worked end to end did I start on geofencing and tenant hierarchies. The temptation to build breadth first is enormous, and it is how most side projects die at seventy percent of everything.

In Scholaris, the school system I am building for Northern Uganda, the grading engine currently carries 527 tests at full coverage. That number looks excessive for a piece of a school app until you remember what it computes. A grading engine that is subtly wrong is worse than no grading engine, because it produces printable report cards that are confidently wrong, and nobody notices for a term.

Four counts from the author’s own repositories.

They write things down, in English

The single clearest difference between the OpenMRS contributors whose work outlived them and those whose work did not was writing.

The people who mattered wrote decisions down. Not documentation of what the code does, which the code already says. Decisions: what was chosen, and why the alternative was rejected. Fleet King has over thirty architecture decision records for that reason, and Scholaris has fourteen. When I come back to a module after two months away, those files are the only reason I do not repeat an argument I already had with myself.

Some of the work I am most pleased with in that community contains no code at all: the onboarding guide for new contributors, plain-language user guides for the containerised database bundle and the metadata extraction tool, and the inventory of configuration items an implementer needs before running that tool. Those documents were written for a nurse informatician in a district hospital, not for a developer, and iterating them against real user testing feedback taught me more about interface design than any UI work I have done.

They say no, and they say it early

The out-of-scope list in the Scholaris specification is not a failure of ambition. It is the reason the project is still alive.

I have learned to say no in client work too, though it took losing time to learn it. When I built the mobile app for a fashion shop in Gulu, my own instinct was to make it a marketplace, because a marketplace is the more interesting system to build. What it actually is, and needed to be, is a catalogue, a mobile money payment, an order and a delivery status for one shop. That is a thing a shop owner can operate on her own. The marketplace version would have been a better portfolio piece with nobody on either side of it.

The other form of no is refusing to delete work you rejected. When I designed Fleet King’s interface I built three complete directions for the same screens and chose one. The other two are still in the repository, because one of them encodes a donor accountability model that is a credible future product for programme fleets, and I would rather keep a rejected idea than lose it and rediscover it badly in two years.

There is a version of no that is harder than either of those, which is telling a client that the thing they asked for is not the thing they need. I have done it badly and I have done it well, and the difference is entirely whether I could describe their own operation back to them first. Nobody accepts a refusal from somebody who has not demonstrated that they understood the request.

They keep digging until they find the actual reason

The habit that separates a good engineer from a competent one is refusing to accept a coincidence as an explanation.

On a Christian bookstore platform I built, products started disappearing from category pages for no reason anyone could see. The easy explanation was a caching problem, and I nearly took it. The actual cause was that categories created early in the project had an ampersand inside their handle and categories created later did not, so a filter written against the clean handle silently matched nothing for the older set. Nothing was broken. There was no error. The page simply told a customer that a category was empty when it was not.

I have made this mistake in the other direction too. The fuel drain detector in Fleet King looked correct against synthetic data for weeks. It only became trustworthy when I pointed it at a live GPS ingestion service and watched it react to a real drain event on a real tank. Clean test data is a comfortable lie, and the best engineers I know distrust it on principle.

They care about the person in the room

In May 2024 I customised and deployed a Bahmni electronic medical record system for a clinic in Kamwokya, Kampala, built its clinical forms and trained the staff. I had opinions about those forms. Several of them were elegant. The clinicians skipped every elegant field and typed everything into the notes box, because during a busy morning the notes box is faster than thinking about where a value belongs.

That is a design failure and it is entirely mine. It also taught me the only test of an interface that means anything, which is what a tired person does with it at the end of a shift.

The same lesson turned up in an audit of my own work. Critical fuel-theft alerts in an early Fleet King prototype looked identical to routine notices. The fix was to encode severity in shape as well as colour, so that a colour-blind dispatcher sees the difference too. Nobody had asked for that. Nobody would have complained until the day it mattered.

The habit underneath the rest

If I had to compress all of this into one word it would be patience, which is an unfashionable answer in a profession currently obsessed with speed. Reading before writing is patience wearing a different hat. So is a small slice you can verify. So, especially, is writing down why you chose something when you could simply have shipped it, which is patience extended to a version of yourself who does not exist yet.

The six habits, and the one word underneath all of them.

The tools I use every day are designed to remove waiting from my work, and mostly they do. What they cannot do is make me willing to sit with a problem I do not yet understand. That willingness was the whole difference in that community in 2023, before any of us had an agent, and as far as I can tell it is the whole difference still.