10 regrets of experienced programmers

Experienced programmers, asked what they’d regret most, point to a common theme: the biggest costs in software careers come from avoidable trade-offs—too much complexity, too little follow-through, and priorities that distort what “real” progress looks like. The most urgent regret is writing more code than necessary. Code isn’t treated as an asset; it becomes a long-term liability that must be maintained, tested, and kept from breaking production. Beginners tend to add abstractions and features as they learn, but seasoned developers often circle back to “less is more,” where total lines of code drop while productivity rises. Even so, the regret isn’t simply about brevity—it’s about minimizing the time others spend wrestling with messy systems. Complexity can feel like genius in the moment, but it often taxes readability, performance, maintainability, testability, and reusability over time.

The second major regret is starting too late. Learning is portrayed as biologically easier when younger, with employers allegedly showing bias toward younger developers because their skills are more “malleable.” The message is blunt: the best time to learn is as early as possible, but the second-best time is now. That same urgency shows up in project management: many programmers regret not finishing more work. Software timelines routinely expand—captured through the “9090 rule,” where being 90% done still leaves 90% remaining. Solo developers can also get distracted, abandoning half-built projects to start new ones, leaving behind directories of abandoned attempts.

Other regrets target career strategy and fundamentals. Some wish they’d pursued a computer science degree less for learning and more for networking and internships, while warning that degrees can become traps when they don’t translate into employable skills. Others look back at missed financial bets—most notably buying Bitcoin early—while using those stories to highlight how easily opportunities are lost. A more technical regret is not learning lower-level languages like C. Even if a career can be built with high-level tools such as Python and JavaScript, the argument is that C provides a foundation that improves everything built on top of it.

There’s also a nuanced stance on JavaScript: using it across the stack can speed development and iteration, even if it’s not the most CPU-efficient or memory-safe option on servers. In contrast, another regret is “grinding” algorithm practice without connecting it to real outcomes—like spending hours on LeetCode brute-force solutions when the real payoff might be teaching others or building practical skills.

Finally, the regrets broaden beyond code. Many wish they’d prioritized health earlier because long hours at a desk, combined with stress and poor diet, can raise serious long-term risks. And the deepest existential regret is learning to code at all—when work starts to feel like vaporware tied to KPIs rather than meaningful impact. The closing note contrasts that fear with a small, tangible win: fixing a production bug, even if it created a few more, as proof that software work can still be real when it improves something that matters.