- The Tech Lead
- Posts
- An Engineer's Deadliest Trap
Careers can feel like war.
Where you and your colleagues are comrades-in-arms.
Yet, I’ve seen a spectacle that has claimed the metaphorical lives of more professionals than I can count.
The profession? Software engineering.
The results? Varied and devastating.
The cure? Simple and effective.
But what’s the trap?
Why are people taken in?
Those are the elusive questions that this article unpacks.
Perhaps, by the end, you’ll find that you have tasted this poison. Fortunately, the remedy is readily available if you are willing to take it.
Let’s dive in.
The Blueprint
The Results
Let’s start at the end.
To understand why this spectacle is so concerning, it’s essential to see the destructive results. This process is like understanding why a tornado is so dangerous by observing the devastation in its path.
Software engineers who fall victim to this trap often exhibit these traits:
Always starting projects but never finishing them. Engineers love to build, but something stands in the way of completing a deliverable.
Problem-solving lacks a clear direction. Solutions without clarity are like rivers without water. Solutions must have clarity.
Always feeling behind. Engineers spend too much time following the internet gurus without taking action themselves.
Left at a dead-end. Projects that see the light of day often crumble because they’re built on a poor foundation.
Confusion. No progress is made in understanding good practices because the target is always moving.
These are just a few of the dangerous side effects that arise from even a small exposure to this poison.
But what makes this problem a problem at all? If the signs are so obvious, why have engineers fallen left and right to its appeal?
The Allure
Perhaps the attraction to this problem is the modern-day equivalent of what Odysseus experienced in Homer’s epic tale, The Odyssey.
Odysseus and the Sirens (1891) by John William Waterhouse
Odysseus is the noble hero of this work.
During his trip home from war, he travels past the island of Ithaca, home to the beautiful but deadly creatures known as Sirens. Here is their description:
First you will come to the Sirens who enchant all who come near them. If any one unwarily draws in too close and hears the singing of the Sirens, his wife and children will never welcome him home again, for they sit in a green field and warble him to death with the sweetness of their song.
Furthermore, Odysseus later tells the men accompanying him:
That is the Island of the Sirens. Circe warned me to steer clear of it, for the Sirens are beautiful but deadly.
They sit beside the ocean, combing their long golden hair and singing to passing sailors. But anyone who hears their song is bewitched by its sweetness, and they are drawn to that island like iron to a magnet.
Of course, the fantasy of this story is palpable, but the parallels are staggering.
Modern-day Sirens are everywhere.
They influence on social media.
They build the next-generation tools of tomorrow.
They have comfortable jobs at chic startups and in big tech.
They even have fancy software to show off to unsuspecting engineers.
But most of all, they make promises.
And engineers listen.
Lulled to sleep by the mirage of what could be.
Fortunately, the culprit is clear once it is called out.
The Trap
Enough with the generalities. Let’s give this trap a name.
It’s often called Shiny Object Syndrome. One could define it as the attraction to something that appears to fulfill a need, but often comes at a high cost, doesn’t fulfill its promise, and abandons better judgment.
The Arkenstone, as depicted in Peter Jackson’s adaptation of The Hobbit.
One may be reminded of J.R.R. Tolkien's book The Hobbit, where the protagonist, Thorin Oakenshield, faces a dragon to reclaim his homeland but becomes blinded by the allure of its most valuable treasure, The Arkenstone.
Camaraderie failed.
Better judgment failed.
…
The rest of the story is for you to read.
Nevertheless, this “dragon sickness,” as Tolkien called it, is real.
Here are some ways that engineers succumb to it:
They always chase shiny new technologies.
They abandon well-founded tools for no solid reason.
Their definition of best practice is vague or constantly changing.
Their code is littered with different ways of doing the same thing.
They look to software “influencers” who recommend based on hype.
etc. etc.
In short, engineers chase a proverbial carrot that is always just out of reach. The results are projects that never see the light of day or buggy software requiring extensive rework.
Either way, the blame falls on the developer because of poor, unsound planning.
While there is undoubtedly a place for experimentation, untested, niche, cutting-edge hype should not be used to run the core aspects of production-grade software.
A Community Divided
Let’s refer to an example I’ve seen in the Android community.
When building interfaces for Android, there is one de facto method for grabbing an element on the screen (such as a button, text field, or text element) so that you can set its properties and observe events.
It looked like this:
override fun onCreate(savedInstanceState: Bundle?) {
val submitButton: Button = findViewById(R.id.submit_button)
} Oh, how developers hated findViewById(). Perhaps justifiably so.
It was a manual process.
It was error-prone.
It felt archaic.
It was easy.
But hated.
It was something developers couldn’t resist reinventing.
But no one could agree on how to replace it.
So, within a few short years, getting a reference for on-screen elements took on several flavors. Like a buffet, take what you want:
findViewById(): The original name in town.
Butter Knife: Let a tool save you just a few letters of typing.
View Binding: Let a different tool analyze your code and do it for you.
Kotlin Synthetics: Same as view binding, but with less setup.
While I could elaborate on even more solutions to the same problem, the point still stands. The result was a divided community with no clear consensus on a “best practice.”
As it stands today, half of those solutions have been officially abandoned.
Not a stellar outcome.
Despite its flaws, the old tried and true findViewById() has stood the test of time. Most solutions tried applying shiny tech to bury that findViewById() function, creating complications and confusion.
The Cure
While I am not a doctor, I can prescribe a simple remedy that will cure this disorder known as Shiny Object Syndrome.
This is the same set of steps I go through when I decide to adopt or pass on using a tool or framework:
Age: How old is it? If it is less than a year old or hasn’t even reached version
1.0.0, I’ll pass. It’s still unstable.Hype: How long has the community been excited about it? I also give this a year. If people are still enamored by and talking about it after that long, it’s probably worth my time.
Stability: Does this tool or its community become a moving target with constantly changing goals or problem-solving techniques? A moving target is a sign of poor vision and should be avoided until their approach becomes more cemented.
The Future: Does this project have a vision for the future? If it thrives in maintenance mode, it likely won’t last.
Community Adoption: Has a large community embraced it as a mainstream tool, framework, solution, or best practice? If so, it will be well-supported, well-documented, and quick to resolve bugs.
Who builds it? If Ted builds this tool in his free time from his parents' basement, odds are it won’t last. However, if a community or company is dedicated to pushing this forward, it will likely have staying power.
Does it solve a problem I currently have? No matter how great or stable a tool might be, I leave it alone if it doesn’t solve my problem or offer any unique advantages over what I currently use.
While this cure is a multi-step question-and-answer formula, its bones are simple: avoid hype and use battle-tested tooling and techniques.
Conclusion
When gearing up to return to the world of software development, remember the unmistakable symptoms of Shiny Object Syndrome: confusion, lack of progress, unstable code, etc…
If this sounds familiar, remember the remedy: shun the hype and see what has stood the test of time.
After all, you are responsible for the quality of the software you are building. Don’t waste this opportunity to do it right by chasing some pipedream sold to you by influencers.
Engineers are thinkers, not ones who should be susceptible to the sway of people who want attention. They don’t know your project's needs —you do. So, weigh their advice with clear judgment.
Not all advice is bad.
But it should be received with a healthy amount of skepticism.