Posted 2025-03-03 • 4 min read • 594 views
10 years ago, it was a good idea to read a series of books, typically titled:
... and many more.
What has happened in practice over the next 10 years? Most of these books have caused immeasurable damage to software development, holding people back from shipping to customers. These books were revolutionary when published. But treating them as gospel? That's where we went wrong.
Algorithms? Sure, they're nice to know. But let's be real - you'll need them once in a blue moon. Most algorithms you need are simple variations tailored to your specific problem. I've never once needed a pure graph search algorithm straight from the textbook. It's always some weird mutation of it. If you specialize in a field that needs them, you'll learn them anyway. The truth? 99% of software development doesn't require complex algorithmic knowledge. Even in ML or game dev, you're rarely implementing textbook solutions. You're hacking, adapting, and bending existing approaches to fit your constraints. "Introduction to Algorithms" might teach you theory, but it won't teach you how to handle messy, real-world data. That comes from getting your hands dirty, not from memorizing pseudocode.
The Mythical Man-Month has some timeless insights - like "adding manpower to a late software project makes it later." But Brooks was writing about massive IBM projects with hundreds of developers working on systems meant to run for decades. What's dangerous is how architecture astronauts weaponize these ideas to justify endless planning and overengineering. "We need to get this right the first time," they insist, while designing elaborate systems that never ship. Meanwhile, competitors who release quickly, gather feedback, and iterate are eating their lunch. Look at the most successful tech companies today - from Amazon to Stripe. They prioritize shipping and learning over perfect architecture. They know that no amount of upfront planning beats real-world feedback.
"Clean Code" is perhaps the worst offender. It preaches rigid rules like "functions should never be more than 20 lines" and "never use comments." These absolutist positions ignore reality. Sometimes a well-commented 50-line function is far more readable than ten 5-line functions with clever names that force you to jump around the codebase like a rabbit. The obsession with making code "read like prose" often leads to over-abstraction that makes debugging and performance tuning a nightmare.
The most toxic outcome? A culture of code reviewers who reject perfectly functional code because it violates some arbitrary style rule they read about. I've watched teams waste days arguing about whether a variable name is "descriptive enough" or if a class has "too many responsibilities," while their product falls behind competitors. The "clean code" cult has created developers more concerned with how their code looks than whether it actually solves real problems for users. Thankfully, this energy now goes towards AI.
Even Test-Driven Development, once treated as the One True Way, has proven excessive in many contexts. Writing tests first can be valuable, but it can also lead to overengineering and wasted effort testing implementation details that will change tomorrow anyway. Many successful products were built with minimal testing early on, focusing instead on validating that they were building something users actually wanted. You can always add tests later when your product direction is clearer. AI changes the landscape here too, but it still won't work for everything.
This problem has only gotten worse with tech influencers. "GraphQL will solve ALL your API problems!" they proclaim. "Microservices are the only way to scale!" They're incentivized to promote novelty and complexity, not stability or pragmatism.
The ocean of bad advice is vast and distracting. But here's the good news: you don't need to know all of it to be a good developer.
Good developers ship. To ship, they think. That's the only thing that matters in the end. In the age of AI, we can greatly reduce the amount of bad advice we need to consume (especially using the latest Deep Research models) and really learn the good stuff.
@ex3ndr@ex3ndr@founders@ex3ndr