Programming Myths We Desperately Need to Retire

The real value in any craft—especially programming—comes from hands-on experience. And that kind of practical knowledge only grows through real-world work, not theory alone.

I’ve been a programming hobbyist during the JAMStack Hype, an academic during the Web3 and Crypto hype and today I am a professional software engineer working on ERP code that gets shipped every quarter that impacts millions of developers — I’ve seen it all!

If there’s one thing I’ve learned, it’s this: a lot of programming advice and “best practices” become meaningless if not taken up with a grain of salt.

The real money-making code is poorly written and riddled with uncovered bugs by generational coders who never even saw the dawn of shiny new tech that gets announced every day – and yet it works, runs businesses and pays our salaries.

Still, everywhere you go, you’ll hear things like:

• “You have to write clean code! Uncle Bob says so.”
• “TDD is a must.”
• “Why aren’t you using Rust yet?”
• “Next.js is the future of the web.”
• “PHP is dead.”
• “SQL? Tables? That’s ancient. Use Mongo!”

And yet, we see that the tech world is still ruled by legacy giants like Java, C++, PHP, using age-old paradigms like OOP.

The tech world is not going to radically change. Ever.

I am here to bust some myths that I can attest to, as I went from being a hobbyist where my shiny clean code never saw the light of day, to a professional software engineer where I get to ship thousands of lines of actual production code every month.

To be relevant, you need the latest.

No!

Let me ask you this: if 90% of websites still run on PHP—including WordPress, which powers a massive chunk of the internet—is PHP really irrelevant?

They’re still releasing new versions of PHP. It’s alive, well, and will probably outlive half the frameworks on Hacker News right now.

The cult of “new is better, old is gutter” is a total myth.

I work for an ERP software giant that rules 80% of ERP world with a product suite that was invented 4 decades ago! And the people still get employed having skills to operate such systems.

Java still runs on billions of devices.

C/C++ still powers the world’s best Kernel software out there.

So, is it really logical to believe that jumping on the newest tech will automatically make you more relevant than working on “legacy” systems? Not really.

Rust is brilliant. Next.js is great. But using new tech doesn’t make you smarter. Building something reliable, secure, and valuable does.

Most of the software that pays our salaries isn’t flashy—it’s stable. It’s safe. It works. Reliability and security matter more to businesses than squeezing out a few extra milliseconds of performance.

You should aim for maximum intellectual perfection

I remember the time around 2017 when JavaScript devs prophesied the use of only “functional” based programming, i.e. everything functions … no classes!

I saw first-hand React.js developers moving away from class-based and OOP-based programming to complete function-based programming with a nasty taste in their mouth.

Now they are doing hooks or whatever “new” architectural design pattern they might have released this year.

Here’s the problem: Real-world code is messy!

Paradigms are tools and not religions.

Developers treat paradigms like gospel and dharma—living in a kind of delulu land where perfect structure matters more than shipping features.

Don’t get me wrong—writing thoughtful, structured code is valuable. But chasing theoretical purity for its own sake? That’s time-consuming, expensive, and often unnecessary.

The best programmers are never pattern-obsessed monks.

They’re the ones who know when to follow the rules—and when to break them to get the job done.

Uncle Bob – Christ of Programming World

I get it. Clean code may have changed your life.

But it doesn’t mean every project needs to be shrined to Uncle Bob.

In the year 2024, I made a conscious effort to program with TDD, thinking I would change the face of my code and achieve 100% code coverage, aiming to be a 10x developer.

And, to be honest, doing TDD is fun! I love it.

However, anyone who has done TDD in real-world code will agree that it’s challenging.

The real-world code may have been written much before Uncle Bob had time to get his pen down. And it’s really trivial to apply TDD principles to such code.

Thinking about tests more than actual code is sometimes a big hurdle in shipping code fast. Additionally, your team should also be on board to accept such practice and train tirelessly to master it.

Similarly case can be made for “Clean Code”. I mean, who wouldn’t like to code cleanly with good variable names and abstract classes?

But to convert something which is like 12 lines of code to 3 class files and numerous helper methods, does it make practical sense?

In the simplest sense, Clean Code is something which is easily readable and debuggable and can be shipped with confidence – let’s not make it a book out of it and shove it down on innocent Developers.

Let’s optimise for performance.

As I mentioned before, the money-making code always demands reliability before performance.

Feature comes first, performance comes later.

Performance is an add-on feature, a selling point,t but not a necessity for a software.

Think about it: ATMs still run on some of the oldest financial systems out there. Are customers asking for a 0.1-second faster withdrawal? Nope. They want reliability. They want it to work—every time.

Writing a small piece of code, unless it powers FAANG level scaling, the one liner you wrote to replace the for-loop saved you 0.022 ms – are congratulations in order?

This kind of micro-optimisation is unnecessary and truly tying your hands down to think and code freely.

Optimise when you measure slowness, not when you imagine it.

Let’s optimise for scale.

“Can it scale?”

Another classic comment that you might have read or heard in upper management meeting rooms or from the guy who just finished reading a paper on distributed computing.

The startup has 12 users, your backend runs on a $5 Digital Ocean droplet, and you are designing a database schema like it’s going to support Netflix-like traffic by next Thursday.

Let’s get real.

Most products never reach the scale you’re “preparing” for.
And even if they do, you’ll have time—and budget—to refactor later.

Optimise for today’s problems and not hypothetical scenarios that might never come. Remember, the best software today was all made monolithic on a single database.

AI is coming to replace programmers

This is a new one.

And probably causing the most damage to newbie developers diaspora out there.

AI is coming for programmers, but to replace boring parts of their job!

Honestly, that’s a relief!

One of the reasons I don’t like working with frameworks is the hidden usage of APIs and contracts they set.

I don’t care about whether my overridden method should return a null, optional or boolean value, I just want to write my business logic. Yet, I’ve to do the boring job of reading the inline code doc.

And that’s where AI will help us all – to fill in the unknown and do the boring tasks.

The world is run according to human behaviour and cannot be defined by a formal scientific equation; if it were, then we would’ve predicted all the stock market crashes. AI will remain as dumb as a tin can in this regard.

All the nice cognitive tasks like product survey, architecture, etc., will still remain the realm of engineers/developers, and we will give away the mundane job of writing a for-loop to AI.

We will always need tools, better tools, and AI is just another tool for us.

Final hot take

Programming is less about being a purist and following the next best trend.

It is about solving problems with the best of the resources and common sense.

The real wisdom for any software engineer will come after shipping the code in the real world, which took me 7 years, and still learning.