Electrical Engineer who can write messy but functional code in C and Python, but mainly deals with analog circuits at work.
Software has a magical property that other engineering disciplines do not: The engineering environment is ideal and fundamentally perfect. It's like building electronic circuits but only in the simulator that uses all idealized parts. And you get the extremely rapid prototyping and scaling that comes with that. (A "single line of code" equivalent error in a production analog circuit can take months to fix and years to distribute)
In a way it feels "unfair" because the fuckery of mother nature and immovable boundaries of physics is largely (and normally completely) cut out of the equation. Imagine having to write code where every variable is a fuzzy range as opposed to a fixed value, it would put a huge clamp on designs.
However,
The intellectual savings from not having to deal with non-linearities and errant physical effects, is largely just shifted into increased overall complexity that all exists in a different realm. So maximum logical thinking and intellect is still demanded.
I think the divide really comes from the difference in space in which the "engineering" is happening. Conventional engineers are dealing directly with nature trying it's best to constantly break your design. And I think there is a degree of comradery that comes with that. Software guys, free form those chains and working in a parallel universe of perfect logic, instead are pushed to the absolute limits of complexity.
> Software has a magical property that other engineering disciplines do not: The engineering environment is ideal and fundamentally perfect. It's like building electronic circuits but only in the simulator that uses all idealized parts.
I get where you are coming from, but man it is very apparent that you haven't had to write device drivers. Hardware is BUGGY and the OS is full of workarounds to make things work well enough most of the time.
EDIT: And now that I think about it, the same is true of any piece of software that interacts with other software components. Your own code ends up full of workarounds to address problems in your external dependencies.
> Software guys, free form those chains and working in a parallel universe of perfect logic, instead are pushed to the absolute limits of complexity
That resonates. You could say that in other branches of engineering complexity is a consequence of natural entropy, whereas in software complexity is largely self-inflicted. Did I get it right?
I'd say with classic engineering, mother nature wrote the OS, so across all the disciplines there is a common shared experience of dealing with Reality OS. Which is eminently present in every step of work.
In SWE, we figured out how to build a VM in Reality OS that runs our own custom environment. All the headache and complexity is there, but it is of a different lineage.
I think computer scientists work in a “parallel universe of perfect logic” but sadly I strongly disagree that the vast majority of software engineers get that privilege.
IMO, contemporary SWE involves a lot of black box treatment, learning complex systems on the fly, and untested large code bases. All of that leads to similar dynamics as more direct physical dynamics in other engineering disciplines do: unexplained behavior, doing things by spec, debugging by process of elimination, etc.
And that’s before mentioning the direct problem of device and network issues; I understand this to be a certainty for those doing things on a global scale.
While it might seem that software runs in an idealized domain free of conventional physics, that's only because operating systems and processors try to provide a "padded cell" in which software can live. But it's a leaky abstraction; for instance, the time it takes to read one byte of memory can vary depending on whether the processor has it on the L1 cache, or has to read it from the DRAM, and even there, it might depend on whether the memory row is open or not, it might get delayed by the DRAM refresh cycle, and so on, and we're not even talking about the case where it's been paged out and the operating system has to read the memory page from the disk. There's a lot of "non-linearities and errant physical effects" there, and as a sibling comment mentioned, the speed of light is still very relevant.
And that's before considering mindfuckery like Spectre and its friends, in which you can, through a careful observation of some timings, watch the effect of an operation which didn't happen, won't happen, can't happen, and sometimes from code which doesn't even exist.
One of the things I think hardware should adopt from software is modular debuggability of system components. I'm a software guy building a display board with a battery management system. I'm building the bms as a pluggable component on the display to make my development easier and the end unit more iterable.
Every wall powered device on the North American grid is connected to the same circuit. And even within circuit design, it's all designed piecemeal with inputs and outputs.
In many ways SWE is like real engineering but with some major differences. I could use the classic example "we aren't building bridges" but that's too simplistic. I think the biggest difference between us and the rest of engineering is the "method of delivery" and how that affects the other processes.
What I mean is imagine if a car company found a defect with their cars, they would have to issue a recall and update their vehicles, a long an expensive process. The key difference is with SWE, we can just push an update and have the thing fixed, there are many possible scenarios here but overall even if you had to push a patch to customers that are running in an air-gapped env, even that would be easier than a traditional recall in engineering. For me this single fact changes the entire dynamic of SWE compared to traditional engineering.
In traditional engineering you can't simply put up a bridge that would support 500 cars and say "oh we'll update it to support 5000 cars down the road", but you can totally do that with SWE application that can only support X number of users at the start but plans to scale up to support more. This thinking of "we can address this down the road" affects practically every decision in SWE compared to traditional engineering outside of specific cases.
Every engineer deals with constraints and finds ways around those constraints. SWE has a set of constrains that is very very different from virtually all other engineering disciplines, and for that reason you get the constant question of whether SWE is even real engineering.
What makes “real engineering” the correct paradigm (and legal framework) for a profession isn’t the method of delivery, it’s the failure mode and how that aligns with cultural values.
In the simplest example: if you ship a car with a bug in its RTOS, people could die. It doesn't matter how easy it is to update. As a culture we’re generally opposed to preventable deaths. In other professions we have set up a regime of legal liability and professional licensing as guardrails and incentives to prevent that failure mode. We should treat software engineering the same, at a minimum in applications where lives are at stake.
Other non-lethal failure modes should also be considered (Experian, anyone?). We may have culturally decided by default or accident that data leaks are no big deal. If we actually did think they were important, it would make sense to have licensing and liability frameworks to reflect that.
The fact that software has fewer practical constraints than building structures is an excuse masquerading as a reason for not having even the most basic controls in place.
That doesn’t make sense to me. If a software bug can cause a death, like in a car, then the failure modes and legal consequences are the same as traditional engineering. What’s the difference?
> then the failure modes and legal consequences are the same as traditional engineering
Exactly my point! Because the failure mode is the same we should have the same guardrails in place for both.
The design and construction of a bridge is independently inspected and verified. The design and implementation of software in a car is not independently inspected and verified. I argue that because the failure modes are the same, we should change the latter to match the former.
The design of a bridge must carry the signature of an individual licensed engineer who is personally liable. The design of software in a car is functionally anonymous. I argue that because the failure modes are the same, we should change the latter to match the former.
The design of software in a car is held to similar standards as the hardware in a car, as one of the people who sign off on it (and not a PE). The software often is independently inspected and verified as part of homologation.
Adding a scapegoat engineer wouldn't do anything meaningful except ruin one dude's career when something happens because
1) automotive manufacturers don't fall under engineering firm regulations
2) one person cannot have meaningful technical oversight over the scope of a vehicle, and
3) there is no software PE accreditation process in the US.
They've been true for over a century at this point though. Since I assume you aren't complaining about every vehicle ever produced not being signed by PEs, what is it about software that you think it should require a PE stamp when hardware should not?
> They've been true for over a century at this point though.
The duration of the status quo doesn’t feel at all relevant to my argument.
> what is it about software that you think it should require a PE stamp when hardware should not?
Any profession of system design whose failure mode is “people die” would better serve a culture that abhors preventable deaths if governed by the same licensure, liability, professional ethics and independent verification used by electrical and structural engineering. I don’t make any distinction between hardware and software, but this article happens to be about software, so that’s what we’re discussing.
> If a software bug can cause a death, like in a car, then the failure modes and legal consequences are the same as traditional engineering.
They are not even remotely. A business may have to pay out a settlement, and failure may attract the interest of regulators (say, the NTSB if it is a car or airplane or the FDA if it's a medical device), but nobody is going to lose their license to practice "software engineering" nor face professional sanction even if there is professional malpractice.
The fact that nobody has gone to jail or had their ability to work in software revoked as a consequence of the 737 Max incident is proof that they are not even remotely similar. Had an aerospace engineer certified a physical part the same way that the software engineers certified that software they most certainly would have been on the hook individually for massive damages and would never work in industry again - both because they'd have been named and shamed in the investigation and because likely their license to practice engineering would have been revoked.
The difference is that as a civil engineer, when I put my stamp on something and become Engineer of Record, I am personally liable for defects in my engineering, in perpetuity, no matter who I go on to work for later.
I can lose my personal wealth, freedom, license and livelihood if it's particularly egregious.
>>you can't simply put up a bridge that would support 500 cars and say "oh we'll update it to support 5000 cars down the road"
In that case the requirement changed, it might require some extra support or upgrades to the bridge, if not we have to build the bridge all over again.
Similar in SWE, the requirement can change, if you planned a small MYSQL database to hold 2 Stores transactions and then "oh well we will need to support 2000 Stores Transactions" you might try upgrade the server or start from zero on a AWS cloud instance that keep up.
In SWE you still have the big decisions than can impact people and budget, a bridge can collapse, so the autopilot software can make the car crash
As a counter to your first example, I once had software deployed in some U.S. embassies in some not so great parts of the world. The machines the software lived on were air-gapped and on computers built specifically not to allow external connections (different keyboard/mouse connectors, no USB, no CD).
To deploy an update required a human, some long flights, and replacement parts. While it's not common, I think it would still break that definition of what is/isn't an engineer.
For me, it comes down to the level of rigor required. I think developing avionics software is probably engineering whereas building an phone app to view/share pictures of cats likely isn't.
I think that there's probably a difference between "attacking a problem to achieve progress in the utility of something" and just slapping together an app that brings literally nothing new to the table.
Making a birdhouse isn't engineering, creating a new type of dwelling for birds might be.
Isn't every company doing all they can to force their other engineering into software delivery paradigm?
The whole "seat warmers as a service" pops to mind
That's the whole idea of "Digital Engineering"
The former Acquisitions Chief for the US Air Force just announced that they got a contract to CERTIFY a plane for airworthiness before ever actually building one in real life [1].
Yeah, incidentally recall campaigns for some companies are the same for software as for hardware, think medical device. But the software is constructed in the same Agile way as anywhere else in fortune500 world.
Engineering, no matter where it is, is about reacting to costs and benefits. Software engineering has radically different costs and benefits than physical engineering. It would be inappropriate to blindly copy over the engineering practices from other fields without adapting to the huge changes on both the costs and benefits sides.
If other engineering fields had metaphorically similar costs and benefits to software, their procedures would look like ours. If they could flip a flag to change the color scheme on their hotel and push the "compile" button to tear down the entire previous hotel and build a new one in 30 seconds, they would not be using blueprints and carefully planning their every move. They'd incrementally build a structure just like we do, pre-existing libraries, iterative development, the whole thing. They don't not because this is not engineering, but because they can't. You can't afford to have an inspector come in at the end of their project and announce that the ceilings are 6 inches under code and the whole thing is condemned.
I find the occasional moon-struck love affair with other engineering disciplines and how they're doing real engineering and aren't they just so dreamy to be badly misplaced. They would be jealous of us, if they knew what we had. They're doing real engineering. We're doing real engineering. The people not doing real engineering are the ones who blindly copy inappropriate methodologies from other engineering disciplines, which is the engineering methodology equivalent of writing object oriented code in Haskell. Building a program like it's a skyscraper and we must plan our every line of code, which we can place only once, and it must be perfectly correct, six months in advance, is as inappropriate as trying to build a skyscraper through iterative development.
In electrical engineering, there is some iteration in development (board spins). But nowhere near the flexibility of software. That's why it's almost always better, imo, to turn a hardware problem into a software one.
- The blue print analogy is used a lot to argue why software engineering isn't real engineering. The reasoning goes like this: you create a blueprint of something like a bridge and you don't start building the bridge until the blue print is done. Then the bridge building process is reasonably predictable and structured because you already solved all the problems. If only software engineering was that predictable. Of course with software, the process of creating the blue print is literally creating the software. The build step tends to be fully automated (compilation). Blue prints for your blue prints used to be a thing when we had waterfall. Creating a blue print for a bridge or a nuclear plant is similarly less predictable. Because that's where you have to do all your problem solving. That's why so many of these hard engineering projects go way over budget.
- SpaceX is using rapid iterations with rocket design. This is real engineering but they are also doing things that come directly from the agile world like not trying to design the entire rocket waterfall style, failing, and then spending another five years fixing the design. Instead they iterate rapidly, go through lots of prototypes and iteratively refine the rocket.
So, it's not that black and white. The process of creating good blueprints on a predictable schedule is not a solved problem. Also not in hard engineering projects. Using agile methodology and testing your blueprints in either simulated or real form helps.
>you create a blueprint of something like a bridge and you don't start building the bridge until the blue print is done. Then the bridge building process is reasonably predictable and structured because you already solved all the problems
Which is hilarious, because nothing in the real world works that way. My BIL is a civil engineer and he spends tons of time traveling to sites to solve problems that pop up during implementation.
I didn't listen to the interviews but, as a pure software person I've observed the following:
1. Most software 'engineers' are more like technicians, plugging libraries into each other
2. A very small subset of software writers are in fact doing real engineering
I'm working with a semiconductor company at the moment, with traditionally trained engineers, many of whom are 25+ year vets from industry and academia. Semiconductor design makes most software 'engineering' look like children playing with safety scissors. In silicon, the bar to ship is nothing short of literal perfection. When's the last time you shipped a software project with 0 known bugs, spent tens of thousands of hours on testing (design verification), and improved on the best-yet-achieved-by-humans performance by 2x - 5x? Never? Same.
It seems to me the reason this question gets asked is due to the massive gulf between software and other engineering disciplines in terms of the level of rigor and correctness brought as table-stakes. As others have pointed out, software has the luxury of being able to hotfix bugs (correctness, and performance) after release. This has led to most of our industry being extremely sloppy, lazy, and frankly kind of embarrassing. Software shipped today is dramatically less efficient, more buggy, and sometimes even less useful than software shipped just 10 years ago, let alone 15 or 25.
I don't have a solution for this problem, but I hope we can one day hang the big-engineering-boys-and-girls, and, ship quality software again.
I'd like to say I fully agree with you, but I don't think this "perfection" you talk about is usually reached, not even in your exceptional domain: Remember the living lists of CPU errata! And retpoline, meltdown, spectre! God only knows how many of those are out there, unknown or actively exploited.
It's true I was in a bit of a dramatic mood, but there really is truth in that statement; at tape-out (release), 0 known-bugs will exist. That's not to say 0 total bugs exist which, as you correctly point out, is obviously and demonstrably not true, but to the best knowledge of people working on the product at the time, it works perfectly.
Hardware people are not the pinnacle of engineering correctness — that would go to people who do formal verification. Unfortunately not even mathematicians think the price is right.
> 1. Most software 'engineers' are more like technicians, plugging libraries into each other
You didn't mine, smelt, and manufacture the raw material yourself? Sorry, not an 'engineer', technician only. You're using other people's stuff to do your thing.
Most software development is not engineering. Engineering is about requirements, guarantees, and specifications.
When you engineer a bridge, there is a use case such as light vehicle traffic. That translates to a load requirement to achieve that goal. Your design must then guarantee that it fulfills that requirement.
Success and failure in this environment are defined and objective. Furthermore, you can largely rely on the guarantee being made; the correct operation is well-defined within some meaningful domain. Engineering turns the subjective qualities of a product into objective bars for success.
Specifications generalize this process by providing well-defined guarantees. These can then be used by another to fulfill their requirements.
Engineering rewards results, not efforts. It is about fitness of purpose, not best efforts. It is about success and failure, not how hard you tried.
My previous career was mechanical engineering. I was on track to be a licensed engineer in my country, I have a mechE masters degree.
Even in “traditional engineering” some people refer to certain tasks as “not real engineering”. Usually they are talking with their ego and wish it was the 70’s so they could be drafting with pencil.
Their opinion doesnt mean anything and is basically regressive.
So the idea of if any task is “real engineering” is just such a pointless debate.
Defining any activity as engineering or “not engineering” isn't useful.
Calling yourself a software engineer is fine as a job application tool, but needing to be seen as an “engineer” is just meaningless ego.
Ive seen this debate for over a decade at this point, some like to split developers vs engineers by some arbitrary standards, but honestly it doesnt and has never meant anything.
The problem is not if software engineers are engineers or not, the problem is with defining software itself, as an EE myself, I do software, we learned how to write programs even in assembly back in the school too, however, you have now (at that’s even before the AI LLM hype) a horde of people who call themselves “engineers” after attending a 3 weeks bootcamp in some front-end framework or library or some data analysis course, they will know how to import a library and repeat some known processes, they lack what every engineer should know, architecture design, I personally believe that if someone can convert an abstract idea into an applicable design, is in fact an engineer, software or not.
In the context of being an engineer - it's not. A real engineer's licence can be revoked due to misconduct, is issued by a governing body and carries some weight.
Software developers can call themselves engineers or even Code-Alchemists, but it carries zero weight.
Apparently, the National Council of Examiners for Engineering and Surveying (the board that regulates other engineering fields in the USA, such as civil engineering) used to offer a Professional Engineer (PE) exam for software engineering, but it was dropped in 2019 due to lack of participation and bad prospects for increased participation.
I think it’s worth separating the question of “do software engineers actually carry professional liability or have their designs independently reviewed” from the question of “is software development work sufficiently consequential and verifiable to warrant professional liability and certification requirements?"
To me, the answer to the first is obviously no and the second is obviously yes.
I think that is an argument for the term rather than against. A SWE SHOULD be held responsible for the things they make and the impacts it causes. Additionally, so should PMs and CEOs but heyyyy.
I guess the big issue is that it is easy to place blame in the case of a bridge failing...but much harder when a system products mass suicides.
I think what's actually fuzzier is the definition of "real" engineering, whatever the hell that is. I'm not discounting that specific practices within engineering have clear definitions, but there's no one consistent way to lump every one of those professions together and have a cohesive "you're in or you're out" definition.
I would say it depends on the specific role and project, but for most people who write code, likely not.
Coming from a mechanical engineering background, I understood "engineering" as the application of science for problem solving - or, put simply, applied science. Some examples:
1. When a civil engineer applies solid mechanics to select a cross beam.
2. When an electrical engineer applies E&M to design a circuit.
3. When a mechanical engineer applies heat transfer to analyze cooling patterns on a laptop.
Under this definition, most "SWE" work isn't engineering - if anything, it's closer to applied math and logic?
That said, definitions are only useful inasmuch as they allow us to make sense of the world and communicate with others, so I'm not sure this is the most useful question
You could consider it as applied science in that we are dealing with CPUs, we do benchmarks, we build models of things ... but this isn't work that everyone does.
I wouldn't call most SWE work close to applied math or logic. Very few people get to deal with things that are math-adjacent or do applied math in general. Many things are just .. plumbing data.
I agree that for people who do that type of work, it's engineering
For a typical fullstack dev building views, CRUDs, and simple DB schemas, less so
And you're probably right that most SWEs don't deal with math-adjacent things.
---
And just to be clear, none of what I'm saying is a value-statement on the types of work different "software engineers" do. It's just a question of categories, which I view as separate from utility
Not a CE myself, but computer engineers definitely consider physics in their solutions since they have to consider complexity, computational speed, memory restrictions, concurrency etc
Aka they take fundamental theoretical concepts and given the physical constraints we have from the existing computing systems they come up with viable solutions.
There is a big difference between the person that builds the skyscraper and the person that does the maintenance.
Most of us empty the trash and change the lightbulbs and think we are structural engineers. I'm ok with what I do, but I don't pretend I'm something I am not.
I've thought about this a lot as a dev. IMHO, no, and the main reason is a strong resistance to standardization: in OS platforms that we work on, software libraries to do basic things that we include, education credentials, and QA. We simply can't agree on a practical knowledge base as a profession that beyond the 1st and 2nd year CS fundamentals. There are some best practices that we've seem to coalesce around, but even those are somewhat ill-defined.
OTOH, I'd also be lying if I said that there weren't real world benefits to working a little more "fast and loose", and I'm at a point in my career where I can accept that the varying level of rigor and standardization in the more profitable software companies is the best balance in today's world, and I try to pick my battles.
But I don't think this is any more "engineering" than an MBA using spreadsheets and accounting statements to decide where to allocate human or capital resources to maximize profit. We just use a fancier set of tools and have a different domain to optimize.
And I know this doesn't reflect every dev job. But it sure does a heck of a lot of them.
When I wrote strictly software on computers, typically with a way to push fixes, I felt like it wasn’t really “real” engineering.
Then I wrote firmware for some devices that was fairly complex and the programming needed to be absolutely perfect to ensure various hardware issues (and product bugs/failures as a result) couldn’t happen.
You wind up creating remarkably stable and thoroughly tested code, both digitally and physically, and the end result is something incredibly precise due to rigorous design and execution both on the software and hardware sides.
That feels a lot more like engineering. I actually miss it a lot. I can’t help but bring a lot of what I learned to usual software development, but I find a lot of people dislike the same kind of rigour and precision. Like it’s in the way of getting things done, and fundamentally that’s all that counts.
I can see why pure software isn’t considered engineering as a result. The “we can push a fix” mentality can seriously undermine one’s care for the work as well as the overall design and testing practices.
In any case, I’d argue it can be engineering, but it often isn’t.
There are times that I feel like I’m doing engineering when I write software. Those are often the most fulfilling (and most frustrating) parts of my job. But most of the time what I’m doing is just putting things together or repairing things to achieve a goal - not figuring out anything new. I’d say I feel more like a construction worker for 80-90% of my workload.
well engineering is not project management , while engineers do a lot of project management, PM is not engineering
Waterfall and Agile is not Software engineering, I think software engineering is algorithm design, API design and anything design, coding and tooling in general
software project management is .. software business, not software engineering
The main difference is that software engineering is extremely tolerant of poor engineering standards and practices, relative to "traditional" engineering disciplines.
This allows many organizations to utilize software engineering skills without having any particular mentality towards engineering itself. Some businesses can be arranged such that the software development practice is much like an assembly line, reducing developers to assembly line workers. Some businesses actually use engineering skills and have an engineering mindset.
The fact that businesses can find success while having terrible or no engineering practice is an example of where software engineering differs from any sort of engineering of physical things. Mechanical, electrical, chemical, etc engineering does not have such a tolerance, they simply exhibit failure if so.
Funny post. I came from purely webdev software engineering to hardware engineering and let me tell you, it is an interesting coalescence of mechanical, electrical, and software engineering (both firmware and regular 'ol software).
I sit in on several different design reviews and it kills me how similar each engineer thinks even with such disparate differences between each discipline.
In terms of difficulty for my smoothbrain to comprehend from easiest to hardest to understand, I'd say it goes mechanical, software, electrical, and then firmware.
Like holy hell, firmware engineering is a dark art. Kudos to firmware engineers.
> 'd say it goes mechanical, software, electrical, and then firmware.
I think it’s about the mindset, like how some people enjoy doing numbers while others see it gibberish, personally I find embedded easier to work with, on the other hand, I still can’t fully comprehend React spaghetti.
I think it is best to drop all analogies to other disciplines (“it’s like a bridge but…”, “it’s like building a house but…”).
These analogies are oddly captivating even for those who are very experienced in software but do not have any experience in other problem domains.
I think that while such analogies provide some comfort, we are better off eschewing them completely. In software we need to focus on the actual “mess” in order to begin to draw useful conclusions.
At the end of the day, what is “real” anything? Isn’t this just a form of the “True Scotsman” logical fallacy?
Interfaces matter so components can cooperate but the internals can, and generally should be, treated as a black box. It’s like connecting chips on a board.
The actual code is more like painting a landscape. There are techniques for representing some idea and many can be chosen. It’s up to the artist to choose the one they think works the best.
So long as the interface to the world outside is solid, it usually doesn’t matter what happens inside.
For instance, if I had an interface to write data to a file it may have time constraints. So long as they’re met, all is good.
We have so many bad cases of people mislabelling themselves like chiropractors that call themselves doctors. This doesn’t seem like the biggest “problem” to worry about. Next you’ll be complaining about people who call themselves “sanitation engineers”. I think you can call a job whatever you want as long as it’s not deceptive. Any current conventions are arbitrary anyway and have nothing to do with the original meaning of the word “engineer”. And millions of people already use “software engineer” so it’s a well established term.
I didn't realize it was time to drag this old chestnut out of storage. Nothing like dusting off a decades long flame war. I'm sure everyone will come to an agreement this time.
One of my favorite arguments in this topic is when 'Real Engineers' say "If my part fails, someone could DIE!"...to the Facebook/IG/TicTok Engineer whose role in Social media drives suicides across the world.
All engineering is making something complex and functional, so yes, absolutely. Of course, there is software that is neither of these things, but there's also fallen trees across rivers that serve as bridges and eventually erode.
Almost nobody uses science and mathematics to prove a design before coding. The closest I came was the glacial waterfall environment of defense software that I now realize wasn't so bad.
Didn't say it needed to be a purely mathematical proof. They don't accomplish this with a combination of materials science and CAD software with a patchwork of regulation/review?
I build ephemeral data structures inside virtual environments that run in a container in a virtual machine using virtual memory on a processor implemented in microcode.
If it were real engineering, we would be able to safely run arbitrary code, just like you can safely plug anything into an outlet and not take down the grid.
There are some safeties built in (fuses/circuit breakers) but ultimately it’s not so different than safeguards in software. Hence why the electric grid often has issues.
No it's not real engineering at all but a different thing altogether. Engineering is the application of hard sciences like chemistry, physics and biology to solve real world problems. Software development can be part of what an engineer does to solve that problem but it's not engineering in itself. Software "engineering" is actually applied mathematics particularly logic to program a computer to complete tasks organized as algorithms. This is why some algorithms and functions in software can be proved via mathematical proofs.
I agree, which is why Ive designed my own set of qualifications for a web developer to be considered senior, and they have integrity and can be reduced to scalar values if needed. Thousands of interviews have proven these qualifications to be successful at sourcing candidates that are true seniors and those that are not.
Most businesses dont need to care since they can find successful outcomes either way. That doesnt mean that qualifications (which can be turned into certifications just by having a recognizable name attached to one's firm) do not exist, that just means software is truly soft in that the consequences of being under-qualified are not at all as drastic as the consequences of being under-qualified to fix powerlines or design a nuclear reactor.
We may be "small-e" engineers, but we aren't Professional Engineers[1]. That requires a license, a degree, training, and an organization that spells out what a discipline is competent at doing.
Generally, a licensed PE is required to complete a four-year degree, and four years of engineering experience, after which rigorous testing confirms their qualification. This ensures a fundamental body of knowledge, in addition to the wisdom and experience of practicing under other experienced professionals. The Professional Engineer takes on a legal responsibility for their work, in part because they are trusted to ensure the welfare and safety of people and property.
Based on my 18 year career, I've only met a few SWEs that I would consider having both the requisite body of knowledge and experience to be called a Professional Software Engineer. Most of the SWEs I have met have lacked some fundamental knowledge that is required to complete a Software project to a high standard of quality and reliability. Even if you exclude networking hardware/software, computer architecture, systems engineering, embedded system design, and other niches (which aren't that difficult to learn, but anyway), most SWEs I've met over my career lack basic knowledge about software engineering.
Often, they simply don't have the experience of working in professional organizations. This is not taught to them in school, and you often have to work at a specific kind of place to learn these standards and processes on the job. But these standard and processes are necessary to coordinate work amongst teams in such a way to avoid common problems, such as lack of documentation, incorrect assumptions about how something works, delivering the wrong solution at the wrong time, etc.
Another thing that's become extremely common in the past few years is lacking a basic body of knowledge about software design. The history of software, its uses, algorithms, techniques, standards and protocols. This fundamental lack of knowledge leads to making mistakes that the industry learned to avoid decades ago.
Most SWEs I've met today are working off a body of knowledge from the 1990s or early 2000s. They have not learned modern software design or implementation techniques, outside of whatever is specific to one or two programming languages (and even then, their knowledge of the language is inconsistent). In addition, most of them have not taken training to teach them how to manage their work within a team effectively, which is especially important with the rise of Agile and Scrum.
It seems that most of what the average SWS knows today was learned from random blog posts submitted to tech forums, which were written by laymen, submitted by laymen, upvoted by laymen, and commented on by laymen. It's the blind leading the blind. And those blind people then go on to work for companies where they hire the blind.
I believe that the Software Engineering industry is almost entirely made up of people who don't understand their own ignorance, bluster their way through jobs and projects, and move from one company to the next, rarely ever significantly improving themselves, mostly leaving companies with shoddy work.
I know this isn't everyone's experience. But I have worked at enough places in enough different industries that it cannot be pure coincidence. HN is a good example: many of the comments on technical articles are often clearly from ignorant and inexperienced people who pass their assumptions off as fact. I can't count the number of blog posts upvoted here whose entire premise was fundamentally incorrect, yet a whole chorus of people chime in to agree, not really knowing what they're saying.
The point of the study, experience, and testing of engineering is to ensure that the people who claim they're engineers, actually can walk the walk, because in Professional Engineering, the result matters, and there are real world consequences.
SWEs are lucky that most of the projects they work on don't have as dire consequences as Professional Engineers. But the more software takes over the world, the greater their impact on society is. Software has lots of real world impacts - from charging electric cars, to suggesting when someone's gait might make them a criminal, to preventing someone from getting credit to buy a house, to creating addictive habits for young impressionable minds, and more. If the world cares about the impact of software, then it needs to hold digital engineers to a higher standard, the same way it did to physical engineers over a century ago.
The problem with this question is that, if it's not engineering, what is it? A better question is motivated by studying the history of chemistry and its progenitor, alchemy. That is: is software development alchemy or chemistry?
Software development is alchemy. Just like alchemy, software dev is not standardized, everyone has their own idiosyncratic naming systems, classifications and rules-of-thumb. Like alchemists, software engineers are often jealous of their proprietary knowledge. Just like alchemists, they are admired, feared and loathed for having secret knowledge. And just like alchemists, you have to be exceedingly brilliant to work in such a chaotic field and get anything done.
So, what changed alchemy into chemistry, and what will be the analog to that in software? Arguably the change started with notion of conservation of mass and energy, and the development of the periodic table (thanks to Lavoisier and Mendeleev, respectively). As for what that analog is for software, first we need a characterization of the field. With alchemy and chemistry both, it's essentially mixing stuff together, heating and cooling it, and seeing what happens. But what is it for software?
First, software engineering is not computer science. Computer science is a tiny subset of software engineering. In daily practice, almost all of computer science is encapsulated in a few, tiny standard libraries - the places where bubble-sorts and hash maps live. (This mistake is consistent, and leads to "leet code" style interview questions which are irrelevant to actual work).
I'd characterize software engineering as the set of solutions to a boundary value problem[0] described as "a set of interacting screens with behaviors pleasing to humans". The current solutions to this problem have been idiosyncratically defined by resource constraints that relaxed exponentially over time[1], and characterized by elements discovered at random, by necessity: e.g. kernels, processes, files, procedures, terminals, etc. In this analysis "language" functions as a kind of "coordinate system" as in physics[2][3], within which each of these elements are described, and within which elements are combined to make new elements, which eventually yield a solution to the boundary problem (which is termed "application"). There is some coorespondence with chemistry, in that we have "elements" which combine into higher-level structures, but we lack an analogy to "conservation of mass and energy". And our elements are still highly partitioned according to coordinate system (although there have been several[4] heroic[5] attempts to unify them within a single framework.)
I don't particularly know what the standardization of software alchemy into software engineering will look like, but I'm certain that this analysis, or something similar to it, is the first steps in the right direction. Personally, I look forward to the day we can shed the considerable weight of our alchemical origins!
Definitely an interesting analogy, I find it uncharitable towards the state of software engineering though. Whereas alchemy/chemistry had to unlock a model of the microscopic world based on observation of the macro world we were born into, software engineering was the entire creation of a new world that we built from the ground up. It’s not that we don’t have a sufficient understanding to build great and precise software works, it’s just that the macro space is so large and unconstrained without the physical limitations that keep problem spaces of physical sciences more tractable and comprehensible.
I do agree SWE is still early days and will develop a lot, but I don’t think it will coalesce the way you’re suggesting though because we’ll keep dreaming up new things to do with arbitrary data and logic.
I think you need to review the history of science. Alchemy did indeed yield many things of practical value, all of which were systematized and rolled into chemistry. And besides, the fact that an alchemy of one kind might be more valuable than an alchemy of another doesn't invalidate my point. It just means that once our field changes phase, it will be even MORE valuable.
> Computer science is a tiny subset of software engineering. In practice, almost all of computer science is encapsulated in a few, tiny standard libraries - the places where bubble-sorts and hash maps live.
I agree with that...
> (This mistake is consistent, and leads to "leet code" style interview questions which are irrelevant to actual work).
...but not so much with that! Computer science is immensely useful in real world work: it helps to be able to look at a task and recognise it as an application of a few, general theorems, say in the field of graph theory or distributed systems, and let that knowledge guide your implementation. Just knowing that the problem you're facing is mathematically undecidable tells you more than weeks of experimentation would, for instance. Perhaps it's often a mistake to ask about it as an interview question, but it's not a mistake to familiarise oneself with the theory.
The issues are twofold with the relationship between computer science and software engineering.
Firstly, typical computer science courses are simply not advanced enough. At the pace of a typical university education, one would need to get to doctorate level before being able to reliably make novel developments in a given field, but that probably won't sound like a good investment of time and money when one could be earning significantly above-average salaries in industry even without the education. I personally believe that making more intensive courses available would be ideal for a large number of otherwise very competent programmers who are limited by their lack of academic computer science education.
Secondly, computers are too luxurious of an environment to necessitate rigour! If you're building a shelving unit, you won't need to perform complicated calculations to measure stress-strain curves or cantilevering forces. The tolerances are so wide that you can get bolt together about any planks of wood and make a piece of furniture that is mechanically adequate. Does that make cabinet-making alchemy? I think it makes it more like craftsmanship, but it's definitely not engineering! Likewise, most computer applications always have CPU cycles to spare, data storage on tap and flexible timing requirements, so innovation only really happens at the limits of the technology: hyperscale applications, safety-critical or embedded software.
I still think it's slightly unfair to say that software development is alchemy, when it is to me more like a well-established but rather conservative craft, which is only occasionally pushed into academic study and engineering rigour when the stakes are high enough.
Software has a magical property that other engineering disciplines do not: The engineering environment is ideal and fundamentally perfect. It's like building electronic circuits but only in the simulator that uses all idealized parts. And you get the extremely rapid prototyping and scaling that comes with that. (A "single line of code" equivalent error in a production analog circuit can take months to fix and years to distribute)
In a way it feels "unfair" because the fuckery of mother nature and immovable boundaries of physics is largely (and normally completely) cut out of the equation. Imagine having to write code where every variable is a fuzzy range as opposed to a fixed value, it would put a huge clamp on designs.
However,
The intellectual savings from not having to deal with non-linearities and errant physical effects, is largely just shifted into increased overall complexity that all exists in a different realm. So maximum logical thinking and intellect is still demanded.
I think the divide really comes from the difference in space in which the "engineering" is happening. Conventional engineers are dealing directly with nature trying it's best to constantly break your design. And I think there is a degree of comradery that comes with that. Software guys, free form those chains and working in a parallel universe of perfect logic, instead are pushed to the absolute limits of complexity.