Robust code isn't about cleverness. It's about code that behaves predictably, fails gracefully, and is easy for the next person (often future you) to understand and change.
These are the principles I keep coming back to.
Make the happy path obvious
The main flow of your function should be immediately readable. Handle errors and edge cases early with guard clauses, then let the happy path run straight through without nesting.
This:
if (!user) return null;
if (!user.isActive) return null;
return processUser(user);Is clearer than deeply nested conditionals that force the reader to track multiple branches simultaneously.
Be explicit about what can fail
If a function can fail, make that obvious in its signature. Use result types, throw specific error types, or at minimum document what exceptions can be thrown. Surprises in error paths are how production incidents happen.
Write for deletion
The best code is code you don't need to write. Before adding something, ask: is this the right place for this? Does this already exist? Can the system handle this at a different layer?
Code that gets deleted doesn't need to be maintained.
Name things for what they do, not how they work
A function named filterActiveUsersAndSortByDate tells you what it does. A function named processData tells you nothing. Good names eliminate the need for comments explaining intent.
Test the behavior, not the implementation
Tests should verify what your code does, not how it does it internally. If refactoring your code breaks tests that aren't testing user-facing behavior, your tests are too tightly coupled to implementation details.
Leave it better than you found it
The Boy Scout Rule: always leave the code a little cleaner than when you found it. Fix the obvious naming issue, remove the dead comment, extract the magic number into a constant. These small acts compound over time into a healthier codebase.
Robustness isn't a feature you add at the end — it's a discipline you practice throughout.
Continue reading