Engineering Habits
11 parts, in reading order.
Engineering Habits, Part 1: Grep Every Caller
I fixed a till button that put pumps in the wrong payment mode, then found the same wrong mapping in a legacy path, guarded by a skipped test that asserted the bug. The fix was one argument. The habit that found its twin is the post.
Engineering Habits, Part 2: The Reviewer Deleted My Fix
My server-side fix for a broken 'revert to default' button worked. A reviewer asked one question, showed me a smaller client-side fix, and I deleted about 25 lines of my own code. Then I did the same thing to myself on a timer bug, three attempts too late.
Engineering Habits, Part 3: Deny by Default, Fail at Start-Up
Adding a role check is easy. Adding one without breaking the clients that already relied on open access is the job. Restrict at class level, opt in the few safe reads, test allow and deny for each role, and refuse to start if a secret is missing.
Engineering Habits, Part 4: The Call You Can't Deny
The obvious way to add a restricted mode to an admin UI would have denied the very call that tells the UI it's restricted. Before you lock a client down, check it can still ask the question that tells it to lock down.
Engineering Habits, Part 5: Break the Real Build
QA needed to reproduce a failed pump authorisation, and the existing answer was a special build hard-coded to fail. A special build only proves the special build. A default-off switch in the shipping binary, with a narrow trigger and a loud log line, tests the thing customers actually run.
Engineering Habits, Part 6: When the Error Message Was Telling the Truth
A mobile fuel app kept failing with 'pump in use', across a lot of sites, and it was reported as our bug. Every trace I followed said the pump really was in use. The error was correct, the count was inflated by retries, and proving 'no bug' still didn't fix anything for the customer.
Engineering Habits, Part 7: Write the Options Down
When a fix has more than one reasonable shape, I write the options and their risks down before I choose. It makes the choice checkable, speeds up review and shows why the smallest safe fix won. The list I wrote for a start-up ordering bug, and what it changed.
Engineering Habits, Part 8: 401 or 403? Say Which Problem It Is
'Who are you?' and 'you can't do that' need different fixes, so they deserve different status codes. An internal admin API returned 401 for both. The post covers why I left it that way at the time and wrote both options down, and how to change it without breaking callers that only check for 401.
Engineering Habits, Part 9: Measure the Test Gap Before You Promise
'Bring the tests into line' can be a tidy-up or a project, and you only know which after you count. A follow-up ticket read like a tidy-up. The post covers what I found when I looked, how I split it into two pull requests, and the linked 'outstanding points' that turned out to be about something else.
Engineering Habits, Part 10: Hiding a Tab Isn't Access Control
A hidden nav item is a convenience. The route guard and the server are the security. The route guard redirects restricted routes and the server does the real enforcement, with tests that assert a control is absent by name. That is how an admin panel with a read-only mode for junior staff should be built.
Engineering Habits, Part 11: The Secret That Hasn't Settled
Where secrets live is a decision you may revisit, and that's fine if each step is safe on its own. The keys for a service that runs on customers' own networks moved from constants in source, to seeded and locked configuration with fail-fast start-up. The post covers what stayed true through each step.