Published on by

Every day you read about vulnerabilities, deal with endless (and often broken) software updates, the apps you use are more and more bloated. Instead of doing that one task you originally needed them for and doing that well they've become jack of all trades, master of none.

So how did we, the software engineers, get there?

  1. Top-down management
  2. High-level abstraction
  3. Lack of debugging
  4. Exceptionalism and logging
  5. Agile, scrum, and endless meetings

Top-down management

We have allowed business-driven feature creep and unrealistic deadlines to override sound engineering principles. We have all but turned into yes-men (or should I say yes-mercs), agreeing to any and all managerial decisions, even those that make no sense for the product, or are actively harmful to the customers. Most of us have suppressed what little ethics we had (if any) and are just following orders. We went from resigning in protest in 2018, over signing letters of protest in 2024, to crickets in 2025. Instead of curiousity and rebelliousness there's complacency and blind obedience. Instead of creative drivers who shape the future for the betterment of our fellow humans we have turned into just another cog in the money-making machine.

High-level abstractions

We got spoiled with tools and languages that hide the complexity and domain-specific knowledge needed to write stable and performant code. I've personally faced juniors who didn't know the difference between bitwise and arithmetic operators, let alone OS fundamentals, nor anything from hardware realm.

Some of those might not be necessary learning for mostly web-driven front-end stuff, but not knowing number systems and boolean algebra? Who's going to maintain all the existing C/C++ code after current generation dies off? Will they reimplement it all in Javascript? As Marvin the janitor would put it so succinctly in Die Hard 2: "I'll be damned if I'm gonna clean up this mess."

Lack of debugging

Debugging truly seems to be the lost art nowadays. I remember when I started working on an embedded application for Verifone PoS terminals back in 2009. I was shocked that nobody in the company could tell me how to setup a debugger and run the code step by step. To my astonished question "But... how do you debug?" I got "We use logs".

In practice that meant writing the code with tracing statements strewn all over it, compiling, deploying, running, observing logs, making a change, compiling, deploying, running, observing logs, ... an endless and pointless iterative loop which took way more time and effort than it would if the code was run under debugger to directly observe the behavior.

Same goes for most of today's code, and most juniors wouldn't know what to do in debugger if their life depended on it.

Exceptionalism and logging

What is an exception? Historically, exceptions were hardware faults (invalid or unaligned memory access, division by zero, etc) raised by the CPU which would almost never occur in well-written code hence the name.

Starting with C++, C#, Java, Python, ... exceptions have morphed into anything but, and today they are (ab)used as a default (and poorly performing!) replacement for proper error handling.

Same goes with logging overuse, what was once a tool for inspecting state of critical variables at runtime has turned into a deluge of irrelevant noise you have to sift through when you have an actual problem to solve. I've been asked to write code with full logging coverage from the beginning which I flat out refused.

Like I, you should write code, debug code, and add logging where it makes sense. Doing it any other way just adds noise, increasing the risk that your log output gets out of sync with underlying code and becomes misleading instead of just useless.

Agile, scrum, and endless meetings

We have been tricked through endless repetition by CEO wannabe-influencers on LinkedIn into accepting the "modern" move fast and break things approach to software development. Definition of minimum viable product has eroded over time and today it encompasses things that barely work.

We shifted from engineering, design-driven, development to mocking what the customer wants, akin to throwing shit at wall and seeing whether something sticks instead of designing APIs and interfaces. We were thus forced into "defensive" programming because we can't rely on usage contracts anymore as they usually don't exist, and if they do, they are seldom honored.

We have been pulled into endless meetings where we rarely have any purpose but our presence is mandatory which further diminishes the time we can dedicate to writing quality code or even just staying on top of current technology trends.

So now that we know what's wrong with the state of software engineering, what are we going to do about it? It is tempting to embrace the Joshua's/WOPR "A STRANGE GAME. THE ONLY WINNING MOVE IS NOT TO PLAY." mindset, but we can, and should, fight back.