There’s a moment in every developer’s career where you face a decision that seems small but defines everything: are you really going to solve this problem, or just make it look solved?
It’s Wednesday afternoon. Something needs fixing. You have two options: understand the real problem and truly solve it, or apply the quickest patch that makes the automated checks pass. Both options close the ticket. Both make the manager happy. But only one of them does something.
Most choose the second. And that’s where it all begins.
The problem nobody wants to admit
Our industry has a problem. And it’s not technical.
We’re not talking about “cloud native” architectures that are monoliths with extra steps. Not about “microservices” that share the same database. Not about tests with 80% coverage that don’t test anything useful.
We’re talking about something more fundamental: at some point, we stopped being creators and became ticket processors.
When Linus Torvalds wrote Linux, he wasn’t following a sprint. When Google’s founders built their search engine, they weren’t trying to pass a code review. They were doing something that had to exist.
When did we lose that?
The industry of outsiders
This industry was built by people who questioned everything. Who didn’t accept “that’s how things are done” as a valid answer. Who read library source code and microprocessor manuals to understand how things really worked.
We were outsiders. Misfits. The ones who thought different.
Now we have generations of developers whose methodology is:
Search on Stack Overflow (now any GPT)
Copy code without understanding it
If it works, commit
If it doesn’t work, find another snippet
And it’s not their fault. It’s the system we created. A system where:
The ticket says “do X” so you do X, even though X is the wrong solution
The sprint ends in 2 days so you take shortcuts, even though you know it’ll explode later
The automated checks pass so your work is “done,” even though it doesn’t work well
“Just following orders” works in the military. It shouldn’t work in software engineering.
The silent complicity
Here’s the uncomfortable part: we all know it.
We know when our code is mediocre. We know when we’re taking the shortcut because it’s Friday and we want to leave early. We know when that PR we approved without reading probably has issues.
We know it. And we do it anyway.
Why? Because we assume “that’s how the industry works.” Because the system rewards speed over quality. Because everyone else does it.
That’s the worst possible reason to do anything.
The developers who know their code is garbage but push it because “the deadline is tomorrow.” The tech leads who approve PRs without reading them. The managers who measure productivity in closed tickets, not solved problems.
We all pretend. And we all know it. And we keep pretending because it works. Until it doesn’t.
The real cost
It’s not just bad code. It’s an entire culture of mediocrity that perpetuates itself.
When we normalize doing the minimum effort to pass the checks, we teach juniors that’s what it means to be professional. That the goal is to close tickets, not solve problems. That the metric matters, not the outcome.
And those juniors become seniors. And they train more juniors. And the cycle continues.
The result: systems nobody understands, that cost millions to maintain, and that users hate. But hey, they were delivered “on time” and “within budget.”
The difference that matters
Doing is uncomfortable. It requires saying “no” when everyone wants to hear “yes.” It requires admitting when you don’t know something. It requires time to understand the problem before jumping to the solution. It requires questioning decisions from people more senior than you.
Pretending is comfortable. You go with the flow. You don’t make waves. You deliver what you were asked for even if it’s garbage. And when it explodes, it’s not your fault because “you just followed the spec.”
The difference between a software engineer and someone who writes code is that discomfort.
Real engineers are willing to be uncomfortable to do things right.
What doing really means
It’s not easy. If it were easy, everyone would do it.
Doing means:
Having opinions. Strong ones. Based on principles, not popularity. And being willing to defend your technical decisions with solid arguments.
Taking the time. To understand the real problem. To design the correct solution. To write code you’ll be proud to read in six months.
Saying no when necessary. To features that don’t make sense. To over-engineered architectures. To deadlines that irreparably compromise quality.
Questioning “best practices.” Especially those everyone follows without understanding why. Kubernetes isn’t the answer to everything. Microservices aren’t automatically better. Sometimes the “boring” solution is the right one.
The moment to decide
The next time you open your laptop, you’ll face a decision. A small one, maybe. A shortcut you could take. A problem you could ignore. A patch you could apply instead of fixing the root cause.
In that moment, ask yourself:
Am I doing or am I pretending?
Would I be proud to show this code to the engineers I admire?
Does this solve the problem or just hide it?
You can’t change the entire industry. But you can change your small piece of it.
You can write that clean code even though nobody’s watching. You can take the time to do it right even though the deadline is tight. You can have the courage to say “this isn’t right” when everyone else is nodding.
The software industry isn’t changed by companies. It’s changed by people. One decision at a time.
One last thing
Those who changed this industry were never the ones who blindly followed the rules.
They were the ones who said “this can be better” and had the courage to prove it.
They were the outsiders. The ones who didn’t accept “that’s how things are done.” The ones who thought for themselves.
The question is: Will you be one of them?
The difference between doing and pretending isn’t technical. It’s ethical. It’s the decision to do your job well even though nobody’s watching. Even though it’s easier not to. Even though everyone else is pretending.
That difference defines everything. It defines the quality of your code, the sustainability of your systems, and the kind of engineer you are.
Do you do, or do you pretend?
The industry needs people who do.