Why We Write the Error Messages Before the Happy Path
The happy path is the easy 20 percent of the work. The errors are where the real engineering lives.
Most developers write the success case first. Get the form to submit, get the API to return 200, get the data to render. It feels like progress because it is visible progress. Then, almost as an afterthought, someone goes back and adds a try/catch block and a generic "Something went wrong" message.
We do it backwards on purpose. Before we write a single line of the happy path, we sit down and list every way the operation can fail. Bad input, timeout, partial write, duplicate submission, expired token, rate limit, the third-party API being down, the third-party API returning malformed data even though it claims success. Then we write the message a real person will see for each one.
This isn't defensive programming for its own sake. Writing the error messages first forces you to actually understand the failure modes of what you're building, before you've fallen in love with the clean version of the logic. It's much harder to admit a design has five ugly edge cases after you've already written forty lines of elegant code that ignores them. Admit it on day one, while the code is still cheap to change.
There's a writing discipline hiding in this too. A good error message tells the user what happened, why, and what to do next. "Invalid input" tells them nothing. "Your card was declined by your bank, not by us — try a different card or contact your bank" tells them everything. If you can't write that message clearly, you probably don't understand the failure yet, which means you're not ready to write the code that handles it either.
The happy path, once you finally get to it, tends to write itself. All the hard decisions — what states are possible, what data can be trusted, what the user needs to know at each juncture — have already been made. What's left is just wiring together a case that, by definition, is the one thing that was never going to be the interesting part of the problem.
This is also, frankly, why complex systems are our business and not a liability. Anyone can make the demo work. The studios that last are the ones that made peace with everything the demo doesn't show.