Are We Really Engineers?(hillelwayne.com)

https://www.hillelwayne.com/post/crossover-project/are-we-really-engineers/

142 comments

Mechanical engineer who worked as an energy engineer before getting his CS degree speaking here, but I'd tentatively say yes. I don't have a whole lot of experience using my CS degree yet but the main difference between a software developer/SWE/programmer and a hacker is the amount of paranoia that goes into making something. If you are a good software engineer, you've tested and verified everything and you've made sure there little to no risk to your end user. If you don't you're a hacker.

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

robocat5년 전

I suggest you avoid using the word hacker, as to me you are using it in a negative sense, while missing that a good hack can be excellent engineering. “Hacker” contains a wild variety of behaviour and skills. The concept is too amorphous and people have wildly disagreeing meanings associated with the word (the meaning is very audience and context sensitive) so it is difficult to use the word as a proxy for the sense you wanted to convey, in a discussion with a wide audience.

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.

Thorentis5년 전

I would go out on a limb and say the negative connotations are correct in most cases and usages. E.g.

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

totemandtoken5년 전

I didn't mean "hacker" as opposing engineering.

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

robocat5년 전

> I didn't mean "hacker" as opposing engineering.

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.

Groxx5년 전

tbh I think it's fine, this site is literally named "hacker news". they're using the term in roughly the same way.

[deleted]5년 전

weinzierl5년 전

> "[...] that there isn't the hacker/engineer dichotomy in "traditional" engineering."

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

totemandtoken5년 전

Yeah, there's definitely a wide spectrum. I just kind of lump them in as makers. Most of the people I've met at my local makerspace fit this bill - they're just tinkering with something or taking up a hobby. But as I mentioned, most of these people I've met are/were engineers professionally. I think it's just that on their personal projects they were more relaxed about "process" than they would be at work.

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

tobmlt5년 전

Computational software engineer with physical engineering qualifications here -- we better be engineers on both sides of the divide! I suppose I don't really count though, as far as the question goes, since the software I write is used for doing physical engineering, and is a tiny fraction of software development, etc.

totemandtoken5년 전

Of course you count.

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

[deleted]5년 전

naveen995년 전

Please see jargon file: http://www.catb.org/jargon/html/

Antoninus5년 전

I agree, the overlapping difference in quality software production is diligent security and testing.

letitbeirie5년 전

My degree is in mechanical engineering but I've been working in software for 4 years now but I worked on industrial control systems for a number of years before that.

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.

jjk1665년 전

> With most other engineering disciplines, the cost of a screw-up _starts_ with a major financial loss

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.

zanellato195년 전

People think that knockoff products don't have engineering in them? Even in cars, a lot of things don't fit neatly as they should and its fine, we just do a little push.

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

the_jeremy5년 전

Is that really a screw up? Companies pay for certain tolerances on their products. I think it's more likely someone acknowledged your anecdote was possible and decided the cost/benefit analysis worked out to that being most profitable. Most things don't have to fit like Lego (while some things have to fit even better than Lego).

jjk1665년 전

Yes, it is a screw up. If something is in tolerance, it goes into the hole it was designed to go into, that's what a tolerance is. What I am describing is something that is out of tolerance for which corrective action needs to be taken to get it into tolerance. This is not an uncommon occurrence, it is the norm. There are times when you deliberately put in room for fine adjustment, but you don't do fine adjustment by bashing on things with a hammer (or if you do then you've made some other mistake).

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.

totemandtoken5년 전

Hey, another one! I thought I was alone in my career path.

watermelon595년 전

Sorry for going off a tangent here, but when you say you got a CS degree after being a mechanical and energy engineer, do you mean you went back to university for a full undergrad in CS? Or was that a Master’s?

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.

letitbeirie5년 전

I didn't actually go back to school for CS - I had a lot of CS classes in undergrad that gave me some of the OOP theory background, but after that has just been whatever I picked up on the job or to solve a problem on the side.

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.

leapis5년 전

“Of the 18 crossovers I talked to, 16 said yes.“

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.

tobmlt5년 전

The answer is a clear yes in my case, but I work on commercial numerical design and analysis software. The interleaving of computers and engineering entailed here makes a hard case that there is not an absolute "no" available. But computational software is a corner case, I know. (sigh)

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.

syntaxing5년 전

MechE here so my thoughts can be biased. It’s high because of two reasons. One the pay is typically much better (upward of 20%-100% (yes 100) better) and secondly the “crossover” barrier is much lower compared to other engineer mobility. For instance I would argue, a MechE becoming a SWE is easier than a SWE to become a MechE since companies are opened to SWE not having a specific degree in it.

analog315년 전

I wonder if there might be a technological barrier. My degree is in physics, so I depend on mobility for any hope of employment. ;-)

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.

jjk1665년 전

I'm a mechanical engineer. Not every software developer is an engineer in my book, but many if not most are.

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.

roenxi5년 전

There is something special about software engineering that deserves a bit of thought - the discipline is all of 70-80* years old. There are people on HN who are older than software engineering.

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.

VLM5년 전

"The Mythical Man Month" first edition is 45 years old as a retrospective on a decade old development project 55 years ago.

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.

ardit335년 전

lets be real, how many versions of the Combustion Engine are.... a gazillion.

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

tobmlt5년 전

Additionally, the process of doing the physical engineering has changed drastically -- computational tools, design space exploration, optimization methods. (recognizing that the grandparent comment stuck specifically to screw-tech, but it's interesting to think about physical-engineering-innovation in broad terms)

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.

goatinaboat5년 전

The strongest indication programming is not engineering is forgetting and reinventing the past

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

xkeysc0re5년 전

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

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.

chrisseaton5년 전

> There is something special about software engineering that deserves a bit of thought - the discipline is all of 20-30 years old

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

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

Dudeman1125년 전

Maybe he meant 70s-80s?

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

weff_5년 전

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

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.

spiffytech5년 전

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

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.

weff_5년 전

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

[deleted]5년 전

Jtsummers5년 전

While the dead comment is rude:

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

canadianfella5년 전

rdiddly5년 전

Look, do you use

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.

GIFtheory5년 전

My take is that engineering is essentially the use of predictive models to solve design problems. I think the general trend is that the more accurate and universally accepted the models are, the more ‘engineery’ a particular discipline is. EEs use models of circuits and devices. ChemEs use models of chemical reactions. MechEs use models based on physics. Financial engineers use models of options pricing, etc. Optical engineers use optics.

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.

rdiddly5년 전

The model aspect is a good addition, because that's one of the things that differentiates engineers from pure scientists, or mathematicians. Engineers design to the model, which in some cases may not represent reality with complete accuracy, but will in those cases be much easier to work with. So long as that model has a demonstrated track-record of producing good results, and the same assumptions it makes have been proven valid for the current design, then it's usually good enough for design purposes.

injb5년 전

EDIT: I should have just read GIFtheory's post below! That's pretty much what I meant.

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

zaptheimpaler5년 전

More specific questions can be readily answered - is software engineering as demanding of perfect execution as other engineering disciplines? are software engineering projects completed on time more/less relative to other disciplines? does software engineering require formal certification to practice? does it have a component of skill in that people who put in more time or have more aptitude do better than others? is it more critical or less critical to

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.

oh-4-fucks-sake5년 전

I'm a bit of a centrist here:

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.

twobitshifter5년 전

I think it depends on the use of scientific principles in your work and the application of engineering ethics.

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.

bluefirebrand5년 전

I like this. One thing I think that complicates matters is companies and teams that adopt SOME engineering principles but not others. When the chips are down I find that QA and Writing tests go out the window to a certain extent in favor of "just get it done". That's not something I imagine happens in "real world" engineering especially when lives and safety are at stake.

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.

lwansbrough5년 전

In Canada the title "engineer" is a legally protected term. You can't legally call yourself a software engineer without going through the Engineers Canada accreditation.

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.

Humdeee5년 전

Is there a source on this? I thought this was for specifically for "Professional Engineer" status. If not, myself (3 year college program grad) and many, many others are not what our current titles are as given by multiple employers.

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

freshpots5년 전

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

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

Humdeee5년 전

Also, digging deeper in for example the Ontario section of your source about licencing:

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

freshpots5년 전

Not quite. All engineers are professional engineers. The term engineer is protected and you are not an engineer unless you also are a professional engineer. No P.Eng. then you're not allowed to advertise yourself as an engineer.

Humdeee5년 전

The vast majority of people without P.Eng do not advertise themselves as engineers as deception, as it's their employers which have given this title. If that is still against the law, I suppose I am witness to many thousands of companies breaking the law by employing many more thousands of people that they have labelled as engineer, yet without P.Eng.

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.

Humdeee5년 전

This source would need to serve as a proxy to the real source (if it exists) in law that claims these rules are in fact, actual law. That is what is being asked. This is not law, it rather a organization on a plight to attempt to make it law. Please correct me if I'm wrong.

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?

Khaine5년 전

Gatekeeping is the entire point of professional bodies, and certifications. It is suppose to show that people with those qualifications have sufficient skill and experience to do the role.

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.

rhodozelia5년 전

>Can a person with an engineering degree call themselves an engineer in Canada?

>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

Humdeee5년 전

This source would need to serve as a proxy to the real source (if it exists) in law that claims these rules are in fact, actual law. That is what is being asked. This is not law, it appears rather a organization on a plight to attempt to make it law. Please correct me if I'm wrong.

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?

rhodozelia5년 전

The jurisdiction of the regulation of Engineering in Canada is provincial. Accordingly each province has a law, such as the Professional Engineers Act in Ontario [1], which creates the regulatory association and gives it power to enforce its bylaws under the Act.

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

Humdeee5년 전

Rhodezelia, thank you very much. Your summary is exactly what I was planning to respond after starting to read through your comment.

I think this fairly answers my original comment:

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

rhodozelia5년 전

It is not limited to the title of “Professional Engineer”. If the software or activity could harm someone or the environment so the activity matches the definition of “professional engineering” defined in the Act and the programmer or person undertaking the activity is calling themselves anything with engineer in the title and are not a P. Eng then they could be fined under the Act.

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.

[deleted]5년 전

rhodozelia5년 전

We have discovered whether you can use the title engineer depends on if your activity concerns the safeguarding of life, public welfare, or the environment. If it does, you should stop calling yourself an engineer. If it does not, then you are not going to lead anyone that you are engaging in the practice of professional engineering and can more safely run the risk of calling yourself an engineer and being open to the regulatory body complaints committee.

hollimolli5년 전

Wonder whether it has the same impact on salary like the common IT certifications (see e.g. https://www.forbes.com/sites/louiscolumbus/2020/02/10/15-top...). Otherwise it's just a waste of time.

dctoedt5년 전

> In Canada the title "engineer" is a legally protected term. You can't legally call yourself a software engineer without going through the Engineers Canada accreditation.

Same in Texas. [0]

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

bitbearr5년 전

Interestingly they discontinued the PE exams due to lack of candidates.

slyall5년 전

Canada always comes up in these threads. Last time was 26 days ago.

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

stevegalla5년 전

I have seen it argued that because HN is founded by Americans everything should be assumed to apply to America unless otherwise stated.

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.

slyall5년 전

The point I am making is that in any Hacker news thread about "engineers" somebody will always bring up this Canadian thing. To the extent I have now read this fact at least a dozen times.

I provided a link as proof.

robertbalent5년 전

However, this is not enforced at all for software engineers.

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

mcguire5년 전

Ok, let's get this straight right now.

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

bigger_cheese5년 전

I'm a Materials Engineer (I currently work in Metallurgy and industrial refining, before that Lithium Ion battery research).

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.

chrisulloa5년 전

Working in healthcare, engineers are liable for breaching data violations around health data. In everything from logging, storage and deletion of data, developers need to make sure that there is no personally identifiable information. There are plenty of other high stakes domains where engineers are certainly liable.

letitbeirie5년 전

True, but it's not just the legal liability.

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.

tofuahdude5년 전

`This is an important question...`

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.

weff_5년 전

That's a definition of engineering.

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.

robocat5년 전

Why does every person who pulls out a dictionary use a definition that looks like it came from a century old dictionary? Words change meaning over time. There were computers a century ago.

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

Conlectus5년 전

It may be an important question because answering it requires dissecting the similarities and differences between software development and the jobs that people usually call "engineering".

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.

VLM5년 전

I thought it kind of odd the author asked randos off the street to define "engineering"

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.

8note5년 전

Mechanical engineering has specifications for "bug" tolerance.

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.

bigger_cheese5년 전

Keep in mind that you do things to alleviate the possibility of "bugs"

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.

cassianoleal5년 전

> Mechanical engineering has specifications for "bug" tolerance.

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

jjk1665년 전

> Engineers use reliable and predictable statistical process control methods to ensure mass produced parts work together under a well defined standard

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.

allo375년 전

What I find funny is that these comparisons between SWE and "real" engineering generally involve a comparison to big safety-critical non-software projects like bridges and mines.

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

ascotan5년 전

I have seen that a lot of people that now have "software engineering" titles that are not doing "engineering of software". They're doing network/platform management or some other task that doesn't involve the actual design and architecture of software systems. ie. it's more of a payscale for HR than an actual discipline

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.

fancyfredbot5년 전

I tend to think of engineers as people who apply scientific and mathematical techniques to solve real world problems. Clearly some programmers do these things, but equally clearly some programmers do not! Why would you expect a yes or no answer?

dropit_sphere5년 전

"Engineer" sounds like kind of a moving target. The only "real" engineers design...engines. So it's worth asking what the actual value is of "engineering."

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.

pjbster5년 전

Software engineering is definitely a thing. But it's hard to define because, unlike a physical thing like a building which sits on a patch of ground which won't change much and which will sit there in atmospheric conditions which are unlikely to vary outside a known range, a piece of software is extremely sensitive to its environment. Pass in a single bad input (perhaps "unexpected" would be a better term) and an otherwise perfectly functional piece of code could bring civilisation to its knees. It's hard to rigorously prove your way out of that scenario.

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.

But there's more to it than "just" this. The engineering discipline also encourages adherence to a code of ethics. Such as this one:

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

dctaflin5년 전

Crossover guy here. I worked as a ChemE for 11 years, then as a software developer for 20. Regardless of terminology, the two fields are very different. If I have to design a process to separate two liquids, I have a few options available, and all are highly constrained by physics and a lot of math and equipment design has gone into optimizing them. But when writing code to solve a problem, the number of possible ways to accomplish it are endless, and other than big-O notation there's not a lot of constraints put on the solution.

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.

ssivark5년 전

I think the difference between craft and engineering is whether the knowledge is systematized (not binary, but on a continuum).

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.

siva75년 전

I think this question always poses something about status insecurity as the old discussion of what makes a "true" software developer. Engineering and Software Development share a key characteristic which is about inventing and implementing things. The key difference is that engineering is fundamentally based on applied physics and math where software development doesn't care about physics because it's an already solved abstraction in this discipline.

Buldak5년 전

I think you're right about the underlying concern about status. My sense is that people in this discussion are really asking whether software engineering is just easier than mechanical or chemical or aerospace--or whatever--engineering. That's also why I don't think calls for certification standards really address this concern (you can just as well be certified to do something easy).

siva75년 전

the absurdity of the question becomes clearer if you start thinking about the right tool for the job. if you need to invent facebook you don't start with reinventing the wheel but with applying software development. it's the right abstraction for the job. and no sane mind would claim that serving content to billion users a day is an easy task but in the end it's just software.

renewiltord5년 전

The enduring popularity of this question baffles me. I get it: other people like other things. But is it an idle enjoyment or is it something that helps conclude other things?

Barrin925년 전

It helps clarify to what standards software is supposed to adhere. As the author points out, the key feature of engineering is building to specification. Engineers have formal processes, standards, fault tolerances and expectations.

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.

renewiltord5년 전

Fascinating. Thanks for sharing your perspective.

CamperBob25년 전

Did you design some software or hardware? Did somebody pay you for it? Congratulations, you're an engineer. That, plus $4, will get you a cuppa joe at Starbucks.

sombremesa5년 전

I have a degree in Software Engineering and NOT CS. I had to teach myself a lot of core CS, largely for interviewing in the industry which is full of CS majors and people with myriad unrelated degrees (or no degrees).

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.

[deleted]5년 전

na855년 전

Aerospace engineer who dabbles in code here: I've seen a lot of these articles and they always miss what I feel is the central tenet of engineering, which is the ethical piece.

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.

cs-szazz5년 전

This question gets more complicated in places like Ontario, Canada, where the term "engineer" is actually protected. To call yourself an engineer in a professional setting, you have to be a member of the Ontario Society of Professional Engineers. Of course in practice, they choose not to go after people who call themselves engineer vs developer, but perhaps that will change in the future.

wyclif5년 전

I'm another 'crossover.' I was a land surveyor for over 10 years before I became a software developer. To me, the unifying factor is methodological. Software engineering is a lot younger than civil engineering or mechanical engineering, and it's a much more rapidly moving and less conservative discipline.

Annatar5년 전

Professional engineer here, by education and trade.

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

hn33335년 전

Not sure if it applies to engineers, but there's a difference in the job description between defining and implementing. Sometimes someone knows some theory, does some math and is done. And his or her result is passed to another person that implements it. Sometimes it's the same person doing both, but probably less often. Sometimes the implementer grows and starts putting down some ground rules (becomes an architect) or the other way round (for example there because might be more jobs for implementers).

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

RupertWiser5년 전

I don't like to call myself a software engineer just because of how contentious the term is. But I will admit that I do feel somewhat more precise at my current job than I was at my previous.

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.

toast05년 전

Yes [1], my degree says Computer Engineering; so prima facia, that's what I am; I suspect some of my job titles said as much too, but job titles are easier to fake than degrees. I'm sure as anything not doing science. I bash on computer systems while they're running with whatever implements are near by; just like the people who run train engines do. Maybe that makes me a mechanic, but I feel like there's a distinction because there's a lot of original design in addition to fixing and modifying the work of others.

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

canadianfella5년 전

sys_647385년 전

No, we're not. We are software developers who are indemnified from being responsible for our bugs. Real engineers go to prison for their bugs.

Conlectus5년 전

The moral differentiation is one the author talks about a lot, because it's the usual reaction.

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

tobmlt5년 전

Not sure if this is hyperbole, but usually bugs are caught elsewhere in the design spiral. If caught early enough, this results in a chewing out at worst (I had a bad first job). If caught late enough, this results in a law suit. (Seen it happen from afar)

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.

dilyevsky5년 전

Clearly you never owned a german car or a tesla. I doubt anyone went to prison for those

speedgoose5년 전

I doubt any engineer at Boeing will go to prison for the engineering of the very deadly Boeing 737 max.

[deleted]5년 전

deanCommie5년 전

We need a button to flag posts as "Clearly just responding to the headline and didn't read the article."

bavcyc5년 전

Software is more of an operating engineer, i.e. changing the state to accomplish a task.

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.

jgwil25년 전

I like the author's conclusion and I think a good litmus test for the difference between craftsmanship and engineering is the adage, "If you're not taking measurements, you're not doing engineering." So when we systematically measure and improve performance, security, productivity or what have you, we are doing engineering.

saberdancer5년 전

I'm not sure what the big deal is. I've finished my studies and got a title that includes "software engineering".

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.

Enginerrrd5년 전

This right here is the major difference between software and actual engineering. I studied and got a 4 year accredited engineering degree and I have been working in civil engineering for 7 years, but, I am not YET an engineer. I don't yet have my license to independently verify and stamp designs. I've passed most of the tests required to do so, but I've got another one to do. In most jurisdictions in the US, there is a 4 year minimum training period AFTER school, where you must train and apprentice under an engineer before you can apply to take the tests. They go through that application with a fine toothed comb. To get authorization for that last test, I had to send in sealed recommendations from 4 different licensed engineers familiar with my work where any one of them has the opportunity to basically say "no, this guy isn't ready" without my knowledge.

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.

saberdancer5년 전

This is true for fields where there are such sanctioning bodies. Some fields like software engineering do not have such bodies and it's wrong to attribute to software engineering rules that are used for some other fields.

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.

Enginerrrd5년 전

Right... My point though is that I think software engineering would benefit from such a regulatory body. Not for everything mind you, but I would expect some things to require a "software engineer's" stamp. Any system that will be used to handle sensitive or classified data, life and death situations (like automotive or aircraft), etc. ought to require a stamp. Frankly, it those cases it probably does, but it is the electrical or mechanical engineer that ends up signing off on it.

tompazourek5년 전

That exists already. There are certification programs, and having certified people is often a requirement to get some contracts.

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.

root_axis5년 전

You can approach the creation of software as an engineering problem, but what's unique about software is that you can still produce useful software even if you don't. If there are budgets and deadlines and guarantees to be considered then you need engineering.

7thaccount5년 전

My own personal views (electrical engineer who deals a lot with software and who codes a lot) are that you can find people that can do engineering work without an engineering degree today. A lot of that stems from powerful software that abstracts away much of the math. So you can load a model into a vendor's product and run transmission load flows without much formal training. However, if you haven't taken any circuit classes, complex power, calculus...etc, you're never going to truly understand the results of what you're doing and the end results will suffer in quality. That's why engineers are generally hired (assuming a PE license isn't required) instead of anyone with a 4 year degree. Before computers, a lot of that would be done by hand (at least the calculations that were feasible at that time) and you would pretty much have to have gone through an engineering, physics, or math program to have those kinds of chops.

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.

blackcats5년 전

You can name anything you want, the career is not a protected name. Software directors? Code artists? Byte doctors? Anything’s possible, nobody cares

kissgyorgy5년 전

No, we are not! I just wanted to tweet today, that "Software Development is NOT Engineering it's ART."

[deleted]5년 전

moocowtruck5년 전

if my job title says i'm an engineer i guess i am :D

[deleted]5년 전

fjabre5년 전

This is just silly. Lots of hubris here. It's also silly to spend much time thinking about this.

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"

Conlectus5년 전

I believe the comparisons between how engineering is practiced make this more than "silly". The purpose of the writing is not to answer that shallow question, but to better understand both fields.

fjabre5년 전

When OP said that we are not 'real' engineers because we have not built a bridge is when I stopped reading. For how could anyone take him seriously after that?

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

Conlectus5년 전

This was in reference to a quote from a software developer comparing software development to building a bridge. That is why "he has never built a bridge" was emphasized.

andrewchambers5년 전

No need to tell us again about your lack of reading comprehension.

fjabre5년 전

Who is 'us'? I'm speaking directly to you.

Seems like you're just interested in name calling. When people resort to name calling it usually means they've lost the argument.

But I'm sorry you're having a bad day.

I'll leave it that. Thank you and take care.

andrewchambers5년 전

Sorry to be grumpy, but i did not read or understood the article at all like you did.

[deleted]5년 전

bsder5년 전

The one thing everybody seems to forget is that the term "engineer" generally means "liable."

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

saberdancer5년 전

Licensed engineer is liable. If you get 10 structural engineers working on a bridge, only single one will sign off on the project. This person needs to be licensed and is liable. But all 10 could have worked on the project and did engineering work.

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

bsder5년 전

> Licensed engineer is liable. If you get 10 structural engineers working on a bridge, only single one will sign off on the project. This person needs to be licensed and is liable. But all 10 could have worked on the project and did engineering work.

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.

esoterica5년 전

Who cares? "Real" engineers love to gatekeep the term because they think there's an aura of prestige associated with the term, and they think that software developers calling themselves engineers are trying to steal valor. But in the present economic environment where fake engineers can make much more money than real engineers, why would anyone want to pretend to be a real engineer?

mrbill295년 전

No, because when software "engineers" are told to build a bridge, two weeks before the bridge is set to open, the dependencies change because they found out no one was using the bridge, so now it's a train bridge. Also instead of going over a river, it's going over a highway, also it's 1/3rd the length. Just need to change some function calls right?