Fantastic article!

But please, don’t just update this thread with the new links. I’d rather they also get posted as separate links. It’s easier to catch the new ones if they are posted as their own posts. Plus, the comments will be relevant to each “chapter” instead of just a mishmash of comments in one thread that were posted before we had the full picture.

I think this is really good research, it is obvious (if you think a little), that engineering stereotypes are wrong, but that hasn’t stopped plenty of people (myself included) from making bad comparisons.

I think the section on licensure is lacking some historical context, though. It portrays licensing laws as essentially benevolent regulations to increase public safety or protect public investments, but that ignores the rich scholarship on how licensing and similar regulations have been used to discriminate against and exclude minorities who might otherwise enter an industry.

We can see this consistently over time with e.g. Jewish folk being banned from many trades in Europe and many Southern USA states using licenses to support segregation. There is competing scholarship for the more recent US case, and I am not an expert, but this rebuttal paper covers some of the common issues and links to lots of seminal work (Was Occupational Licensing Good for Minorities? A Critique of Marc Law and Mindy Marks).

(Edit: it’s further off-topic, but I should note that the modern story is more complicated and now licensing may help women and black people in the US, though often for racist reasons. (Research Spotlight: Occupational Licensing Reduces Racial and Gender Wage Gaps))

@hwayne: Is there a way I could pay you some amount of money for these essays? Or would you be willing to put together some swag or the like?

Essay number two is now up.

That is something I’ve thought about a lot. The article is therefore a very interesting read. I’m a mechanical engineer myself, who is also very involved into software (both privately and professionally). I would describe engineering as follows: “To design something to an optimum under constraints”. I know this is very broad, but it goes very well along with “everyone can build a bridge, but only engineers can build a bridge which barely stands” to quote Practical Engineering. I think software engineering fits very well with this: Everyone can write software that works, but only software engineers can write software that barely works (clean and minimal code and no excess functionality). On a broader picture engineers among many other things also ensure that this something works for its defined lifespan.

I’ve one remark about the math part though: Engineers almost solely use discrete math also, because many problems are not solvable otherwise, but you only learn this during the later semesters and many engineers don’t need higher math when working. Continuous vs discrete: A falling ball can be very easily described with continuous math, but if you want to include air resistance you have the go discrete. Hint: Engineers in the field mostly want that.

I think that this has the potential to really open a lot of doors that software engineers have closed for themselves (or never realized were open) through our perceptions of exceptionalism. By getting a clearer orientation about how our work compares to that of others, I believe this project will facilitate conversations across professions that we would not have realized were even possible before. Congratulations for publishing this!

Hurray! I’m very happy that you’re publishing these. The history and general practices of science and engineering are fields that interest me deeply, and I think this work on making the comparison between software and other engineering fields is really fascinating. The occasional teases on your Twitter account have been fun to follow.

Anecdotally, even as a student I noticed that the people who were least familiar with each others’ fields exaggerated the differences the most. For example, I did some grad work at a big state school where people mostly socialized in their own departments, and you sometimes heard people talk about other departments very dismissively, or with an air of mystery. (“What do you think those people do all day, anyway?”)

By contrast, I got my undergrad degree at a smaller, physically isolated engineering university, where we all more or less had to get to know each other due to sheer proximity. ;-) In that setting, the similarities tended to stand out more than the differences, and there seemed to be little question that software folks “did engineering”.

Hm nice that you actually went and interviewed people! FWIW I was not surprised by their opinions. I would definitely consider programming a kind of “engineering”.

One way to see this is that you can do it badly! If it weren’t engineering, then maybe there’s no way to do it badly. But we all have lots of opinions on when a program is poorly written. For example, you can call a website that is constantly crashing or slow “badly engineered”; you need apply engineering to rectify that situation :)

I think software has the potential to be (and is in some cases) a lot more rigorous than other fields of engineering due to increased use of testing (and mathematical techniques, to a lesser degree). This was a big change even since I started my career, i.e. we didn’t write tests and now we do.

I always liked this talk about deterministic simulation and “adversarial” testing of FoundationDB. I think more software projects will start to look like this in the future, and it feels above the level of rigor that you can achieve in the “real world”, mostly due to speed.

https://www.youtube.com/watch?v=4fFDFbi3toc&ab_channel=StrangeLoop

Thanks @hwayne for a great set of articles, which I can a cross due to the repost or the first article and hightlights the importance of learning from the pitfalls in other disciplines.

Thank you for doing this research and writing it up! I am looking forward to reading. There may be other terms, but did you happen to evaluate the term “architect?” I feel like it is in a similar boat of being analogous to “engineer.”

My personal view is that words do have meaning, but their meaning differs based on context. Likewise, words may be useful to different audiences of people. What is generally always true is needing to explain what I do beyond just the term “engineer” or “developer” or “architect” or “programmer.”

This may be a odd analogy, but I think about the term “cook” vs “chef.” Many of the best chefs refer to them as cooks.. so maybe words also attempt to reflect status or humbleness.