Hacker News new | past | comments | ask | show | jobs | submit login
Are We Really Engineers? (2021) (hillelwayne.com)
317 points by phgn on Jan 19, 2022 | hide | past | favorite | 389 comments



I think the best definition of engineering is that it's a process of optimization within a solution space bounded by constraints. If you pile up some mud and let it dry, you have made a dwelling but you are not an engineer. If you calculate the load requirements for a series of I-beams given a certain budget and build a skyscraper, you are an engineer.

As the author correctly notes, there aren't necessarily hard boundaries on what qualifies as engineering, but I think there clearly are axes on which something is "more engineer-y" vs "less engineer-y", and as the constraints of the solution space go from physical (tension, voltage, pressure) to non-physical (interpersonal relations, public perception, aesthetic judgment), the activity goes from more engineer-y to less engineer-y.

In software, we're always optimizing on cost / developer time, but that's closer to the non-physical side of the constraint physicality axis. As you optimize for things like memory usage, execution time, binary size, then you get closer to the physical end of the constraint-type axis, and are thus more engineer-y.


So a plumber is an engineer. It’s easy: an engineer is someone who has a degree in engineering (whether or not such degrees should be degrees on engineering is another question). The current trend of calling programmers/developers engineers is a pure business trend (it originated in HR departments).


At uni I had one course in software engineering. It was different to other courses as it was about defining metrics and constraints, measures of success, requirements etc. As well as evaluating what building blocks you had available.

To me the term didn't come from HR it came from trying to get "programmers" to think in terms of constraints, value, risks etc. Seems a pretty clear and simple definition.

The reason I think its not taken off in the same ways as say mechanical engineering is because in general customers cannot actually see the product, only certain elements of its outputs.

If you couldn't see bridges either in use or after a failure. You just saw cars disappear at one end and appear at the other, not even able to measure the gap or time taken to cross in any meaningful way then structural engineers would bullshit and self grandise as much as software engineers.

Maybe one day the average person will know enough to hold us to account, then we will begin engineering properly.


> To me the term didn't come from HR it came from trying to get "programmers" to think in terms of constraints, value, risks etc. Seems a pretty clear and simple definition.

The trend of giving high sounding titles started decades ago as more and more educated people entered the workforce and involves all jobs.

Manager? Vice president.

Secretary? Executive assistant.

Developer? Engineer.

Reports and collects some data for his bosses? Data analyst.

Warehouse worker? Logistics and distribution specialist.


Not to nitpick your point too much, but VP tends to have a specific meaning, even if its given to many employees. Usually, it means that this employee can sign contracts or make certain regulatory commitments on behalf of the company. Its not always self-aggrandizing.


It absolutely does not usually mean that, there are a ton of finance VPs that nobody would ever let sign anything meaningful without someone up the chain reviewing it. There are also tons of people who sign contracts for companies who are not VPs. There are companies where VP is really just about comp; all jobs above $x/year are some flavor of VP, even ICs.

It doesn't have to always be self-aggrandizing for it to be true that lots of people are now called VP who used to just be middle-managers.


There's a joke in finance that VP is an entry-level job. Largely because that field is very status-driven and people want a glorified title, despite entry-level responsibilities.


In medicine doctors are now “providers” no different than nurse practitioners, physician assistants, RN, PT, pharmacists etc. it’s the opposite, leveling everyone to the lowest common denominator


In some countries some profession names are reserved. There you know that a doctor is a doctor, not a guy who went to a hygiene bootcamp.


I remember software engineering courses to be about the process, the metrics available, the way to mesure and quantify whatever is going on in a project.

As opposed to learn about a type of algorithms, some math, some language or some pattern.

10 years latter, I’m glad for the exposure.

It was more useful to understand and talk to folks on the sides of the dev department : security, ops, qa, support. Heck, even product.

I felt that with those, the dev could monkey patch whatever together and still be part of some engineering process.

Now I don’t know. I sure do push code around.


Is there a foundational body of knowledge for software engineering the way there is for established engineering discipline? Something that can be tested against like the FE and PE in the US? Would the FE, for example, suffice?

If not, then, at least in my mind, it seems difficult to pin down exactly how software engineering can occupy a space in the domain of modern engineering.


NCEES tried a few years back and developed such a curriculum but there wasn't enough interest so they got rid of it. IIRC, something like a total of 6 people were certified as a software engineer in the last year it was available. I don't see required licensure for software engineers happening unless 1) it's driven by employers or 2) it's driven by regulators. I don't see #1 ever happening because it's asking the employers to give more leverage to their employees. I'd personally like to see #2, at least on certain safety critical applications.


If engineering is applied science with gatekeeping, I'm frankly not interested.

Some sort of specific liability in the legal code could make sense, though.


Isn't the gatekeeping standardized verifiability and liability? Those are sorely needed in a lot of software endeavors.


I think the difference is one of disposal and retry.

In physical engineering, you really get one chance. If you make a mistake or miscalculation, there is a cost associated with undoing what's been done, as well as trying again.

In software, there is no such additional cost. You can trivially start from scratch, or any point between scratch and here, at any given time. There is no disposal cost.


I think that is a perception, but its driven by not being able to "see" the product of the work.

Security breaches, locked in data (poor dB structure or no direct access) reverse engineering undocumented functionality, even just dismantling supporting infrastructure and migration costs are huge. Another huge factor is when business logic is codified and the knowledge is lost from the business and only temprarily held by transient consultants or developers.

An sap project for a single region for a $1bn per year company can easy cost over $10m and no software is being developed, only config, process change and data migration. Never mind increased staff turnover reduced productivity.

But very few people have the experience and expertise to understand what they are really signing up for.

Just think about a 3d model can do for a construction project and what that would look like for code and you can see how poorly we do this really.


This ignores the vast amount of software that interfaces with physical systems. When software fails and causes a rover to crash into the surface of Mars, there is certainly a cost and one cannot trivially start again from scratch. Same even with software that does not interface with physical systems, like algorithmic stock trading.


If Iec 61508 was applied to all software that would also do it.

(Make software actually be engineered)


I agree, but I think the horse is out of the barn in many respects. It will be very hard to get organizations to adopt such standards without being forced to by some regulatory agency, unfortunately, because that constraints adds cost and impacts schedule.

That's without even considering all the kinds of rules-lawyering that would be applied afterwards.


In some ways physical engineering is more forgiving. Consider the cost of a security breach. A bridge can be rebuilt, but data cannot be unpublished.


The people who were on it when the bride collapsed are pretty tough to restore from tape...


> So a plumber is an engineer

Yeah, we call them civil engineers.

In the US, in order to be an engineer one either had to have a license to call themselves an engineer, or a company could confer that title to employees. These days, it's less about the specific education, and instead the process of solving problems.

Engineering is a discipline which may be applied to many domains, including software. I define an engineer as someone who uses fundamental principles and processes of science and engineering to solve real world problems.

Our customers need to ask a skilled expert a question and receive an answer.

If I merely implemented code to achieve this goal, I would not consider that engineering, but rather coding.

Instead, if I first defined the problem statement, gathered requirements, documented assumptions, broke down the problem into discrete deliverables, defined metrics and success criteria, and created a plan of record, that would be engineering.

I have a formal education in engineering, and aside from the mathematical and science fundamentals required for engineering, a large portion of my education was dedicated to the process of solving problems (also proudly, a good portion was dedicated to learning about ethics as well).


You've got one of the big words that I would insert into this discussion -- science. I think the two biggest words missing from here are "science" and "risk." As Alan Kay puts it, science is about getting a description elegant enough that, like the Maxwell equations or Lisp's metacircular evaluator, it fits on a T-shirt. And engineering is about taking that T-shirt and building a bigger more ambitious bridge than anyone could have attempted if they didn't know about forces and stresses and scientific metallurgy.

Engineering involves risk tradeoffs, and if your developers are not making your risk decisions then they are not engineers -- and also you're going to spend a lot more money producing software (the authority to do risk assessment should always be as close to the "in the trenches" work as possible, every degree of removal invites the risk decisions to be made on lower-quality more-aggregated more-gutfeel information rather than clear metrics).

Most of computer programming is instead tinkering -- build a proof of concept, put it under stress, see what is being stressed, buttress those parts. The fundamental idea of architecture, "let's add some structure in advance so that we can build a self-sustaining system and take away the scaffolding later," is only really seen today maybe in test suites or so? Those are the scaffolds of our day I think. We're still in very early years for computing as a proper engineering discipline. But at least we do make some simple risk calculations.


> Most of computer programming is instead tinkering

Most of mechanical engineering is still tinkering. Not all problems are solved. Many of the people here pining for "real engineering in software" need more interdisciplinary experience, ffs.


Interdisciplinary experience is something I most engineering educations provide.

I can only speak from my undergrad experience, but almost every engineering discipline took the same background courses, as well as mechanical, thermal, fluid, and electrical engineering classes and from there, went on to take courses related directly to their field.

From my experience, tinkering is another way to say prototyping or building a proof of concept.

As we've gained experience, the need to prototype the same solutions decreases, but when learning new tools and methodologies, experimenting and prototyping is very much part of the engineering process.


> we call them civil engineers.

We do not. Civil engineer is a specific thing, with training, education, and licensing. The person who designed the system being installed or serviced was likely a civil engineer, the plumber is a plumber. And that's ok, everyone doesn't have to be an engineer. Being an engineer isn't inherently better than being a non-engineer.

> an engineer as someone who uses fundamental principles and processes of science and engineering

Do you see how saying an engineer is someone who does engineering isn't useful to other people? I'm sure you know what you mean, but basically everyone is and is not an engineer according to your definition.


A plumber with enough experience can do engineer-y things, e.g. design an appropriate plumbing system for a house or renovation.

Or a plumber can just be a guy following a plan and cutting and gluing pipes together.


But they cannot stamp a design, meaning it's not legal (depending on scope and permitting requirements). I can tell a person what ails them if they give me a list of symptoms but that shouldn't be conflated with me practicing medicine as a doctor. An HVAC technician can lay out a design for, say an operating room, but a licensed engineer is the only one who can stamp it saying it meets standards for ventilation. This where the fuzzy terms of "engineer-y" can get us into trouble. ~engineerish != engineer


> We do not. Civil engineer is a specific thing, with training, education, and licensing.

Yes. That is the joke (among non-civil engineers with civil engineer friends).

> Do you see how saying an engineer is someone who does engineering isn't useful to other people?

No. Because that is not what I wrote.

I also provided a concrete problem, along with an engineering and non-engineering approach to solving it.


>a good portion was dedicated to learning about ethics as well).

This is the first I've seen this point in the discussion. Engineering is considered a profession, distinct from a vocation. The term derives from professing an oath to serve the public in an ethical manner. If developers had to take a similar oath, I wonder if it would open them up to civil/criminal liability when they acted unethically (e.g., creating code in a social media application with the goal of manipulating behavior for profit)


Do you think engineers existed prior to the 18/19th century when degrees became a thing? It seems problematic to your definition that most of the wiki page on engineering is dedicated to things done by non-engineers.


Also there are people without any degrees that do far more engineering than many developers who hold software engineering degrees.


The engineering process is to apply design tools to architect a solution with expected performance before anything is built. In traditional engineering this generally boils down to mathematical models that dependably replicate expected behaviors to a known degree of error. Building happens after the modeling says a solution is possible.

With software, true engineering only happens if the development model can follow such a process. Nobody wants to put in the work to do this for all code though.


Upfront-heavy design is a cost saving adaptation to the constraint that experimentation with large scale structures is expensive. Even then, traditional engineering disciplines are very much into prototypes, scale models, and intricate test and measurement apparatus.


Upfront design is one of the methodologies of engineering but so is trial and error.

Being a good engineer is adopting the right combination of methodologies to fit the problem space.

Being a good software engineer means knowing what you should plan out in advance and what you need to test and design as you go.


It’s a simplistic definition. Since the topic of calling developers engineers is rather superfluous, I think we should go for simple definitions.


I can think of many simple yet incorrect definitions. They have as much utility as this one.


Depends on what the "plumber" is doing. Certainly there are plumbing tasks (eg pipe sizing for a chemical plant) which I would qualify as engineering. I would qualify it that way because they probably had a series of constraints (must transport X liters of substance Y / second at Z temperature, fit within service routing of the structure, minimize cost, etc etc) which they optimized against. I think a plumber who, say, fixes a sink, is not doing a similar process. Between those points lies the gray area of subjectivity!


It's easier than that: an engineer is someone who does engineering.

I'm not convinced there is much utility in conferring the attribute of engineer to someone who is not practicing engineering when it's just as possible to say "She studied engineering" or "She majored in engineering" to denote the status of having an engineering degree but not engaging in the doing of engineering.


>an engineer is someone who does engineering.

I don't think this is actually useful without strict definitions of what constitutes engineering. If I go to a homeopath who prescribes an herbal tea to cure my cancer are they "practicing medicine"? The law says they are not, and cannot, because of clear definitions of the term.


You know, some programmers build game __engines__...

More seriously, the first programmers were electric/electronic engineers, so the engineer title was probably inherited. And game engines actually require lots of math and physics.


I don’t doubt working on game engines is hard (I do web development). If you build game engines then you are probably a game engine developer. I don’t hold a degree in engineering myself; no shame of not having the “engineer” title.


I've had to go on HN a bunch to say this. Engineering school is brutal and generally requires passing a great deal of difficult courses that signal to certain employers that you'd be a good fit to design the power grid or components of space shuttles. They also give you a certain framework/toolbox to work with after you've done calculus, differential equations, circuits, dynamics, statics (not statistics), material balances, coding + all the upper level classes. This is different than the framework/toolbox that an economist would get to help recommend policy changes. Economists don't call themselves engineers and engineers don't call themselves economists. I'd actually argue that the mathematical models and econometrics used by economists is closer to engineering than just programming. A programmer/developer also has a very challenging job that involves what is essentially solving a complex technical puzzle under a huge variety of social constraints such as working within a team and meeting project deadlines and making trade-offs (for example, monolith or microservice). It isn't what engineers define as engineering though.


I agree with almost all of your point, but a small nit pick:

>Economists don't call themselves engineers and engineers don't call themselves economists.

There are quite a few universities that offer courses/degrees in "financial engineering" and they often are in the mathematics/economics colleges and don't have a typical engineering curriculum as you laid out.


Plumbers typically don’t have the background to systematically evaluate the solution space and optimize the solution. But chemical engineering looks vaguely like plumbing if you squint.


Many chemical engineers do mostly plumbing. If you're really great at optimizing plumbing for a large range of conditions, then yes you're doing an engineer's job.


An engineer doesn't just wing it because they're "really great" at it.


I don't know what part of "optimize for a large range of conditions" sounded like "wing it". You can't do that by winging it.


Projection, probably. ;)


Unfortunately, an awful lot do, even the licensed/degreed engineers. I have lots of anecdotes from personal experience that indicate many are more technician/tinkerers than engineers.


Well, plumbers frequently work as contractors to mechanical engineers. Its better to think of them as technicians, even though much of their training and for single family homes/etc the work is basically engineering on a smaller scale (computing gas flow vs pipe size over a run, etc).

I think shat this article fails to note is this engineer light/technician class which tends to be the more hands on portion of "engineering" in the case of sw, they would be more light engineering more programmer less overall design. AKA your systems architect/principal enginner is probably doing "engineering" the software engineers are likely just programmers.


>an engineer is someone who has a degree in engineering

Some would define it differently as someone who has an engineering license. There are States who have actually presented lawsuits aimed at preventing people from describing themselves "engineer" if they don't have that license. And, while an engineering degree is the more common first step in the licensing procedure, it's possible for one to get a license without an engineering degree. In the legal sense, they are more of an engineer than someone with a degree and no license.

Regarding the plumber, I think the mechanical engineer who designs the plumbing system would be the engineer, while the plumber is the technician. Just like the electrical engineer designs the system but an electrician installs it. Both roles are equally important but shouldn't be conflated.


Plumbers here in Australia are licensed, so if your definition of "engineering" includes being certified by a regulatory body, then plumbers are closer to "real engineering" than software engineers.

(FWIW, I don't subscribe to that notion of what "engineering" is)


Can only speak for German degrees and while the first part of your answer is correct in spirit, the second one is kinda off.

You can have the exact same curriculum and be called engineer or not be called engineer, depending on the university. You can even learn nothing related to engineering and have an engineer title, or the other way round.

I'm not saying you're wrong (especially the first part), but there's a lot more to it, especially in countries where 'engineer' is a protected name/profession.

Personal opinion: I don't care. My degree is "Computer Science", not "Computer or Software Engineering" and I see myself as a Software Developer (although I will allow programmer)


My first computer science degree was a Master of Engineering degree. Does that make me an engineer over someone with a Master of Science but the same degree course content?


Depends on accreditation and licensing as recognized by your state more than the words in the name of the degree. There are far more BS than BE programs producing engineers in the US.


I could agree - but I was responding to the parent who said 'an engineer is someone who has a degree in engineering' which seems to not make sense in my case.


Yea, but my point is that even disregarding accreditation a "degree in engineering" is more often BS/ MS and focusing on titles doesn't reliably work.

Every degree in my school's college of engineering was BS/MS. And I think something like 25 of 27 were "degrees in engineering".

If you want to go full circle, they are "degrees in engineering" because they're accredited by ABET, and satisfy the first requirement towards licensure and a PE.

There is no simple definition, which is the whole point of accreditation and licensing boards.

ETA: But if the programs in your hypothetical have an identical curriculum (and both are accredited), then yes, they would equally be "degrees in engineering".


I'm with you on this. My personal definition of an engineer involves designing systems that can potentially kill humans or other creatures.

If you design pacemaker software, you're an engineer. If you build RESTful websites, you're not. I say that as someone who builds RESTful websites.

The reason engineers need difficult certification exams is, so they don't destroy lives or expensive property.

There was a programming PE (USA) at some point, but it was closed.


As he says in the article, many engineers in the past had neither a degree nor a certification. And they were certainly building "real things".


Actually I believe the term "software engineer" was coined by Margaret Hamilton while at NASA in the 1960s. Her Wikipedia article has some relevant quotes and references: https://en.m.wikipedia.org/wiki/Margaret_Hamilton_(software_...


I don't think so. Software engineering, and by extension, software engineers became a thing in the 60's. Margaret Hamilton coined the term ~'63.


I have studied computer science and have a master of engineering.


In the same way that a professional is someone who gets paid, yes.


a plumber is actually a civil engineer, and I doubt one would get a degree for plumbing...


> it's a process of optimization within a solution space bounded by constraints

That just describes problem solving.


Yes exactly! The word engineer comes from the latin ingeniare which is partly derived from ingenium which means clever. The entire job of an engineer is cleverly solving problems.


Everyone solves problems in their jobs. Engineers are not the only problem solvers in society.

On another tangent, I wish we’d redefine what it means to solve engineering problems. I have noticed that there’s this property of engineering that as problems are solved, new ones are created. So it’s this never ending cycle of new problems blossoming.


You clearly haven’t met many of ‘everybody’. People of all occupations solve problems, yes. Most humans barely do, though.

In terms of creating new problems, making life better is an under-defined, open-ended problem. There’s always a lowest-hanging fruit, that doesn’t mean we should stop picking them.


I would definitely say anyone who cleverly solves technical problems is an engineer.


Now we just need to define "solve", "cleverly", and "technical".

What if their solution is non-technical, still an engineer?


> it's a process of optimization within a solution space bounded by constraints

By that definition, almost any profession - from surgeons and taxi drivers to construction workers and cooks - are all doing "engineering"?


Categories are made up and don’t exist at the end of the day. Even the difference between marketer and engineer can be fuzzy.


Unless you're suggesting that the word "engineer" is entirely meaningless, this doesn't rebut the given objection to the proposed definition. If the word means anything at all, then the question has to be answered: Is the thing that it means that particular thing, or a different thing?


Literally all categories describing real-world phenomena are fuzzy at their extremes. Reality itself is fuzzy at extremes


Then what job isn't engineering?

By the definition given - "a process of optimization within a solution space bounded by constraints" - a taxi cab driver is certainly an engineer, with no fuzziness. Nor would it be an extreme case testing that fuzzy borders of that definition.

And that's why herval disagrees with that definition. As do I.

Definitions can also be overly broad, which is why we no longer use the term "star" to refer to planets, nor refer to the sun and moon as "planets". https://en.wikipedia.org/wiki/Definition_of_planet .


While this is supposed to be an argumentum ad absurdum, it's quite great. Makes you consider that anything from dentistry to sanitation could really be thought of as similar to engineering and gives a nice healthy kick to the ego of an engineer.


You are right. The output they work towards is a longer lasting item (system).


In my region we always called softies lightweight engineers, although that term is proposed to be claimed by engineers in the field of energy and resources. I think it is still a good fit. Engineer is a very broad term, the knowledge of electrical and mechanical engineers overlap to some degree, but the focus is very distinct.

Otherwise engineer is just a title too, so I guess it is mostly meaningless?


What's the difference between a lightweight engineer and the other kind?


The engineering part is purely virtual for software developers I guess. While there is some basic physics in most curricula, most computer scientists are a bit "lightweight" on topics usually associated with engineering.


Which other fields of engineering are "lightweight"? Industrial? Chemical?


No, I guess it is only applied to computer science. Most people sort it more towards math than engineering.


"Computer science" is sort of a different thing and not necessarily engineering, even though the typical software engineer's formal degree is in "computer science" (and also people don't use the terminology totally consistently). But as for software engineering, I think the article makes a really solid case that electrical, chemical, and industrial engineering don't have anything relevant in common that software engineering doesn't, so putting the latter in a separate "lightweight engineering" category just isn't right.


> we're always optimizing on cost / developer time, but that's closer to the non-physical side of the constraint physicality axis

I think this is exactly what the author points out as "software engineers don't know real engineering". What makes you say that no other engineering practice don't optimize on cost / engineering time?

There are degrees of quality in engineering, and one of the factors is definitely "time spent on engineering". If you are making cheap frying pans, I doubt that you're going to hire a rocket scientist to check whether the screw holding the handle is strong enough to resist 5000 heating cycles...


> ...as the constraints of the solution space go from physical (tension, voltage, pressure) to non-physical (interpersonal relations, public perception, aesthetic judgment), the activity goes from more engineer-y to less engineer-y.

This would put industrial engineering deeply in "less engineer-y" territory, IMO.

I think someone is very engineer-y when they pick a simple, easy bridge design which requires less skilled labor to produce, even if this takes them away from working with more juicy physics problems.


I think I would agree with that (industrial / process engineering is "less" engineer-y than, say, mechanical engineering), but since they're still optimizing against measurable physical constraints (how many chiller units can we fit in this section of the warehouse, how long does it take a worker to move from the freight deck to the storage racks, etc), I think they're over my personal line. But of course, drawing sharp category boundaries is a losing game, which is why I prefer to think in terms of axes / vector spaces.


I think "drawing sharp category boundaries is a losing game" is as close as we are going to get to a clear lesson, here.


Engineers can both perform the problem solving and design for desired projects and...

AND...

If need be reduce it down to the underlying science and mathematical principles from which it came from, and because of that can analyze why things are "good" or "bad" at a much more fundamental level.

Practitioners/Crafters are repeating "recipes" with far less comprehensive knowledge of the principles that led to those recipes. They may know historical evolution and practical reasons why one recipe is better than another, but their depth of knowledge is far less.

So getting back to software, you can see two types: people that know algorithms and can mathematically design and analyze problems. Or you have people that are just following the api docs and basic examples of loops + if-then but don't know how CPUs work inside, how OSs work, and why.

And do you need full engineers for a website layout or ruby on rails site? No. But if you are scaling or have complex data models or will have actual load, then ... you need engineering.


> I think the best definition of engineering is that it's a process of optimization within a solution space bounded by constraints.

This is a fantastic definition.


It is.

It shows very clearly why most software devs are not engineers. I know I'm not.

As a field, we don't "optimize within a solution space bounded by constraints".

We throw crap at the wall to see what sticks, hacking up something like what the users said they wanted, then changing it all to do what they ask for once they start using it.

It's normally done as a craft where we're using fuzzy human instincts to get to a good-enough solution and move on.

And for systems where lives aren't on the line, nor millions of dollars every five minutes (financial trading, massive server farms at Google, etc), that is actually the correct tradeoff. Engineering is overkill for most software.

NASA needs software engineers. Microsoft doesn't.


Exactly. Public safety is central to Engineering practice. Bridges and buildings come to mind but many life-critical software projects in aerospace, medical devices, automotive, also have emphasis on safety. The development process is way more controlled in embedded industries compared to web/IT/enterprise.

Even Google and financial services are really just services that scaled and acquired a massive userbase.

“Software Engineering” is really just an application of civil engineering project management to programming projects. The job title of software engineer is used too liberally however.


Microsoft definitely needs software engineers. Privacy and security of users is on the line, even if they literally aren't going to die, lives can easily be ruined by a data leak from the wrong company.


Yes, that's a good point and I overstated.

Microsoft needs a _few_ software engineers.

Most of their developers won't be and shouldn't be, though.

Conversely, NASA will have plenty of software systems that have nothing to do with spaceflight, like their website.

They shouldn't be paying software engineers to engineer those systems, but rather software developers to build and maintain them.


But what is numerical optimisation if not throwing crap at the wall to see what sticks? Do you only count analytical optimisation as optimisation?


That's a good question.

To me, the difference is that when we're writing software and just trying semi-random UX ideas and implementation approaches out, we don't have any real constraints that we're genuinely bounded to.

So, yes - throwing crap afu the wall is an optimization process.

It's the other half of the above definition that it misses, IMO.


...crap at the wall, sorry.

I'm not great at typing on my smartphone.


Optimization? "An engineer is someone who can do for 10 cents what anyone could do for $1."


In other words, what all engineering professions have in common is that their practitioners solve problems difficult enough that merely finding solutions is a substantial part of the job.


This is roughly how I explained it to my mother. I told her that no, I'm NOT an engineer and I used this analogy:

An engineer is a guy who measures stuff upfront to create a plan of action (like measuring how much concrete we need if need a bridge to carry 500 cars). He never gets his hands dirty nor does he build the actual bridge. He has a ton of responsibility and must call on vast knowledge to know what patterns will be needed and if they will cope with the loads.

On the other hand, programmers are more akin to gardeners (my mom is super into gardening) and carpenters - we have to get our hands dirty and build the thing. We have to use and stay true to the spec (from the engineer above) as close as possible, measuring a piece of wood 3 times before we cut it (not the fail fast nonsense) and carefully plant new plants that won't kill the whole garden. We also need to pull out weeds and prune the bushes and so forth. With a bit of careful implementation you can have a gorgeous garden and bird/insects/squirrels visitors and so on.

Software Developers I would say, is then a combination of the above, depending on your experience you might lean more toward one side or the other. The best developers have a good balance of Knowing stuff and Doing stuff.


Engineering encompasses both. Does someone dictate literally every action of yours in great detail? No? You're an engineer and must exercise engineering acumen.


> a process of optimization within a solution space bounded by constraints

That's just regular old optimization. There's no point in optimizing anything that doesn't have constraints, because there aren't any bounds.


this is wrong. unconstrained optimization is done all the time. One quick and easy example is mean-variance optimization.

Edit: I think you're conflating unbounded and unconstrained.


I come from an aerospace engineering background (did structural engineering on commercial aircraft that were in the design and approval stages) and am in software now (games). I've had two different takes on this. Neither is perfect. Would appreciate comments on them.

(a) If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering.[0]

(b) If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering.[1]

[0] If software is engineering, then it's the only engineering discipline I'm aware of in which the participants are regularly expected to produce deliverables they don't fully understand. What do I mean by that? Well, if we software peeps fully understood our deliverables, we wouldn't have bugs, or at least, we'd always know what bugs are there. If as a structural engineer I had delivered a final draft of an analysis document which showed that I didn't fully understand the part and how it would perform, my boss would not have been pleased. Most software bugs are treated more casually than that, so we clearly have a tolerance for delivering work that we don't fully understand.

You might take issue with the idea that I "fully understood" a structural part. Fair. When I calculated the strength of a beam in a thrust reverser I didn't understand the individual molecular interactions, I didn't need to know if the metal was of a body-centered cubic crystal structure, etc. But this is because I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative (from the point of view of a factor of safety), and fully encapsulated all the understanding I needed to produce a part fit for use.

[1] This feels like the more flawed of the two proposals, because I expect EEs can do this. Control systems folks can definitely do this, and I would absolutely call them engineers.


The strength of a beam is an atomic calculation. A software engineer should fully understand a function that calculates the length of a string...

How is a spaceship blowing up not a bug? These happen fairly frequently... Oh, and oil spills? Fukushima? Mines that collapse?

Talking about games. The physical equivalent to video games is pinball machines. Anyone who has played these can tell that the ball sometimes get stuck in weird places. This is exactly the equivalent of a software bug. Shouldn't the engineer have a total understanding of the machine so that the ball never gets stuck? You know, maybe games aren't so important that everything must be perfect.

Also, I have a 2 year old. None of his toys have lasted more than 3 months. Literally 0 out of dozens. Isn't there a fortune to be made by engineering toys that can endure a kid's strength?


> This is exactly the equivalent of a software bug.

Not really, because you can usually shake or tilt the pinball machine to set the ball free.

> oil spills? Fukushima? Mines that collapse?

These events happen (literally) once every few years or half decade. Software bugs happen (literally) billions of times per hour.

(I’m not normally this pedantic, but felt the need since your comment comes across as knee jerk defensive without a whole lot of substance to work with)


> Not really, because you can usually shake or tilt the pinball machine to set the ball free.

That's silly. A bug is an unintended behavior of the system. If you shipped a debugger with every video game, you'd probably be able to get yourself out of most bugs.

> Software bugs happen (literally) billions of times per hour

You're comparing things with different criticality. A bug that doesn't prevent you from doing your work is like a match that doesn't light up properly. These events happen all the time in the physical world.

Bugs that shut down AWS for 24 hours tend to be less frequent...

Let's just no enter in a debate about the frequency of "physical world bugs".

Yes I admit it was a little knee jerk defensive.


> Not really, because you can usually shake or tilt the pinball machine to set the ball free.

And you can restart a program that crashes or reboot a system. Or workaround the bug.

> These events happen (literally) once every few years or half decade. Software bugs happen (literally) billions of times per hour.

Yes but you are looking at big impacting things. A TV that breaks because the power supply was badly engineered and a capacitor broke down doesn't get on the newspaper, as it doesn't an app that crashes on a phone. A software bug that makes a plane crash or make a company loose billions of dollars is something as rare as the kind of events that you pointed out.


> Not really, because you can usually shake or tilt the pinball machine to set the ball free

> Software bugs happen (literally) billions of times per hour

Physical bugs occur very frequently as well, we just correct them ourselves like in your pinball example.


Yeah, oil spills occur because companies make conscious decisions to do the bare minimum to operate their pipelines. 500K gallons of crude spilled in Louisiana a few weeks back and nobody knew about it until cleanup efforts were underway. Why did the spill occur? It wasn't because the pipeline was engineered poorly. It was because the pipeline was not properly maintained. And people wonder why there are those who do not want an oil sands pipeline carved through an aquifer.

Engineers don't work with infinite budgets and they usually are not the people who are making final decisions on either maintenance or implementation. Many of these failures occur because of budget constraints, time constraints, or decision makers who go against the recommendations of experts.

IMO, the closest thing to a "software engineer" is a software architect. Everyone else is a craftsman.


> Engineers don't work with infinite budgets and they usually are not the people who are making final decisions on either maintenance or implementation.

There are plenty of examples where the problems as the design, not the implementation, such as:

https://en.m.wikipedia.org/wiki/Hyatt_Regency_walkway_collap...

Different projects have different costs for failure. A bridge failure costs more than a child's toy that breaks. A browser tab crashing costs less than a mars orbiter that burns up in the atmosphere. Engineering isn't confined to just working on things where people die or stuff explodes if you mess up.


This has been covered in detail elsewhere. The constrains on software engineering are such that the bugs are tolerated and it is cheaper to ignore them. If it was any other way then we'd care more about bugs.


> Isn't there a fortune to be made by engineering toys that can endure a kid's strength?

Maybe, but there's probably a bigger one to be made selling replacements for those toys.


> Fukushima? Mines that collapse?

Those 9.0 earthquakes? That isn't a defect. The software equivalent is an intern deleting the production customer account database. That isn't a software defect, but there is still a failure with plenty of blame to go around.


> A software engineer should fully understand a function that calculates the length of a string...

Once you get into language semantics of iterating over characters vs bytes vs graphemes, it's not always so trivial.


I appreciate you sharing your perspective! Mine's somewhat different having worked in another industry.

I worked in semiconductor manufacturing as a process engineer. What counts as bug in that setting? It's completely expected to have defects in the final wafer. They go through a QA process. Some die can be repaired but others are trash. Die also get graded and low quality chips go to customers with less mission-critical needs. There's also a department dedicated to investigating early failures in defective product from customer returns.

Personally, I viewed the product that I delivered as the wafers coming out of the steps I owned. High volume manufacturing is an ongoing process much like software development.

As an individual process owner, I had metrics and goals to meet but my processes fit into a larger system I didn't fully understand. Process development happened by incremental changes much like software feature development. We would convert a small percentage of the production line with a new change at one step like you might use feature flags, but we sometimes had to rollback changes when something unexpected came up at yield or test.

It might be more the nature of semiconductor manufacturing, but I view failures as part of the engineering process that comes up when we're pushing our tools and systems to new limits.


Good point, (a) doesn't hold up when you're dealing with the bleeding edge. Plenty of experimental airplanes, designed by highly credentialed engineers, fell out of the sky on the way to producing today's safety miracle of commercial aviation. Similar story (hopefully usually less deadly!) with other miracles, like modern semiconductors.


When I worked in aerospace, there was a big, one-of-a-kind piece of metal where the fabricators had drilled a bunch of rivet holes in the wrong places. The structural engineers had to figure out if they could still use it. There's bugs in everything.


I think a good software analogy for this would having a piece of multi-threaded code that accesses a shared resource using locks.

There will probably be some waiting involved (analogous to defects). The engineer determine wha rate of waiting/working is acceptable, and if the software actually does perform like predicted.

If it does not, as in the wait(defect) rate is higher, it might indicate a genuine bug in the system (like locks not being released in a timely manner), or a failure of planning.


> But this is because I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative (from the point of view of a factor of safety), and fully encapsulated all the understanding I needed to produce a part fit for use.

I am not sure how this is different from evaluating a library, database technology, or architecture, going through design review, learning properties of distributed systems (which have corresponding proofs by the way) to understand which properties you need to satisfy with a given solution, reading the documentation, viewing other open-source code that uses the technology, reading publications/testimonials from people and companies using it in productions, etc., etc., like we do.

In particular "applying simplifying assumptions" - this is what we all have to do particularly in a distributed, cloud-computing world where you are essentially purchasing a conceptual primitive (like "virtual CPU" or "replicated block storage" and building on top of simplifying assumptions about how those work, because you can't walk up to the NAS rack and start hitting it with a hammer to see if the data can be recovered after, the same way you can't hit a steel beam with an actual hurricane to know what will happen.

Although if I worked in the datacenter operations team for a cloud provider, I would absolutely hope to one day be able to test how we handle if I yank some plugs or hit the NAS rack with a hammer :)


It is absolutely wildly different. "Evaluating a library", "reading the documentation", etc., is absolutely NOT the same as basing your calculations on a hundred+ years of rigorously proven methods and deeper physical truths. How could you possibly infer that these are the same thing?


software engineering is a younger discipline, we don’t have hundreds of years yet.

You seem to think that our understanding of CPU operation or distributed systems isn’t based on physical truth and rigorous testing.

Also a programming language or library or whatever has often been deployed by tens of thousands of organizations, across tens if millions of deployments, across trillions of discrete times the code path has been hit, and we know how it acts. That’s rigorous in its own way


How about this one:

(c) If your project assumes the underlying device/system will behave exactly as it is told to, then you might be in a discipline that is distinct from engineering.

This means "engineering" would include some software projects (like fault-tolerant system design), but exclude many others (like most desktop/mobile/web apps, perhaps with components like databases being exceptions).

My rationale for this is that, best as I can tell, traditional engineering is (for the lack of a better phrase) about "taming the real world"—which doesn't always behave the way you tell it to, because it's inherently uncertain, failure-prone, and impossible to model exactly. So if your task is dealing with that, then you're doing engineering. Whereas if your main problem is coming up with the correct specification—but you assume it will be executed faithfully—then it's not really engineering per se, but something else (not sure if we have a name for it).

Thoughts?


Intriguing! I'll have to let that percolate...


I haven't fully figured out the implications to be honest. Some are more intuitive than others. For example, it would mean (some?) financial engineering is a misnomer ;) but it would also suggest that designing digital circuits is only engineering in certain cases, like high-speed cases where you have to make the design robust to extraneous analog effects. For what it's worth, I think it somewhat aligns somewhat with your point about abstractions.


I appreciate the focus on abstractions. I'm unenthusiastic about giving up on (b), because when you've got a discipline where anybody can reach for any old terrible abstraction and stand some unholy monstrosity up that actually seems to work okay, I have a difficult time wanting to call it engineering.

And I am fully in favor of financial engineering not being engineering. :-)


>When I calculated the strength of a beam in a thrust reverser I didn't understand the individual molecular interactions, I didn't need to know if the metal was of a body-centered cubic crystal structure, etc. But this is because I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative (from the point of view of a factor of safety), and fully encapsulated all the understanding I needed to produce a part fit for use.

While I fully agree with almost everything in your post, this sounds an awful lot like an abstraction to me. Perhaps the different between creating software and engineering based on the physical sciences is the degree in which the abstractions are understood and rigorous. Perhaps software engineering is simply in its infancy and may eventually lead to more rigorous designs with less or no bugs in the future?


I think there are bigger guarantees and checks the beam works as it's specified so the next engineer can continue.

Google was using in production (firebase cli) the notorious trick the js developer played us other week. I doubt the other fields would rely on some random developer from Australia who has had a colorful past to provide the beam for structural engineer. And there's definetly more testing from all sort of parties they work om real life as advertised.

Then again no one is offering free open source beams and you can't since you need materials not just one time drawings of an idea.


The beams may not be open source but the calculations are


If the beam is in a critical application, it may have provenance, or a material history, for similar purposes.


In software, the range of correct operation (eg: maximum web server load with response time under x ms) is commonly unspecified and omitted. The strength of the beam gives a conservative estimate of its capabilities. Still a model/abstraction, but one with boundaries.


The difference (if any) between simplification and abstraction is the subject of some debate!


I think the difference in [0] is your input variable space is much smaller for "traditional" engineering disciplines. To grossly simplify: ME? You need tolerances for a specific amount of force (in different directions.) EE? You need tolerances for specific amounts of current passed through a circuit.

With software your inputs are tremendously varied, because user input is not as well-formed as in any other engineering disciplines. In fact we deliberately try to find ways to input things that are not supposed to be inputs by designers of systems (i.e hacking things). If "hacking" bridges was a thing, it would be something like people trying to see if they can diffuse a thermite solution into the rock-face instead of driving a car over it, and I'm not sure any structural engineer has planned for that scenario.


> Well, if we software peeps fully understood our deliverables, we wouldn't have bugs, or at least, we'd always know what bugs are there.

I don't think this is really incompatible with some of what Hillel gets at in his post with regards to professionalism and quality. I think it's possible for software engineers to have much higher confidence in what sorts of bugs their solutions do and do not contain, but the practice is mostly tilted towards velocity over catching every last bug.

Because not all bugs are the same and not all requirements are equally important. Robust software systems are supposed to be built to minimize the impact of bugs in individual components where possible, with defensive programming techniques and such.

> I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative

I think this is a better candidate for a key difference than your other suggestions. We don't have a lot of good ways to apply conservative simplifying assumptions once software gets to a certain scale. We have abstractions, but where they are imperfect, any missed detail is a possible integration flaw.


Does this imply that the more complicated a stack gets, the less engineering can be done, and it devolves into something else?


Maybe? The problems definitely change. So much of software engineering is about managing complexity well. I haven't worked on sufficiently large projects or in sufficiently large organizations to tell you how exactly how it changes, I just know that it's different from talking to people who work at Google and Amazon and so on.


Love this comment!

> (a) If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering.[0]

This might arise from the different contexts without implying a different activity is taking place. Fixing bugs after launch is something you can do in software engineering, but can't really do in (say) structural engineering. If they could invisibly and safely swap out part of a bridge without stopping traffic, I'm betting they'd do it all the time! In software we can, and it makes sense to use this feature of digital products as part of the engineering process, in order to meet other requirements, like time and cost.

(Whether it is overused or not is another question. I consider "good engineering" vs. "bad engineering" as distinct from "is engineering" or "is not engineering", ymmv)


Isn't aerospace engineering the field that gave us pitot tubes that froze up at high altitude?

> well-understood and rigorously accepted simplifying assumptions that were conservative (from the point of view of a factor of safety), and fully encapsulated all the understanding I needed to produce a part fit for use.

Isn't even this "reaching for abstractions"?

I would argue that software engineering has two factors that result in higher bug counts: the lack of consequence, and the youth of the field.

Lack of consequence shows up in errors in other fields, too. How many times has a civil engineer created an intersection that doesn't drain properly, or a curb that was slightly too high?

Youth of the field shows up in other engineering fields also. See: pitot tubes, above.


There's as many definitions of engineering as there are jurisdictions. Someone joked at some point that designing a PCB is real engineering (solidly into EE territory). Chip design as well (designing an ASIC is indeed generally considered to be EE). But replace that ASIC with a microcontroller and firmware and suddenly the firmware writer is no longer an engineer, despite the part having the same spec as the ASIC it replaces. Misplace one of these microcontrollers with the correct firmware on it in the wrong bin and it might even end-up on the same board the ASIC was supposed to go. And nobody would notice a thing.

> If we software peeps fully understood our deliverables, we wouldn't have bugs, or at least, we'd always know what bugs are there.

In the embedded world that's more true than in "general purpose software" as the problem space is often better defined. There are also Realtime OSs that offer hard guarantees in terms of execution time and memory consumptions (or at least will have a hard cap on the upper bounds). It is possible to develop software that’s extremely predictable and has runtime measured in years. But it’s costly and takes time.

> so we clearly have a tolerance for delivering work that we don't fully understand.

Yes, when non-critical. You'll see it too with "silent upgrades" of physical products over their lifetime. Some of them are to correct non-critical flaws discovered over time.

This tolerance has increased a lot over time as the cost of update has lowered (keep in mind not that long ago OS updates shipped as physical media!). And the cost of shipping bad (non-critical) software isn't the same as shipping defective products (think about the costs of a physical product recall). That allows a level of acceptable risk that’s alien to most other engineering disciplines.

From the article:

> In Canada you can't even call yourself a Software Engineer unless you're accredited!

How much of that is the licensing body trying to squeeze a few dollars here and there? Do they actually enforce those rules? Would it be enforceable (if you can't define it properly, first amendment should apply...).


Point a seems more related to the "culture" surrounding modern engineering than it does a prerequisite for the discipline itself. Looking at how SpaceX engineers produce things looks totally different (from my outside perspective) from how a civil engineer sitting behind a desk would sign off on designs. Engineers at SpaceX seem to be more accepting of failure and have the "move fast, break things" mindset that most traditional engineers don't have.


engineers at spacex are unlikely to go to jail because one of their designs blew up, but most engineers who design bridges or buildings dont have that luxury.

Move fast, break things, pay for it with someone's life, lose your professional accreditation and maybe your freedom.

Maybe they're playing similar but different games rather than playing the same game differently.


As the article says: "bridges and buildings" engineering isn't even representative of all of civil engineering, let alone the entirety of the engineering profession. Also, not all engineers are even professionally accredited.

I'd wager that the vast majority of engineers would not go to jail if their design failed.


I think a key defining trait of engineering is the necessity of having a correct, precise model of the domain you are working in, so that you can solve multifaceted problems with the minimum possible resources.

A typical non-engineering characteristic of software is the widespread acceptance of techniques/libraries that claim to make development easier at the cost of increased(outsourced) complexity and efficiency.

I think a design technique that (allegedly) allowed you to spend half the time in a CAD software, but the resulting part would be less sturdy and more expensive to make wouldn't be exactly popular.

Yet this is the bread and butter of software engineering, and since waste can be arbitrarily big, directly results in Wirth's law, with software consuming the extra resources and regressing to barely acceptable performance.

Imo, one of the places when real engineering happens in the software world is video games. Here, there are actual constraints are very tight - one has to simulate a believable world, display 60 frames of meticulously calculated graphics on a clockwork cadence, synchronize players over an unreliable network in real-time, and so on and so forth. And do these things on cheap console hardware whose designers often favored raw performance over ease of use, sometimes to extreme degree, like the PS3. I'm pretty sure I barely scratched the surface.

Yet it's commonplace to see chat applications crawl to a halt (Teams) and use enormous resources, while having a fluid UI in a game that just happens to run flawlessly beside a fully rendered 3D game world is considered the price of admission, not some technical feat.


From my observations engineers in many disciplines would wing it all the time. Sometimes because of time/budget constraints, or simply because of lack of established methodology for certain corner cases. The scope of 'corner cases' also tended to be a lot larger in their disciplines' infancy: things like bridges (and yes, aircraft) were regularly built with assumptions pulled out of one's asses.


Software is built on 150 layers that change incredibly often

new cpus, changes to OS, core libs, frameworks, runtimes, vms, language libraries, new protocols, other hardware

the dynamic here is way too big


Also a previous engineer (Systems & radar engineer on DoD projects like missile defense, avionics, etc) and now software engineer. Definitely disagree on both points.

> (a) If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering.[0]

Every system has bugs. If you aren't expecting, controlling for them, and implementing measures to reduce their impact and likelihood - you might be in a discipline that is distinct from engineering. Why else would redundancy be a critical requirement in just about any mission critical systems?

> (b) If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering.[1]

Well in radar, missile defense, helicopter systems, it was all abstractions up and down the stack. Maybe the 1000 engineers working on these projects weren't all real engineers? You have to use abstractions if you want to do anything real. You are regularly using models, simulations, tools, integrating with other teams' systems/components which become abstractions.


> If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering.

Totally disagree. Engineer = design and build things. Whether what you build has bugs or not is irrelevant to the definition.

> If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering.

All science is based on abstraction. Laws of physics used by aerospace engineers are abstractions of some more complex reality.


Is a child performing engineering when they resolve to build a tower of blocks and do so? If not, what distinguishes them from someone who is performing engineering?

In your view, are simplification and abstraction the same thing? Or do they differ, and if so, in what way?


> (b) If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering.[1]

Yeah my experience is trad engineers don't believe in nice things, haha. That's the difference. Just look at how moribund hardware is with a lack of open source tools compared to software.


Somehow, the first Tacoma Narrows Bridge comes to mind. Carefully engineered, it still fell apart in a stiff breeze (fortunately, no one was killed).


> What do I mean by that?

My go to example every time is DOM.

Out of the software developers I have encountered either online, during employment, or in person maybe 1 out of 50 who actively touch the DOM understand it well enough to have talks about it without wetting the bed. That's pretty tragic because the standard methods in most common use are about 23 years old (DOM Level 2) and take about 2 hours to learn.


The problem is that “software” is as broad as “aerospace” or “construction”.

Some aerospace things are highly engineered — airplane, rocket ships, etc; some things aren’t — kites, paper airplanes, etc; and some things are in-between, like gliders or hot air balloons.

You get the same in buildings — which range from sheds to houses to skyscrapers.

Also, the end of [0] and your discussion of your usage of routine abstractions to solve problems makes me wonder if you consider your own job to be (b)-type engineering.


I do not consider what I do now to be engineering. I'm responsible for a product used by my whole studio and I try to be very careful and produce a high quality deliverable, but I do not think of it as engineering.


>(a) If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering

A software bug means you can't drag and drop, or have to wait to import your contacts.

An engineering risk means the hood of the car decapitates you above 30 mph, or the diesel fumes give everyone cancer.

>(b) If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering.

Everything's rated. You open a catalog from a supplier. If there's any question, go up in size. A lot is skids now. There are also trade associations. Dust settles. Products turn from novel invention into utility. Existing capacity is built around one thing a shop does right, especially the knowledge from the workers.

Software is much harder. Go. Just go. Get it done. Get it out. Who cares if it's awful code. We need to make money now.

Engineering is the applied science. Applied means you use it. You don't create it. If you do create it by chance, it's not your responsibility. Ma Bell didn't go into the business of the Big Bang when they discovered cosmic background radiation. Their job was telephones. Science means consistent observations regardless of the environment. Everyone thinks of scientists as people in lab coats. Nothing like that. Lot's of reading.

Software is much more focused on engineering. In other disciplines you are a cashier at a grocery store. Software is much more like Menlo Park. You have a fixed commodity in server cost and bandwidth. Add value to it however you can.


Actually, I am a real engineer, and designing gearboxes for airplanes is quite real. So are programmers engineers or not?

Consider real engineering at Boeing. There are engineers and technicians (aka draftsmen) working side by side. They are often doing the same work. The difference, as far as Boeing is concerned, is the engineers have a degree in engineering and the technicians do not.

But if they are often doing exactly the same thing, what's the real difference?

Think of it another way. Think of an auto mechanic. He can fix your car. He can take your car apart and put it back together. He can customize it. But is he an auto engineer (who often does those tasks, too)?

Nope.

A programmer, technician, mechanic plugs numbers into formulas, follows instructions and procedures and practices laid out by an engineer.

An engineer derives the formulas, writes the instructions, develops the procedures, and refines the practices.

For example, a technician builds a band pass filter by using a circuit he's already used before and knows works. Maybe he'll tweak the RC values. An engineer will drive the RC values needed by understanding the calculation. The technician may use calculation (though they rarely do), but they don't understand where the formula comes from. An engineer does.

In software, a programmer calls a sort function from the supplied library. An engineer writes the sort function, and can tell you its complexity and why the algorithm he chose (or invented) is the most appropriate one for the particular sorting task, and what the cases are where the sort will perform poorly, and why.


I have an engineering degree but I work as a technician for an aerospace company. To me, the difference between an engineer and a technician is this:

As a technician, if I see something that looks wrong in a product, I point it out and make a report. But it's the engineer that makes the decision to fix it or to Use-As-Is. If that part fails and kills someone, the responsibility is on the engineer that signed off, not me that did the work.

That's the core of being an engineer I think, taking the end responsibility for a product.


> A programmer, technician, mechanic plugs numbers into formulas, follows instructions and procedures and practices laid out by an engineer.

Engineers do that too.

A structural engineer I know uses software to design beam strengths in buildings. He understands what the software is doing, but he didn’t write the software and he uses the outputted parameters at part of his designs.

A mechanical engineer I know needed to design a gear to mesh with an outer ring gear. He uses proprietary software to define the shape of the gear, entering necessary parameters and the output is generated into a CAD file.

Both are real engineers working as independents, but neither meets your definition.

I design a JavaScript framework that I use, the process of developing that meets my definition of engineering. I call a huge variety of functions without needing to know any of the internals. If I need to, I can go as deep as I wish to understand those internals (my background is assembler, followed by an EE degree, followed by embedded software, followed by business software). An engineer doesn’t derive everything from first principles, but they breath compromise and parry with conflicting constraints: they have the judgement to go down rabbit holes when it is necessary.


> He understands what the software is doing

That's the key. A structural engineer ostensibly has the background necessary to work without the tool, albeit with much less efficiency. Because of that they should have a first principles understanding of what situations the tool won't apply rather than the situation breaking down to 'garbage in/garbage out'.

I'll be the first to admit that measuring this in terms of education is at best a proxy for that knowledge, and have met technicians that truly understand what they're working on better than most engineers they worked with, and engineers that promptly forgot everything as soon as the exam was over. But what is listed above is the underlying piece that's attempting to be controlled for. It's a hard concept to measure.


That's right.


> Engineers do that too.

Right, they do. Not everything an engineer does is engineering.

> A structural engineer I know uses software to design beam strengths in buildings. He understands what the software is doing, but he didn’t write the software and he uses the outputted parameters at part of his designs.

I've worked with formula-plugger engineers, too. But they would, now and then, misuse the formulas because they didn't understand its limitations. And, if the problem didn't quite fit the formula, they were dead in the water. While they had engineering degrees, I considered them mechanics.

> A mechanical engineer I know needed to design a gear to mesh with an outer ring gear. He uses proprietary software to define the shape of the gear, entering necessary parameters and the output is generated into a CAD file.

Could he design the gear without the CAD tool? If he could, he's an engineer. If not, he's a mechanic.

P.S. I'm all for using labor-saving devices. But they are not a substitute for understanding.

P.P.S. The guy who programmed the CAD tool is an engineer.


I remember one formula-plugger "engineer" I worked with. His results were off by a factor of two, so I got called in to find out what went wrong. I quickly found out that he was misusing the formula. I explained to him where he went wrong, over and over, but he refused to believe it as the formula was king.

Another "engineer" spent a couple weeks trying to eliminate the noise in a circuit, essentially trying things at random. Finally, an actual engineer was called in. In 10 minutes, he had calculated an RC circuit to fix it, and the noise went away.

Having an engineering degree doesn't guarantee competence.


This is how I was thinking about this as well.

computer programming (e.g. writing code) is not software engineering. Any "software engineering" that took place, if any, would occur before the first instruction is even written for a production system.

a computer program consists of the the instructions to be executed by a CPU to manipulable it's state to hopefully solve some problem. This serves the same purpose as the plans that an engineer would hand to a builder, e.g. place this beam here and use these screws to secure it to that pole. After a builder has completed the construction of the building, the program has finished execution.

The CPU is the builder and the program instructions are the plans. The act of writing the program is the same as an engineering writing their plans; except instead of code they use diagrams or whatever.

the engineering parts came into play in developing those plans. that is, before the instructions were written. this is where the conversation should begin to explorer what is software engineering. we don't know how to engineer software.


> Any "software engineering" that took place, if any, would occur before the first instruction is even written for a production system.

Great comment. Designing a bus protocol or the C++ standard is definitely software engineering.

Programming is akin to trades like construction or production technicians. However, usually a software developer is involved in the design, implementation, production and maintenance whereas the former are only involved in last two.

That is because programming projects are subject to change in production. Waterfall is too slow for many businesses and the implementation winds up being a mess despite the linear workflow. Iteration is necessary to improve any design.


> In software, a programmer calls a sort function from the supplied library. An engineer writes the sort function, and can tell you its complexity and why the algorithm he chose (or invented) is the most appropriate one for the particular sorting task, and what the cases are where the sort will perform poorly, and why.

Designing and analyzing algorithms is usually considered the work of computer scientists, I would think. Software engineers are something different.


If you design and analyze algorithms intended to solve practical problems then you are an engineer. It is similar to the physicist vs engineer separation, they often do the same kind of calculations but physicists do it to create generic formulas while engineers do it to get formulas for the specific scenarios they are working on now.

So if you design a sort function intended to be optimal for your given workload, then you are an engineer and not a computer scientist.


Scientists do research, engineers apply research.


> engineers have a degree in engineering

> An engineer writes the sort function, and can tell you its complexity and why the algorithm he chose (or invented) is the most appropriate one for the particular sorting task, and what the cases are where the sort will perform poorly, and why.

So what of the people that can do this but don't have a degree? And what of the people that have a degree in engineering but can't do this? Are both also engineers, or are neither of them engineers, or is one an engineer but not the other?


I said that Boeing defined engineers as having a degree in engineering. That is clearly not my definition.

I've known engineers that were no better than mechanics. And a couple (very rare) mechanics who could do engineer work, and would be engineers in my estimation.


Ok. Rather than offering an alternate definition, it seemed to me that you were explaining why Boeing's definition made sense by leaning on the implication that the possession of a degree equaled whether or not you could do such things. I misread.


No problem! BTW, I know a very good mechanic who I tell him now and then that it's a tragedy he didn't get a degree in it. He's a born engineer, held back by not having the math training.


I'm a hacker, always have been. Took a detour to be a PhD scientist, and another one to be a "software engineer", but I'm a hacker. And this hacker can tell you: most (95%) of software "engineering" is not engineering, but more or less the equivalent of telling anecdotes about your grandparents experiences while arguing you have a solution to covid.

That said, there's 5% of software engineering out there that is engineering; read the RISKS mailing list archives if you want to see some examples (and counterexamples).

If software engineers were engineers, testing would be a higher priority, and visible regressions would happen rarely, if at all.


> If software engineers were engineers, testing would be a higher priority, and visible regressions would happen rarely, if at all.

That would mean they were doing their jobs badly. All engineering requires balancing priorities such as physical strength (or in software, correctness), and cost. An engineer who overbuilds everything 10x will quickly be out of work.


When correctness matters less than business results, then your role has passed from engineering into business. Software is somewhere in the middle. Software engineers are often informally expected to own the results without owning the profits.


Cost is an important constraint in engineering. Nearly every engineering project has cost as a component of the engineering process as omitting it yields projects that cannot be completed.


If you could create and patch buildings incrementally like software, you don't think people would do that?

Correctness in itself is not a meaningful goal. If something works well enough to meet the needs of the user, being more 'correct' doesn't necessarily provide more benefit.


Buildings have been created and patched incrementally for millennia.

It's one of the things that Engineers got pretty good at, because people died over and over.


> If software engineers were engineers, testing would be a higher priority, and visible regressions would happen rarely, if at all.

You say that as if software engineers determine the priorities ...


The difference between a "software engineer" and a real engineer like a civil engineer is that when a manager type tells a civil engineer to ignore safety or standards for profit reasons, a civil engineer gets to tell them to fuck off


You, as a software engineer, should also tell your manager to fuck off if they are making bad decisions. No one is inherently above you. If they're the kind of management to never listen to you then that doesn't make you less of an engineer, that makes them shitty managers to ignore these important principals behind their systems


You get fired the real engineer doesn't. You are paid to do what management tells you.


Language and phrasing is of course important. I have disagreed with my management on many occasions and I have never been fired.


Many companies have a culture of continuous deployment that often means "bugs happen, its part of life around here". You would go against the whole mantra of the company and industry. Not easy to tell the boss to fuck off.


It’s even more strict than that. A non-engineer is not allowed to be a supervisor of a civil engineer. This is why civil engineers work in a firm structure: the entire chain of command is made up of civil engineers. Any company who wants engineering work done must contract with a firm. This makes any potential conflicts of interest external rather than internal.


This is also why most defense companies are run almost entirely by engineers. Even though they're not required to be, they organize themselves that way to ensure a culture of design excellence. It's better to fail to deliver a product than to deliver a product that will kill people.


Boeing and their famous 737 max screwup where run by engineers with solid work and engineering ethic ?


The decision to sell a safety feature as an optional extra was pushed by bean counters.


Is this what went wrong at Boeing? Also, how is Tesla structured? Are software engineers working on autopilot functionality managed by true engineers?


Boeing ended up getting run by bean counters with the eventual expected results where the bean counters wanted to charge for a safety feature. Magically, the planes with the safety feature (every single plane sold to USA, Canada, and EU based airlines) had no issues. The ones sold to nations where they were trying to save money, had the issues that we all know of today.

As for how Tesla is structured, well it's Musk at the top who delegates everything and spends his time on Twitter trying to boost the stock price to hit his quarterly stock price goals. As for if they're managed by engineers, I have no clue.


> defense companies ... than to deliver a product that will kill people

Isn't that the point?


Most products defense companies produce are to prevent people from dying or to do completely tangential tasks.


> If software engineers were engineers, testing would be a higher priority

Many classes of engineers don't have the chance to test their designs. They have to know it will work ahead of time. The closest analogy in CE/CS might be formal methods, which (as I suspect you would agree) are sorely under-utilized.


Those engineers use tests, their tests just don't operate on "full real systems".


In fact we would be using a lot more simulators.


> If software engineers were engineers, testing would be a higher priority

testing is not that important for a hacker but important for an engineer (although hackers do penetration testing).


Are Customer Satisfaction Engineers really engineers? Are software architects really architects? Is a Doctor of Philosophy a real doctor?

Edit: apparently that should have been “Is a MD a real doctor?” TIL :D

The only reason this dumb question refuses to die is that software developers can actually borrow and apply approaches from “real” engineering. The difference is that “we” do not have to, either to be successful, or to be in compliance with any regulation or cultural expectation (with exceptions).

I’m also generally annoyed by the retroactive continuity of it all. “Software Engineer” started as a job title chosen by HR on a per-company, not industry-wide, basis, and not as a flavor of Professional Engineering. We’re probably closer to that aspiration now (unevenly distributed) but it still stinks of post hoc justification.


>Is a Doctor of Philosophy a real doctor

Nitpick, but yes, actually "doctor" comes from the latin "to teach" and originally refers to doctor of philosophy, and has been co-opted for MDs. The real question is "are mds (who dont teach) real doctors?"


That's interesting. Though, I'm not a fan of the notion that I'm no longer a Dr. after leaving academia post PhD. But, that's just my emotional take, and doesn't counter your origination history.


> I'm no longer a Dr. after leaving academia post PhD

"Does a PhD thesis have to be novel?" - I don't care how you slice that answer, even if you were confirming/revisiting existing studies. If you have a PhD, you contributed to human knowledge in either the master or PhD theses, imo.


Hey, I did my PhD more than 10 years ago, and I've taught more in my time in industry than what I could have taught in academia.


> The real question is "are mds (who dont teach) real doctors?

This makes my day!


I hadn't noticed the weird parallel where Japan also uses one word, "sensei" in their case, for both teacher and medical doctor.


To add to this, you'll see different degrees for research vs. professional practice doctorates in various fields.

For example, you can get a Ph.D. in psychology, or a Psy.D. in psychology. Generally speaking, Ph.D. is for psychology researchers and Psy.D. is for professional psychologists. Similarly in law, a J.D. is often part of the process of becoming a lawyer, and a J.S.D. is for someone who wants to do research.


actually "doctor" comes from the latin "to teach"

There's only one robust doctor test and it doesn't involve etymology. If someone else's mother refers to you as such, then you're a doctor.


I would argue that physicians are actually engineers. They are applying medical sciences.

Just like software engineering is the application of computer science.

It’s the truest definition I’ve been able to think of.


Physicians are repair techs for humans

Engineers design and create, physicians fix problems and do maintenance.


You can become a chartered engineer with a background in software engineering so it is a 'real flavor' of Professional Engineering. I'm studying for the CSQE which is a Certification on Software Quality Engineering from the same body that awards regular quality engineering certificates and I've been pretty surprised/happy with the focus it has on processes that allow for reproducible quality, metrics to monitor software improvements, and its general depth on testing as a whole (for example state machine, property, and model-based testing).


Do you have any good links about this please?

It's interesting how the traditional standards bodies are adapting to the new tech.


They might be referring to the American Society of Quality: https://asq.org/cert/software-quality-engineer

It's not equivalent to a software engineer in Canada: https://www.egbc.ca/Registration/Individual-Registrants/How-...

This may be different in other countries.

I worked in manufacturing and there were P.Eng. holding mechanical and industrial engineers that held ASQ certifications on top of but not as substitutes for their P.Eng.


> Is a Doctor of Philosophy a real doctor?

‘Doctor’ means someone who’s learned enough to teach. Many physicians calling themselves doctor don’t actually have any kind of doctorate at all and only get the title as a curtesy due to their own profession’s historical fears of lacking one.


Interestingly, in Brazil practicing lawyers who passed the bar exam are also called "doctors" due to an Imperial decree from 1825, that was also a courtesy to them from the then Emperor.


When you go to the doctors, the title "doctor" is a "customary title". They don't hold doctorates.

You'll notice that surgeons are usually called "mister".

Perhaps it stems from how the two professions arose. In ye olden days, a lot of surgery was performed by barbers.

So when people ask if someone is a "real" doctor, their actual understanding is the wrong way around. In their minds, the words "Philosophy" in PhD somehow means they aren't proper doctors.

Note that there are also higher doctorates, such as DSc (doctor of science, which will be specifically scientific), DD (doctor of divinity), etc.. I don't think I've ever met someone with a higher doctorate, though.


> You'll notice that surgeons are usually called "mister".

Will I? So far I haven't...

(I'm in the US, though, and from your comment history I think you might be in the UK? Does it differ between countries?)


In the UK fully qualified doctors are called 'mr' or 'ms' - only baby doctors are called 'doctor'.


Yes, I'm from UK.


> Is a Doctor of Philosophy a real doctor?

Actually, a Doctor of Philosophy is the only real doctor.


Well also Doctor of Engineering etc.


That's a PhD (in engineering).

Non-phd doctorates I'm aware of would be MD, Psy. D, JD.


No it's an EngD. Maybe it's a Commonwealth thing.


They exist in the US too. There ain't nothin' wrong with an EngD, it's a great terminal degree. But the Doctor of Engineering is not a doctor in the sense being discussed here. Why? Because the definition of a doctor is (or was) someone with a license to teach at an institution of higher learning. That's not the aim of an EngD, at least in the US and many other places: its goal is explicitly to produce an engineer who will use his knowledge in the real world.

The same thing goes for EdD, DPA, etc. These are professional degrees, not teaching/research degrees.


Indeed. Real engineering is mostly defined by regulatory rules. Crappy bridges and unsafe factories existed before the government regulated it.


The Doctor of Philosophy is a somewhat unlucky example, since this really goes back to the original trivium. Medicine, on the other hand, is an applied science (so, strictly speaking, if you're not bound to teaching…).


I thought I was over this argument because it always hits a dead end, but Hillel took a really entertaining approach with this series. Looking back, I'm almost always having this argument with other software people, but never traditional engineers. I hadn't thought much about how our stereotypes are wrong.

A great example from the second post in the series is how software people don't have experience with the unpredictability of traditional engineering projects: "Part of this misconception comes from us seeing the results of the engineering process, not the process itself. We don’t see the friction, the overruns, the delays that happen because someone built the wall one inch to the left, or when a critical supplier goes out of business. To assume that software is uniquely unpredictable is a special kind of arrogance."

This has me wondering why the software world is so unpredictable in the first place and why we aren't working on that? Or at least getting better at dealing with it. Also, why are we so inclined to think the physical world is so predictable? Probably because we spend so much time on our computers...

excited to finish the rest of this series


> This has me wondering why the software world is so unpredictable in the first place… Also, why are we so inclined to think the physical world is so predictable?

Ignoring time spent designing, software's manufacturing time is essentially zero. Compare that with days/weeks for devices and years for vessels/structures. So because we're used to the latter timescale, the pace of software feels like watching a video at 100x speed.

If engineers could instantly and cheaply print each new version of the airplane or bridge they're tasked with building, they'd start looking a lot more like the software industry. When software doesn't have its rapid/free iteration superpower (as in the early days or in must-never-fail situations), it starts looking like traditional engineering.


I'd say the core of what engineering is, is building something according to formal specifications and well-defined error-rates and constraints. It need not be mathematical in nature but it has to be strict and measurable. And as a consequence, almost any engineering discipline has well-defined methodologies and processes, and engineers are formally trained.

I think this is in line with the intuition of the article. Someone who writes software for a spacecraft is an engineer because they work within extremely well defined limits and towards strictly enforced specifications. People who write software for the military or who write compilers probably do too.

I don't think this applies to how most software developers work when it comes to the web or just your average project. There is in my experience no rigor of that sort. People just write code, and sure there's performance considerations but usually not in a systematic way, and it's often more tinkering than engineering.


This makes sense to me as someone educated as an electronics engineer. I've since moved over to software development and on occasion feel it can be called engineering, but more often it cannot.

> building something according to formal specifications within constraints...

Yes this is close to what I consider engineering, but maybe it is better to say 'design something according formal specifications within a set of constraints'. Engineering is a process of design. Does this mean implementation is excluded from the definition of engineering?

Plumbers and carpenters build according to specifications and architects design the specifications yet neither are called engineers.

Software development more often than not has little in terms of formal specifications and design, and as the article points out it is very much a field of change. It also focuses mostly on implementation instead of design. That is closer to what a plumber, carpenter and other tradesmen do.


I think you are largely correct, but I think I would instead characterize it as well-defined requirements and guarantees. What I mean by these terms is: requirements are a formal statement of a problem, guarantees are a formal statement about a solution, and a specification is a formal implementation that guarantees the requirements are met.

For instance, using the case of a bridge, the requirement might be something like: "lasts 10 years, max 10 ton load", the implementation might be a steel bridge, and the guarantee of the specification might be something like: "lasts 20 years, max 20 ton load".

Put another way, the key distinction is that engineering has an objective measure of what is considered adequate (i.e. solving the problem) and an expectation that only adequate solutions should be implemented.


The only formal specification of a software is the software itself. If there would exist a way to specify exactly what a program should do formally you wouldn't need the programmer: you already have the formal specification, can't you just compile that to executable code?

A formal specification doesn't make a lot of sense, if no sense at all. It's a waste of time and you will end up doing the work two times, one to write the specification and then to translate that specification in a real programming language.

The most difficult part of the job of the programmer is not into writing the code, it's into translating the informal specification from the customer to a formal specification in the form of computer code.


I highly recommend people read the article before jumping to the comments because it makes several interesting points.

My personal take is that there is no right answer because the definition of engineering is quite wide. Like the author we can argue that some work of the software engineering is indeed engineering (planning, designing, estimating) whereas the act of writing code for a giving feature is more akin to a craft.

That being said, I don't really care and I say that as a Canadian software engineering graduate, as opposed to a computer science major. If you like the engineer title and you want to use it (and it's legal in your country) then you should go for it.


Precisely, I don't understand why people get constantly worked up with this.

Is _all_ software development engineering? No, of course not. If you are banging out CRUD clone #432 then no, you are not an engineer, you are more of a technician (a programmer in our case).

But, consider this, could you design all of Google's infrastructure without applying engineering principles (most likely derived from computer science and computer engineering)?

Or perhaps you write and design complex embedded software to fly satellites, where you have to combine knowledge from multiple branches of science. Isn't that engineering?

The answer, as most everything else in life, is "it depends".


> Precisely, I don't understand why people get constantly worked up with this.

I guess because many of those who call themselves engineers are exactly those who bang out CRUD clone #423.


I'd say that if you routinely create new applications or services from scratch and make all of the design decisions (with consultation with colleagues), put them into production and take ownership of them, then you're most definitely a SWE, even if you do pair programming.

If on the other hand you generally implement small atomic changes based on predetermined design decisions not made by you and those changes are signed off by other people and you don't put them into production yourself, you're probably better described as a developer.

I think the distinction is maybe if you're the (an) architect or not?


I think a lot of people here (and the author of the article) are missing the obvious: an engineer is someone who works with engines. An engine is basically just a machine that does work. The question is really whether software can be considered "machines." They're certainly complex devices made up of different parts working in unison that perform work, so I think yes. If a bridge can be considered a machine then surely so can software. Therefore, programmers are engineers. All this talk about rigid specifications, certifications, math, respect for the title, etc. is very odd to me.


what do you think about plumbers and carpenters not being considered engineers?


> Many people have asked me why I care so much about this project. Why does it matter whether or not software is “really” engineering? Why can’t we just say that “software is software”? It’s because of these misconceptions. People have a stereotyped notion of what engineering looks like. Because software doesn’t look like the stereotype, they assume that we are wholly unlike engineering.

This helped me understand his motivation, although I like to frame the problem differently.. more like "why does software seemingly fail to learn from other disciplines, or even its own history?". IMO the answers are sort of universal - the best practitioners do know, but they either can't/won't teach due to time or legal constraints, and even if they did no one would listen. I've seen good tech-company internal wiki articles that are often much more comprehensive and well thought out than a 100 blog posts. It happens in many other fields like say quantitative trading, or law or hardware/semi manufacturing too. There is a low base level of public knowledge, say like TA or PE ratios in investing, and then real firms are decades ahead. I feel like it is the difference between a small, loosely competence based hierarchy (like a company) vs. a huge, flat network like the internet. Hierarchies are able to continuously build upon a structured body of information, even codifying knowledge that only a few people within the hierarchy understand. Flat networks don't work that way for better and for worse.


Ah yes, the yearly debate on whether software engineers are real engineers and the strawman arguments about other disciplines & qualifications.

The typical gatekeeping mentality of those who have degrees and those who don't. It's not very productive or even worthwhile to peruse.

We all deal with creep scope, people, and problems. Let's stop debating stupid titles or certifications.


I think you've kinda ignored the fact that this is a really good article with a complex take on the question that's tackling the silliness of the question head-on instead of just shouting opinions into the void.


This is a repost https://news.ycombinator.com/item?id=25823907

We all do the same thing and have the same levels of education or experience. Let’s stop debating titles that are already established in the industry. It’s quite apparent that majority of people agree and a select few don’t.


"this is an important question"

I'm not so sure about that. I'm not very concerned with the labels. I think it's fair to say it might be in a gray area, and maybe she me day in the future it will resolve into one or the other.

It's probably useful to understand why "engineer" is attached to the field in the first place. I think it's because CompSci programs often grew of of Electrical Engineering programs: that's where a lot of programming started, way back. When Comp Sci went it's own way as a distinct field, it kept the "engineer" association even though it almost completely ( especially today) lost much emphasis on EE. When I was looking at grad programs 20 years ago, even then a Master's degree at a very good tech University only had a single required EE course. Entry requirements for those not in CompSci undergrads we're 4 courses: discrete math, assembly, a grad-level fast paced intro to programming, and a course dedicated to algorithms. EE knowledge wasn't required or emphasized at any level.

So programming has strong roots in engineering, but expanded beyond it. I'm fine with this gray area.


I'd like engineering in computing, including software, large server farms, etc. to be engineering not specifically EE (electronic or electric power engineering) but just engineering as in general engineering principles as illustrated in EE, chemical engineering, mechanical engineering, civil engineering, aeronautical engineering, etc.


Was going to say the same. The article doesn't back that statement up with anything.

Many of us don't have engineer in our job title, and I've never heard of anyone being upset at it not being there.


It does though, the primary thesis of the article is that the question (whether or not software engineering is engineering) is important because if software engineering is the real deal, then we're ignoring useful lessons from all the other disciplines.


Thanks for sharing! This is a great series of articles I've never seen before. I'm also a crossover as defined here and agree with a lot of the perspectives, particularly about the many transferable skills in part three. I think working in a complex manufacturing environment helped me develop software debugging skills.

I see the licensure argument get brought up a lot. Many people working in "traditional" engineering fields never get their PE because there's just no need in their industry. Sure, that may not make them a licensed "Engineer" in some jurisdictions, but it doesn't make their work any less engineering.

The work done by other engineering fields also varies widely. Looking back on my work as a process engineer, it's honestly hard to say that entailed any more "engineering" than my software position does now.


It's not a taking anything away from us, to say we're not engineers.

It would be helpful if engineering had a widely accepted succinct definition like the scientific method, but it doesn't.

Building software is its own thing. It requires some engineering discipline. It requires some scientific method. It requires some artistic creativity. It requires operating efficiently within some community.

It also (usually) does not require the rigor of engineering because it's ephemeral, and it doesn't require the proof of science because it's every changing, there is no truth.

It's software, and that's not better or worse than engineering it's just different.


Absolutely not. My job title is "engineer" but compared to what my dad does, mechanical engineering, it's much more an art with bits of actual engineering and mathematical rigour sprinkled on top. I honestly think I should be called a developer and leave it at that. I don't think of myself as an engineer in all honesty.


I call myself an engineer so I stay in the family's grace :D My grandfather is a civil engineer, my father a systems engineer, so I am... a software engineer.


Does it matter if we are or aren't? I think some of us are, I think some folks are artists, some are scientist, some are laborers. It doesn't really matter because at the end of the day, unlike other disciplines all of these people can come together, collaborate, and produce things that captivate people, business, science, etc...

I tend refer to myself as a generalist because I'm not sure one label really fits. I do a bunch of different things, but the reality is I'm just trying to add value for myself, my customer, my teams and my business and I do it mostly with my thoughts and a computer.


The difference is simple. We are not engineers for the same reason cheerleaders are not athletes.

There is too much money to be made by trivializing the industry and the players involved benefit greatly by lobbying against it being "real" engineering.

Whats the difference between a skyscraper and pool house in terms of "real" engineering. Nothing. Whats the differene between a spacecrafts code engineering and a website. Nothing.

There are just lower stakes and it is used as a straw-man against professionalizing the industry of software.


I had the privilege of sharing office space with the engineers at a former employer, with at one point sitting next to a chemical engineer on my left and a mechanical engineer on my right. The former spent all day analyzing formulations and generating test data, and the latter spent all day putting together various parts and gizmos in SolidWorks. To me the biggest difference between us (besides the work itself) was process -- this half of the engineering department was full of it. And it was respected. There were notebooks describing process for every little thing, and so much of the work produced had to be signed off on.

We sometimes worked together closely, as we were building machines that were driven by software, and I felt respected by them and they seemed comfortable with us being titled Software Engineers. We seemed to share a similar mindset and curiosity about the world and discussions tended towards the scientific.

Though, I would note that that software org spent a lot of time writing things in-house; our department had almost zero integration with outside vendors save those that were performing some other service for us. I am not sure that this modern flavor of "software engineering," where it seems more time is spenting thinking about how to glue together various services, resembles what we did there.


> "Consider chemical engineering. Chemical engineering is unlike mechanical, civil, or electrical engineering. Chemical engineers create processes to manufacture products at scale, often using experimentation and iteration. But nobody would disagree that it is engineering. Chemical engineering started in the late 1800s, before states licensed engineers. If chemical engineering started now, people would refuse to call it engineering. And they’d be wrong to refuse."

This induced a little painful wincing. Chemical engineering relies heavily on detailed knowledge of fluid mechanics, because industrial chemical processes generally take place in liquid or gas phase, often under conditions of high pressure and temperature, and so you do indeed need the same kind of general approach that the other listed fields of engineering apply. They rely on mathematical models, to ensure that you don't get explosions (ideally anyway), etc. They need to be able to calculate things like the pressure at the bottom of an oil storage tank and so on. Look at any textbook on fluid mechanics for chemical engineers, it's the same kind of thing.

The author may be thinking of something like organic chemists who work in tamer lab settings, devising new reactions at benchtop scale, but organic chemists generally aren't going to be able to scale up a promising benchtop process without the input of a chemical engineer who has a detailed knowledge of fluid mechanics. Nobody refers to such organic chemists as 'engineers' in my experience, I think the more generally accepted terms are 'researcher' or 'scientist'.


You and the article are both right. Chemical engineering does rely on that knowledge, but plenty of it is done via experimentation. Process controls are largely developed through a lot of experimentation and data collection to understand how a process responds to various inputs.

There was a great comment elsewhere about how engineering is about dealing with the unknowns and noise of the real world, which is why engineering requires empirical evidence to further refine or create those models. Engineers may use models to calculate estimates but it all needs to be backed up by data.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: