Is Programming a Bad Career Choice? Unveiling the Realities Beyond the Code

We all know someone, especially if you work in a physically demanding job, who likes to joke about how “real work” is done with your hands, not a keyboard. They might say something like, “You think you work hard? I spent my week hauling bricks in the scorching sun.” And while they might have a point about the physical exertion, let’s agree on one thing: stress and losing your mind are universally bad, regardless of the job. Welcome to the world of programming.

The Programming Team Paradox: Assembling Chaos from Brilliant Minds

Imagine starting a new job on a programming team, fresh out of school, brimming with enthusiasm and textbook-perfect coding principles. You envision clean, elegant code, efficient systems, and projects that showcase the beauty of logic and structure. Then reality hits.

You meet Sarah, the project lead for a critical banking application. Sarah introduces you to Mark, the security expert. Getting to Mark involves navigating a digital obstacle course of security protocols implemented after a minor data breach incident last year – “Never again,” as Mark declared. You then meet David, who specializes in legacy systems using COBOL. You wonder why he’s on the team for a cutting-edge mobile app project. “Oh, David’s handling the user interface,” Sarah explains. User interface in COBOL? Apparently, David made a compelling case for COBOL’s robustness and maintainability for the UI, and the team, weary of endless debates, just went along with it.

Meanwhile, Emily is obsessed with incorporating every bleeding-edge JavaScript framework she can find, regardless of project needs. The application design now resembles a patchwork quilt of experimental technologies, each requiring different integration approaches and potentially conflicting with others. Tom and Harry, senior developers, are locked in a perpetual battle over coding styles – tabs versus spaces, curly braces on the same line or next line, and the debate rages on, polluting the codebase with inconsistent formatting. The junior developers, tasked with merging their code, have resorted to brute-force methods, copy-pasting snippets and hoping for the best, leaving behind a trail of technical debt.

The project was initially conceived as a streamlined, microservices architecture. However, due to shifting requirements, unclear communication, and a general lack of architectural oversight, it has morphed into a monolithic beast with microservices awkwardly bolted on, like extra supports haphazardly added to a bridge halfway through construction. The original vision is lost, replaced by a Frankensteinian system held together by duct tape and sheer willpower. And now, you, the new recruit, are invited to contribute your innovative ideas, even though you’re still trying to decipher the existing chaotic mess.

Would you trust your bank account to an application built like this? Probably not. Yet, a variation of this organizational madness is behind much of the software we use daily – from online banking to social media platforms, and even those “secure” programs that are supposed to protect our data but sometimes…don’t.

The Universal Truth: All Code Decays

There’s a secret ritual every programmer performs occasionally, in the quiet solitude of their home. Lights dimmed, a glass of something strong in hand, perhaps some ambient music playing softly – they open that file. It’s a different file for everyone. Sometimes they wrote it, sometimes they stumbled upon it, but they knew instantly it was special, something to be saved and cherished.

They scroll through the lines, a tear forming in the corner of their eye at its sheer elegance. Variable names are descriptive and consistent. Functions are concise and focused. It performs its single, mundane task flawlessly, without unnecessary complexity or bloat. It’s code written by one person, untouched by others, a perfect little gem. It reads like poetry, written by someone who understood the craft deeply.

Every programmer starts out crafting these perfect snowflakes of code. Then reality intervenes. Deadlines loom. “We need six features implemented by next week!” Corners are cut. Code is copied and pasted with minor adjustments. Coworkers contribute, each with their own style and approach, unintentionally melting the pristine snowflakes. All these once-perfect pieces are thrown together into a single, incomprehensible mass. Someone slaps a trendy design pattern on top, like a Picasso painting hastily placed over a pile of melting snow, hoping to distract from the underlying mess. The following weeks are spent shoveling more code onto the pile, just to keep the Picasso from falling over.

The promise of standards is often touted as the solution to this code entropy. But the problem is, there are more “standards” than there are actual problems computers solve. Each standard is debated, modified, and interpreted differently by individual developers, leading to endless variations and inconsistencies. Even when everyone tries to adhere to standards, the reality is that no large codebase escapes into the wild without multiple ways of doing the same thing, often in wildly different and incompatible ways. The first few weeks at any new programming job are often spent just deciphering how things work, even if you’re fluent in all the languages, frameworks, and standards involved, because in practice, standards are more like mythical unicorns than concrete rules.

The Ever-Present Darkness: Unveiling Layers of Complexity and Horror

Imagine growing up with a peculiar closet in your bedroom. It seemed normal at first glance, but upon closer inspection, you discovered hidden depths. The right wall gave way to a small alcove, a handy shelf-like space. Then, looking up in the alcove, you noticed another opening, leading to a dark, unseen crawlspace. This abyss, devoid of light, instantly became the daytime lair of every monster you imagined kept at bay by your nightlight and stuffed animals.

Learning to program is akin to discovering this crawlspace. You master the basic tools and concepts, feeling confident. Then you peer deeper, and you uncover layers of complexity and potential pitfalls you never imagined existed. The more you learn, the more you realize how much more there is to know, and how much can go wrong.

Take the average web developer, for instance. They are proficient in numerous languages, frameworks, libraries, protocols – a vast toolkit of knowledge. Yet, they must constantly learn new technologies at an almost weekly pace. They must also diligently track updates and bug fixes in the hundreds of tools they already use, ensuring everything remains compatible and functional. They even have to remember and work around those quirky bugs they exploited for clever solutions in the past, hoping nobody “fixes” them and breaks their carefully crafted workarounds.

Just when you feel you’ve got a handle on things, everything breaks. “WTF?” is the common programmer’s lament. The debugging begins. You delve into logs, trace code execution, and eventually, you uncover the root cause: some developer, somewhere, decided that because another developer, in a moment of questionable logic, thought 1/0 should equal infinity, they would use this “infinity” shorthand in their code. Then, a more sensible developer, rightly recognizing this as idiotic, decided to make this an error in their new compiler version. But, being a bit…uncommunicative, they didn’t announce this change. Now, your perfectly functioning code throws cryptic errors, your digital snowflakes melt into digital urine, and you spend hours hunting for the phantom cat.

Your hard-earned expertise is the only thing that saves you from losing your job, allowing you to diagnose and fix the issue in “only” six hours instead of days. Another obscure detail is added to the ever-growing mountain of knowledge you must retain, simply because so much software is built upon layers of questionable decisions and undocumented changes by countless developers, some brilliant, some…less so.

And this constant fire-fighting is just within your chosen specialization – a tiny sliver of the vast ocean of computer science knowledge. No single person alive understands how every component of even a five-year-old laptop truly works. Why do tech support guides always tell you to “turn it off and on again”? Because even the experts often have no idea what’s actually wrong, and rebooting is a brute-force method to trigger the computer’s built-in self-repair mechanisms. The only reason programmers’ computers seem to work better is that they understand computers are complex, unpredictable systems prone to inexplicable behavior, and they’ve learned patience and a certain level of…acceptance of the madness.

The Internet: A Beautiful, Broken Hellscape

Remember the chaos of programming teams and the decay of code? The internet is all of that, amplified a billion times. Websites that appear deceptively simple, like online stores with just a few dynamic pages, are maintained around the clock by entire teams. The reality is, everything online is perpetually on the verge of breaking, everywhere, for everyone.

Right now, as you read this, someone at Facebook is likely staring at dashboards overflowing with error messages, desperately trying to pinpoint the cascading failure before the entire social network implodes. A team at Google is probably running on caffeine and adrenaline, three days without sleep, battling a critical outage. Somewhere else, a database administrator, surrounded by empty energy drink cans, is working through the night to restore a corrupted database, while their family wonders if they’ve vanished off the face of the earth. If these unsung heroes falter, even for a moment, parts of the digital world could grind to a halt. Most people are oblivious to the tireless work of sysadmins and operations engineers, but if they all decided to take a simultaneous lunch break, society might just descend into digital anarchy before they even reached the sandwich shop.

You can’t simply “restart” the internet. It’s a vast, intricate, and fragile network built upon a shaky foundation of unofficial protocols, “good enough for now” code, and countless “TODO: FIX THIS URGENTLY – DANGEROUS HACK” comments written years ago and long forgotten. And this precarious infrastructure is constantly under attack – from nation-state espionage to opportunistic hackers, and even bored internet trolls looking for chaos. Remember 4chan? A random meme or a coordinated prank originating from a corner of the internet could disrupt businesses, damage reputations, or even destabilize systems, just because they felt like it for an afternoon. But in the grand scheme of internet fragility, 4chan is just a minor tremor in a digital earthquake zone.

On the internet, the bar for entry is incredibly low. You can declare, “This kind of works some of the time if you use this specific technology,” and BAM! it becomes part of the internet. Anyone with a few dollars and a basic computer can throw up their own poorly written code, attach it to the existing web, and make the whole system a little bit worse. Even skilled programmers often skip learning the official specifications and standards set by committees, choosing to “just make it work.” As a result, everyone spends half their time wrestling with compatibility issues, illogical behaviors, and the constant threat of unexpected failures, desperately trying to patch things up and hoping nobody notices the cracks in the digital facade.

Here are the unwritten rules of the internet: within minutes of your first online search, your browsing history is being analyzed. Signing up for a new online service? Your personal data is now part of countless databases. Sending an email? Your address is likely being added to marketing lists you never opted into.

These things aren’t inevitable because of apathy or lack of effort to prevent them; they happen because the entire system is fundamentally broken, built on layers of imperfect code and maintained by people just trying to keep it running, one patch at a time. If you work with the internet, your job is often reduced to writing code that is “good enough” to survive for a few hours, just long enough for you to grab dinner and maybe a short nap before the next crisis hits.

Driven to the Brink: The Mental Cost of Code

Funny, right? Maybe not always. Consider this programmer exchange:

“Is that function called arrayReverse?”

“s/camel/_/”

“Cool, thanks.”

Helpful? Sort of. But if that response seems bizarre or nonsensical, congratulations, you haven’t yet succumbed to “code-speak.” You haven’t spent so much time immersed in the world of programming logic that you begin to communicate like a compiler. The human brain isn’t naturally wired for the intricate, abstract logic that programming demands. Yet, a whole profession is built around performing incredibly complex logical operations all day, every day. Navigating vast, labyrinthine systems of conditions and requirements, debugging intricate errors down to a missing semicolon – this constant mental strain takes its toll.

Programmers often develop a kind of occupational aphasia. They look at people speaking and mentally parse their sentences like code, waiting for the “semicolon” – the point where the thought is complete. They become immersed in a world of pure abstraction, where meaning is reduced to the precise manipulation of symbols. The world becomes a giant, meaningless machine where sequences of numbers go in, are processed through complex logic, and different numbers or a kitten picture (if you’re lucky) come out.

The potentially damaging effects on the programmer’s brain are even reflected in the programming languages themselves. Consider these code snippets, all performing the same simple task:

def reverse_array(arr):
  return arr[::-1]

function reverseArray(arr) {
  return arr.reverse();
}

def reverse_array(arr)
  arr.reverse
end

sub reverse_array {
  my @arr = @_;
  return reverse @arr;
}

And then there’s this example, from a programming language designed for obfuscation:

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>+++++++.>++.+++++++..+++.>+++++++.<<+++++++++++++++.>.+++.------.--------.>+.>++++++++++.

This program, according to its creator, is “two lines of code that parse two lines of embedded comments in the code to read the Mayan numbers representing the individual ASCII characters that make up the magazine title, rendered in 90-degree rotated ASCII art.” It won an award, naturally.

Is this the kind of world we want to inhabit? A world where smoking a pack a day is considered normal (“Of course he smokes, who wouldn’t in this job?”)? Eventually, many programmers reach a point where their entire reality, every relationship, every interaction, is viewed through the lens of code. They swap stories of sleep-deprived coding binges as if experiencing code-induced hallucinations is just another Tuesday. This is a profession where people might forgo human connection to spend weeks perfecting a programming language for…orangutans.

Programmers are constantly pushing their brains to perform tasks they weren’t evolutionarily designed for, in stressful, ever-changing environments they can never fully control, for ten to fifteen hours a day, often seven days a week. And yes, it’s driving many of them a little bit crazy.

So, while programming might not require lifting fifty-pound objects, it comes with its own unique set of challenges. Perhaps the trade-off isn’t physical strain for mental ease, but rather physical comfort for the constant, gnawing feeling that you’re wrestling with digital demons to keep just a small corner of the internet functioning for another day. So, Is Programming A Bad Career? It’s certainly not for the faint of heart, and understanding the less glamorous realities is crucial before diving into the world of code.