Challenging assumptions and conventional wisdom in software development. These are insights from years of building, breaking, and rebuilding systems.
Break down complex problems to their fundamental truths and build up from there.
Key Questions:
Consider not just the immediate consequences, but the consequences of consequences.
Key Questions:
Instead of thinking about how to achieve success, think about how to avoid failure.
Key Questions:
Abstracting too early is more expensive than duplicating code. Wait until you have three concrete implementations before creating an abstraction.
EXAMPLE
Building a 'flexible' authentication system for one use case vs. implementing specific auth flows and abstracting after patterns emerge.
The best technology choice is the one that ships value fastest. Your users care about their problems being solved, not your architectural purity.
EXAMPLE
Choosing boring, proven technology over the latest framework when building a startup MVP.
Every layer of abstraction, every microservice, every tool adds complexity. Choose simplicity unless complexity provides clear, measurable value.
EXAMPLE
Starting with a monolith and extracting services only when you have actual scaling problems, not theoretical ones.
If your system needs extensive documentation to understand, it's probably too complex. Good design is intuitive.
EXAMPLE
RESTful APIs that follow conventions vs. custom protocols that require lengthy documentation.
"The biggest risk is not taking any risk. In a world that's changing really quickly, the only strategy that is guaranteed to fail is not taking risks."— On building and iterating