Blog
Part 1 of ?? (TBD!) in the series: Engineering, product, AI, and staying relevant until you (maybe, if ever) retire.
Inflationary dilution of an important word
I’m getting increasingly tired of hearing almost everyone call themselves an “engineer” in the world of software.
It feels like the term has been completely diluted, stripped of its weight and handed out like candy by organizations, or attributed by some people to themselves, in order to elevate their profile and their CV. Which is fine, albeit in a most cynical “Realpolitik” sense! “Hate the game and not the player”… and since the game of corporate hiring is played with inflated CVs passing through the hands of People Procurement Departments (also known as “HR”, one of the most useless business functions, a true “bullshit job” if I ever saw one), I totally get it. You do what you have to do to earn a better living; caveat emptor on behalf of the hiring manager.
But still, that’s how junior developers who can write a React component or glue together a few REST APIs have the gall to introduce themselves as a “software engineer”, because that was the job title on a job posting written and managed by people who themselves probably don’t know what engineering is, either. And so the farcical parade of corporate job-title inflation and misplaced expectations continues.
You should know that actual engineers, both those formally trained and those who spent years doing actual engineering to “earn” the self-ascribed title, all roll our eyes derisively at these phenomena, and for many good reasons. Sorry, not sorry! It’s an exclusive club, and not everyone joins it just by calling themselves an engineer.
Real engineering is something specific and demanding. Writing code can be demanding, but is not engineering, just like drafting a CAD model (whether 2D or 3D) or running an FEA/CFD simulation is not necessarily engineering by itself. These activities can be part of an engineering endeavor, but engineering by themselves they are not.
What it is, and what it isn’t
Engineering is about understanding trade-offs, thinking through the system architecture and design, considering components and their interactions (and failure modes), constraints, requirements, and long-term implications, including non-functional requirements, such as maintainability, extensibility, security, etc. It doesn’t matter if you’re doing chemical engineering, mechanical, electrical, electronic, or proper software engineering. Actual engineering requires a certain set of skills and a certain mindset. Granted, you might have acquired those skills and the mindset either through formal training or by exposing yourself professionally again and again to situations that require such skills, in order to navigate complexity and ambiguity. And let’s also not discount that just like not everyone is a good fit for becoming a doctor, a diplomat or a dancer, so is not everyone a good fit character- and capability-wise for “doing engineering” competently. And that’s OK. People are different; isn’t that also part of diversity? Horses for courses, and all that. Common sense. No value judgement.
Anyway. If you don’t bring those elements to the fore, and especially if you don’t actually understand (or, God forbid, don’t care to understand) the system you’re working on, you are not engaging in engineering, but in fumbling; in trial-and-error until something kinda works. Maybe it works for now, maybe it works under certain conditions that you don’t fully grasp or cannot fully grasp. Maybe it never had a chance of working, because you didn’t actually spend time and expend the mental effort to grasp the intricacies and interfaces of the system you are in charge of engineering. If that is the case, then engineering this ain’t. Call it anything but “engineering”.
Engineering, however, is not just about making something work to an unknowingly limited extent, or at all, but about understanding why something will work, how something could fail, which aspects of the system work synergistically and especially against each other, and navigating this tricky landscape so that what you deliver does the things it’s supposed to do, and does them well. You need to make conscious trade-offs between system aspects. Sometimes you might need to compromise between some other aspects, usually aspects that are related to organizational aspects, project schedules or the available budget. And, ideally rarely, when backed into a corner by situations beyond your control (or by situations of your own making…) you might need to sacrifice aspects A and B in favor of the (less valuable) aspects C and D. Tough luck, but it happens, especially without actual engineering in play.
All this requires reasoning about the entire system to the extent that this is possible given the resources allotted to the endeavor, the information available on which you base decisions (even though you will never know everything at all or to the degree you’d like), the skills that you or others working on the system possess, and other factors. Understanding the factors that dominate how the system behaves but also understanding the factors that influence (for better or for worse) the environment in which the engineering endeavor operates are engineering. You need to be able to reason about the entire system, not just a little slice of it. Except, of course, if that little slice is a smaller, well-delineated part of the overall system, and your own task is then effectively an engineering sub-endeavor, ideally because your own engineering skills and mindset, character and personality (you should be resilient and persistent, perhaps even stubborn as a mule in the face of not understanding something), and domain expertise are a good match for the challenge.
$ADJECTIVE $DOMAIN Engineer
Yet, unfortunately, the corporate world has kept inflating the term, just like it has done to countless job descriptors in the past. Just like in a large multinational corporation I used to work in everyone was a “Global Something Manager $DOMAIN”, nowadays seemingly everyone is a Senior/Junior/Something Engineer.
Interestingly, this was never the case at companies I used to work in that did actual, formal engineering, e.g. electronics or mechanical engineering. This inflation seems to fester in the world of software. Only there can anyone slap the “engineer” label on themselves without formal training (fine, as I said, you might have grown to become an engineer not by training, but through practice), and especially without actually ever displaying any of the aforementioned qualities that are a prerequisite for engineering instead of fumbling through an endeavor.
In the software world, “engineer” has become a fancy title for “person who codes”. This is a double-edged sword: not only does it devalue the meaning of the word, but it carries the hidden implication that a person who codes, even if competently, with or without the assistance of LLMs/agents, must seemingly elevate their professional identity through the use of a word that doesn’t necessarily describe them, as if “person who codes” / “programmer” / “developer” are insufficient to describe what the person actually does.
Why are people insecure about being “mere” programmers?
Programming is cool, but it’s just the implementation part
I’ve worked on hardware products where we argued for weeks about whether the dipole of antenna should be X or Y mm and what this does to housing ergonomics and radar performance, whether to use one battery chemistry over another, or how a particular form factor would affect the entire product. Those were real engineering discussions, full of trade-offs, physics, real-world constraints, and difficult conversations with the RF guy, the mechanical team, and the business side. Day in and day out, learning from experiments, simulations, new requirements coming in from the market, constraints imposed by technologies that were available and affordable at the time, and a myriad other factors that all of us had to understand well enough to make sure that the outcome of the engineering endeavor, i.e. a product or process, was not going to be an exercise in “winging it”. That was engineering.
Tapping away at a keyboard, following a tutorial, copying and pasting from StackOverflow (earlier) or Grok/ChatGPT/what-have-you or handing over the reins to an “agent” to code something is not engineering. If you write the code yourself or contribute the largest part of the code, it’s programming. If you don’t, it’s orchestrating. Regardless of how much code you write yourself, it can be valuable work, but it’s not engineering in the proper sense.
Gate-keeping is totally OK
Am I gate-keeping? Sure I am. We gate-keep all kinds of things in our world, and for good reason. Or would you like the static viability of the apartment building you live in to have been “vibe-coded” by an “orchestrator” civil engineer?
We need to gate-keep words too, because words matter. They are our human-to-human “API”, if you are willing to indulge in nerdy similes. Nowadays, words are even our preferred human-to-machine “API”. An API in which words mean different things to the server and the consumer of the API would be a pretty shitty API, wouldn’t it?
When we dilute terms like “engineer” we also dilute the standards and expectations that come with them. We end up with people who think shipping something that “works on my machine” is sufficient. We get systems that are fragile, full of technical debt, and unable to survive real-world conditions or under conditions that were never considered, because (surprise surprise!) no time was spent on risk analysis, scenario/“what if?” planning, system architecture, etc.
Corporate-world BS with real-world consequences
I’ve spent years doing both hardware and software work that required and requires actual engineering discipline, regardless if it was an engineering endeavor I engaged in as an employee, one that I had to eat the consequences of on my own, or others had to live with consequences when I was not anymore around. The difference between the software and the non-software world is night and day. In the non-software actual-engineering world we accept that perfect knowledge is practically never available (otherwise there is no product or technology innovation potential to begin with), yet we do the legwork to figure out at least the drivers of each aspect of a system, the interactions between them (see also the unsexy but immensely valuable Quality Function Deployment method), and to figure out sensible, affordable trade-offs with minimal compromises and ideally zero sacrifices (e.g., of a key value proposition of the product system), in order to deliver something that has economic value not just today, but for years to come.
In the software world, charlatans sell you this mindset as “Agile”, but then bring in ritualistic kindergarten-like practices like task estimation with story points or T-shirt sizes, daily standups, and other Kabuki-theater nonsense that makes CxOs claim a successful “Agile transformation.
In the software world, seemingly everything nowadays is a matter of “shipping fast”. More features, more code (a bigger attack surface for bugs and vulnerabilities too), as long as it’s cheaper and faster to churn out all that, even if this serves nobody who has to pay for the product, especially when its pricing has been artificially inflated by eternally-inflated developer salaries, and more recently by thousands of dollars per developer per month for LLM tokens.
There are many factors that feed into this difference between the two worlds. Some of those are explored in “The exceptionalism of software is unwarranted” , an article that posits that software development is in fact different to other types of development, but not that different as to warrant sloppiness or a lack of engineering, in most important cases. Others have to do with “software eating the world”, with ROI-chasing diverting capital into more frothy investments, such as what led to the dot-com crash, or to the SaaS craze of the post-GFC world when everyone was making Web 2.0 apps to “become the next Facebook”, or to the iPhone craze that led to mobile-app development (and Apple’s growth through App Store commissions) booming (and eventually, busting), etc.
Not everything is worth the cost of engineering; but some things are
But let’s come back to the dilution of the “engineer” attribute, because it isn’t harmless. Not everything deserves to be engineered. Your quick-and-dirty conceptual/mock prototype doesn’t need to be engineered. Neither does an MVP need to be engineered, since you are going to get punched in the face by brutal feedback or (usually) total indifference when you show it to those who you think will be knocking down your door to try it out.
Many things though deserve and many more things need to be engineered. Properly engineered, especially if what you’re developing is the vehicle to a mid-to-long-term viable business and not just to an exit scenario in which someone else takes the hot potato off your hands before the jig is up (which is another way of saying “timing the market” or “speculation”).
For those things that deserve and need to be engineered, staffing a project/team/department/endeavor/business with self-described “engineers” who aren’t is a recipe for failure or disaster (depending on who’s paying for the consequences of the lack of deserved/required engineering effort). You cannot expect engineering from those who are not up for it, no matter whether they or your company’s “job grade” system adds the “Engineering” suffix or the “Senior” prefix to their job title.
Such misleading labels will not bring you what the product/endeavor needs, just like you cannot label me a “Scientist” and expect me to perform in a scientific team.
Misleading with labels (mis-)leads to poor system design, unrealistic expectations, long-term risk and eventually, products and companies that struggle when things get hard. And things will get hard, even in software where you don’t have to deal with lead times for prototypes, physical-goods recalls, (too much) regulatory compliance (in most business domains). You will (hopefully) one day learn that the non-engineered “software architecture” you slapped together (or had Claude Code sloppily build through an accumulation of unexpressed assumptions) will indeed crumble under load due to a sudden influx of users, or even one stray npm install.
So don’t mislead with labels, and don’t mislead yourself. Call yourself a programmer if that’s what you do. There’s zero shame in it. But let’s stop pretending that every person who writes code is an engineer. Real engineering requires depth, systems thinking, and accountability for the thorough analysis of the system, the trade-offs that dominate its real-world performance, and the consequences for making mistakes due to shoddy work by either engineers or “engineers” (in name only).
A thirst for understanding is what you need
Want to earn the “engineer” label? Cool. Either educate yourself formally as an engineer in any domain except software (where things are not formalized). You will find that the skills transfer superbly to software engineering, especially if you educate yourself in systems engineering. Or (totally fine, too!) spend time around people who do actual engineering, whether software or non-software, and participate in the aforementioned activities that require acquiring and bringing to the fore engineering skills, methods, and the mindset of craving the understanding of a system, even if just to placate your paranoia about things going awry and/or your perfectionist, deep-seated need for making decisions with risk approaching zero.
Want to earn the title without formal engineering studies? Self-study Systems Engineering, work alongside real engineers, and develop the craving (if you have it) to truly understand the systems you touch. Then you’ll be on the right path to make the fancy job title less of an inflationary bureaucratic descriptor that only has value within the company that employs and the next ones that will employ you.
