Are We Really Engineers? (2021)(hillelwayne.com)
hillelwayne.com
Are We Really Engineers? (2021)
https://www.hillelwayne.com/post/are-we-really-engineers/
410 コメント
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 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.
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.
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.
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.
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.
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.
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.
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)
(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.
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).
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
>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.
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.
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.
[deleted]
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)
(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)
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)
[deleted]
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".
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.
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_...
[deleted]
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.
[deleted]
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.
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.
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.
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?
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"?
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 .
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).
[deleted]
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?
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.
[deleted]
> 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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
[deleted]
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.
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.
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.
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.
(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?
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.
> 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.
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.
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.
> 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. 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.
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.
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.
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.
[deleted]
> 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.
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.
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.
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 :)
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
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?
(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. :-)
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?
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.
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.
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.
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)
> (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.
> 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...).
> 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.
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'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.
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
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.
> (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.
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?
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
[deleted]
> 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.
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.
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?
> 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.
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.
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.
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.
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.
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 ...
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.
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?
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.
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.
> 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).
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.
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?"
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.
"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!
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.
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.
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.
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.
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.
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.
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.
‘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".
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?)
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.
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.
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.
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.
[deleted]
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
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.
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.
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.
> 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.
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.
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.
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".
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 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?
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.
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.
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.
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'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.
[deleted]
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.
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.
[deleted]
[deleted](1)
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.
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.
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.
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.
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.
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'.
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.
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.
Yes, some of us are: I take the position that whether software engineering is an appropriate term does depend on the individual and the team and organization they are embedded on. There are individuals, teams and organizations where the term "software engineering" is fitting, whereas others do not deserve it.
For many years, a lot of software development was pioneering (many projects build the first X of its kind e.g. the first OS, the first word processor, the first spreadsheet, the first Web browser). Bridge construction, in contrast, is older, so not as many bridges are pioneering new techniques. The predictability that is associated with trad. engineering can only take hold once things of a kind have been done often enough so best practices can emerge.
BTW, software engineering isn't the only type of non-traditional engineering: the University of Cambridge has one of Europe's best engineering departments; part of it is a group called Information Engineering, where software systems and models for e.g. speech recognition are researched and developed.
For many years, a lot of software development was pioneering (many projects build the first X of its kind e.g. the first OS, the first word processor, the first spreadsheet, the first Web browser). Bridge construction, in contrast, is older, so not as many bridges are pioneering new techniques. The predictability that is associated with trad. engineering can only take hold once things of a kind have been done often enough so best practices can emerge.
BTW, software engineering isn't the only type of non-traditional engineering: the University of Cambridge has one of Europe's best engineering departments; part of it is a group called Information Engineering, where software systems and models for e.g. speech recognition are researched and developed.
Glad to see this come up, because maybe five years ago I had an argument about this with a guy at a tiki bar in Vegas during CES.
I don't remember what argument I made (again, because it was at a bar in Vegas), but it was potent enough that he and his girlfriend relocated to another part of the bar. People have surprisingly strong opinions about this.
The term "engineer" has been bastardized over the last 40 years. Housewives became "domestic engineers." Janitors became "custodial engineers." Garbage men because "waste handling engineers." None of them are engineers. If I was an engineer, I hope I'd be more amused than miffed.
But as far as I'm concerned, engineering is a science; software is an art. But it's not like "artist" hasn't been bastardized in recent years. Witness the Subway "sandwich artist." Renoir tosses in his grave. Picasso, not so much.
I don't remember what argument I made (again, because it was at a bar in Vegas), but it was potent enough that he and his girlfriend relocated to another part of the bar. People have surprisingly strong opinions about this.
The term "engineer" has been bastardized over the last 40 years. Housewives became "domestic engineers." Janitors became "custodial engineers." Garbage men because "waste handling engineers." None of them are engineers. If I was an engineer, I hope I'd be more amused than miffed.
But as far as I'm concerned, engineering is a science; software is an art. But it's not like "artist" hasn't been bastardized in recent years. Witness the Subway "sandwich artist." Renoir tosses in his grave. Picasso, not so much.
This guy seems to think that engineers only make things that are dangerous.
Sure, there are engineers that build bridges. But there are also enormous numbers of computer engineers that build custom ASICs for, I dunno, TVs and Furbies. There are electrical engineers that build RF tag antennae for cartons in warehouses. There are chemical engineers who design more tasty marshmallows.
On the other hand, there are also computer scientists who build software for nuclear power plants and fighter jets, which must be perfect or people will die.
This is the problem with traditional engineering as a discipline: they require certification as a gatekeeping mechanism, under the pretense that some engineers do things that require safety protocols. Thus Real Engineers are certified to do Dangerous Work.
To me engineering is simply the application of math and science to design and ultimately build. In this respect, computer scientists are inarguably engineers.
Sure, there are engineers that build bridges. But there are also enormous numbers of computer engineers that build custom ASICs for, I dunno, TVs and Furbies. There are electrical engineers that build RF tag antennae for cartons in warehouses. There are chemical engineers who design more tasty marshmallows.
On the other hand, there are also computer scientists who build software for nuclear power plants and fighter jets, which must be perfect or people will die.
This is the problem with traditional engineering as a discipline: they require certification as a gatekeeping mechanism, under the pretense that some engineers do things that require safety protocols. Thus Real Engineers are certified to do Dangerous Work.
To me engineering is simply the application of math and science to design and ultimately build. In this respect, computer scientists are inarguably engineers.
A lot of those other things are (potentially) dangerous too. TVs and furbies with electronics in them could give you an electric shock or start a fire. Bad marshmallows could poison you or give you cancer.
The people writing the software for power plants or jets should be licensed software engineers, not coding bootcamp alumni. The whole point of licensure is to add a degree of accountability to any job which involves danger to the public.
The people writing the software for power plants or jets should be licensed software engineers, not coding bootcamp alumni. The whole point of licensure is to add a degree of accountability to any job which involves danger to the public.
> TVs and furbies with electronics in them could give you an electric shock or start a fire
In no universe will a small low-voltage chip cause a fire except in exceptional circumstances. This is a non-dangerous product. But you can only design one if you are a certified engineer.
Most engineering tasks are harmless. They require certification and licensing largely as a gateway mechanism, like being a beautician. No one says that people who design harmless products aren't "electrical engineers" or "computer engineers". Danger certainly isn't the defining feature of engineering -- gateway certification might be, but shouldn't be.
And on the flip side, it is absolutely the case that for designing software which is potentially dangerous should require certification and liability considerations. Do these guys get to be called engineers then? What if all they do with their certification is make video games?
In no universe will a small low-voltage chip cause a fire except in exceptional circumstances. This is a non-dangerous product. But you can only design one if you are a certified engineer.
Most engineering tasks are harmless. They require certification and licensing largely as a gateway mechanism, like being a beautician. No one says that people who design harmless products aren't "electrical engineers" or "computer engineers". Danger certainly isn't the defining feature of engineering -- gateway certification might be, but shouldn't be.
And on the flip side, it is absolutely the case that for designing software which is potentially dangerous should require certification and liability considerations. Do these guys get to be called engineers then? What if all they do with their certification is make video games?
I don’t know what kind of batteries are in furbies but my childhood friend’s house burned down due to a battery charger catching fire. These were AA batteries recharging. It absolutely is the case that low voltage devices like AA batteries can catch fire if there is a short inside them when they’re charging.
I believe the real core part of being a licensed engineer is you can be personally liable for mistakes in plans you sign off on, and to be able to do this you need to take exams and complete training showing you're capable of doing this correctly. This isn't a thing in programming.
This is pretty interesting to me.
I think most software developers think of engineering as making sure the software will perform under stress. But this requirement is (usually) meaningless from a customer safety standpoint. Sure it sucks if the system breaks, but unless your business model is also safety critical, that failure isn't a safety problem.
But leaking customer data is a safety problem. So for most people, software engineering should as much (or more) about security as things like time complexity tradeoffs.
I think most software developers think of engineering as making sure the software will perform under stress. But this requirement is (usually) meaningless from a customer safety standpoint. Sure it sucks if the system breaks, but unless your business model is also safety critical, that failure isn't a safety problem.
But leaking customer data is a safety problem. So for most people, software engineering should as much (or more) about security as things like time complexity tradeoffs.
It is a thing for software engineering students at University of Waterloo. They take physics and chemistry courses and learn all about safety and various standards. They write exams and at the end they become licensed professional engineers with iron rings.
But there are very few software projects that have this level of rigor that I'm aware of, right? I've not heard of a project where a software engineer has had to sign off on it like a civil engineer signs off a bridge. Maybe they exist! But I've worked on critical systems and yet to see this in practice.
I think you’re right. However, I do know that CSPE [1] is trying to change this. It’s a bit of an uphill battle for them, though. Ideally (for them) there would be new laws in place mandating professionally certified software engineers signing off on projects.
Having said that, it would probably take a bunch of high profile disasters to move the needle on the issue, politically speaking.
Having said that, it would probably take a bunch of high profile disasters to move the needle on the issue, politically speaking.
This is exactly what's discussed as the misconception 'Engineering is high-consequence' in TFA:
"It does mean that the engineers spent a lot of time on something that’s low-consequence or non-safety critical. In retrospect, this shouldn’t have surprised me. The world is vast and our industry is huge. Someone needs to design the bridges, yes, but someone also needs to design all of the little things we use in our day-to-day life. Much of the engineering there is low-stakes, low-consequence, just like much software is."
"It does mean that the engineers spent a lot of time on something that’s low-consequence or non-safety critical. In retrospect, this shouldn’t have surprised me. The world is vast and our industry is huge. Someone needs to design the bridges, yes, but someone also needs to design all of the little things we use in our day-to-day life. Much of the engineering there is low-stakes, low-consequence, just like much software is."
Sometimes when I read these the discussions I get the impression that software engineers think "real" engineering is about making life or death decisions all the time, but a lot of the work is so systematized it can turn into enormous amounts of paperwork. Especially as the things you work on become more deadly.
Before I went into web development I worked briefly as a mechanical engineer on nuclear power plants, and I feel like I more critical thinking when I'm pushing code to prod than I ever did reviewing load calculations on coolant pipes (despite how important a functioning cooling system might actually be)
Also want to point out that most aerospace engineers have no certification outside of a college degree, at least in the US.
Before I went into web development I worked briefly as a mechanical engineer on nuclear power plants, and I feel like I more critical thinking when I'm pushing code to prod than I ever did reviewing load calculations on coolant pipes (despite how important a functioning cooling system might actually be)
Also want to point out that most aerospace engineers have no certification outside of a college degree, at least in the US.
People focus on the life-or-death decisions because they are more dramatic, but really any time you are making physical devices you'd probably prefer a boring design. If you are planning to make a billion little computer chips to go in silly toys or whatever, you probably want to minimize the creativity for most of the design.
The article literally spends an entire section rejecting the belief that real engineers work only on dangerous things. The title is "Engineering is high-consequence", and discusses how one of the hardest problems an engineering team dealt on one project with was designing the handle for a device.
>To me engineering is simply the application of math and science to design
This still excludes the majority of what software engineers do. Sure, a little bit of it is carefully designed and applies complex math, but the majority isn't really math or science related at all.
This still excludes the majority of what software engineers do. Sure, a little bit of it is carefully designed and applies complex math, but the majority isn't really math or science related at all.
I studied Engineering in university (Electrical was my primary discipline, but in the first year we also spent some time on Civil, Chemical and Materials Eng) before later moving onto Software Engineering as a career.
To me, the biggest difference between SWE and the other "real" Engineering disciplines is about respect for the laws of physics.
Engineers from the classical disciplines have a deep understanding of the immutability of physical laws, and build mental models that accurately represent this as best they can. SWEs, on the other hand, have a tendency to build mental models that are more conceptual or metaphysical, and try and force these onto real-world silicon.
(This is somewhat idealised, of course. There are hack engineers that don't understand first principles in the slightest, just as there are software engineers who have no high-level understanding of the code they just copy-pasted from Stack Overflow).
To me, the biggest difference between SWE and the other "real" Engineering disciplines is about respect for the laws of physics.
Engineers from the classical disciplines have a deep understanding of the immutability of physical laws, and build mental models that accurately represent this as best they can. SWEs, on the other hand, have a tendency to build mental models that are more conceptual or metaphysical, and try and force these onto real-world silicon.
(This is somewhat idealised, of course. There are hack engineers that don't understand first principles in the slightest, just as there are software engineers who have no high-level understanding of the code they just copy-pasted from Stack Overflow).
That is an interesting distinction. Laws of physics are clearly a constraint to whatever is being engineered. In software development this sometimes plays a role too, more so on embedded and real-time systems. Real-time systems have a time constraints which is a law of physics and embedded software development has to incorporate memory, cpu and sometimes thermal constraints.
I do consider software for these systems closer to engineering, so you might be on to something. That doesn't mean I'd exclude other software development but the notions of (law of physics) constraints and predictable outcome are important factors.
I do consider software for these systems closer to engineering, so you might be on to something. That doesn't mean I'd exclude other software development but the notions of (law of physics) constraints and predictable outcome are important factors.
> SWEs, on the other hand, have a tendency to build mental models that are more conceptual or metaphysical, and try and force these onto real-world silicon.
Aka if you are a good software engineer you understand well how hardware works and how to push the boundaries.
If you a Stack Overflow copypaste technician you are nowhere near an engineer.
Aka if you are a good software engineer you understand well how hardware works and how to push the boundaries.
If you a Stack Overflow copypaste technician you are nowhere near an engineer.
>Aka if you are a good software engineer you understand well how hardware works and how to push the boundaries.
It's not even necessarily about pushing the boundaries and milking every last drop out of the hardware; there's a culture amongst even productive senior software engineers of handwaving over hardware altogether.
From my experience, bringing up optimisations or performance around non-embedded, non-gaming software engineers will invariably steer the discussion towards big-O notation and algorithmic abstractions.
It's not even necessarily about pushing the boundaries and milking every last drop out of the hardware; there's a culture amongst even productive senior software engineers of handwaving over hardware altogether.
From my experience, bringing up optimisations or performance around non-embedded, non-gaming software engineers will invariably steer the discussion towards big-O notation and algorithmic abstractions.
> I found in my research that people defending the title “engineer” rarely coherently define what an engineer is, usually boiling it down to “engineers solve problems”. The arguments against the title tend to be a little more developed, as are the arguments about transcending it.
It's a pity the author didn't go into more detail about why problem-solving is not the key defining characteristic of engineers. Since the author claims this is somehow not coherent enough, I'll share my very strong view that this is exactly what separates engineers from programmers:
Engineers apply technology to solve problems. They are rarely interested in technology just for the sake of it (that's what scientists are for), but rather in what it can do for them.
Most people in our industry today are far from being engineers. Engineers don't pick their technologies based on hype (or more charitably, excitement), and then try to find problems to solve. That's how some companies ended up using machine learning for projects where simpler statistical methods would have sufficed. It's how inexperienced developers fell for MongoDB's marketing and jumped straight to using it without considering whether it's better for their use case than the alternatives. It explains how at some point a ton of companies were using blockchain for things that could have been done with centralised databases (although that one's likely more due to company executives trying to impress investors).
If you’re always focused on using the latest thing, you’ll always have a solution in search of a problem. Reach for new tools when you have or anticipate a problem that you think might reasonably be solved by such tools. Do that and you've at least inched a bit closer to being able to reasonably refer to yourself as software engineer... if that's your thing - I'm generally not a fan of the title myself, but the engineering mindset is the most important thing I look for when interviewing candidates.
It's a pity the author didn't go into more detail about why problem-solving is not the key defining characteristic of engineers. Since the author claims this is somehow not coherent enough, I'll share my very strong view that this is exactly what separates engineers from programmers:
Engineers apply technology to solve problems. They are rarely interested in technology just for the sake of it (that's what scientists are for), but rather in what it can do for them.
Most people in our industry today are far from being engineers. Engineers don't pick their technologies based on hype (or more charitably, excitement), and then try to find problems to solve. That's how some companies ended up using machine learning for projects where simpler statistical methods would have sufficed. It's how inexperienced developers fell for MongoDB's marketing and jumped straight to using it without considering whether it's better for their use case than the alternatives. It explains how at some point a ton of companies were using blockchain for things that could have been done with centralised databases (although that one's likely more due to company executives trying to impress investors).
If you’re always focused on using the latest thing, you’ll always have a solution in search of a problem. Reach for new tools when you have or anticipate a problem that you think might reasonably be solved by such tools. Do that and you've at least inched a bit closer to being able to reasonably refer to yourself as software engineer... if that's your thing - I'm generally not a fan of the title myself, but the engineering mindset is the most important thing I look for when interviewing candidates.
As engineers in Canada you have a Ritual to Calling which is supposed to be similar to an oath to public safety above all. And to be a professional engineer you have to go through a training period and a final test to be considered. I am mostly talking about physical engineers here (Civil, Chemical, Mechanical, Electrical, etc)
That said - the term engineer (software engineer specifically) has been heavily diluted - same as data scientist - to the point of irrelevance or that it points to some basic proficiency of understanding and capability and not some level of mathematical knowledge. There are lots of exceptions and many people who are highly adept and capable but I wouldn't say that is an accurate portrayal of the entire class of title-holders.
That said - the term engineer (software engineer specifically) has been heavily diluted - same as data scientist - to the point of irrelevance or that it points to some basic proficiency of understanding and capability and not some level of mathematical knowledge. There are lots of exceptions and many people who are highly adept and capable but I wouldn't say that is an accurate portrayal of the entire class of title-holders.
> engineer (software engineer specifically) has been heavily diluted
Oh, it goes way beyond that and has for decades. When I was in the oil business, you saw all manner of job titles with engineer on them like (drilling) mud engineer that people would joke were actually mud salesmen which they basically were.
And the computer company I worked for for a long time used system engineer for a pre-sales role that supported the account reps.
Oh, it goes way beyond that and has for decades. When I was in the oil business, you saw all manner of job titles with engineer on them like (drilling) mud engineer that people would joke were actually mud salesmen which they basically were.
And the computer company I worked for for a long time used system engineer for a pre-sales role that supported the account reps.
Why focus on the argument of “Engineering is Mathematical” and ignore “Engineering Uses Scientific Knowledge to Solve Problems?” I’m not heavily invested in the outcome I just found it curious to only focus on mathematical usage as that’s easy to apply to software.
Where did the term "software engineer" originate?
Early part of my career, working at non-tech companies, everyone was a "developer".
Many years later, I was exposed to the world of Silicon Valley tech companies, where people were referring to themselves as "software engineers".
Even now, at most non-tech companies the term "developer" is probably more widely used, though even these companies are now starting to switch to using "engineer". Most of the younger employees these non-tech companies hire use "engineer", but talking to the older veterans, they still refer to themselves as "developers" more often than not.
Early part of my career, working at non-tech companies, everyone was a "developer".
Many years later, I was exposed to the world of Silicon Valley tech companies, where people were referring to themselves as "software engineers".
Even now, at most non-tech companies the term "developer" is probably more widely used, though even these companies are now starting to switch to using "engineer". Most of the younger employees these non-tech companies hire use "engineer", but talking to the older veterans, they still refer to themselves as "developers" more often than not.
Does it even matter? It doesn't, this is like comparing apples to oranges. The biggest reason there is more rigor in other fields is because they are less iteration-friendly.
I personally call myself a programmer, even if my job title says engineer.
I personally call myself a programmer, even if my job title says engineer.
I really like the writing style on this. Very practical and readable, while getting straight at the interesting philosophical questions and not using a bunch of vapid filler.
Also here's a take: yeah, software engineering is engineering, it's just really _bad_ engineering which is why we're missing most of the things you'd expect to see in an engineer. We're in the early days of the craft, like 20% of the way to wherever it will end up, and we're doing the equivalent of, say, the structural engineering that goes into building a log cabin.
Also here's a take: yeah, software engineering is engineering, it's just really _bad_ engineering which is why we're missing most of the things you'd expect to see in an engineer. We're in the early days of the craft, like 20% of the way to wherever it will end up, and we're doing the equivalent of, say, the structural engineering that goes into building a log cabin.
[deleted]
I think this is the key point, and it's one I'd agree with "...software engineering is real engineering, but a lot of people who write software aren’t doing software engineering."
Personally I would probably draw the circle of software engineers fairly tightly and acknowledge that the rest of us are programmers, or developers, or software architects, or plumbers.
I'd certainly exclude someone like myself from the magic circle of software engineer. My career started accidentally in economic and environmental modeling (ah GAMS, my psycho ex, how I miss you), currently involves creating addons for Blender, went through a brief CRUD app phase back when Facebook was young (shudder) and has involved random trips into data science at various points. I'd also exclude virtually everyone I've ever worked with if I'm honest because most of what I've worked on has either been bespoke and artisanal and so was been software crafting, or it's essentially been plumbing together systems designed by real software engineers and then prettying up the resultant monster. Despite that I've had the title software engineer a few times, as have lots of my colleagues.
I'm not sure that the author is right in saying that it is easier for programmers to transform into software engineers than tradesmen into real engineers. I definitely think that in both cases some seriously heavy training and a lot of unlearning needs to be done.
Personally I would probably draw the circle of software engineers fairly tightly and acknowledge that the rest of us are programmers, or developers, or software architects, or plumbers.
I'd certainly exclude someone like myself from the magic circle of software engineer. My career started accidentally in economic and environmental modeling (ah GAMS, my psycho ex, how I miss you), currently involves creating addons for Blender, went through a brief CRUD app phase back when Facebook was young (shudder) and has involved random trips into data science at various points. I'd also exclude virtually everyone I've ever worked with if I'm honest because most of what I've worked on has either been bespoke and artisanal and so was been software crafting, or it's essentially been plumbing together systems designed by real software engineers and then prettying up the resultant monster. Despite that I've had the title software engineer a few times, as have lots of my colleagues.
I'm not sure that the author is right in saying that it is easier for programmers to transform into software engineers than tradesmen into real engineers. I definitely think that in both cases some seriously heavy training and a lot of unlearning needs to be done.
The reason it is easier for programmers to transform into software engineers is the same reason we are having this conversation. For the most part, I think this is because software is so cheap and accessible. Anyone can become a software artisan with just a laptop and time. For traditional engineering, you need resources.
Here's a quote from the second post:
"When it comes to things like making circuit boards, it’s pretty common for things not to work the first time. You have to do it again, and you have to send it out to the factory and do it again. You know it costs you another however many £1000 and another two weeks on the schedule. -Mike (electrical)"
If building software was expensive like engineering in the physical world, we wouldn't have to have this argument. It's too bad that physical engineering is so expensive, because we'd probably have a lot more people trying it out.
If building software was expensive like engineering in the physical world, we wouldn't have to have this argument. It's too bad that physical engineering is so expensive, because we'd probably have a lot more people trying it out.
"Engineers work on predictable projects with a lot of upfront planning and rigorous requirements. Software is dynamic, constantly changing, unpredictable."
Ask someone building medical robots if their software is unpredictable. Or someone building a car ECU. Or an airplane guidance system. Or controls for industrial machinery. Or telecom equipment.
Our entire industry literally follows a manifesto whose purpose was to eliminate upfront planning and rigorous requirements, called "Agile". It was an intentional choice to be irresponsible, and we all ate it up because it meant we didn't have to do any due diligence. Just churn out software turds as fast as you can, get a big smile and a thumbs up from the user, and you're done.
Who cares if tomorrow it fails and the thermostats for 10,000 houses goes out in the middle of winter? At least we didn't have to write documentation! Moving too fast over here, can't be worried about shit like "making sure it's safe" !
Oh, whoops!, every social security number in the country is exposed. But we could never have prevented that, we write software, it's inherently unpredictable!
It's all too predictable. The industry is led by children who don't know how to do their jobs, there are no industry requirements or certifications, and there is no trade school to really learn. Can you imagine an electrician wiring your house up after a 6 week "boot camp" ? Or a mechanical engineering intern building a bridge?
Ask someone building medical robots if their software is unpredictable. Or someone building a car ECU. Or an airplane guidance system. Or controls for industrial machinery. Or telecom equipment.
Our entire industry literally follows a manifesto whose purpose was to eliminate upfront planning and rigorous requirements, called "Agile". It was an intentional choice to be irresponsible, and we all ate it up because it meant we didn't have to do any due diligence. Just churn out software turds as fast as you can, get a big smile and a thumbs up from the user, and you're done.
Who cares if tomorrow it fails and the thermostats for 10,000 houses goes out in the middle of winter? At least we didn't have to write documentation! Moving too fast over here, can't be worried about shit like "making sure it's safe" !
Oh, whoops!, every social security number in the country is exposed. But we could never have prevented that, we write software, it's inherently unpredictable!
It's all too predictable. The industry is led by children who don't know how to do their jobs, there are no industry requirements or certifications, and there is no trade school to really learn. Can you imagine an electrician wiring your house up after a 6 week "boot camp" ? Or a mechanical engineering intern building a bridge?
A long time ago when this was discussed someone suggested "software gardener" would be a good term. As a professional software developer and hobby gardener I kind of agree.
I think engineering is an attitude.
Disclosure: I'm not an engineer, but a scientist working among engineers.
Historically, we got away with letting engineering be defined by the curricula and credentialing of the traditional engineering disciplines such as civil, electrical, and so forth. And by the cultures of companies that did engineering well. It was hard enough, and took long enough, that a shared culture tended to rub off on people without needing to define it.
One tradition was that an "engineer" was qualified to approve a design, with some authority and responsibility for the outcome.
Partly as a way to increase the number of engineers in the mid 20th century, engineering adopted an "engineering handbook" approach, where engineers learned how to choose and apply standard formulas for solving specific kinds of problems, such as sizing pipes, wiring, and so forth. More recently, this is being gradually replaced by the use of high level software tools such as electrical and mechanical modeling. Engineers are reluctant to let testing alone be a criterion for approval of a design.
Software is too new to have such a history, and admits of a much wider variety of entry routes. It may be too early to know what software engineering consists of.
Disclosure: I'm not an engineer, but a scientist working among engineers.
Historically, we got away with letting engineering be defined by the curricula and credentialing of the traditional engineering disciplines such as civil, electrical, and so forth. And by the cultures of companies that did engineering well. It was hard enough, and took long enough, that a shared culture tended to rub off on people without needing to define it.
One tradition was that an "engineer" was qualified to approve a design, with some authority and responsibility for the outcome.
Partly as a way to increase the number of engineers in the mid 20th century, engineering adopted an "engineering handbook" approach, where engineers learned how to choose and apply standard formulas for solving specific kinds of problems, such as sizing pipes, wiring, and so forth. More recently, this is being gradually replaced by the use of high level software tools such as electrical and mechanical modeling. Engineers are reluctant to let testing alone be a criterion for approval of a design.
Software is too new to have such a history, and admits of a much wider variety of entry routes. It may be too early to know what software engineering consists of.
> we actually use discrete math, where we deal exclusively with non-continuous numbers. This includes things like graph theory, logic, and combinatorics. You might not realize that you are using these, but you do. They’re just so internalized in software that we don’t see them as math!
I strongly disagree with this level of charity. That's like saying every cyclist is a physicist.
Someone who takes a short programming course might not even have heard the term discrete mathematics, and almost certainly won't be qualified to develop a proof of correctness for an algorithm, i.e. to actually do discrete mathematics in a serious sense.
> most of computer science is viewable as a branch of mathematics
And yet there's a world of difference between a computer scientists and the average software developer.
> Every time you simplify a conditional or work through the performance complexity of an algorithm, you are using math. Just because there are no integrals doesn’t mean we are mathless.
But the absence of doing math surely does make someone (or some line of work) mathless. Most software developers go their whole careers doing no serious math.
> Just because we use a different branch of math doesn’t mean we’re not doing engineering.
Perhaps the argument can be made that engineering doesn't necessarily have to include math, but this isn't the way to make it.
Again, the average developer does not know any mathematical field in any real depth. This is in sharp contrast to, say, aeronautical engineers.
> Whether or not we are engineers is irrelevant to whether or not we are good engineers.
Disagree. If the term engineer has any meaning, it has to indicate some level of competence. The bar has to be set somewhere.
We all agree that changing a car tyre does not qualify someone as any sort of engineer. Is it controversial to suggest that something analogous should hold for software work?
The later Craft vs Engineering section makes far more sense to me.
edit:
> We are separated from engineering by circumstance, not by essence, and we can choose to bridge that gap at will.
I think this is a matter of market forces rather than a community-wide failure.
There's high demand for software developers, including for inexperienced software developers with little formal training. This is, at least in principle, a fine thing (ignoring things like major security issues arising from incompetence). Someone who completes a brief course on programming may be called a software developer, and a professor specialising in critical software systems might be called the same.
It's not like nuclear engineering where there's a formal system of gatekeeping. Provided we don't ignore the spectrum of expertise, I don't see a reason to worry about software work being intellectually disreputable by nature.
I strongly disagree with this level of charity. That's like saying every cyclist is a physicist.
Someone who takes a short programming course might not even have heard the term discrete mathematics, and almost certainly won't be qualified to develop a proof of correctness for an algorithm, i.e. to actually do discrete mathematics in a serious sense.
> most of computer science is viewable as a branch of mathematics
And yet there's a world of difference between a computer scientists and the average software developer.
> Every time you simplify a conditional or work through the performance complexity of an algorithm, you are using math. Just because there are no integrals doesn’t mean we are mathless.
But the absence of doing math surely does make someone (or some line of work) mathless. Most software developers go their whole careers doing no serious math.
> Just because we use a different branch of math doesn’t mean we’re not doing engineering.
Perhaps the argument can be made that engineering doesn't necessarily have to include math, but this isn't the way to make it.
Again, the average developer does not know any mathematical field in any real depth. This is in sharp contrast to, say, aeronautical engineers.
> Whether or not we are engineers is irrelevant to whether or not we are good engineers.
Disagree. If the term engineer has any meaning, it has to indicate some level of competence. The bar has to be set somewhere.
We all agree that changing a car tyre does not qualify someone as any sort of engineer. Is it controversial to suggest that something analogous should hold for software work?
The later Craft vs Engineering section makes far more sense to me.
edit:
> We are separated from engineering by circumstance, not by essence, and we can choose to bridge that gap at will.
I think this is a matter of market forces rather than a community-wide failure.
There's high demand for software developers, including for inexperienced software developers with little formal training. This is, at least in principle, a fine thing (ignoring things like major security issues arising from incompetence). Someone who completes a brief course on programming may be called a software developer, and a professor specialising in critical software systems might be called the same.
It's not like nuclear engineering where there's a formal system of gatekeeping. Provided we don't ignore the spectrum of expertise, I don't see a reason to worry about software work being intellectually disreputable by nature.
>> we actually use discrete math, where we deal exclusively with non-continuous numbers. This includes things like graph theory, logic, and combinatorics. You might not realize that you are using these, but you do. They’re just so internalized in software that we don’t see them as math!
> I strongly disagree with this level of charity. That's like saying every cyclist is a physicist.
Boolean logic, and while loops are proper examples of discrete math. They’re practiced by virtually every developer. An equivalent example from the world of continuous math could be integrating over some range.
> I strongly disagree with this level of charity. That's like saying every cyclist is a physicist.
Boolean logic, and while loops are proper examples of discrete math. They’re practiced by virtually every developer. An equivalent example from the world of continuous math could be integrating over some range.
Understanding the control-flow constructs of an imperative programming language is not equivalent to understanding the discrete maths of imperative programming (Hoare logic, Z notation, B-method, etc).
As I said, the average developer is incapable of doing serious discrete mathematics such as formally proving the correctness of an algorithm. For that matter, I doubt the average developer would know what it means for a language to have a formal semantics.
To anticipate the path of a frisbee is to, in mathematical terms, solve a differential equation. Dogs can catch frisbees. We still don't say that dogs understand the mathematics of differential equations. [0][1]
In the software world, formal methods are a niche, as are the associated mathematics. Being costly, they are not used in mainstream software work.
[0] (PDF) http://www.math.pitt.edu/~bard/bardware/classes/0220/dkc.pdf
[1] https://www.wired.com/1993/05/dogs/
As I said, the average developer is incapable of doing serious discrete mathematics such as formally proving the correctness of an algorithm. For that matter, I doubt the average developer would know what it means for a language to have a formal semantics.
To anticipate the path of a frisbee is to, in mathematical terms, solve a differential equation. Dogs can catch frisbees. We still don't say that dogs understand the mathematics of differential equations. [0][1]
In the software world, formal methods are a niche, as are the associated mathematics. Being costly, they are not used in mainstream software work.
[0] (PDF) http://www.math.pitt.edu/~bard/bardware/classes/0220/dkc.pdf
[1] https://www.wired.com/1993/05/dogs/
First I want to let you know that I didn't take it personally (all in jest), but I've never been so artfully called a dog in my life. Thanks for that :)
I'm sure cats could catch frisbees too, they just won't.
I'd rather be a dog. So what if I do know some discrete math and I do know what it means for a language to have a formal semantics? Does that make me an above average developer or a software engineer?
> So what if I do know some discrete math and I do know what it means for a language to have a formal semantics?
We were discussing whether the average software developer can be said to 'do math' in the sense that aeronautical engineers do. I think it's plain that the answer is no. Whether it matters is another topic.
As I said above, in terms of market forces, it's fine that most software developers go their whole careers doing no proper math. It's also true that some highly skilled software professionals are expert in the relevant math.
As to Are software developers engineers?, I hope it's uncontroversial to say Some of them are, some of them aren't. What's less clear, and less obvious, is where the bar should be set. Personally I consider only a small minority of software development work to be anywhere near engineering, but like the article notes, I don't have experience in any 'conventional' engineering field.
Given that router-installation technicians are called engineers these days, software isn't alone in its collision with the word.
We were discussing whether the average software developer can be said to 'do math' in the sense that aeronautical engineers do. I think it's plain that the answer is no. Whether it matters is another topic.
As I said above, in terms of market forces, it's fine that most software developers go their whole careers doing no proper math. It's also true that some highly skilled software professionals are expert in the relevant math.
As to Are software developers engineers?, I hope it's uncontroversial to say Some of them are, some of them aren't. What's less clear, and less obvious, is where the bar should be set. Personally I consider only a small minority of software development work to be anywhere near engineering, but like the article notes, I don't have experience in any 'conventional' engineering field.
Given that router-installation technicians are called engineers these days, software isn't alone in its collision with the word.
> And yet there's a world of difference between a computer scientists and the average software developer.
The world would be served by realizing how different these too skill sets are. I had professors who couldn't code their way out of a paper bag, and known successful devs who wouldn't know a proof if it walked up and bit them on the nose.
The world would be served by realizing how different these too skill sets are. I had professors who couldn't code their way out of a paper bag, and known successful devs who wouldn't know a proof if it walked up and bit them on the nose.
I would cast a really wide net and say that an engineer is someone who produces designs in compliance with the best methods for their particular field. I don't think most of us software folks are engineers, because the work-product in this field is usually a particular implementation, rather than a design. Last time I worked on a big project, the person whose job seemed the most engineer-y was the 'Software Architect' but I don't know if that title is standardized.
I think our fixation on this title is really silly and strange. I did an engineering degree, the math is a little easier than physics because we're aiming to get to the sort of standard answers, and then there's some extra memorization. I could understand people with no technical background at all being impressed by the title, but if you've done a CS or a Physics degree you've almost certainly seen harder problems. What's so cool about it? We just learned how to compose the answers as boringly as possible.
Edit: also most of my friends from engineering school went on to become programmers because it is more fun and you don't have to worry about letting the magic smoke out.
I think our fixation on this title is really silly and strange. I did an engineering degree, the math is a little easier than physics because we're aiming to get to the sort of standard answers, and then there's some extra memorization. I could understand people with no technical background at all being impressed by the title, but if you've done a CS or a Physics degree you've almost certainly seen harder problems. What's so cool about it? We just learned how to compose the answers as boringly as possible.
Edit: also most of my friends from engineering school went on to become programmers because it is more fun and you don't have to worry about letting the magic smoke out.
> getting the wires to bend correctly and the plastic onto this shiny piece of anodized aluminium wire. […] That was the thing that took three months in the project.
Well, there you go, that's how I know we're not really engineers. Because every software developer working reports to (or reports to somebody who reports to) somebody who lives by the maxim "if it takes more than an hour to do, it's not worth doing".
Well, there you go, that's how I know we're not really engineers. Because every software developer working reports to (or reports to somebody who reports to) somebody who lives by the maxim "if it takes more than an hour to do, it's not worth doing".
I was startled recently to see someone on Twitter sneer at a certain celebrity for not being an engineer. I checked, and he seems to have a degree in physics, and a job title (which may not be accurate) that has the word "Engineer" in it.
So, being tired of the debate about software developers, I'm wondering who else thinks that a physicist (by education) is not worthy of being called an engineer.
So, being tired of the debate about software developers, I'm wondering who else thinks that a physicist (by education) is not worthy of being called an engineer.
When Margaret Hamilton coined the term "software engineering", I believe she was thinking more along the lines of chemical engineering: whereas chemistry examines how chemicals work and maybe how to synthesize a given compound, chemical engineering is about designing processes to produce a chemical at scale so that it may be used in industry. And I think that's what software engineering should be about, if indeed there is such a field: the design of formalized processes that, when applied, can be used to write, deliver, deploy, maintain, and fix software at scale.
I also think up to this point we've mainly been LARPing at software engineering. To really do it, we are going to need as a first step tools that give us stronger assurances that the software will function as needed at scale. Things like unit tests and Rust's borrow checker get us part of the way there but we will need better tools that give us stronger guarantees when it comes to integrating various components.
I also think up to this point we've mainly been LARPing at software engineering. To really do it, we are going to need as a first step tools that give us stronger assurances that the software will function as needed at scale. Things like unit tests and Rust's borrow checker get us part of the way there but we will need better tools that give us stronger guarantees when it comes to integrating various components.
I think "Software Engineering" should mean "The study of how to best develop software".
That is different from "software development" which is the practice of developing software. Or you could say "software development" is applied Software Engineering.
When you build a house the engineering part is designing the house and designing the processes how to build it. The rest is just the building-part which is not really engineering.
In software you could say there is little difference between designing software and actually writing software. But the subtle difference is that whatever makes it GENERALLY easier to develop software is "engineering".
Engineering is a study of how to do things, not the actual doing of things. So I would say that someone who writes a compiler, or reusable library, is a software engineer when they are doing that. But if they are just writing code they are equivalent to a construction worker, not an engineer. You can of course be both, at different times.
That is different from "software development" which is the practice of developing software. Or you could say "software development" is applied Software Engineering.
When you build a house the engineering part is designing the house and designing the processes how to build it. The rest is just the building-part which is not really engineering.
In software you could say there is little difference between designing software and actually writing software. But the subtle difference is that whatever makes it GENERALLY easier to develop software is "engineering".
Engineering is a study of how to do things, not the actual doing of things. So I would say that someone who writes a compiler, or reusable library, is a software engineer when they are doing that. But if they are just writing code they are equivalent to a construction worker, not an engineer. You can of course be both, at different times.
I did a lot of different things in my career... I definitely saw engineering or at least saw something that was a gateway to engineering, but the challenge was that the vast majority of organizations had incentives that went another direction. Meaning, for most the cost and time to engage in any kind of disciplined behaviors was beyond what they were willing to do. Of course, the argument can be made that if they followed engineering practices it might have saved them time and money, but by and large companies don't have the knowledge to do things differently. You could argue that's why they hire software engineers - to show them how to do it right - but my own experiences were that most companies can't get out of their own way.
So, sure - there could be such a thing as software engineering, we could all be software engineers, but in most places we just hack along as programmers trying to hold it together with spit and baling wire.
So, sure - there could be such a thing as software engineering, we could all be software engineers, but in most places we just hack along as programmers trying to hold it together with spit and baling wire.
Maybe it’s the intangibility that lends to an attitude of less respect.
Designing something in the physical world like a road you can’t screw up or people might get hurt. You could say the same about software but only in a very few instances. There’s no necessary reverence for the laws of the natural world. Electricity and gravity will kill you.
Designing something in the physical world like a road you can’t screw up or people might get hurt. You could say the same about software but only in a very few instances. There’s no necessary reverence for the laws of the natural world. Electricity and gravity will kill you.
Hmmm. I don't necessarily know if I agree with that framing.
I think there's a lot of software out there that could cause severe harm if it weren't written well enough, or its use cases were not thoroughly thought through. Thinking of all the software that runs hospitals, banks, etc. And then all the indirect harm caused in consumer software (often among teens). Not to mention software written for evil purposes, such as that to take down power networks, support child trafficking, etc. I think there's a pretty strong case to by made that software is serious business. Even if fiddling around with terraform providers or whatever feel pointless sometimes.
I think there's a lot of software out there that could cause severe harm if it weren't written well enough, or its use cases were not thoroughly thought through. Thinking of all the software that runs hospitals, banks, etc. And then all the indirect harm caused in consumer software (often among teens). Not to mention software written for evil purposes, such as that to take down power networks, support child trafficking, etc. I think there's a pretty strong case to by made that software is serious business. Even if fiddling around with terraform providers or whatever feel pointless sometimes.
[deleted]
It depends what kind of programming you do if it can be called engineering or not. Most of software development is not engineering. The core difference in my mind is that engineering implies transferring abstracted design to physical reality (you have to understand physical limitations and constraints to do that). Programming most of the time is producing abstraction mechanisms that are quite detached from physical objects. A good comparison would be 3D modeling and sculpting. When sculpting you have to understand the properties of the stone and tools, but in 3D world almost anything is possible. If you can imagine - you can do it. https://tautvilas.medium.com/engineering-free-programming-is...
Does it matter?
Solve problems for people. Teach them how to solve bigger problems. Learn from them how to solve other problems. Make life better for people.
I don't care if that's called "engineer," "developer," "codemonkey," or "hooman." Just do the thing, and try to always get better at doing the thing.
Solve problems for people. Teach them how to solve bigger problems. Learn from them how to solve other problems. Make life better for people.
I don't care if that's called "engineer," "developer," "codemonkey," or "hooman." Just do the thing, and try to always get better at doing the thing.
[deleted]
I think we're more similar to writers. Code can be creative or artistic, but structure and discipline are important for anything large.
There are technical writers and there are creative writers. You can write about math or science or food.
Code has the same range.
Coding is just a form of expression and explanation, but machines are the readers not people
There are technical writers and there are creative writers. You can write about math or science or food.
Code has the same range.
Coding is just a form of expression and explanation, but machines are the readers not people
I think the more important question is whether tabs are better than emacs, or whether you should use BSD or vim.
I have 2 acquaintances, one is a Graphic Designer, the other is an Electrical Engineer who models and designs power grid controls.
The Graphic Designer stated out her career designing advertising material and magazine layouts and websites in Photoshop. Nowadays she has transitioned to using CSS/HTML directly, and then to React.
The other guys core competency is power distribution systems and modelling distributed control systems. He started using Matlab to help with his calculations, and develop computer models. The company he works for pivoted to selling grid modelling software, so he rewrote the models he did in Java.
Nowadays if you went on LinkedIn, both would have the title "Software Engineer". Both write code, but I'd argue that their core competencies are still entirely different.
The Graphic Designer stated out her career designing advertising material and magazine layouts and websites in Photoshop. Nowadays she has transitioned to using CSS/HTML directly, and then to React.
The other guys core competency is power distribution systems and modelling distributed control systems. He started using Matlab to help with his calculations, and develop computer models. The company he works for pivoted to selling grid modelling software, so he rewrote the models he did in Java.
Nowadays if you went on LinkedIn, both would have the title "Software Engineer". Both write code, but I'd argue that their core competencies are still entirely different.
Not disagreeing but in a lot of jurisdictions the Graphic Designer would not be able to use the Engineer title.
I mean, she is a frontend dev by all accounts - in most places, sadly, engineer is not a protected title - and colloquially people refer to frontend people as software engineers.
[deleted]
In Denmark we have a term that circumvents this issue completely. It was coined by Peter Naur in 1966: “Datalogi”. The discipline of understanding and working on data. I think it encapsulates the core of the profession really well while avoiding overlap with other disciplines.
I agree with the conclusion that we shouldn't shut the door.
It would be stupid to not try and take into account the experience of other engineering disciplines, just because "we don't fit the mold perfectly".
Sometimes it'll help, and sometimes it won't. What's interesting is to engage with other people.
I am lucky in that regard to have been trained in a French "engineering school", where I was trained in electrical engineering, electronical engineering, signal processing engineering, computer science, and logistics. People I was trained with work on the electricity grid, others on the noise that care tires make. There is no question that knowing concepts about electricity or control theory made me a better software engineer.
It would be stupid to not try and take into account the experience of other engineering disciplines, just because "we don't fit the mold perfectly".
Sometimes it'll help, and sometimes it won't. What's interesting is to engage with other people.
I am lucky in that regard to have been trained in a French "engineering school", where I was trained in electrical engineering, electronical engineering, signal processing engineering, computer science, and logistics. People I was trained with work on the electricity grid, others on the noise that care tires make. There is no question that knowing concepts about electricity or control theory made me a better software engineer.
The statement about math is inaccurate:
> [Standard engineering] is where we work over a continuous domain, like real numbers. Things like calculus, trigonometry, and differential equations are in this category. This is what most people in the US learn in high school, codifying it as what they think of as “math”.
> In software, we don’t use these things, leading to the conception that we don’t use math. But we actually use discrete math ...
It is false to say that we never work over a continuous domain in software. We have continuous domains in software all the time whether its audio-related software, self-driving cars, networking, or many other examples. And we definitely _also_ have to use discrete math alongside these continuous domains.
> [Standard engineering] is where we work over a continuous domain, like real numbers. Things like calculus, trigonometry, and differential equations are in this category. This is what most people in the US learn in high school, codifying it as what they think of as “math”.
> In software, we don’t use these things, leading to the conception that we don’t use math. But we actually use discrete math ...
It is false to say that we never work over a continuous domain in software. We have continuous domains in software all the time whether its audio-related software, self-driving cars, networking, or many other examples. And we definitely _also_ have to use discrete math alongside these continuous domains.
Yes, the OP states a good question.
My thought, going back some years, is that in some fields engineers work with strength of materials, e.g., what a steel I-beam will hold, and more generally work with, assemble, combine components with known properties. E.g., there are actual standards organizations that state the properties. In computing we have some of that -- components with known properties -- but not nearly enough.
I'm drawn in part to the possible analogy with Lego blocks -- components can just snap together.
This is a simple view, mostly because where we get to do engineering is small and where we don't, where the problems are, where we don't yet know how to do engineering, is large.
Reading this thread, it looks like some others give more than my simple view here. But I cast my vote with those who also agree, with more evidence than I'm presenting here, that in computing we need more engineering.
Once I did work with some people who wanted to regard a computing system as a network of queues and, then, apply queuing theory with, maybe, some probabilities and optimization. Supposedly they did apply such engineering to the design of an important I/O subsystem. So, that seems to have been an example of making software design engineering.
In engineered systems, it is common to monitor the systems for correct behavior, and I was in a project trying to do the monitoring with just judgment and guesstimates, in particular, thresholds selected just intuitively on one variable at a time. Of course, thresholds on several variables, one at a time, have the geometrical region of normal performance always just a box. Well, we can't believe that normal performance is accurately a box. So with a small box, get a lot of false alarms and with a big one, poor detection rates. Bummer.
Gee: Very commonly in monitoring, e.g., testing for a disease, we have for each test at least false alarm rate. We would also like detection rates. There is the famous, old Neyman-Pearson result on how to get the highest detection rate for any given false alarm rate. So, to do better than just judgment, I worked up a quite general test, with multi-dimensional data, including high dimensional, distribution-free, with known, adjustable false alarm rate and provable non-trivial detection rate. I published the thing. Soooo, that was a small step toward engineering for system monitoring.
We need more engineering.
My thought, going back some years, is that in some fields engineers work with strength of materials, e.g., what a steel I-beam will hold, and more generally work with, assemble, combine components with known properties. E.g., there are actual standards organizations that state the properties. In computing we have some of that -- components with known properties -- but not nearly enough.
I'm drawn in part to the possible analogy with Lego blocks -- components can just snap together.
This is a simple view, mostly because where we get to do engineering is small and where we don't, where the problems are, where we don't yet know how to do engineering, is large.
Reading this thread, it looks like some others give more than my simple view here. But I cast my vote with those who also agree, with more evidence than I'm presenting here, that in computing we need more engineering.
Once I did work with some people who wanted to regard a computing system as a network of queues and, then, apply queuing theory with, maybe, some probabilities and optimization. Supposedly they did apply such engineering to the design of an important I/O subsystem. So, that seems to have been an example of making software design engineering.
In engineered systems, it is common to monitor the systems for correct behavior, and I was in a project trying to do the monitoring with just judgment and guesstimates, in particular, thresholds selected just intuitively on one variable at a time. Of course, thresholds on several variables, one at a time, have the geometrical region of normal performance always just a box. Well, we can't believe that normal performance is accurately a box. So with a small box, get a lot of false alarms and with a big one, poor detection rates. Bummer.
Gee: Very commonly in monitoring, e.g., testing for a disease, we have for each test at least false alarm rate. We would also like detection rates. There is the famous, old Neyman-Pearson result on how to get the highest detection rate for any given false alarm rate. So, to do better than just judgment, I worked up a quite general test, with multi-dimensional data, including high dimensional, distribution-free, with known, adjustable false alarm rate and provable non-trivial detection rate. I published the thing. Soooo, that was a small step toward engineering for system monitoring.
We need more engineering.
Anyone can be an engineer. If you don't have a PE or an ABET accredited engineering degree then you may still be an engineer, although most likely you're something closer to a technologist (although your skills may be both more valuable and more in demand than an engineer's).
I have met maybe two people in my life that have learned the kind of first principles physics and mathematics basis outside of formal channels of academia or licensure. It's just really inconvenient and probably an inefficient use of time for most people to learn to be a classical engineer when you can make more or better by getting damn good at applying some technology (programming, welding, trucking, whatever).
I have met maybe two people in my life that have learned the kind of first principles physics and mathematics basis outside of formal channels of academia or licensure. It's just really inconvenient and probably an inefficient use of time for most people to learn to be a classical engineer when you can make more or better by getting damn good at applying some technology (programming, welding, trucking, whatever).
For the life of me I can't get invested in these semantic games. The author even acknowledges Wittgenstein!
This question only matters as regarding whether it has operational significance, and it's really hard to imagine a situation where the term would have any operational significance. The author says that we can benchmark against other engineering disciplines and look for guidance or inspiration if software is engineering. But we can do that whether or not we use the term! We can compare software to plumbing, and take away what we can, or compare it to law and take away what we can, or compare it to electrical engineering and take away what we can. The term itself is irrelevant here.
This question only matters as regarding whether it has operational significance, and it's really hard to imagine a situation where the term would have any operational significance. The author says that we can benchmark against other engineering disciplines and look for guidance or inspiration if software is engineering. But we can do that whether or not we use the term! We can compare software to plumbing, and take away what we can, or compare it to law and take away what we can, or compare it to electrical engineering and take away what we can. The term itself is irrelevant here.
I think this is bang on the money. Before asking _if_ software engineering is "real engineering" we should ask what we mean by engineering and why the question matters, otherwise it's a fruitless effort of talking past each other.
Hillel seems to want to ask if we're "real engineers" so that we can learn from the other engineering disciplines, especially on taking responsibility, which I think is a good way to frame the question.
Most of these comments seem to instead bicker about semantics, which I feel misses the opportunity to be more focused and constructive.
Hillel seems to want to ask if we're "real engineers" so that we can learn from the other engineering disciplines, especially on taking responsibility, which I think is a good way to frame the question.
Most of these comments seem to instead bicker about semantics, which I feel misses the opportunity to be more focused and constructive.
The word "engineer" has different etymologies in different languages. In English, this comes from the word "engine", which, in turn, from the Latin "ingenium" "talent, device."
In Arabic and Hebrew, "engineering" and "geometry" are the same word "handasa". So an engineer is someone who draws blueprints, measures/validates them, and those blueprints are later used to create something. My guess is that it comes from the architects building the ancient Egyptian pyramids (a simple geometric shape).
The first is more like craftsmanship, the second is more like modern engineering.
In Arabic and Hebrew, "engineering" and "geometry" are the same word "handasa". So an engineer is someone who draws blueprints, measures/validates them, and those blueprints are later used to create something. My guess is that it comes from the architects building the ancient Egyptian pyramids (a simple geometric shape).
The first is more like craftsmanship, the second is more like modern engineering.
Waterfall is Engineering
Agile is CraftsmanshipOn a side note I saw Renaissance Technologies still hire "Computer Programmers" which I thought was pretty nostalgic. They also are hiring System Administrators and Network Technicians. No fluff at one of the highest paying firms :)
When people ask me what I do, I say "computer programmer". I can't be doing with all that job title inflation.
Sometimes I just say "programmer", but that seems to confuse people; like I'm the guy who decides at what time The Simpsons goes on telly, or something.
Sometimes I just say "programmer", but that seems to confuse people; like I'm the guy who decides at what time The Simpsons goes on telly, or something.
Don't get me started with "network engineer"...
One thing that can be added - is this person working in a regulated industry? For instance, does your company have to follow a controlled design, manufacturing and verification process and have things documented properly along the way? Do you have to adhere to industry standard not because it's a good practice but because the law requires it?
If not, I would say the work is likely not engineering. You can use Auto-CAD tool but there is a difference between 3D printing a spoon and designing a bridge. Likewise, just because one uses programming tools, it doesn't mean that the work is engineering.
If not, I would say the work is likely not engineering. You can use Auto-CAD tool but there is a difference between 3D printing a spoon and designing a bridge. Likewise, just because one uses programming tools, it doesn't mean that the work is engineering.
Is a lawyer an engineer?
Hillel asks engineer-turned-swes whether they think swe is engineering. He should compare that rate to the rate lawyer-turned-swes think swe is similar to law.
Without comparing rates, you might include swe in engineering by an overbroad definition of engineering.
Also if you think engineering is whether the state has granted you a license: 1) cope, 2) since lawyers need a JD, they’re definitely engineers right?
Personally, I think we appropriated the term eng in the mid-90s to up the social status of programmers. Nothing wrong with that, but FAANG SWEs make substantially more than trad engineers now, so we should aim higher.
Hillel asks engineer-turned-swes whether they think swe is engineering. He should compare that rate to the rate lawyer-turned-swes think swe is similar to law.
Without comparing rates, you might include swe in engineering by an overbroad definition of engineering.
Also if you think engineering is whether the state has granted you a license: 1) cope, 2) since lawyers need a JD, they’re definitely engineers right?
Personally, I think we appropriated the term eng in the mid-90s to up the social status of programmers. Nothing wrong with that, but FAANG SWEs make substantially more than trad engineers now, so we should aim higher.
> Pete McBreen and Paul Graham who say that we are not engineers because engineering cannot apply to our domain. Engineers work on predictable projects with a lot of upfront planning and rigorous requirements
This strikes me as a really silly argument, it has an element of “we’re too good for other engineering disciplines “. I don’t think it’s difference in our specifications, software engineering does still apply the same underlying principles and intents in solving problems.
Admittedly, software engineering has some way to go to reach the same levels of guarantees and rigour, but the fundamentals are there.
This strikes me as a really silly argument, it has an element of “we’re too good for other engineering disciplines “. I don’t think it’s difference in our specifications, software engineering does still apply the same underlying principles and intents in solving problems.
Admittedly, software engineering has some way to go to reach the same levels of guarantees and rigour, but the fundamentals are there.
I think it’s less that software programmers are "too good," and more that interesting programming work is too new to have established engineering practices/standards/etc
One of the reasons engineers exist is to mitigate a high cost of getting something wrong. That's different to saying "people could die" ... it can be as mundane as, once we've made a million of these widgets there's a very high cost to remake them all because something was miscalculated. When software work heavily incorporates these elements of process and planning, I call it engineering. When it doesn't (for example, when it's built entirely agile style with literally no planning ahead beyond what we do for the next 2 weeks) I don't.
I'm a software engineer by day, software craftsman by night.
My own personal work is made with love and care but I won't necessarily fret over details like extreme testing, scalability, readability of the code.
My paid work is a lot more thorough. Meetings and planning. Group work. Testing. My work does have consequences (although I think that's not really a prerequisite for the title of engineering). While no official board has standards of software. My work definitely has standards. My peers and managers have standards that we enforce upon ourselves
My own personal work is made with love and care but I won't necessarily fret over details like extreme testing, scalability, readability of the code.
My paid work is a lot more thorough. Meetings and planning. Group work. Testing. My work does have consequences (although I think that's not really a prerequisite for the title of engineering). While no official board has standards of software. My work definitely has standards. My peers and managers have standards that we enforce upon ourselves
I think there's one key term that hasn't been mentioned in relation to this debate much: accountability.
Engineers are a countable for their work. I am accountable if my code fucks up in production. An engineer is accountable if a foundation fails. Not "how bad are the consequences", but "am I accountable if something does goes wrong"
Engineers are a countable for their work. I am accountable if my code fucks up in production. An engineer is accountable if a foundation fails. Not "how bad are the consequences", but "am I accountable if something does goes wrong"
Quite simply, as someone from a place where the term is protected, an Engineer is someone that is licensed by an engineering regulatory body.
The more interesting discussion is what is engineering work. The best definition for engineering to me is: "the application of scientific principles to efficiently solve a unique problem". Which is something that most "software engineers" aren't doing, but by that same definition, most people with traditional engineering degrees aren't doing either, even if they are a licensed.
The more interesting discussion is what is engineering work. The best definition for engineering to me is: "the application of scientific principles to efficiently solve a unique problem". Which is something that most "software engineers" aren't doing, but by that same definition, most people with traditional engineering degrees aren't doing either, even if they are a licensed.
I've made this question into a poll. Let's vote on it:
https://news.ycombinator.com/item?id=30000645
https://news.ycombinator.com/item?id=30000645
There are three types:
- CS person who has in-depth understanding of how computers works and mathematics. Typically writes code in a low-level language, can write a compiler, mostly will solve computer problems that indirectly solve problems at a consumer level.
- Developer person who is analytical and has a good grasp of mathematics. Can build tools to be used by other developer persons. Uses high-level languages to solve problems at a consumer level.
- Hacker person who uses tools built by the CS and developer person to solely solve problems at a consumer level.
- CS person who has in-depth understanding of how computers works and mathematics. Typically writes code in a low-level language, can write a compiler, mostly will solve computer problems that indirectly solve problems at a consumer level.
- Developer person who is analytical and has a good grasp of mathematics. Can build tools to be used by other developer persons. Uses high-level languages to solve problems at a consumer level.
- Hacker person who uses tools built by the CS and developer person to solely solve problems at a consumer level.
This may not be a popular comment, but if you have to ask, then no. In Canada at least, engineering is a regulated profession. No one can legally call themselves an engineer without a four-year Bachelor of Engineering degree from an accredited University and membership in the professional engineering body of the Province in which they practice. Doctors and lawyers are other regulated professions; one cannot simply call themselves a doctor, lawyer or engineer.
I have come to feel that the problem with comparing software development with established engineering disciplines is that doing so ignores the possibility that it is, or could be, a rather different discipline than we have seen heretofore. I do not have any insights into what a mature discipline of software engineering would look like, but I no longer feel there is much to be gained in debating comparisons between established engineering and software development.
First define "engineering", then ask that question.
Real, actual, Engineers in my home state of Indiana are required to graduate from an accredited 4 year education, and then pass a state administered test.
The reason is simple, professional engineers work on things that would cause loss of life or grievous injury should they fail.
Because of professional licensure, and all it entails, Engineers can give a hard NO to the wants and desires of management. Programmers will never have that kind of clout.
The reason is simple, professional engineers work on things that would cause loss of life or grievous injury should they fail.
Because of professional licensure, and all it entails, Engineers can give a hard NO to the wants and desires of management. Programmers will never have that kind of clout.
> Because of professional licensure, and all it entails, Engineers can give a hard NO to the wants and desires of management. Programmers will never have that kind of clout.
Just because you have a PE license and you say "No", doesn't mean the firm contracting you will continue hiring you. In reality, engineers are under a lot of pressure to acquiesce to the demands of management (who is generally an engineer also due to regulations). This is why external auditors/inspectors come in and offer independent analysis. These _external auditors_ are not under the same organizational pressures that engineers in the firm/being contracted are. It has only somewhat to do with licensure and more to do with oversight.
Just because you have a PE license and you say "No", doesn't mean the firm contracting you will continue hiring you. In reality, engineers are under a lot of pressure to acquiesce to the demands of management (who is generally an engineer also due to regulations). This is why external auditors/inspectors come in and offer independent analysis. These _external auditors_ are not under the same organizational pressures that engineers in the firm/being contracted are. It has only somewhat to do with licensure and more to do with oversight.
> Programmers will never have that kind of clout.
Why not? If you're writing software for a medical device giving a hard no to a feature request could be a very sensible course of action, and any sensibly managed company would listen carefully to that opinion.
Why not? If you're writing software for a medical device giving a hard no to a feature request could be a very sensible course of action, and any sensibly managed company would listen carefully to that opinion.
> Do we deserve that title?
You deserve it if you graduate in engineering. Otherwise you don't.
People get offended when I express this idea for some reason but it would be considered absurd to call yourself an engineer in any other field but software without an engineering major.
Anyway those titles are here to stay. Managers rebranded as vice presidents, secretaries become executive assistant, street cleaners are ecological operators and so on and on.
You deserve it if you graduate in engineering. Otherwise you don't.
People get offended when I express this idea for some reason but it would be considered absurd to call yourself an engineer in any other field but software without an engineering major.
Anyway those titles are here to stay. Managers rebranded as vice presidents, secretaries become executive assistant, street cleaners are ecological operators and so on and on.
After how many years of experience doing engineering work do you get to call yourself an engineer as a dropout?
I ask because I'm pretty sure that after 15 years of on-the-job experience on top of 10 years of coding-for-fun experience I have more engineering skills than any fresh grad you can point at.
I ask because I'm pretty sure that after 15 years of on-the-job experience on top of 10 years of coding-for-fun experience I have more engineering skills than any fresh grad you can point at.
You don't, you didn't graduate.
Nobody cares how skilled someone is, in many countries, e.g. Italy where I live it would be illegal to give such a title to someone who isn't graduated in engineering.
John Carmack who is one of the most brilliant minds we had in the last decades didn't graduate, he isn't an engineer.
Only in software there is this ridiculous trend to rebrand as engineers.
A car mechanic follows better engineering practices than every single dev I met, from data analysis to problem solving, no one would call him an engineer.
Nobody cares how skilled someone is, in many countries, e.g. Italy where I live it would be illegal to give such a title to someone who isn't graduated in engineering.
John Carmack who is one of the most brilliant minds we had in the last decades didn't graduate, he isn't an engineer.
Only in software there is this ridiculous trend to rebrand as engineers.
A car mechanic follows better engineering practices than every single dev I met, from data analysis to problem solving, no one would call him an engineer.
This seems incredibly political. How would you meaningfully define "engineering degree" without first defining what "engineering" is? And how would you define engineering in such a way that it excludes people learning it outside of some preferred institution? Of course you can learn engineering at the job.
Posted a year ago too -- and thanks for re-posting because I had been trying to remember the title/author of this to find it again and hadn't been able to find it!
https://news.ycombinator.com/item?id=25823907
(Yes, at first I saw Jan 18 2021 and thought it had been published yesterday; but it's 2022 now y'all!)
https://news.ycombinator.com/item?id=25823907
(Yes, at first I saw Jan 18 2021 and thought it had been published yesterday; but it's 2022 now y'all!)
IMO, Engineering is the application of science.
Software development is the application of computer science.
Using this definition, physicians are engineers, applying medical sciences.
Software development is the application of computer science.
Using this definition, physicians are engineers, applying medical sciences.
I think Hillel Wayne needs to go further down this trajactory. Focusing on the classification individual workers is myopic.
The fact is, the computing industry in the US arose during a huge wave of deindustrialization and offshoring. It has grown up in a completely different economic context. This, more than anything intrinisic to the field, influences the norms.
This macro perspective must be the starting point.
The fact is, the computing industry in the US arose during a huge wave of deindustrialization and offshoring. It has grown up in a completely different economic context. This, more than anything intrinisic to the field, influences the norms.
This macro perspective must be the starting point.
If you are using science and empirical knowledge to create technology and processes, you are an engineer.
If you are simply using existing technologies and following existing processes without understanding the fundamental principles behind them, my preferred word for that is "technician".
Technicians follow existing development processes, engineers create, validate and improve upon them.
If you are simply using existing technologies and following existing processes without understanding the fundamental principles behind them, my preferred word for that is "technician".
Technicians follow existing development processes, engineers create, validate and improve upon them.
What makes an tech person an 'engineer' is being competent with data structures and algorithms and other classical computer science subjects.
They can work on high difficulty 'engineering' problems.
A developer uses libraries with that stuff already made for them and is limited by the available tools but can still get a lot done.
They can work on high difficulty 'engineering' problems.
A developer uses libraries with that stuff already made for them and is limited by the available tools but can still get a lot done.
15+ years into the job I still, most of the time, call myself a "computer programmer", i.e. I program computers to do some stuff, most of the times to move some data around. But maybe people on the dev-ops side are more on the "engineering" side, I wouldn't know.
I always felt (perhaps wrongly) that “Engineer” connotes some kind of a professional licensing process (P.Eng for example). I think the title would be more earned if software engineers had to agree to an oath and sign their work (somewhat accountable if harm is caused by negligence).
Since you use P.Eng. I'm assuming you're Canadian. Software engineer is a licensed P.Eng. in Canada. For example, BC: https://www.egbc.ca/Registration/Individual-Registrants/How-...
There are a few exceptions to who can use the word "engineer" in a job, but software doesn't get the exception in Canada. E.g., https://www.peo.on.ca/public-protection/complaints-and-illeg...
There are a few exceptions to who can use the word "engineer" in a job, but software doesn't get the exception in Canada. E.g., https://www.peo.on.ca/public-protection/complaints-and-illeg...
We're plumbers, not engineers.
Dude. We're definitely not plumbers.
It takes years to become a plumber. Plumbers have to hold a high school diploma, enter a trade program, begin an apprenticeship that can take up to five years to complete (required to be able to work as a plumber), pass a state exam and become licensed, and join a trade association. They have to follow codes and standards, and often work with other trades like architects putting together blueprints. Plumbers are business people, too; they have to get clients, keep up with them, get paid, and survive on their reputation. And for all that, they make on average $57k a year in the US.
We're artisan primadonnas who get paid three times that of a plumber, with literally no requirements to do so. There are people working at online banks who haven't completed high school.
It takes years to become a plumber. Plumbers have to hold a high school diploma, enter a trade program, begin an apprenticeship that can take up to five years to complete (required to be able to work as a plumber), pass a state exam and become licensed, and join a trade association. They have to follow codes and standards, and often work with other trades like architects putting together blueprints. Plumbers are business people, too; they have to get clients, keep up with them, get paid, and survive on their reputation. And for all that, they make on average $57k a year in the US.
We're artisan primadonnas who get paid three times that of a plumber, with literally no requirements to do so. There are people working at online banks who haven't completed high school.
I feel that I am. It doesn't really matter. I tend to work on my own stuff.
I started as an EE, and a lot of the discipline from there, has traveled with me, in my software adventure.
I don't ship bugs (that I'm aware of). My issues need to be at 0, before I will release.
I started as an EE, and a lot of the discipline from there, has traveled with me, in my software adventure.
I don't ship bugs (that I'm aware of). My issues need to be at 0, before I will release.
I look at it like "sanitation engineer". That's a real engineering job that requires engineering expertise to do right, but the term is often used (sometimes derisively) for anyone who does anything involving waste/cleaning.
Real engineers can build a structure that with lifetimes of decades or more, with only minimal maintenance.
Other than old Netware servers, when has anything computer related you've seen had an uptime measured in decades?
Other than old Netware servers, when has anything computer related you've seen had an uptime measured in decades?
I put software engineering as "can you write an sla and be legally liable for it?" If so, then you're an engineer. If not, you're a dev. I personally call myself a software plumber.
I definitely feel more like some kind of tech scribe, where we now count and tabulate up the "rules" of the accounting, rather than being the instrument of data entry and accounting.
An engineer doesn't say "Move fast and break things".
Modern software engineering is mostly abstraction engineering. If you can build abstractions on top of abstractions and they are profitable, you are probably a good software engineer.
See Discussion of the Method by Billy Koen. He was a nuclear engineer. His definition of engineering was something like applying heuristics to solve problems.
The US Supreme court has ruled that the First Amendment allows us to call ourselves engineers, so at least in this jurisdiction – yes, we are (if we choose).
Titles are cheap.
Better questions:
Better questions:
Do you have the knowledge and experience to do your job well?
Is your brain naturally wired for the type of work you do?Given the professional title, in an university approved by the Engineering Order, definitely.
Unfortunately not something with the same value everywhere.
Unfortunately not something with the same value everywhere.
I don't think very many people can build or operate a siege engine so the real question for our modern times is: is anyone?
off-topic: if you want to read something interesting about the effects of abstraction, take a look at this https://www.amazon.com/gp/product/B07NS35S76/ref=dbs_a_def_r...
Software defines an 'engine' that runs and does work. We build and maintain those engines therefore we are engineers.
Yes, we’re all engineers. Some better than others.
A piece of paper changes nothing, only in the legal system in which you operate.
A piece of paper changes nothing, only in the legal system in which you operate.
That Atlantic article is too long and doesn't get to the point. Philosophers are faster than this.
Doubt it. Mostly we chase TC and forget what actually matters to society and the planet as a whole.
Watch "Das Boot", the entire ship has one engineer and he commands respect in the movie.
My father-in-law, a lifelong licensed civil engineer, would (and often did) say 'no'.
It took an engineer to invent Autotune. A programmer never would have been able to.
If I have to call my niece they/them, then you have to call me an Engineer.
We are not. And I'm fine with that. Please stop calling me an engineer.
I have a Master of Software Engineering degree. Ask me anything.
Why does this matter?
We could be, and sometimes we are, but often we are not.
of course.
look at the code base for a product like YouTube and then look at the product.
there is no difference between looking at a bridge and the people driving on it.
look at the code base for a product like YouTube and then look at the product.
there is no difference between looking at a bridge and the people driving on it.
I'm just me
LOL no. We're artisans and craftsmen.
“We are Devo. D–E–V–O.”
Maybe we should Ask Brunel, or perhaps a little more recently dare I say Elon Musk.
https://en.m.wikipedia.org/wiki/Isambard_Kingdom_Brunel
I won’t link Elon Musk.
https://en.m.wikipedia.org/wiki/Isambard_Kingdom_Brunel
I won’t link Elon Musk.
software engineering is like roman civil engineering
yes we are
*if we is anything like me
*if we is anything like me
I think Hillel is a pretty interesting guy. But I think that he's a bit missing the mark here.
It feels like his view of engineers is that they are people who can put together a solution and then use a lot of fancy numbers and established facts to support their solution. In his oil drilling example.. he's not going into the same issues that we face. (Is that drilling analyze for failure worth the money in investigation, etc)
With software engineering you're putting together instructions to fit within a computer's hardware capacity to solve your problem in the context that you need to operate it. There are a lot of ways about it .. however we have a lot of issues in our field surrounding the technical aspect on this:
1. Academics is dead focused on the hard part of language schemas, grammars, correctness-proofs, etc. 2. The research that we have about design patterns and their usages are nothing more than surveys and try to debunk a negative. (This goes back to the whole "academics proved unit tests don't provide value") [The results are never influential and they completely ignore the quality of the data]
Additionally:
I want to say that as engineers .. at companies, we're put into aggressive processes and methodologies that prevent us from operating a very high quality output. As a software engineer, you should have verification to prove your program works as intended, you should have monitoring to validate that constantly in production, you should have experience+data that supports the design decisions.
There are metrics there to quantify our solutions.. but being business and shipping led.. that's forced to the wayside.
---
Slight addition here: We're in a phase in the industry where experience is completely ignored and we're forgoing technical "merit"(By that I mean experience, strong practices, discipline.. not the business says I'm good) in favor of blasting people into the door.
We're not getting a lot of people that are willing to learn from the methods of old and make constructive commentary, we're getting people that are not willing to be disciplined, and we're getting people who forgo good practices because "they dont' wanna". (You see this all the time with lazy arguments about people hating to do unit tests, bad tooling, etc)
TL;DR to my argument, are we engineers right now.. some have the privilege to be.. but most are punished for doing so because it may annoy the PO. We totally can be engineers, no one really rewards you for this.
It feels like his view of engineers is that they are people who can put together a solution and then use a lot of fancy numbers and established facts to support their solution. In his oil drilling example.. he's not going into the same issues that we face. (Is that drilling analyze for failure worth the money in investigation, etc)
With software engineering you're putting together instructions to fit within a computer's hardware capacity to solve your problem in the context that you need to operate it. There are a lot of ways about it .. however we have a lot of issues in our field surrounding the technical aspect on this:
1. Academics is dead focused on the hard part of language schemas, grammars, correctness-proofs, etc. 2. The research that we have about design patterns and their usages are nothing more than surveys and try to debunk a negative. (This goes back to the whole "academics proved unit tests don't provide value") [The results are never influential and they completely ignore the quality of the data]
Additionally:
I want to say that as engineers .. at companies, we're put into aggressive processes and methodologies that prevent us from operating a very high quality output. As a software engineer, you should have verification to prove your program works as intended, you should have monitoring to validate that constantly in production, you should have experience+data that supports the design decisions.
There are metrics there to quantify our solutions.. but being business and shipping led.. that's forced to the wayside.
---
Slight addition here: We're in a phase in the industry where experience is completely ignored and we're forgoing technical "merit"(By that I mean experience, strong practices, discipline.. not the business says I'm good) in favor of blasting people into the door.
We're not getting a lot of people that are willing to learn from the methods of old and make constructive commentary, we're getting people that are not willing to be disciplined, and we're getting people who forgo good practices because "they dont' wanna". (You see this all the time with lazy arguments about people hating to do unit tests, bad tooling, etc)
TL;DR to my argument, are we engineers right now.. some have the privilege to be.. but most are punished for doing so because it may annoy the PO. We totally can be engineers, no one really rewards you for this.
Etymologically[0]:
> mid-14c., enginour, "constructor of military engines," from Old French engigneor "engineer, architect, maker of war-engines; schemer" (12c.), from Late Latin ingeniare (see engine); general sense of "inventor, designer" is recorded from early 15c.; civil sense, in reference to public works, is recorded from c. 1600 but not the common meaning of the word until 19c (hence lingering distinction as civil engineer). Meaning "locomotive driver" is first attested 1832, American English. A "maker of engines" in ancient Greece was a mekhanopoios.
The original meaning seems to characterize a very specific kind of activity and not what the broad genus "engineer" that we believe today suggests. The growing inclusiveness over time actually seems to suggest that the demarcation between "engineering" and "other arts" is an open question even when posed in historical contexts predating software. The problem of determining whether "software engineering" is engineering is not a problem unique to software development, I think, even putting to one side the numerous cases of what is arguably title puffery.
The ancient Greek "mekhanopoios" is interesting because the ending, "-poios", from "poiesis", refers to making or producing. So the mekhanopoios is someone who produces machines; he does the production. The division of human activity (in relation to knowledge) into poiesis, praxis and theoria seems to give us a good starting point for understanding the myriad activities that human beings engage in because it is a principled classification. But "engineering" seems to have been appropriated for new uses over time for diverse, though not necessarily principled reasons (specialization, analogical similarity, a desire to cash in on established prestige). As a result, at least until the bad appropriations have been dispatched, maybe we cannot expect a crisp taxonomy because the evolution of the meaning of the term has not been principled in the first place.
There does indeed seem to be a connotation of sophistication, specifically scientific sophistication, which is a question of methodology. Even if we accept this definition, sophistication is, of course, a matter of degree, not kind, and what counts as sophisticated seems to be relative to the state of the art. But you could then speak of degrees of engineering. Just as science that is more rigorous and thus more perfect could be said to be more scientific, so, too, we may speak of one field as more of an engineering field than another.
So where does this leave software engineering? If engineering is understood in terms of productive aim achieved by means of scientifically-informed methods, then presumably software is the product, so it's a question of establishing the scientific basis for the field and identifying the "scientifically-informed methods".
[0] https://www.etymonline.com/word/engineer#etymonline_v_25786
> mid-14c., enginour, "constructor of military engines," from Old French engigneor "engineer, architect, maker of war-engines; schemer" (12c.), from Late Latin ingeniare (see engine); general sense of "inventor, designer" is recorded from early 15c.; civil sense, in reference to public works, is recorded from c. 1600 but not the common meaning of the word until 19c (hence lingering distinction as civil engineer). Meaning "locomotive driver" is first attested 1832, American English. A "maker of engines" in ancient Greece was a mekhanopoios.
The original meaning seems to characterize a very specific kind of activity and not what the broad genus "engineer" that we believe today suggests. The growing inclusiveness over time actually seems to suggest that the demarcation between "engineering" and "other arts" is an open question even when posed in historical contexts predating software. The problem of determining whether "software engineering" is engineering is not a problem unique to software development, I think, even putting to one side the numerous cases of what is arguably title puffery.
The ancient Greek "mekhanopoios" is interesting because the ending, "-poios", from "poiesis", refers to making or producing. So the mekhanopoios is someone who produces machines; he does the production. The division of human activity (in relation to knowledge) into poiesis, praxis and theoria seems to give us a good starting point for understanding the myriad activities that human beings engage in because it is a principled classification. But "engineering" seems to have been appropriated for new uses over time for diverse, though not necessarily principled reasons (specialization, analogical similarity, a desire to cash in on established prestige). As a result, at least until the bad appropriations have been dispatched, maybe we cannot expect a crisp taxonomy because the evolution of the meaning of the term has not been principled in the first place.
There does indeed seem to be a connotation of sophistication, specifically scientific sophistication, which is a question of methodology. Even if we accept this definition, sophistication is, of course, a matter of degree, not kind, and what counts as sophisticated seems to be relative to the state of the art. But you could then speak of degrees of engineering. Just as science that is more rigorous and thus more perfect could be said to be more scientific, so, too, we may speak of one field as more of an engineering field than another.
So where does this leave software engineering? If engineering is understood in terms of productive aim achieved by means of scientifically-informed methods, then presumably software is the product, so it's a question of establishing the scientific basis for the field and identifying the "scientifically-informed methods".
[0] https://www.etymonline.com/word/engineer#etymonline_v_25786
If you squint your eyes at all the statements people make about why SWE might not be engineering, it boils down to a "looseness". SWEs aren't precise, they ship bugs (as Scramblejams says in a sibling comment), they don't build to a spec, and rarely can they tell you all the ways the thing they're building can fail.
Yet, as Hillel says in their post, 'Most people would agree that the software running on spacecraft counts as “real engineering”.'.
I think looseness stems from three interrelated factors (1) potential complexity of a piece of software (2) the role complexity plays in causing faults (3) the fault tolerant nature of many domains in which software runs.
(1) Potential complexity - literally the amount of logic branches - that can exist in a piece of software. If you were to compare the logic branches for a bridge, what would it be - 10? 100? if(load> X); if (temp > Y); etc...
(2) The reality is you can hold a bridge (or the relevant variables[0]) in your head. Holding it in your head is necessary to be certain you can think through failure cases, or even know what cases to conduct/write tests for.
When writing software, the branches can get so unbelievably high that it's basically impossible to hold the whole thing in your head. Even if you break apart and solidify each underlying abstraction in your system, a single user outcome may be composed of so many underlying abstractions that their interactions are impossible to predict.
(3) Going back to the '"...software running on spacecraft counts as “real engineering”.' I think this is a not-loose example of SWE . The stakes are high, and accordingly, I'm certain a lead engineer on such a piece of software would do as much as possible to fully understand the entirety of the system so that it can be precisely tested. Get the number of irrelevant variables as high as possible, and keep the complexity of code as small as possible.
OTOH, most software is low stakes. Even if you're dealing with money, transactions can be rolled back, payments refunded. There are rarely undoable mistakes, and even more rarely do those mistakes destroy the project (spacecraft) or kill a person.
---
So in summary - I guess my point is: SWE is its own thing, in creating a world where complexity is orders of magnitude higher than in physical things. "Engineering"-ness operates on a plane of rigor, the high end of which contains only certain kinds of software.
[0] I'd define an irrelevant variable as an abstraction that has zero possible implication for the logic branches of your project. For a bridge, this might be melting point of the steel (not a bridge guy, as you can tell); for a typical software project, this might be the OS.
Yet, as Hillel says in their post, 'Most people would agree that the software running on spacecraft counts as “real engineering”.'.
I think looseness stems from three interrelated factors (1) potential complexity of a piece of software (2) the role complexity plays in causing faults (3) the fault tolerant nature of many domains in which software runs.
(1) Potential complexity - literally the amount of logic branches - that can exist in a piece of software. If you were to compare the logic branches for a bridge, what would it be - 10? 100? if(load> X); if (temp > Y); etc...
(2) The reality is you can hold a bridge (or the relevant variables[0]) in your head. Holding it in your head is necessary to be certain you can think through failure cases, or even know what cases to conduct/write tests for.
When writing software, the branches can get so unbelievably high that it's basically impossible to hold the whole thing in your head. Even if you break apart and solidify each underlying abstraction in your system, a single user outcome may be composed of so many underlying abstractions that their interactions are impossible to predict.
(3) Going back to the '"...software running on spacecraft counts as “real engineering”.' I think this is a not-loose example of SWE . The stakes are high, and accordingly, I'm certain a lead engineer on such a piece of software would do as much as possible to fully understand the entirety of the system so that it can be precisely tested. Get the number of irrelevant variables as high as possible, and keep the complexity of code as small as possible.
OTOH, most software is low stakes. Even if you're dealing with money, transactions can be rolled back, payments refunded. There are rarely undoable mistakes, and even more rarely do those mistakes destroy the project (spacecraft) or kill a person.
---
So in summary - I guess my point is: SWE is its own thing, in creating a world where complexity is orders of magnitude higher than in physical things. "Engineering"-ness operates on a plane of rigor, the high end of which contains only certain kinds of software.
[0] I'd define an irrelevant variable as an abstraction that has zero possible implication for the logic branches of your project. For a bridge, this might be melting point of the steel (not a bridge guy, as you can tell); for a typical software project, this might be the OS.
(2021)
in my linkedin I am :D
Just because we use [discrete, not continuous] math doesn’t mean we’re not doing engineering
Yes, it does. The analog-digital divide makes engineering that much harder than programming where 1's remain 1's and 0's remain 0's regardless of real-world curveballs like temperature and fat people.
Yes, it does. The analog-digital divide makes engineering that much harder than programming where 1's remain 1's and 0's remain 0's regardless of real-world curveballs like temperature and fat people.
Isn't the appeal you're making also refuted by the article?
"not all forms of engineering result in physical processes. In particular, industrial engineering rarely does."[0]
[0]:https://www.hillelwayne.com/post/are-we-really-engineers/#:~....
"not all forms of engineering result in physical processes. In particular, industrial engineering rarely does."[0]
[0]:https://www.hillelwayne.com/post/are-we-really-engineers/#:~....
Nope.
HRs like to write "Software Engineer" on my payroll.
Good if it pleases them and my ego. But I never graduated from an engineering school.
But I do the same mud stacking (that is plugging bricks to do CRUDs) as my fellow "real engineers" coworkers.
I have too much respect for anyone designing mechanical stuff to call our industry "engineering".
HRs like to write "Software Engineer" on my payroll.
Good if it pleases them and my ego. But I never graduated from an engineering school.
But I do the same mud stacking (that is plugging bricks to do CRUDs) as my fellow "real engineers" coworkers.
I have too much respect for anyone designing mechanical stuff to call our industry "engineering".
> But I do the same mud stacking (that is plugging bricks to do CRUDs) as my fellow "real engineers" coworkers.
That's the problem with the current state of the Software Development field: Most of the work (90% I'd pull out of my ass) can be done by "qualified technicians", what in Germany is called Berufsschule, in Mexico "Técnico Superior" [2] and in the US I think it may be the result of studying in a Community College.
The work of Software Engineers themselves, that should be doing real Engineering work. To prepare the ground and the "map" for the Technicians to build. It's the difference between an Architect (in an architecture firm) and their armies of interns or technicians (don't know the name in English). Or a Lawyer and also all the people that work for them (interns).
The thing is, that the Software/Computer/IT Engineer degree has been watered down since its inception for 40 years. I think mainly due to the huge demand that the Computing field has had for developers during this time.
[1] https://eacea.ec.europa.eu/national-policies/eurydice/conten...
[2] https://www.sectei.cdmx.gob.mx/oferta-educativa/tecnico-supe...
That's the problem with the current state of the Software Development field: Most of the work (90% I'd pull out of my ass) can be done by "qualified technicians", what in Germany is called Berufsschule, in Mexico "Técnico Superior" [2] and in the US I think it may be the result of studying in a Community College.
The work of Software Engineers themselves, that should be doing real Engineering work. To prepare the ground and the "map" for the Technicians to build. It's the difference between an Architect (in an architecture firm) and their armies of interns or technicians (don't know the name in English). Or a Lawyer and also all the people that work for them (interns).
The thing is, that the Software/Computer/IT Engineer degree has been watered down since its inception for 40 years. I think mainly due to the huge demand that the Computing field has had for developers during this time.
[1] https://eacea.ec.europa.eu/national-policies/eurydice/conten...
[2] https://www.sectei.cdmx.gob.mx/oferta-educativa/tecnico-supe...
[deleted]
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.