“Your code is garbage and it makes the world a worse place to live in”

The thing about the Linus Torvalds rant is that he was probably criticizing more than just one pull request

A few months back, a long message from Linus Torvalds started circulating around developer Twitter, Reddit, YouTube, and basically every corner of the software world that enjoys public technical humiliation.

The message was directed at a Meta engineer over a Linux kernel pull request. And Linus, as usual, was not diplomatic about it.

He called parts of the code “crazy and pointless”. At one point he said

“your code is garbage and it makes the world actively a worse place to live in”

Read this full article for free here!!!

Naturally, people split into two groups.

One side thought this was unacceptable behavior from someone leading one of the most important open-source projects in history.

The other side laughed because, honestly, this is not even close to the harshest thing Linus has said publicly.

But the interesting part is not the drama itself.

The interesting part is that this whole interaction exposed several things the software industry has been quietly struggling with for years.

Not just code quality.

How developers think. How teams justify complexity. How people confuse abstraction with intelligence. And how experience changes your relationship with software entirely.

Edited by me

The weird part is that both sides are supposed to be elite

Linus Torvalds created Linux.

Then he created Git.

Which means he is personally responsible for two systems that millions of developers use every day while also secretly hating every second of it.

Linux powers huge parts of the internet. Git powers modern software collaboration. And both systems have a reputation for being brutally unforgiving when you do not understand what is happening underneath.

On the other side, the engineer involved worked at Meta.

FAANG engineers go through absurd hiring pipelines. Algorithm interviews, systems design interviews, behavioral rounds, internal performance reviews. The industry treats these companies as proof that someone belongs in the top percentage of developers.

So when people saw Linus publicly tearing apart a patch written by a Meta engineer, it created this strange reaction:

“If even these people get destroyed publicly, what chance does everyone else have?”

And honestly, that reaction says a lot about how insecure software engineering has become.

Most developers spend years feeling like they are one conversation away from being exposed as incompetent.

Then they see one of the most famous programmers alive dismantling a patch line by line, and suddenly all the imposter syndrome comes rushing back.

The helper function that started the argument

The funny thing is that the technical issue itself looked incredibly small.

It was basically a helper function that combined two 16-bit integers into a 32 bit integer using a shift and a bitwise OR.

Something like this

return ((u32)hi << 16) | lo;

Instead of leaving the operation directly in the code, the patch introduced a helper abstraction for it.

And this tiny decision triggered a surprisingly serious argument.

Because Linus was not really arguing about one helper function.

He was arguing about indirection.

And the older I get, the more I think this is one of the biggest sources of bad software.

Most abstraction is defensive programming against imaginary future problems

A lot of developers are taught that abstraction is automatically good.

University courses teach it. Clean code culture teaches it. Architects love it. Frameworks encourage it.

You end up with this idea that if something can be extracted into another layer, helper, interface, wrapper, manager, service, provider, adapter, hook, utility, or factory, then it probably should be.

But after enough years reading production code, you start noticing something uncomfortable.

A huge amount of abstraction exists purely because developers are scared of writing direct code.

Direct code feels temporary. Abstract code feels “engineered”.

Even when the abstraction makes the code objectively harder to read.

That helper function from the Linux patch is a perfect example.

The original operation was already understandable. You read it once and move on.

But once you hide it behind a helper, the reader now has to

• stop reading
• jump to another definition
• understand naming intent
• verify behavior
• return to original context

All for logic that already fit on one line.

That is cognitive overhead. And cognitive overhead accumulates faster than most developers realize.

People love talking about CPU performance. Almost nobody talks about reader performance.

The industry quietly rewards complexity

One thing I genuinely dislike about modern software culture is how often complexity gets mistaken for competence.

A developer writes simple obvious code and people think

“that’s easy.”

Another developer introduces three layers of architecture, generic abstractions, configurable pipelines, dependency injection containers, and twelve interfaces that barely do anything.

Now suddenly everyone thinks this person is a serious engineer.

Even if the final system becomes slower to understand, slower to debug, and harder to maintain.

Some teams almost romanticize indirection.

You open the codebase and a button click passes through

• a controller
• a dispatcher
• an action layer
• a middleware system
• an event emitter
• a service
• a repository
• a transformer
• a helper utility

just to update a boolean in a database.

And people defend this by saying the architecture is “scalable”.

Scalable for what exactly?

Sometimes the future complexity never arrives. Sometimes the company dies in two years. Sometimes the product gets rewritten. Sometimes the abstraction itself becomes the maintenance burden.

There is this famous quote by David Wheeler

“All problems in computer science can be solved by another level of indirection, except for the problem of too many levels of indirection.”

That quote becomes more true every year.

Clarity is harder than cleverness

What makes this topic annoying is that writing simple code is actually difficult.

Anybody can write complicated code.

Complicated code gives the illusion of sophistication. You can always justify another abstraction layer with some hypothetical future requirement.

Simple code forces you to understand the problem well enough to remove unnecessary movement.

That is harder.

And sometimes duplication is completely fine.

This is another thing that clean code discussions often distort.

Developers panic the moment they see repeated logic. Then they extract it too early into some shared utility that slowly grows into a monster nobody understands anymore.

Meanwhile the duplicated code was probably easier to maintain.

Because it was local. Because it was obvious. Because the reader did not need to mentally reconstruct an entire abstraction system to understand it.

Of course there are limits.

A 500-line function full of unrelated logic is terrible. A codebase with uncontrolled duplication also becomes chaos.

But software discussions online tend to swing between extremes.

Either

• “everything should be abstracted”

or

• “never abstract anything”

Reality is more annoying than that.

The real skill is knowing when the abstraction actually reduces mental effort instead of increasing it.

And honestly, most developers are not very good at that.

The gap between old school programmers and modern software culture

This part will probably annoy people, but I think there is a real cultural divide here.

Linus comes from an era where software development was fundamentally more technical.

Not necessarily smarter. Not magically superior humans. But the environment itself forced depth.

Computers were limited. Documentation was worse. Tooling was rough. You often had to understand memory layouts, hardware behavior, compilers, operating systems, and low-level debugging just to build useful things.

There were fewer abstractions protecting you from reality.

Now compare that to parts of modern software development.

A lot of people enter the industry through bootcamps, frontend frameworks, AI tools, no code platforms, cloud abstractions, and tutorial ecosystems that intentionally hide complexity.

Which is not automatically bad.

The problem starts when people mistake abstraction layers for understanding.

You can build entire applications today without knowing much about operating systems, networking, memory management, or even what your framework is doing underneath.

And sometimes that is fine.

But eventually reality leaks through.

Performance problems appear. Concurrency issues appear. Infrastructure costs explode. Debugging becomes impossible because nobody understands the stack anymore.

At that point, depth suddenly matters again.

And I think that is partly why old school programmers sound so impatient.

Not because they hate beginners. But because they spent decades watching software become more bloated while hardware brute-forced the inefficiency away.

Software engineering became socially optimized

Another weird thing about the industry is how much software development changed socially.

Programming used to attract a very specific type of obsessive person.

Now it is a mainstream career path.

There are perks. Remote work. High salaries. Startup culture. Personal branding. LinkedIn influencers teaching “10x engineering habits”.

And none of that automatically makes someone a bad engineer.

But it does change the culture.

A lot of people optimize for appearing competent instead of becoming competent.

You see this constantly

• resume driven development
• architecture chosen for trendiness
• unnecessary microservices
• people using technologies they barely understand because it sounds impressive
• developers speaking in abstraction jargon to hide weak fundamentals

Meanwhile the genuinely strong engineers I have met usually explain things very simply.

Not because the problems are simple. Because they understand the problems deeply enough to remove unnecessary noise.

That is different.

Linus is still wrong about some things

I do not think the answer here is

“everyone should communicate like Linus Torvalds.”

Because public humiliation absolutely pushes people away from contributing.

Especially beginners.

And open-source already struggles with contributor burnout, maintainer hostility, and communities becoming unapproachable.

Some developers thrive under harsh criticism. Others shut down completely.

Pretending tone never matters is dishonest.

At the same time, I also think modern engineering culture sometimes overcorrects so hard toward emotional comfort that technical criticism becomes difficult.

People start treating direct feedback as personal aggression.

A pull request gets rejected and suddenly the discussion becomes about feelings instead of whether the code actually improves the project.

That balance is messy.

You need standards. But you also need people willing to participate.

Linux survives partly because its standards are extremely high. But many smaller communities would collapse instantly if maintainers copied Linus word for word.

Context matters.

Most developers eventually unlearn half the rules they started with

This might be the funniest part of programming.

You spend years learning design patterns, architecture principles, abstraction strategies, SOLID rules, DRY rules, dependency inversion, layered systems, reusable components.

Then eventually, if you stay in the industry long enough, you start deleting half of it.

Not because the concepts are fake.

Because you finally understand the trade offs.

You realize

• duplication is sometimes cheaper
• abstraction can increase confusion
• flexibility has maintenance costs
• generic systems become harder to reason about
• clever code ages badly
• readability is not the same thing as elegance

And maybe this is the real point underneath the Linus rant.

Good software is not about how many concepts you can introduce.

It is about how many unnecessary concepts you can remove without breaking reality.

That sounds obvious. But most codebases do the exact opposite.

And honestly, I am not even sure the industry rewards simplicity anymore.

A lot of the time, simple code looks unimpressive until you are the person debugging the alternative two years later.