Note #18
It’s hard to articulate how low I feel the bar has become. I’ve tried to write this more than once. It appears some people working in the software industry are incapable of critical thinking, observational skills, analytical abilities, or troubleshooting.
In the valiant effort to combat imposter syndrome and gatekeeping, the programming world has taken a bad turn down a blind alley by celebrating incompetence. You don’t have to reduce an entire profession to a clueless gang of copy-pasta pirates to make new recruits feel welcome. It undermines the aspiration to improve. It reduces the work to magical thinking. It is not good.
It really should not be difficult for a software engineer with more than a few months of experience to ascertain a general sense of where an issue resides. Let what I said absorb, for a moment, a general sense of an issue.
Not a remedy or solution. Not an exact pinpoint of the problem. Just a general sense of where to start looking. Yet, time and time again, I encounter supposed “professionals” who seem utterly lost when faced with even the most basic troubleshooting scenarios.
A particularly troubling aspect of this issue centres on a subset of software engineers: those who are junior in skill, regardless of their official title. These are not the engineers who are new to the craft but the ones who have been in the industry for long enough yet still exhibit a startling lack of fundamental problem-solving abilities.
These are the engineers who, despite having the opportunities and resources to improve, continue to approach each challenge as if it were their first day on the job. They lack basic problem-solving instincts, demonstrating a level of incompetence that should be unacceptable.
A recent incident perfectly demonstrates this. I found myself dedicating several hours to meticulously observing, comparing, and ultimately eliminating all potential causes of a problem that a junior engineer on my team had been “struggling” with for over a week.
What’s more infuriating is that this engineer initially spent days in denial about the issue’s existence. Instead of productive problem-solving, they bombarded various stakeholders across the organization with a barrage of misguided questions and unfounded assertions about the problem’s origin.
To no one’s surprise — except perhaps the junior engineer’s — the root cause had absolutely nothing to do with any of the wild theories they had been peddling. This exercise in futility not only wasted valuable time but also unnecessarily burdened other team members and departments with irrelevant inquiries.
Worst of all was the complete reluctance to work with me or even listen to me as I attempted to diagnose the issue with them. Even a simple suggestion of commeting out a block of code was met with “I don’t want to do that, I have to add it back again after” - I was truly desparing by this point.
I decided it was best to simply fix the problem myself. In total this took me less time than it took trying to work through even the smallest of steps with the junior engineer. This isn’t an exageration, the commits and deploy logs speak for themselves.
It’s as if the fundamentals of logical thinking get thrown out of the window at the earliest opportunity. I’m talking about the bare minimum skills one should develop within their first year on the job, if not sooner.

Read the rest of my notes