Reasons great engineers struggle to design well
Being deep in the code is a necessary rather than a sufficient condition for designing well.
Being deep in the code is a necessary rather than a sufficient condition for designing well.
Figma was built for designers. And it was built exceptionally well for that demographic. But its dominance now becomes a liability as UI work shifts both upstream and downstream.
Closing the gap between product and engineering can eliminate a large class of unforced errors.
Deciding not to solve a problem, or solving a different one, can also be a viable solution.
Implementation — writing code — is a complement to specification — writing down what the code should do. Agents are commoditizing the former, pushing up demand for the latter.
Hiring is an incomplete information game and to succeed you have to treat it as such.
Dependencies that point in the wrong direction are one of the easiest and most costly design mistakes one can make.
Books have a nice kind of survivorship bias: If something is still being read after decades or centuries, it must contain some universal truths or be useful at a fundamental level.
Trust is a key enabler of growth (and conversely, lack of trust a key inhibitor).
High performers care deeply not just about doing the work but how it’s done.
Fewer parts make for better software and better products.
Early on you need to be fast. And to do that you have to have the confidence to break with best practices.
When people ask for advice on personal investing, I’ve found they are either looking for confirmation that what they do is great (it’s usually not) or some sort of secret sauce for outperforming the market (which doesn’t exist). So people are inevitably disappointed by the answer. The best advice for personal investing is simple and boring: Diversify, invest with a long time horizon, minimize…
One thing I’ve learned over time is to read fewer books but to take the time to write summaries for the good ones. The ROI of spending 2h writing a synopsis is much higher than spending those 2h powering through the next book on your list. Reading is not about page count or speed. What matters is how it changes your thinking and what you take away form it. Optimize for comprehension, not volume.
“Just to future-proof things” is perhaps the most common argument I hear to defend questionable design decisions. Future-proofing only makes sense if you have some idea of what the future will look like and you understand what the tradeoffs are.
Code generation is arguably one of the most interesting applications of LLMs, and one of the first with real commercial use (Copilot/Codex, Codegen, etc.). If you spend time on the internet these days you’ll see people claim productivity gains ranging from 0 to 100x, selection-biased to the high end (1). Whenever you see several orders of magnitude of disagreement, it’s worth trying to understand…
People sometimes argue that you’re more likely to build a successful business as a solo founder. The argument goes that without co-founders, you get faster decision making, and since speed is one of most important advantages you have, you get a better shot at iterating yourself to success. There is an important point that’s often missed here: Having co-founders significantly lowers the probability…