> Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment.
That's correct. I've heard people describe Go as wanting you to code the sad path first, and then backfill the happy stuff (the business logic) once the error handling is complete. This tracks to my experience. That is, when I program that way, I feel like I'm in sync with the language.
Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment.
I’ll have to think about that a bit. Trivial cases don’t matter. Complex cases are more nuanced.
This is really insightful, thank you.