Shortcut Approach and Defensive Coding
I present to you two underrated programming approaches that everyone working in a team — or planning to — should know about.
I first encountered the shortcut approach a long time ago when I was just beginning to write my first tablets. Back then, my rudimentary code naturally embodied the shortcut approach: a chaotic heap of bold tricks, ambiguous decisions, and enigmatic squiggles. But in the beginning, there was only dust, and only later did it coalesce into stars. Likewise, I was going through my own formation, honing my skills. This is normal, especially for a self-taught programmer.
Over time, of course, the strategy changes. If you’re an experienced master, you know your enemy well. However, the path from novice to expert is long, filled with all kinds of temptations born of idleness, procrastination, or sheer exhaustion from work and ruthless deadlines. And when you’ve smelled gunpowder, tasted pain and disappointment — willingly or not — you come to realize that you alone must take responsibility for your scribbles. That’s when it becomes clear that the shortcut approach works against you.
Some may deliberately continue to torment themselves and test the patience of others. However, mature programmers distinguish themselves by cultivating discipline and following best practices. Not that this is something to boast about, but when you’re seasoned, it feels beneath you to write code haphazardly. It’s somewhat degrading; it disrupts harmony and violates aesthetics. And anything that violates aesthetics is the bane of a good programmer.
That said, the term “aesthetics” can be misinterpreted. An algorithm that solves a complex problem in O(n) and consists of only a few trivial lines — where nothing can be removed — is a true masterpiece of aesthetics.
So what is the shortcut approach?
- String literals are scattered throughout the code like fallen leaves on a sidewalk. It works, but it’s far more practical to collect everything into a separate component with constants, for example.
- Functions performing a thousand and one tasks. Experienced programmers prefer: one function — one task. We passionately love pure functions.
- A mix of different paradigms and styles in the same project. Classes where inspiration struck, procedures where speed was needed. Clearly, maintaining a consistent approach and style is a virtue.
- Duplication. No explanation is needed.
- Ignoring simple and well-known patterns. Your code may be better, but no one knows that.
- Using dependencies where native constructs would suffice.
- Micro-optimizations… No, that sin doesn’t belong here. But the absence of optimizations? That’s a sign of the shortcut approach.
One could continue this list, but how is all of this different from a sloppy, hastily scribbled manuscript written by a hungover youth? The difference is simple: it’s usually just plain laziness. Those who take the path of the shortcut approach know full well that they are screwing a bolt into a wall with a hammer.
Once, while reviewing a pull request from a colleague, I couldn’t help but wonder: why does his code look like the rough draft of an overworked scrawler? Naively, I asked the author how he arrived at such a solution. His response stunned me: “I follow the path of least resistance (shortcut approach).”
It was an astonishing revelation: wait, you can do that? That’s when I grasped the significance of this brilliant concept. And to this day, I try to steer clear of it.
So, what now? Should we endlessly refine our code with files of varying grit until it gleams like a gemstone, polished to perfection?
Hardly. Although, if that’s your thing — go for it. But coding isn’t carpentry. If you’re building a house, you’d better plan every detail from the foundation up. Code, however, plays by different rules. You can produce a rather unhealthy manuscript riddled with rough edges, and it will still work. (Duct tape works wonders too, after all.) Sometimes, “good enough” is exactly what the situation calls for. If a feature or component fails to meet expectations, it’s often easier and cheaper to scrap it entirely. No tears shed. But if it succeeds? Then you can polish it, knowing precisely where your efforts and resources will have the most impact.
Not everything can be measured with A/B tests, but your solution should always align with practicality. No room for personal ambitions, unresolved traumas, or the irresistible urge to show off. Just clear goals, rational actions, and well-grounded decisions.
Now, if a solution demands unmatched precision and impeccable quality, then, alas, there’s no way around it. You’ll have to roll up your sleeves and do the meticulous work. But unless you’re developing an OS kernel or writing automation software for a nuclear power plant, sterile, clinically perfect code isn’t necessarily a virtue. Generally speaking, good code doesn’t smell like formalin or antiseptic. It’s alive, breathing, evolving — imperfect, perhaps, but functional and purposeful.
Defensive Coding
I discovered the second approach much later — after moving to Sweden, switching programming languages, and diving into cloud backends. By that point, I thought nothing could surprise me anymore — not comments in Sanskrit, not loose typing, not random annotations scattered like confetti, making debugging a nightmare. I’d seen it all.
But that day left an indelible mark.
Our team was assigned to develop a module, and as the lead, I was responsible for its overall functionality. Just before deployment, driven by the belief that reassurance is never truly enough, I decided to review the code one last time. While inspecting the module’s internals, I stumbled upon something that set off all sorts of alarms. We couldn’t possibly deploy this to production. Or… could we?
Naturally, I pointed out the glaring design flaw to the author and, with a wry smile, quipped, “You didn’t notice the elephant in the room?”
To my surprise, he was fully aware. He disarmed me with an ironclad argument: “It works.”
Sure, it works — but that’s not the point. It was obvious that sooner or later, we’d have to overhaul this mess. Before I could respond, he hit me with something even more ruthless: “If we do everything perfectly, we’ll be out of a job soon.”
Unbelievable.
Like before, I laughed heartily — what a wonderful joke. Hilarious, really. But deep down, something told me there was more than just a grain of truth to it.
A year or two later, at another company 🙂, I shared this story with some colleagues. One of them promptly remarked, “In China, we call this defensive coding.”
Turns out, the practice of writing code only you can understand — sprinkling in a few sneaky flaws to ensure future “fixes” — is a well-known strategy. And with every fix, new defects are born. An endless cycle, cleverly designed to guarantee job security for years to come.
I was prepared for many things, but not this. Although, considering the legacy of communism, I probably shouldn’t have been surprised. I still struggle to understand why such tricks are necessary, but if the stars shine, it must mean someone needs them.
Imagine a job market oversaturated with candidates — hundreds vying for a single position, all equally skilled. Once an employer commits to one, they’ve unwittingly stepped into a trap no labor union could’ve engineered better. Firing a troublemaker just to hire another isn’t cost-effective. The new hire would have to unravel all the nuances, uncover hidden flaws, and possibly rewrite everything from scratch. A colossal workload. Swapping one hardened sock for another? Pointless.
Collectivism at its finest!
But here’s the thing: if you’re a good programmer, you’ll always have work. The better you do your job, the better you become. Solve one problem, move on to the next — no hesitation, just the quiet satisfaction of progress. Your code should work, and it should be written as well as truly necessary. Nothing more, nothing less.
The thing is, technologies change fast. What’s perfect today might be obsolete tomorrow. Your code may be flawless, nothing to add, nothing to remove. Then suddenly, a new built-in function appears that does the same thing — only faster, with cleaner syntax. You don’t need to try hard to make your code outdated — it’ll get there all on its own.
Who cares how brilliantly a component is written in jQuery if jQuery itself is considered a relic? Everything we take pride in today might be digital dust tomorrow.
That’s why code should be written with practicality in mind. The key is finding the balance between time and quality. Throwing something together quickly, knowing it’ll need to be redone later? Sometimes that’s fine — like for POCs or MVPs, where speed trumps longevity. But as a rule? It’s a sin.
Polishing an app to perfection, agonizing over every detail — even down to variable names — can be just as bad. Business doesn’t wait. While you’re perfecting, someone else is shipping.
A reasonable balance is everything. And no matter how tempting the shortcuts or how seductive perfectionism feels, don’t neglect the fundamentals of good design.
So, enjoy your perfectionism — just do it wisely.
Thanks for reading the article. Now you know about some of the “wonders” of engineering. If any of this sounds familiar, give it a like so I know I wasn’t the only one who’s suffered from such extravagance.
