Edward de Bono, in his book "Why Are We So Stupid?", argued that the main enemy of human thinking is patterns. We walk along well-worn paths in our brains, not even noticing that there are more beautiful and convenient routes nearby.
But if you dig deeper, the problem isn't that we're stupid. The problem is that we've built an entire industry where stupidity has become a business model. Today we'll examine the mechanism that turns IT into a massive machine for producing Gavvah — that same energy of suffering from ancient mythology, which feeds dark forces.
And no, "evil HRs" or efficient managers aren't to blame. Something far scarier is.
1. HR Xerox Machines and the Great Illusion of Control
Let's get one thing straight right away. Young HRs copying requirements from one job posting to another are a symptom, not a cause. They're just reflecting what's in the air. They write, for example, "Eloquent knowledge required" not because they hate architecture, but because that's what their template says. And that template was approved by those who consider themselves experts.
But the real trouble isn't even that. The real trouble is that the industry has developed a cult of measuring work by anything: fatigue, lines of code, closed tickets, moved Jira cards, hours in time trackers. A manager looks at these metrics and thinks: "Well, we have numbers — which means the process is manageable." And a developer looks at the same metrics and understands: "I'm not evaluated by how well I think, but by how convincingly I simulate activity."
And this vicious circle generates Gavvah on an industrial scale. We measure everything except the effectiveness of thinking. We count lines of code, but we don't count how many of them will be rewritten in six months. We take pride in a hundred closed tasks, but forget to ask: "Did it actually make things better?"
Edward de Bono would say: "You confuse effort with results. You can run a marathon in the wrong direction — it'll be not only hard, but pointless."
2. Dogmas vs. Tools: On the Question of ORM
Take, for example, the world of PHP development. There are two camps (among a million others):
Those who use Eloquent everywhere they possibly can.
Those who consider Eloquent the spawn of hell and swear allegiance to Doctrine or raw SQL.
But any dogma is a dead end. And de Bono taught us exactly that: don't be slaves to patterns.
Yes, Eloquent is ActiveRecord. Yes, ActiveRecord mixes business logic and data access. Yes, this can lead to problems in complex projects. But:
For simple CRUD applications, Eloquent is a great tool. It's fast, understandable, and you can build an MVP in a day with it.
For complex domain models, it's better to use Data Mapper (Doctrine) or abandon ORM altogether in favor of raw SQL and Query Builder. By the way, Doctrine is also pretty useless crap.
The important thing to understand: there are no silver bullets, and you don't have to choose between two stools (you know which ones). If you're using Eloquent in a microservice with three tables — good for you. If you're shoving it into a financial system with thousands of entities and complex relationships — you're most likely signing yourself up for pain.
But even in complex projects, you don't necessarily have to dive headfirst into Doctrine. Often, Laravel's built-in Query Builder is enough. It gives you the flexibility of SQL without the magic of Eloquent and without the overhead of a full-blown ORM.
No dogmas. Only context. Only pragmatism.
Don't ask "what's right?" — ask "what works in this context?"
3. Why Don't We Refactor? (Or "Initiative Fucks the Initiator")
Now about the main pain. You join a project. You open a controller. You see 3000 lines of code, mixed with Eloquent queries, business logic, and HTML. Your hand reaches for the keyboard to rewrite it all.
And then you remember the old saying: "Initiative fucks the initiator."
Why don't programmers refactor, but simply slap another band-aid on top? De Bono would say it's biological laziness. The brain conserves energy and chooses the most well-worn path.
But reality is harsher. It's not just laziness. It's that:
No one will ask you to refactor. Tasks like "improve architecture" are usually not a priority. You're evaluated by closed tickets, not by beautiful interfaces.
Refactoring is risky. In legacy projects, there are no tests (or they exist but fail). One wrong move — and production goes down. And the responsibility for the outage will fall on you, the initiator.
Time is money. Business doesn't want to pay for what's "invisible." Rewriting a module with clean Query objects will take a week, but might yield long-term benefits. Adding one more method through Eloquent takes 15 minutes. The choice is obvious to a manager.
In the end, the project turns into that very machine for producing Gavvah. And the worst part — you become part of it. You endure. You overcome. You look at this code and think: "Well, at least it works."
Seems like folks prefer familiar pain over unfamiliar comfort. Because familiar feels safe.
4. The Cult of Suffering as a Religion
Why do we keep putting up with this? Why don't we leave for companies where people know how to think, where architecture is valued, where Eloquent isn't used as a panacea?
The answer is simple and cynical: we're used to it.
If I didn't kill myself at work today — I must have worked poorly.
If a project requires heroic effort every day — it must be complex and important.
If I endure — I'm a professional.
This is an industrial neurosis. We confuse suffering with expertise. We're proud that we survived a project where we had to dig through someone else's crap, instead of being proud that we didn't let that crap appear in the first place.
De Bono talked about lateral thinking — the ability to go beyond patterns. But we can't go beyond the patterns because our employer, our HR, and we ourselves have made these patterns familiar. They have clear rules, clear pain, and a clear paycheck at the end of the month.
5. The Finale
And so you've read this article to the end. You recognized yourself. You recognized your project with its 500 Eloquent models, its monster controllers, its eternal N+1 query debugging.
You think: "Damn, it's true. I should quit. Find a company that uses CQRS, repositories, and clean architecture. Where people know how to think, not just copy tutorials."
Don't bother thinking that. You'll be replaced by a neural network soon anyway — and it can not only shove Eloquent everywhere, but also generate band-aids faster than you. And on weekends.
Top comments (0)