Are We Really Engineers? (2021)

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.

(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.

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.

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.

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.

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

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.

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.

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.

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'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 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 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.

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.

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.

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.

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'.

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.

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.

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.

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).

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.

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.

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.

I personally call myself a programmer, even if my job title says engineer.

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.

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.

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?

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.

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 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.

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".

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.

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.

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.

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.

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.

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.

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

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.

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.

> [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.

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.

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).

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.

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 Craftsmanship

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.

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.

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.

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

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.

https://news.ycombinator.com/item?id=30000645

- 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.

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.

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.

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!)

Software development is the application of computer science.

Using this definition, physicians are engineers, applying medical sciences.

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 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.

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.

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.

Other than old Netware servers, when has anything computer related you've seen had an uptime measured in decades?

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?

Unfortunately not something with the same value everywhere.

A piece of paper changes nothing, only in the legal system in which you operate.

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.

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

I won’t link Elon Musk.

*if we is anything like me

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.

> 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

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.

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.

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".