Michele Pin

Boring is THE feature.

Toyota has a principle I like: when a process detects something wrong, stop it before the defect travels further down the line. That's jidoka. My software takeaway is simple: make failure visible before someone builds more work on top of it. At 05:30 AM, with patchy WiFi, a scanner at 11% battery, and a truck already at the dock, nobody cares how impressive your abstraction is. They need to know whether the operation completed. They need the next step to be obvious. And if something breaks, we need enough evidence to find out why. Explicit state transitions. Stock changes that commit together. Retries that don't receive the same delivery twice. Logs that tell you what actually happened. There's room for clever engineering underneath. The person holding the scanner shouldn't have to experience it. Boring is THE feature.

Being the only one who understands the codebase doesn't make you irreplaceable. It makes you stuck.

An ERP should support the job.

An ERP should support the job, not become the job. The warehouse operator already knows how to receive a delivery. Your software should help them record it, check it, and move on. Some training is unavoidable. Memorising which buttons to press in which order so the system doesn't lose its mind shouldn't be part of it. Make the next action obvious. Explain what's missing. Catch mistakes before they become somebody else's problem. If users spend their day managing the tool instead of doing their work, we've given them a second job.

Five buttons nobody uses aren't flexibility. They're furniture.

A Ferrari and a box of tissues

When I joined, the warehouse software was still a demo. I worked on turning it into something that could handle receiving, moving, boxing, and shipping in real operations. The important part was keeping track of what happened to the inventory. In warehouse software, a Ferrari and a box of tissues get lost exactly the same way. A movement gets recorded halfway. A quantity changes without a matching history entry. A retry performs the same operation twice. The price changes the consequences. It doesn't change the bug. That's why I care about stock consistency, clear states, and traceable movements. The system shouldn't need to know something is expensive before it starts taking care of it.

If all a line tells you is '// do not remove', its purpose is lost. Only the fear survived.

I only controlled the WMS.

The hardest problem I tackled was boxing. The process coordinated ERP, MES, and WMS, was built around a different entity model, and lived in a file of roughly 4,000 lines. I only had access to the WMS. I couldn't redesign the rest of the suite to make my part easier. So I documented the requests, responses, and database mutations. Before changing the process, I needed to understand what it actually did. From that map, I reverse engineered the WMS flow into a separate, modular layer: small functions for core operations and writes, a DTO mapping layer, and a thin endpoint that passed data down and assembled a strongly typed response. The frontend stayed unchanged. The useful part wasn't making a large file smaller. It was making the responsibilities explicit enough to extend the process without guessing.

'Try it again' is a recovery instruction, not an explanation. A successful retry doesn't tell you what happened on the first attempt.

If five layers return the same generic error, you didn't add safety. You buried the cause.

A diet starts at the supermarket. Unnecessary complexity starts at naming. Try reading '!isNotRegistered' out loud.

Use your software like your users will. Holding a scanner in one hand is a very different design review from clicking a demo with a mouse.

A hotfix should reduce the blast radius. If you're redesigning the workflow under pressure, give it a proper name and a proper review.

Hospitality wasn't a career gap.

I spent thirteen years in hospitality: heat, angry customers, people shouting, and a service that didn't pause because somebody was having a bad day. All while staying composed, in an ironed shirt and polished shoes. That isn't a gap in my tech CV. It's where I learned to handle pressure without passing it on to everyone around me. Production incidents still matter. Staying calm means I can work through them: find what's broken, contain it, and tell people clearly what's happening. Different tools. Familiar pressure.

Great backend engineering is often invisible. The operation completes, the records agree, and nobody has to call you. That's the reward.