27 ms·

Are We Really Engineers?

181 points by nathcd 6y ago

leapis 6y ago
“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.
- syntaxing 6y ago
  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.
  - analog31 6y ago
    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.
- tobmlt 6y ago
  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.
sombremesa 6y ago
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 6y ago
  [deleted]
7thaccount 6y ago
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.
renewiltord 6y ago
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?
- Barrin92 6y ago
  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.
  - renewiltord 6y ago
    Fascinating. Thanks for sharing your perspective.
deleted 6y ago
[deleted]
tofuahdude 6y ago
`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_ 6y ago
  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.
- Conlectus 6y ago
  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.
- robocat 6y ago
  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!
ssivark 6y ago
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.
ascotan 6y ago
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.
roenxi 6y ago
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.
- canadianfella 6y ago
  20 years old? Are you high?
- Jtsummers 6y ago
  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.
- VLM 6y ago
  "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.
siva7 6y ago
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.
- Buldak 6y ago
  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).
  - siva7 6y ago
    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.
sys_64738 6y ago
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.
- Conlectus 6y ago
  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.
- speedgoose 6y ago
  I doubt any engineer at Boeing will go to prison for the engineering of the very deadly Boeing 737 max.
- deleted 6y ago
  [deleted]
- deanCommie 6y ago
  We need a button to flag posts as "Clearly just responding to the headline and didn't read the article."
- dilyevsky 6y ago
  Clearly you never owned a german car or a tesla. I doubt anyone went to prison for those
- tobmlt 6y ago
  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.
VLM 6y ago
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.
- 8note 6y ago
  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.
cs-szazz 6y ago
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.
toast0 6y ago
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.
- canadianfella 6y ago
  Train engineers are not engineers and they are not mechanics.
totemandtoken 6y ago
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
- robocat 6y ago
  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.
  - Thorentis 6y ago
    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.
lwansbrough 6y ago
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.
- Humdeee 6y ago
  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. =)
  - Khaine 6y ago
    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.
  - freshpots 6y ago
    https://engineerscanada.ca/frequently-asked-questions 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.
esoterica 6y ago
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?
fancyfredbot 6y ago
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?
CamperBob2 6y ago
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.
jgwil2 6y ago
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.
mrbill29 6y ago
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?
kissgyorgy 6y ago
No, we are not! I just wanted to tweet today, that "Software Development is NOT Engineering it's ART."
fjabre 6y ago
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"
- Conlectus 6y ago
  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.
  - fjabre 6y ago
    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.
    - andrewchambers 6y ago
      No need to tell us again about your lack of reading comprehension.
      - fjabre 6y ago
        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.
hn3333 6y ago
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).
zaptheimpaler 6y ago
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.
root_axis 6y ago
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.
deleted 6y ago
[deleted]
jjk166 6y ago
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.
oh-4-fucks-sake 6y ago
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.
blackcats 6y ago
You can name anything you want, the career is not a protected name. Software directors? Code artists? Byte doctors? Anything’s possible, nobody cares
dropit_sphere 6y ago
"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.
na85 6y ago
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.
RupertWiser 6y ago
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.
saberdancer 6y ago
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.
- Enginerrrd 6y ago
  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.
bigger_cheese 6y ago
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.
- chrisulloa 6y ago
  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.
  - letitbeirie 6y ago
    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.
letitbeirie 6y ago
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.
- watermelon59 6y ago
  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.
  - letitbeirie 6y ago
    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.
- totemandtoken 6y ago
rdiddly 6y ago
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.
- GIFtheory 6y ago
  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.
  - rdiddly 6y ago
    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.
bsder 6y ago
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.
- saberdancer 6y ago
  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.
  - bsder 6y ago
    > 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.
mcguire 6y ago
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/software-engineering https://www.computer.org/education/bodies-of-knowledge/softw...) is entirely disjoint from the production of software.
moocowtruck 6y ago
if my job title says i'm an engineer i guess i am :D
pjbster 6y ago
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-code/ 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-timnit-gebru-fired-letter-reinstated-diversity https://www.theguardian.com/technology/2020/dec/16/google-ti...
wyclif 6y ago
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.
dctaflin 6y ago
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.
allo37 6y ago
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?
Annatar 6y ago
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."
bavcyc 6y ago
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.
twobitshifter 6y ago
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.
- bluefirebrand 6y ago
  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.

181 points by nathcd 6y ago

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

syntaxing 6y ago
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.
- analog31 6y ago
  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.
tobmlt 6y ago
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.

sombremesa 6y ago

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 6y ago
[deleted]

7thaccount 6y ago

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.

renewiltord 6y ago

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?

Barrin92 6y ago
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.
- renewiltord 6y ago
  Fascinating. Thanks for sharing your perspective.

deleted 6y ago

[deleted]

tofuahdude 6y ago

`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_ 6y ago
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.
Conlectus 6y ago
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.
robocat 6y ago
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!

ssivark 6y ago

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.

ascotan 6y ago

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.

roenxi 6y ago

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.

canadianfella 6y ago
20 years old? Are you high?
Jtsummers 6y ago
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.
VLM 6y ago
"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.

siva7 6y ago

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.

Buldak 6y ago
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).
- siva7 6y ago
  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.

sys_64738 6y ago

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.

Conlectus 6y ago
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.
speedgoose 6y ago
I doubt any engineer at Boeing will go to prison for the engineering of the very deadly Boeing 737 max.
deleted 6y ago
[deleted]
deanCommie 6y ago
We need a button to flag posts as "Clearly just responding to the headline and didn't read the article."
dilyevsky 6y ago
Clearly you never owned a german car or a tesla. I doubt anyone went to prison for those
tobmlt 6y ago
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.

VLM 6y ago

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.

8note 6y ago
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.

cs-szazz 6y ago

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.

toast0 6y ago

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.

canadianfella 6y ago
Train engineers are not engineers and they are not mechanics.

totemandtoken 6y ago

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

robocat 6y ago
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.
- Thorentis 6y ago
  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.

lwansbrough 6y ago

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.

Humdeee 6y ago
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. =)
- Khaine 6y ago
  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.
- freshpots 6y ago
  https://engineerscanada.ca/frequently-asked-questions 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.

esoterica 6y ago

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?

fancyfredbot 6y ago

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?

CamperBob2 6y ago

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.

jgwil2 6y ago

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.

mrbill29 6y ago

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?

kissgyorgy 6y ago

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

fjabre 6y ago

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"

Conlectus 6y ago
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.
- fjabre 6y ago
  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.
  - andrewchambers 6y ago
    No need to tell us again about your lack of reading comprehension.
    - fjabre 6y ago
      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.

hn3333 6y ago

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

zaptheimpaler 6y ago

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.

root_axis 6y ago

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.

deleted 6y ago

[deleted]

jjk166 6y ago

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.

oh-4-fucks-sake 6y ago

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.

blackcats 6y ago

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

dropit_sphere 6y ago

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

na85 6y ago

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.

RupertWiser 6y ago

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.

saberdancer 6y ago

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.

Enginerrrd 6y ago
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.

bigger_cheese 6y ago

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.

chrisulloa 6y ago
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.
- letitbeirie 6y ago
  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.

letitbeirie 6y ago

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.

watermelon59 6y ago
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.
- letitbeirie 6y ago
  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.
totemandtoken 6y ago

rdiddly 6y ago

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.

GIFtheory 6y ago
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.
- rdiddly 6y ago
  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.

bsder 6y ago

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.

saberdancer 6y ago
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.
- bsder 6y ago
  > 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.

mcguire 6y ago

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/software-engineering https://www.computer.org/education/bodies-of-knowledge/softw...) is entirely disjoint from the production of software.

moocowtruck 6y ago

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

pjbster 6y ago

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-code/ 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-timnit-gebru-fired-letter-reinstated-diversity https://www.theguardian.com/technology/2020/dec/16/google-ti...

wyclif 6y ago

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.

dctaflin 6y ago

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.

allo37 6y ago

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?

Annatar 6y ago

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

bavcyc 6y ago

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.

twobitshifter 6y ago

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.

bluefirebrand 6y ago
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.