10 Years Later: Software Opinions I’ve Completely Changed

Software development opinions shift with time, and the biggest change here is a growing skepticism toward “one-size-fits-all” rules about simplicity, process, and best practices. After a decade in the industry, the recurring theme is that what counts as “simple” or “complex” often can’t be judged up front. Local readability—whether a small slice of code is understandable without jumping through a maze of indirection—matters, but the boundary between helpful abstraction and needless complexity is only clear in hindsight. Iteration becomes the practical answer: build, learn, and revise rather than treat any single principle as universal.

That uncertainty shows up in debates about abstraction and typing. The speaker wrestles with the classic “keep it simple” argument, noting that adding an extra layer of indirection can make a previously messy problem easier to test and operate. A concrete example is a discussion of pseudo-random number generation (Mulberry 32) to illustrate how small, self-contained implementations can be “simple” even if they’re not immediately obvious on first encounter. The deeper point is that complexity isn’t just about code length; it’s about locality of behavior and how quickly someone can form an accurate mental model.

Typing also lands in a more nuanced place than earlier preferences. Typed languages are praised as essential on teams with mixed experience levels, especially as tooling like LSPs improves navigation and inference. At the same time, the speaker’s relationship with types has evolved: types are treated as compile-time constraints rather than literal truths about runtime memory layout. In JavaScript/TypeScript land, values and objects exist with underlying representation details, so types can feel like “assertions” rather than guarantees about the world.

The conversation then turns into a series of opinionated pushbacks against common software maxims. “Most programming should be done before a single line of code” is rejected in favor of experience-driven building—thinking helps, but over-relying on diagrams and pre-planning is seen as a trap for some teams. Front-end development gets a partial rehabilitation: the frustration is framed as partly cultural, and web components plus a return to simpler approaches (Ajax, mixing in server-generated pieces when needed) is offered as a way to rediscover enjoyment.

On engineering practices, the transcript repeatedly favors pragmatism over dogma. Code style wars, linting minutia, and “elegance” as a metric are dismissed as distractions. Code coverage is treated as not directly equivalent to code quality—useful, but not a moral score. Database choices are also approached with realism: for most people, database micro-optimizations won’t matter, and overthinking storage can distract from higher-leverage work. Serverless is viewed as promising for event-driven bursts (often paired with SQS/SNS-style patterns) but risky for debugging and operational complexity.

By the end, the through-line is less about which technology wins and more about how to decide what to do next: reduce complexity where it harms locality, accept that tradeoffs only become obvious after shipping, and keep returning to the most durable advice—write the code you need, invest in soft skills, and avoid turning any single doctrine into a religion.