Not to look down on hackers, but the main reason I think this whole question exists in the computer side of the world but doesn't exist for mechanical engineers is that there isn't the hacker/engineer dichotomy in "traditional" engineering. Maybe makers vs mechanical engineers counts, but almost all of the makers I knew were employed as engineers.

A good software engineer/developer and a good "traditional" engineer take the time to think through every edge case, every corner case, and any other case that might cause problems. Makers/Hackers just get to the first thing that works, damn the consequences for anyone else. Which is fine because often the only people using their product is themselves.

Just my $0.02

Edit: I am suggesting hacker is a loaded/confusing word that is definitely not the opposite of engineer. Good engineering and good hacking are compatible - the right temporary fix can be excellent engineering. Cowboy (≈hacker) mechanical and civil engineers exist, so the concept of hacking is not incompatible with engineer. Using the word hacker intrinsically includes the concept of software, so contrasting hacking and engineering is not a tidy argument.

"I'm just going to hack something together." (usually means do substandard work but with the benefit of speed)

"It works, but it's a nasty hack." (a workaround that might be clever, but isn't necessarily safe, testable, or repeatable).

A "hacker" in the sense that GP is using it means somebody who's default method of working involves doing the above on a regular basis.

Think of it this way - a hacker will give you an MVP. An engineer will take an MVP and turn it into true-blue infrastructure or if that can't be done, give you a technical analysis detailing why not. In some (many) cases, a person will need to do both and they both require their own skill sets. I agree they aren't mutually exclusive, but I never wrote what I wrote to imply that.

See also (caveat: I don't wholly agree with this): http://www.paulgraham.com/gba.html

Your sentence “there isn't the hacker/engineer dichotomy in ‘traditional’ engineering” can be paraphrased as: there is a dichotomy between a hacker and a software engineer... aaarrrgh!!

I am saying I have trouble following your comment, and your reply is confusing me further. I just wanted to say that using “hacker” as part of a comment will often cause confusion.

Disclaimer: I studied as an electronic engineer, and I consider myself a software engineer (I engineer my software carefully to work reliably as designed: although I can admire a good spaghetti cowboy solution if it meets some commercial or personal goal!)

Edit: “I don't wholly agree with this: http://www.paulgraham.com/gba.html ,” really displays that the meaning of hacker is a variable.

I'm sure there are as many "engineering hackers" out there as there are computer hackers, if not more. They just go by many names: DIYer, tinkerer, hobby mechanic, electronics enthusiast...

When I was in doing my Engineering degree in college, one of my professors once tried to make a spectrum of technical ability. One the low end he put "tinkerers" and on the high end he put "engineers." I think that's where a lot of my perceptions of technical ability are coming from. Like I said, it's just my opinion

And yes, good engineering should always be admired and sought after. But hacking and making has its uses and charms.

My answer: to an extent. Broadly speaking, software engineers do _basically_ the same thing that "real" engineers do - learning patterns and applying the useful/applicable pieces to the problem at hand.

The fundamental difference that separates software engineers from the rest is the consequence of failure and the culture of caution that comes with it.

If you're working on (non-embedded) software and you ship broken code to prod, chances are your consequences range from embarrassment and some angry emails on one end to a major financial loss at worst. With most other engineering disciplines, the cost of a screw-up _starts_ with a major financial loss and worst case? Honestly the sky is the limit. Fatalities, environmental ruination, loss of critical infrastructure, you name it - there are enough case studies on industrial horror shows to keep you up for the rest of your life, and in engineering school we had to read a lot of them.

This isn't accurate. Engineering screw ups are extremely common, we just don't usually take notice of them because they are so much lesser than the horror stories we learn about in school. If I had a nickel for every time I had to beat on something with a hammer to get it to line up the way it did in the CAD model, I could probably afford to pay someone else to beat it with a hammer. Little mistakes are a daily occurrence in most places, to say nothing of situations where "that's not really a problem, you just need to re-tighten it every now and then." The tragedies you occasionally see on the news are just the mistakes too big to hide behind closed doors.

Its not exactly the same (which two engineering practices are, anyway?) buts its pretty close.

In the case of the thing that needs to be retightened periodically, I'm referring to a case where a cost/benefit analysis would show that regular maintenance is more costly in the long run. Imagine a $1 Million dollar machine that is supposed to cost $50k per year to run over its lifetime of 10 years, but due to poor design winds up costing $100k per year to run. No one is going to pay an extra $1 Million to build a new machine to save $500k, but that's still $500k lost due to a screw up.

There isn't some secret army of engineers performing optimizations behind my back. Engineers design things to work, but we are fallible human beings who suffer confusion, exhaustion, distraction and at times just pure incompetence. Depending on the complexity of a system, we might have fellow engineers review our plans to look for issues we missed, but those reviewers too are fallible so things nevertheless get through.

I’ve been thinking of going back to school to go the opposite route (CS -> engineering, probably aerospace), but I have no idea how to go about it or how to estimate how much cash I need.

I also got a bit lucky when I was looking for my first fully-CS job in that my title was "automation engineer," so I was getting interest from recruiters thinking I was a _test_ automation engineer. That opened up the door, after that it was just sweet talking my way in and faking it till I made it, lol.

I’m just as surprised to see the number be this high. I can’t help but wonder if this might be due to survivorship bias: crossovers are, after all, self-selecting. Perhaps not all engineers would say the same, if forced to swap roles.

Regardless, I’m excited to hear more from these crossovers. As a (soon-to-be) recent graduate, I think there can tend to be a great difference in perception between CS students and Engineering students, particularly at institutions without rigorous CS programs. Many tend to view CS students in the same way that some CS students view bootcamp students- people motivated by an “easy path to success”. I’ve found this opinion is rarely held of engineering students, given the reputation of engineering programs. I think it’s very useful to profile the motivators, mindsets, and general attitudes between the disciplines, if only to see that perhaps the difference isn’t as large as one might assume.

We certainly view our pure CS people as experts in what they do -- and the things I see them do are, e.g., build out cloud based versions of our product, add new GUI features, automate build and test systems (until management tries to replace them with us... a dubious proposition at best). That's just the stuff I see day to day, since it's most closely tied with us on the numerical side. Why wouldn't that be engineering? I could speculate but I don't care to. We are all working to make the product the customers want.

It was easy to learn programming. One reason was that the tools were always relatively cheap (even when they cost money), and the cost to learn by trial and error was negligible. At least this is true for the basics. Becoming a good programmer who can be an asset to a large project is outside my wheel house, though I'm in the process of learning.

Today, for mechanical design, you at least need access to SolidWorks, and the part of learning that comes from experiencing failure is costly and time consuming. Surely 3d printing is changing that equation, but not overnight.

But you can test the waters of programming without asking anybody for permission, and if you discover that you hate it, then you can just bury it. And many do. Programming is hard or most people, for reasons that I don't think we understand.

Now, programming and mechanical design by themselves are not engineering, but if someone wants to get into a new skill through the back door, they are similar. A person with SolidWorks skills can be useful as a designer without being a full blown engineer.

Engineering is a method of problem solving: accomplishing goals within a specified framework by using your understanding of the situation to identify constraints and predictably satisfy requirements.

To translate that into something more clear: if you can quantify what you're doing, and within some range you know you'll succeed and outside that range you will fail, you are doing engineering. If you're regularly doing engineering, you're an engineer.

If you regularly find yourself saying "we need a server response time of less than x" or "we only have y amount of memory to work with" or "this layout reduces churn by z%", you're doing engineering. Even if the numbers are only implicit (for example saying it has to run on a phone is just a standin for it has to meet the quantitative requirements to run on a phone) it still counts.

There are plenty of software developers who are more artisans than engineers - they don't think in terms of satisfying requirements and what is "good enough" but rather in qualitative terms. Perhaps they are more interested in how their software is made than what it actually accomplishes, or perhaps they aren't really trying to accomplish anything specific and are more just hacking for its own sake. If nothing else, plenty of software developers simply don't question why they are doing something in a given way, deferring to past experience or taste over understanding. Note that in many situations, the artisanal approach is perfectly valid, though in cases where predictable and optimized solutions are really necessary, an engineering approach is really warranted.

Also note that no one exclusively engineers. Just because you're not doing engineering right now doesn't mean you never did in the past nor never could in the future. And vice versa, just because you're an engineer at the moment doesn't mean you can't occasionally apply an artisan's touch.

Engineering is very much about the accumulation of experience - the reason all the planning is up front isn't because the Secret Society of Engineers said so, but because they are practicing something that has between hundreds (electrical, maybe ~200 years) and thousands (mining, dates back to the stone age) of years experience.

In 100 years, software engineers will have an enormous advantage over almost all non-engineers at designing and running software projects. There'll be a few amateur prodigies that nobody trusts, and putting an engineer in charge of software projects will mysteriously trigger a lack of things going wrong.

Software isn't unpredictable. Nearly nothing is unpredictable. The process of figuring out which bits are predictable isn't finished because the hardware keeps changing and forcing the tech stack to change. When the S-curve of hardware progress flattens, software engineering will gain in importance.

* Changed from 20-30 because that was wrong. Changes none of the arguments.

The strongest indication programming is not engineering is forgetting and reinventing the past. Also revolutionary tools and techniques are invented far too often in CS.

In mechanical engineering we've had screws for a few centuries and off the top of my head the most recent innovation in screw fastener tech was the creation of the "Torx" screw standard in the 60s. The Torx innovation was due to smarter torque controlled automatic screwdrivers on assembly lines WRT electronic drive tech and early digital control.

Gas, Diesel, Turbine, Rotary, in-line, V, Turbo, Carburated, SuperCharged, SkyActive-X etc.. etc..

While the basics principles are the same and over 120 years old, the Combustion engine has been re-invented and re-engineered a gazillion of times...

Maybe some of you guys here are young, but there were cars (large SUVs, or Sports Cars), that would consume 8-9mpg, yet still be slow as molasses compared to today's cars.

So, yes while the basic principles of the combustion engine are the same... but it has been re-engineered (from scratch), a many times, and each time it would be slightly better and better.

Same with planes, jets, tanks, etc...

Then there are innovations in manufacturing enabling new designs. 3D printing is coming along. Not everybody has to pull from a catalog of shapes, thicknesses, etc, for structural design.

If it was engineering, or even a “profession”, experience would be prized, instead ageism is rampant.

You are right that software engineering is a relatively young field, but people have tried to apply engineering principles to software since at least the Fifties. The term itself was coined sometime in the early 60s and was used by the ACM in 1966.

20-30 years? You think software engineering began in 1990 at the earliest?

Common production software, GCC for example, is older than that.

God knows 10 years ago is always gonna feel like 1990.

How do you define software engineering such that it's 20-30 years old? Why isn't it 50 years old? I ask because I've heard the argument that software engineering is a young discipline but it feels like you're really stretching it with those 20-30 years.

>When the S-curve of hardware progress flattens, software engineering will gain in importance.

But a lot of software engineering issues are entirely divorced from the underlying hardware. So I'm not sure how the shape of hardware has any significant bearing to our current situation.

>Engineering is very much about the accumulation of experience

I would argue that we actually know a ton about how to build software. It's just that it's not really being taught or valued or applied. I would argue that's an important distinction because it strengthens the analogy of electrical engineer vs electrician. So it's more about just an accumulation of experience.

To play devil's advocate with the other's position, even just over the time I've been in software since the early/mid 2000s I've seen things shift a number of times as new hardware creates new demands from our software or obsoletes old development struggles. PC RAM capacities rising 100x from 20+ years ago, more operations coming over on a slow and flaky WAN from untrusted devices, fewer people tolerating apps that only work on the tower PC stuck on their desk, more apps expected to sync state across devices because they're cheap enough we can own a bunch of them, use cases we learned to handle with plugged-in tower PCs adapting to power-draw-sensitive mobile devices, mobile devices being 1.5GHz instead of 16HMz, CPUs becoming fast enough that performance is often a footnote concern for whether to implement crypto, dedicated AI microchips changing what's possible on-device...

All of these seem like very reasonable justifications to rethink the way we build software, to change what's standard practice or to invent new tools that solve old problems in a modern context. To some degree the clock on when our industry starts accumulating stable knowledge won't start ticking until these kinds of changes stop happening.

But we already have stable knowledge that's simply not considered valuable. Your list of changes over the decades is of course a change but I don't understand why the attitude is "unless things stay stable over the next 30 years, there's no point in trying".

All those SOLID, agile, TDD, DDD, micro-services memes that are being implemented so superficially and cargo-cultishly are actually grounded in a real understanding that has a context, constraints, and trade-offs. The issue is that superficial and cargo-cult application. "Software engineers" that decide they're going to do micro-services without understanding what it solves, how it solves it and what they're trading off. And a business that doesn't care or know enough to ask for better. Maybe they don't need better! Maybe it's ok to slap together and the product will be equally mediocre whether the devs use cargo-cult pattern X or not. Maybe the quality doesn't matter that much to the business. In which case the devs being hired also don't need to actually know that much software engineering. In which case maybe the idea of electrical engineer vs electrician makes sense here too.

> the discipline is all of 20-30 years old.

Is kind of silly. The term "software engineering" originated in the 1960s, well beyond your range for it.

specialized knowledge or techniques

to design things,

to achieve or cause a specific outcome

within certain limits or constraints?

Then you're doing engineering. Whether to call yourself an engineer, well in the absence of a formal certification program, that's gonna be up to you and/or your employer. Former civil/structural here (that's the bridge-building one, and as far as I know, the most stringently credentialed/licensed).

It's helpful to remember that "engineer" comes from the French ingénieur which is also the source of the word "ingenuity." So an engineer is basically just an ingenuity-izer if you will. If you trace it back further, you get to the Latin ingenium (engine), of which the "genium" part comes from gignere (basically to cause something) which gives us "engender" and "generate" and "progeny" so you see there's a creative aspect too.

So, similarly, SWEs are engineers to the extent that they use widely accepted models to solve design problems. People building compilers, databases, or OS schedulers might be called engineers, because there are relatively well accepted (but evolving) models of the performance and capabilities of those things—-although those models are perhaps less universally accepted than say, Newton’s laws. Hacking, on the other hand, is not engineering, because it is not backed by something like a well-understood model. It therefore tends to command less respect, as the output of such activity is less certain—since there is no good predictive model to judge whether that activity will achieve the goal.

The devil is in the details though. How specific does the outcome need to be? And do you actually have to achieve the intended outcome in order for it to be engineering? Or just use the techniques with the hope of achieving the outcome?

Personally I think engineering is characterized primarily by predictability, usually through mathematical modelling. There's no absolute guarantee of success, but a Hail Mary isn't good enough either. Engineering is somewhere in between.

For example, the Mars Climate Orbiter didn't work, but no one would say that the people who built it weren't doing engineering. A simple but critical mistake was made in it's implementation. If it had been build according to the model, it would have worked.

On the other hand, was the Obamacare website engineered? I would say no. A few napkin calculations would have shown that it would not handle the load. No one had any business expecting it to work as deployed. And that is how a lot of software is written. No serious attempt is made to model the problem and prove that the solution will work.

Now that I think of it, so-called software engineering is the only engineering discipline I can think of where it's widely believed that mathematics is not required. The blogosphere seems to be riddled with posts that might as well be called "No good at maths? No problem - just become a programmer!"

But the "are we really engineers" question, like many others about definitions is destined to go in circles IMHO. Most important quote from the post:

> It’s a standard Wittgenstein game problem: human constructs do not neatly fall into precise definitions.

The actual debate seems to be around social status.. are software engineers as high up the social status ladder as "real" engineers? I don't know/care. Play stupid games, win stupid prizes :D If software engineering stays a sufficiently selective, high-paying, important field for long enough, it will gain the prestige to be considered "real" engineering. Otherwise it will not.

I think it will become both - more bifurcation. The top salaries & status will be reserved for 1/10th of the engineers. A lot of the bottom will become lower paid and more automated, closer to technical support.

I think of software lies somewhere nebulously between craftsmanship and engineering.

There's a flavor of pure craftsman/artisan that can make an excellent product with overall little "technical" knowledge. A traditional potter works much on instinct, texture, feel. He might know how to select a clay by color, not knowing or even thinking about the constituent minerals. Water is added in eye-measured doses.

Then, there's a flavor of pure engineer that executes most of his tasks in structured, industry-prescribed, formally-verified, deterministic ways. Particle aerospace engineers are the extreme in this category--they're a slave to the formal methods that rule their design, build, and test processes.

But we software "engineers" float back and forth between the two--and all the time. One minute, we might hacking together a throwaway script that checks if Amazon has toilet paper. The next: writing a test for a rules engine that tests every corner case in a truth table. Or proving that some algo runs in O(log n) time.

Most craftsmen/artisans lie somewhere on this spectrum, but I feel we software "engineers" wobble around a large swath.

So, call us software engineers, call us software craftsmen--they both apply.

Software for a F-35 definitely falls under software engineering. Bolting together frameworks for a home page is not engineering. In the same way, bolting a new turbo on your car is also not engineering.

Similarly, engineering needs processes to ensure high quality products. Having test suites with complete code coverage is much like engineering. Having code reviews is like engineering.

In terms of ethics, there are not codes that are followed by software “engineers”, but the world would benefit from adopting the codes from engineering, namely the principle duty of an engineer to protect the safety, health, and welfare of the public. If you’ve ever programmed a dark pattern or created an addictive interaction, you’re not protecting the public.

The other piece of this is that often I think Engineers are planners and not doers. They make the spec, do the match to figure out the tolerances, etc. Then some other people build the bridge or machine the part or whatever.

In software "engineers" are both planners and builders which seems like a weird mismatch of skills. The people who are better at building than planning get labelled hackers, the people who are better at planning and testing and verifying are labelled engineers.

Fun fact: In Canada you cannot call yourself an engineer unless you actually complete an engineering program and join the brotherhood of engineers or something. They have promise rings and a secret handshake.

I had a friend question me for calling myself a software engineer (even though they referred to themselves as one.) I've been programming for 15 years (8 years professionally) by 26 but they were unemployed and not practising after getting their BSc.

So in my opinion, there's more charlatanism coming out of academia than from honest professionals who have established a career and deep knowledge of their profession. But then again, I'm not building dams and bridges. So the answer mostly depends on what you're doing and how you got there.

I've asked many times even on these forums and have yet to get a credible source on this. I've been officially "called" sw engineer as per job title for roughly over a decade with 4 different large employers. I've never given this premise much credibility because of that, and perceive it to be wishful gatekeeping. I am hoping for some kind of clarification however.

I'd like to retire one day being able to say I've built a 40-50 year career while being a living, breathing lie. That makes me chuckle. =)

"An engineer is an individual who has been issued a licence to practise engineering by a provincial or territorial engineering regulatory body after demonstrating that they have the requisite education, skills, knowledge and experience. An engineer is sometimes referred to as a licensed engineer, a registered engineer or a professional engineer."

Professional engineer and engineer are both functionally equivalent and protected. You can't legally have the term engineer in your title in Canada unless you are an accredited engineer and pay your dues.

> Licence “Professional Engineer”, “Engineer” or “ingénieur” “P.Eng.”

This is exactly what I was referring to. They consider all of these monikers to to be in a "Professional Engineer" context. To interpret: not all engineers are professional engineers, but all professional engineers are engineers, and they will fight tooth and nail for the P.Eng protection. Hence my question about "Professional Engineer" status.

LinkedIn would be a simple search on this. Can you say why there are no fines or action being taken? I work with hundreds who have been given the engineer title, yet many more of us do not have P.Eng designation than those that do. How on Earth have the thousands upon thousands of us not been contacted even once in our decade(s) of employment, over multiple companies? We are openly breaking the law, after all, correct?

I believe the employees personally would be exempt, correct? As they are have been given these titles by their employing body and not self proclaiming a different title given upon them.

I have never heard of a software engineer *requiring* a licence to do their work. How many titles out there have sales engineer? Have you ever heard of a Sales Engineering program to graduate from? I'm not one to flaunt laws, but it's hard to imagine a large portion of companies, some very reputable, are illegally employing boatloads of engineers in Canada. On a lighter note, it's also hard not to imagine that this organization is the personified Karen of engineering gatekeeping. Is there anything, anywhere that actually sources Canadian Law?

I have never in any software engineering position I've ever applied for seen any form of "Applicant must show an engineering licence to be considered". Why is that not ever seen? Shouldn't all these companies be abiding by the law?

I'm simply leaving all doors open to prove it wrong with an open mind, but the evidence has to be clear. Is it part of law or is it not? And if so, from an official source, where?

This is one of the many problems with IT. I've interviewed many people with IT Security certifications who cannot explain the difference between encryption and hashing.

On the flip side, it is one of the great things about IT, that you don't need to go to university to get a job.

>No. Individuals with an engineering degree are known as engineering graduates, and a licensed engineer must take responsibility for their engineering work.

https://engineerscanada.ca/frequently-asked-questions

I have never heard of a software engineer requiring a licence to do their work. How many titles out there have sales engineer? I'm not one to flaunt laws, but it's hard to imagine a large portion of companies, some very reputable, are illegally employing boatloads of engineers in Canada. On a lighter note, it's also hard not to imagine that this organization is the personified Karen of engineering gatekeeping. Is there anything, anywhere that actually sources Canadian Law?

I have never in any software engineering position I've ever applied for seen any form of "Applicant must show an engineering licence to be considered". Why is that not ever seen? Shouldn't all these companies be abiding by the law?

I'm simply leaving all doors open to prove it wrong with an open mind, but the evidence has to be clear. Is it part of law or is it not? And if so, from an official source, where?

The Act is a bit different in each province. The Act for Ontario says

> Offence, use of term “professional engineer”, etc.

>(2) Every person who is not a holder of a licence or a temporary licence and who, (a.1) uses the title “engineer” or an abbreviation of that title in a manner that will lead to the belief that the person may engage in the practice of professional engineering;

>(b) uses a term, title or description that will lead to the belief that the person may engage in the practice of professional engineering; or

...

>is guilty of an offence and on conviction is liable for the first offence to a fine of not more than $10,000 and for each subsequent offence to a fine of not more than $25,000. R.S.O. 1990, c. P.28, s. 40 (2); 2001, c. 9, Sched. B, s. 11 (59).

only if you are using the word engineer in such a way that would lead someone to believe that you are engaging in the practice of professional engineering is it illegal.

The practice of professional engineering also has a definition under the Act:

>“practice of professional engineering” means any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising that requires the application of engineering principles and concerns the safeguarding of life, health, property, economic interests, the public welfare or the environment, or the managing of any such act; (“exercice de la profession d’ingénieur”)

If the activity being performed does not affect safeguarding of life, public welfare, or the environment you are probably off the hook and not leading anyone to believe that you are practicing professional engineering and can use the word engineer in your title and nobody will care.

If the activity being performed could kill someone or damage the environment and you are using the title of Engineer then that is contrary to the act and if something goes wrong and someone wants to file a complaint with the regulatory body against you for representing yourself as an Engineer when in fact you are not then you could be found guilty by the regulatory body's complaints committee.

So it depends what software one is writing does:

Crud app? probably not professional engineering

web site? probably not professional engineering

software that controls a dam spillway? probably professional engineering

software that controls traffic lights? probably probably professional engineering

software that controls a vehicle on a public road? probably professional engineering

software that controls an airplane? probably professional engineering

Thanks for asking the question and prompting me to dig in to this a bit more.

[1]: https://www.ontario.ca/laws/statute/90p28

I think this fairly answers my original comment:

> I thought this was for specifically for "Professional Engineer" status.

In Canada One needs to be careful as to what projects they take on if they are calling themselves anything with engineer in the title.

Same in Texas. [0]

[0] https://pels.texas.gov/downloads/eb17.htm (search for "Software Engineering")

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

As HN readership isn’t strictly American, I don’t see why specifying that engineer is a legally protected title in Canada is a bad thing...

From the article, Mat’s previous job was Geological engineering. “His firm was hired to analyze a block cave in British Columbia.”

Also from the article “In Canada you can’t even call yourself a “Software Engineer” unless you’re accredited!”

The article specifically mentions Canada.

I’m sorry if I’m not reading into the most generous possible phrasing of your comment, but I can’t figure out what point you’re trying to make.

To me this is similar to the comments of the form “found the x” on HN. In this case you could have said “found the Canadian” and I still wouldn’t know what point is being made.

So, to my point, HN has international readership, some of which is Canadian, having people on HN point out some of the specifics about practicing engineering in Canada (or any other country for that matter) seems to be a useful addition to the commentary. Some HN readership is still in high school or early into their college or university studies and not everyone has access to the same resources, mentors, or even knowledge of where to research answers to their questions. Sharing on HN is a great thing and can be beneficial to these people. I know I’ve personally benefitted a great deal from HN comments.

I provided a link as proof.

So in lot of companies the official title is software engineer even without any accreditation.

"But ours is a world always in flux, where the laws of physics change weekly. If we did not quickly adapt to the unforeseen, the only foreseeable event would be our own destruction."

The "laws of physics" as they apply to software are the same now as they were in 1968 when the term "software crisis" was created. They're mathematics, logic, and algorithms---not the physics of engineers, but just as rock solid. All of the "flux" and change are either getting a new model of bulldozer or changing the color of the paint in the bathroom.

And yes, clients change their requirements in every other field, too. The major difference is that those other fields have the scones to tell the client, "That will cost more." There is one difference, though.

"You need a license to be a “principal engineer”, a.k.a. the person who formally signs off on plans as valid."

Yes, you need someone who accepts bottom-line responsibility. That is something that exactly no one in software development wants.

Now, me, I don't claim to be any kind of engineer. (Unless I'm running the train. Toot! Toot!) I'm a programmer. That's not because I don't feel what I do to be engineering-ish. It is because I find that what passes for the actual field of "software engineering" (https://www.computer.org/education/bodies-of-knowledge/softw...) is entirely disjoint from the production of software.

One thing I don't think was covered in the article was liability. I think that is a major thing that separates software engineering from other branches of engineering. Maybe it is not the case in the US but in my country if I contribute to an engineering project I can be held accountable in a court of law for my work.

I can see a future where software has similar laws applied to it.

I used to write software for industrial control systems. Knowing that someone's life is relying on the software I wrote (but last had control over) 8 years ago to do what it's supposed to right now is a deeply unsettling feeling.

It really isn't.

The definition of engineer is "a person who designs, builds, or maintains engines, machines, or public works."

We're building software engines, machines, and public works. Just because we're applying it for the software incarnation of the concept doesn't break the definition.

This is getting silly.

How isn't that like claiming you're a chef because you have a catering company where you serve microwaved foods, and claim it's silly to try to distinguish degrees of cooking skills.

By the definition you gave, no one can be a chemical, industrial, or electronic engineer. Silly!

In doing so, we see what lessons there are to take from each other, and gain a better understanding of both fields. For example, the author cites that version control is an innovation that traditional engineering could hugely benefit from.

Back in '47, the ECPD, which later more or less turned into the ABET, used the definition:

"The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property."

It would seem programming-type-stuff is more of a technical craft than an act of engineering. Ideally on the best days on projects of small scope, programming can approach engineering levels of rigor.

The tolerance for bugs is vastly higher in programming than in structural steel engineering, for example. There are no valid statistical analysis techniques for programming to reliably predict quality of code, although infinite conflicting opinions exist alongside some rather trivial rules. Some "full stack" types approach full cognizance of their design; but its rare outside narrow areas like embedded or device driver designers. Economics of operation is usually hand waved away with "moores law" and "batteries always get better over time", and environmental impacts (aside from mere greenwashing and virtue signaling) are ignored. Engineers use reliable and predictable statistical process control methods to ensure mass produced parts work together under a well defined standard, programmers are like "here's a URL to the docs for the API from a couple versions ago best of luck to ya".

I'd say on the technical continuum that programming is very much like village blacksmithing. Somehow in general the horses get horseshoes but its not cheap, efficient, safe, clean, predictable, or fast.

The future being distributed very unevenly, I'd predict we'll see the first widespread "real engineering" of computer-stuff appear in corporate IT departments probably revolving around statistical analysis of cloud computing.

These are manufacturing tolerances and safety factors.

Unless you're testing the piece of steel you're bout to use, you don't really know that it's yield strength is what the box says. Similarly, the welding might be done by an apprentice with a bad teacher, and during maintenance, the repair guy might run out of a certain bolt and use a different one with a washer.

When you purchase Steel it is purchased to a specification (such as minimum yield strength) if the steel fails to meet those specs the supplier can be held liable.

In software terms I suppose the equivalent would be purchasing a commercial library with support from vendor.

For major construction projects welds are inspected and singed off on, they may be tested as well.

Again in software terms equivalent would be code audit and test cases.

In construction there is a lot of inspecting stuff, signing off on it and certifying stuff. I think software people would go crazy if they had to deal with the same amount of paperwork.

That's what these days is referred to as an SLO.

Golden signals, USE, RED are ways of measuring them on a high level.

You program your systems to be resilient to a certain level of failure (retries, graceful failure), and you program them to be able to cope without a malfunctioning part by isolating it from the rest of the system (circuit breakers, bulkheads).

Last year I took a job from a surprisingly big car manufacturer. They had designed and built a 2 million dollar glue dispensing machine. Only after it was fully assembled did they realize that they didn't have a way to get the glue into it. They needed it to be running the next week. Engineers run into bugs all the time, we just don't get convenient error messages.

What about all the poor quality consumer-grade stuff out there? Are mechanical and electrical engineers not designing that too?

Engineers should be able to understand design principles and be able to architect a new system from those principles. In today's world i think we are moving further away from this than closer. We spend much of our time learning trivia such as how to fiddle with a particular software platform to get it to work.

Additionally with all the various abstractions that we have built (lock-in cloud services, high level languages, proprietary platforms, etc) many people are no longer capable of discussing with you what is happening on the CPU or how data should flow through a system or the disadvantages of a distributed architecture, etc.

I think that software engineering is still in it's infancy in someways and hasn't yet matured enough to be an engineering discipline. That being said there is an egalitarian quality about being a "software engineer". We're all software engineers.

In my mind, there are two: making stuff, and tolerances.

Making stuff is magic. Most people reading this can sit down at a computer and formalize an idea such that the computer can do it. Most people can't do this. It is valuable for the same reason the ability to design a car or escalator or rocketship is valuable.

Tolerances is all about providing certain guarantees about the stuff you make. I think most developers could hit those guarantees...if they were ever verbalized. What, you want me to decrease memory usage by 50%? Actually, I probably can do it. At the very least, I can point you some academic papers as to why it's impossible.

But nobody has ever asked me to do that, ever (except in interview questions). I suspect my experience is common among developers.

So, from a "making-stuff" perspective, yeah, we're engineers. From a "tolerances" perspective, most of us aren't, but wouldn't have much trouble becoming them. It's just that no one actually wants that.

Nevertheless, an engineering discipline would seek to identify all sources of unpredictability and tame them.

Engineering is "the elimination of guesswork". Let's see how some typical activities might be classified under this broad definition.

  - Installing a package from Npm and invoking some functions from it: Not Engineering.

  - Writing a function definition with a specified contract, a test suite to verify the contract is satisfied, documentation for users of the function, a characterised performance envelope, etc. : Engineering.

  - Downloading the source code for a function from Github and verifying that it satisfies the same function contract, passes the same test suite and offers satisfactory performance characteristics: Engineering.

https://ethics.acm.org/code-of-ethics/software-engineering-c...

This code transcends managerial demands for shortcuts in the name of budget constraints or deadlines. Or it should do; professional engineers who are certified as such know that they can stand their ground and be given the full backup of a national organisation. An organisation which can fight a court case if necessary or blacklist an offending employer and cause other engineers to avoid working there. Whereas even the best software developers will be simply fired for any kind of professional pushback:

https://www.theguardian.com/technology/2020/dec/16/google-ti...

I lived through the "design patterns" trend, which seemed like an attempt to create a software equivalent to the "unit operations" we ChemE students all learned, but it was basically a flop because in the end you can use almost any design pattern to solve a given problem.

I don't much care whether you call it "engineering" - but the gap between the smokestack industries and software remains.

Can decisions be motivated by clear objectives and rigorous deductive reasoning, which are useful to validate the design process and also to clearly communicate what is being done and why?

A lot of conventional software “knowledge” is too hand-wavy & wooly (not to mention fad-driven) to pass that threshold, imho. A lot of software platforms/infrastructure we use is the way it is for fairly arbitrary historical reasons, quite apart from the fact that many domains where software is applied are quite hard to parametrize rigorously. There are islands however, where the design is fairly rigorous and could be considered closer to the spirit of “engineering”. But the most important input for a craft to mature into engineering is time and rigorous effort.

Either ways, I don’t see this question mattering too much in immediate practice.

The people who write software for a space-shuttle do engineering work, your average app store app is likely not 'engineered'.

I think it matters because it says a lot about how seriously the software industry as a whole takes the quality of its products and to what standards we hold software and with what goals in mind we make software. If we treated software like engineers treat aircrafts we'd likely have a lot less of it, but what we had would probably not crash that often.

The debate is tied to the debate about why so much software today feels so terrible and bloated and that makes it relatively important in my opinion.

You can't call yourselves 'hackers' and 'engineers' at the same time. (I mean, you _can_, but talk is cheap)

That's not a bad thing by a long shot. There's a time and place for hacking as there is for engineering.

I've said it before on HN and I'll say it again: Engineering is a social process, not a technical one.

It's a social process because society has certain expectations of the people who design bridges and skyscrapers and cars and toaster ovens. By certifying a design you as the engineer are making a representation to society, not just that you are trained but also that you have conducted yourself in an ethical manner. You are making a representation that, for example, you did not cut corners just to save your employer money, or that you sought fair compensation for your work (so that you are properly motivated to carry out your due diligence), or that you didn't opt to use $fancy_new_but_not_proven product merely because the manufacturer took you out to the strip club.

Conversely, when engineers screw up then society rightfully demands that there be consequences whether punitive or remedial. This is why engineering isn't just a job but a Profession, that is to say Engineering as a field is self-governing. Professional Engineers are accountable to their fraternal orders (regulatory bodies) who are themselves accountable to society.

Given limitless time and money, anyone can design a bridge that will stay up. But only a properly trained engineer can design a bridge that will just stay up, and therein lies the difference between a software engineer designing and maybe implementing code that will fly on the Space Shuttle versus me slapping together some javascript for my personal website. The latter is not engineering just because I'm an engineer.

The computer game "Civilization" by Sid Meier provides a succinct definition of what engineering is:

engineering is an application of scientific theories and methodology to solving real world problems.

(Perhaps not in those exact words, but you get the idea.)

There are two major flaws with the article:

1. the author assumes that licensing is the result of legal requirements, whereas in reality, state licensing exams exist to ensure that licensees all have the same common denominator of standardized, required knowledge to perform adequately and correctly within their profession;

2. core part of the engineering process is writing formalized requirements and specifications stemming from those requirements, but the article skips this, the most important aspect of engineering: "The third quality will be discussed in the next essay."

Perhaps another distinction is between trying something and see if it works, and knowing it will work (or won't work) before it's implemented. Then the difference is between knowing from experience and knowing from having studied the theory (and having worked through the proofs).

I used to work in an agency and we would charge by the hour so you needed to find a safe space between speed and safety. I wrote some nice, and some not so nice code there.

I now work at a much larger company and the environment is vastly different. We focus heavily on metrics, are very careful with testing, make sure to design design components, security reviews, and have plenty of documentation.

I really do wish software engineering could be used as the term to identify this kind of environment where it's not just about the code, but about all the stuff you do around code to ensure it's safe.

[1] Not in the State of Texas; I'm not licensed, and don't intend to be.

That said; which engineering field are you basing this on? I thought that generally only lead engineers or architects were responsible in that way.

If you try to hide your bugs, paper over them, and somebody gets killed... that's where the crime comes in... Looking at you Boeing.

Most of what people think of for an engineer, is someone using material properties to do something useful.

IMO concentrate on how to do your job/task/hobby to the best of your ability and learn new things to do better, and it doesn't matter as to the label under which you do.

Even with that title, I don't think it's a big deal if someone who didn't get the same title calls himself an engineer. Talk is cheap, but if you can create systems you can call yourself an engineer in my opinion.

What is lacking is an understanding of the ethics, duty and responsibility to the public that is hammered into the conventional engineers on day one. It starts with subtle things... In school, we had very strict standards for report formats. If you screwed up something (like putting a figure title above a figure instead of below, or vice versa for a table) you got ZERO credit for that report, regardless of how much of your grade it counted for. If you misreported the significant figures on a result? Zero credit. Didn't do an appropriate error analysis? Zero credit.

This isn't just anal retentive BS though. It teaches from the very beginning that failure to adhere to the code has serious ramifications. It teaches you that when you, as an engineer with a duty to the public, report a figure as a result of your calculation, you had damn well better be right. If you get it wrong, people can and do die.

In the real world, if I inappropriately call myself a "Professional Engineer" or a "Structural Engineer", that's straight up illegal. I can lose the right to future licensure for something like that. If as a P.E., you make a mistake, or perform work outside of your scope of knowledge, the licensing board WILL sanction you ruthlessly. For minor things, they may just require you to re-mentor under an engineer and get all of your work reviewed before you stamp it. For more serious things, you will lose your right to sign off on work at all.

Fields where this is used are highly regulated with usually law mandated sanctioning process that is designed to reduce direct risk to humans.

Do fields where there is no such risk have this type of sanctioning? For example mechanical (machine) engineers or chemical engineers.

Being an engineer doesn't mean you need to be sanctioned by some body. If you get sanctioned, you might be Chartered Engineer or something similar. Interestingly, UK has Chartered IT Professional.

For example, if your company wants to build a computer system for the government, the contract usually requires certain certifications for the people that will build it.

There are also some jobs that require certain certifications for the candidates. It's not too uncommon I'd say. It all depends on the stakes.

Software is different in a lot of ways. Especially at the high level, you are solving a puzzle. Let's say you need to generate a report. You've got all the tools in your language and several libraries. You know you'll have to talk to a database, pull down data into some kind of data structure, open a file handle, write the data, close the file, and save the results somewhere and then send an email. Is it technical? Yes. Challenging, well...maybe not this example, but software can be very challenging yes. But is it engineering? I wouldn't call it that. And no, I'm not sneering at it, or calling engineering superior. I just see the two as very different.

The stuff you do in engineering school (calculus, differential equations, statistics, linear algebra, circuit analysis, signal processing, Fourier transforms, control theory...etc as tools to solve problems with radio, industrial machines, turbines..etc) has pretty much zero to do with web design, standard business apps, databases, compilers...etc. If you use engineering as a general term to mean "make technical stuff" than you could apply it to either field equally, but engineering has already had a definition for many years and software is it's own thing. So use the term "coder", "developer", "programmer", "hacker", "complexity guru", or even "software engineer" as they all make sense. But the general term "engineer" would apply to mechanical, electrical, chemical, industrial, civil, biomedical...etc. All of those fields have the same core math classes and they then usually share an intermediate set of classes (thermodynamics, dynamics, statics, circuits...etc) before the advanced classes which specifically apply to your field. I don't think a very high percentage of coders (amazing, technical, often better paid, and very valuable as they are) have an overlapping lineage and language with what you would think of as traditional engineering. Believe me when I say I'm not gatekeeping the term either. I just honestly feel like there these things are taxonomically different. Maybe a new single word term should exist to convey what software developer does with two words.

Of course we are engineers. OP uses "building a bridge" as an example of 'real' engineers. This is patently ridiculous on the face of it.

The one thing that unites us is we like to build. Whether it's the great pyramids or the latest social network, engineers are the ones who get it done.

We build. That's what engineers do. We build something to solve some problem whether it's with bits and electrons or with larger physical mediums like slabs of concrete. Engineers are builders and they build to solve some particular use case.

"Scientists build to learn. Engineers learn to build"

'Real' engineers are not judged by whether or not they can build a bridge as if it's some rite of passage to being a real engineer. That's ridiculous on the face of it.

That he used this example as some kind of proof to justify his argument is where he lost me.

Do "software engineers" really want to be liable for software bugs? That's what you're asking for.

Lot of people here are putting = between engineer and licensed engineer.

However, your processes mutate so that the liable engineer can reasonably sign something and not get hung out to dry.

This means reviews, engineering change orders, signoffs, etc.--ie. all the bureaucracy that software programmers love to complain about gets turned up to 11.

"Agility" and "Liability" are directly conflicting goals.