[HN Gopher] Are We Really Engineers?
___________________________________________________________________
Are We Really Engineers?
Author : phgn
Score : 151 points
Date : 2022-01-19 19:38 UTC (3 hours ago)
(HTM) web link (www.hillelwayne.com)
(TXT) w3m dump (www.hillelwayne.com)
| kloch wrote:
| Titles are cheap.
|
| Better questions: Do you have the knowledge and
| experience to do your job well? Is your brain naturally
| wired for the type of work you do?
| jll29 wrote:
| Yes, _some_ of us are: I take the position that whether software
| engineering is an appropriate term does depend on the individual
| and the team and organization they are embedded on. There are
| individuals, teams and organizations where the term "software
| engineering" is fitting, whereas others do not deserve it.
|
| For many years, a lot of software development was pioneering
| (many projects build the first X of its kind e.g. the first OS,
| the first word processor, the first spreadsheet, the first Web
| browser). Bridge construction, in contrast, is older, so not as
| many bridges are pioneering new techniques. The predictability
| that is associated with trad. engineering can only take hold once
| things of a kind have been done often enough so best practices
| can emerge.
|
| BTW, software engineering isn't the only type of non-traditional
| engineering: the University of Cambridge has one of Europe's best
| engineering departments; part of it is a group called Information
| Engineering, where software systems and models for e.g. speech
| recognition are researched and developed.
| softwarebeware wrote:
| I have a Master of Software Engineering degree. Ask me anything.
| MaxBarraclough wrote:
| > we actually use discrete math, where we deal exclusively with
| non-continuous numbers. This includes things like graph theory,
| logic, and combinatorics. You might not realize that you are
| using these, but you do. They're just so internalized in software
| that we don't see them as math!
|
| I strongly disagree with this level of charity. That's like
| saying every cyclist is a physicist.
|
| Someone who takes a short programming course might not even have
| heard the term _discrete mathematics_ , and almost certainly
| won't be qualified to develop a proof of correctness for an
| algorithm, i.e. to actually _do_ discrete mathematics in a
| serious sense.
|
| > most of computer science is viewable as a branch of mathematics
|
| And yet there's a world of difference between a computer
| scientists and the average software developer.
|
| > Every time you simplify a conditional or work through the
| performance complexity of an algorithm, you are using math. Just
| because there are no integrals doesn't mean we are mathless.
|
| But the absence of doing math surely does make someone (or some
| line of work) mathless. Most software developers go their whole
| careers doing no serious math.
|
| > Just because we use a different branch of math doesn't mean
| we're not doing engineering.
|
| Perhaps the argument can be made that engineering doesn't
| necessarily have to include math, but this isn't the way to make
| it.
|
| Again, the average developer does not know any mathematical field
| in any real depth. This is in sharp contrast to, say,
| aeronautical engineers.
|
| > Whether or not we are engineers is irrelevant to whether or not
| we are good engineers.
|
| Disagree. If the term _engineer_ has any meaning, it has to
| indicate some level of competence. The bar has to be set
| _somewhere_.
|
| We all agree that changing a car tyre does not qualify someone as
| any sort of engineer. Is it controversial to suggest that
| something analogous should hold for software work?
|
| The later _Craft vs Engineering_ section makes far more sense to
| me.
|
| _edit:_
|
| > We are separated from engineering by circumstance, not by
| essence, and we can choose to bridge that gap at will.
|
| I think this is a matter of market forces rather than a
| community-wide failure.
|
| There's high demand for software developers, including for
| inexperienced software developers with little formal training.
| This is, at least in principle, a fine thing (ignoring things
| like major security issues arising from incompetence). Someone
| who completes a brief course on programming may be called a
| _software developer_ , and a professor specialising in critical
| software systems might be called the same.
|
| It's not like nuclear engineering where there's a formal system
| of gatekeeping. Provided we don't ignore the spectrum of
| expertise, I don't see a reason to worry about software work
| being intellectually disreputable by nature.
| strulovich wrote:
| >> we actually use discrete math, where we deal exclusively
| with non-continuous numbers. This includes things like graph
| theory, logic, and combinatorics. You might not realize that
| you are using these, but you do. They're just so internalized
| in software that we don't see them as math!
|
| > I strongly disagree with this level of charity. That's like
| saying every cyclist is a physicist.
|
| Boolean logic, and while loops are proper examples of discrete
| math. They're practiced by virtually every developer. An
| equivalent example from the world of continuous math could be
| integrating over some range.
| MaxBarraclough wrote:
| Understanding the control-flow constructs of an imperative
| programming language is not equivalent to understanding the
| discrete maths of imperative programming (Hoare logic, Z
| notation, B-method, etc).
|
| As I said, the average developer is incapable of doing
| serious discrete mathematics such as formally proving the
| correctness of an algorithm. For that matter, I doubt the
| average developer would know what it means for a language to
| have a formal semantics.
|
| To anticipate the path of a frisbee is to, in mathematical
| terms, solve a differential equation. Dogs can catch
| frisbees. We still don't say that dogs understand the
| mathematics of differential equations. [0][1]
|
| In the software world, formal methods are a niche, as are the
| associated mathematics. Being costly, they are not used in
| mainstream software work.
|
| [0] (PDF)
| http://www.math.pitt.edu/~bard/bardware/classes/0220/dkc.pdf
|
| [1] https://www.wired.com/1993/05/dogs/
| CSSer wrote:
| First I want to let you know that I didn't take it
| personally (all in jest), but I've never been so artfully
| called a dog in my life. Thanks for that :)
| MaxBarraclough wrote:
| I'm sure cats could catch frisbees too, they just won't.
| CSSer wrote:
| I'd rather be a dog. So what if I do know some discrete
| math and I do know what it means for a language to have a
| formal semantics? Does that make me an above average
| developer or a software engineer?
| JamesBarney wrote:
| > And yet there's a world of difference between a computer
| scientists and the average software developer.
|
| The world would be served by realizing how different these too
| skill sets are. I had professors who couldn't code their way
| out of a paper bag, and known successful devs who wouldn't know
| a proof if it walked up and bit them on the nose.
| exdsq wrote:
| On a side note I saw Renaissance Technologies still hire
| "Computer Programmers" which I thought was pretty nostalgic. They
| also are hiring System Administrators and Network Technicians. No
| fluff at one of the highest paying firms :)
| dhuk_2018 wrote:
| Don't get me started with "network engineer"...
| blippage wrote:
| When people ask me what I do, I say "computer programmer". I
| can't be doing with all that job title inflation.
|
| Sometimes I just say "programmer", but that seems to confuse
| people; like I'm the guy who decides at what time The Simpsons
| goes on telly, or something.
| thenerdhead wrote:
| Ah yes, the yearly debate on whether software engineers are real
| engineers and the strawman arguments about other disciplines &
| qualifications.
|
| The typical gatekeeping mentality of those who have degrees and
| those who don't. It's not very productive or even worthwhile to
| peruse.
|
| We all deal with creep scope, people, and problems. Let's stop
| debating stupid titles or certifications.
| ajkjk wrote:
| I think you've kinda ignored the fact that this is a really
| good article with a complex take on the question that's
| tackling the silliness of the question head-on instead of just
| shouting opinions into the void.
| saltyfamiliar wrote:
| I think a lot of people here (and the author of the article) are
| missing the obvious: an engineer is someone who works with
| engines. An engine is basically just a machine that does work.
| The question is really whether software can be considered
| "machines." They're certainly complex devices made up of
| different parts working in unison that perform work, so I think
| yes. If a bridge can be considered a machine then surely so can
| software. Therefore, programmers are engineers. All this talk
| about rigid specifications, certifications, math, respect for the
| title, etc. is very odd to me.
| AussieWog93 wrote:
| I studied Engineering in university (Electrical was my primary
| discipline, but in the first year we also spent some time on
| Civil, Chemical and Materials Eng) before later moving onto
| Software Engineering as a career.
|
| To me, the biggest difference between SWE and the other "real"
| Engineering disciplines is about respect for the laws of physics.
|
| Engineers from the classical disciplines have a deep
| understanding of the immutability of physical laws, and build
| mental models that accurately represent this as best they can.
| SWEs, on the other hand, have a tendency to build mental models
| that are more conceptual or metaphysical, and try and force these
| onto real-world silicon.
|
| (This is somewhat idealised, of course. There are hack engineers
| that don't understand first principles in the slightest, just as
| there are software engineers who have no high-level understanding
| of the code they just copy-pasted from Stack Overflow).
| goodpoint wrote:
| > SWEs, on the other hand, have a tendency to build mental
| models that are more conceptual or metaphysical, and try and
| force these onto real-world silicon.
|
| Aka if you are a good software engineer you understand well how
| hardware works and how to push the boundaries.
|
| If you a Stack Overflow copypaste technician you are nowhere
| near an engineer.
| razzio wrote:
| That is an interesting distinction. Laws of physics are clearly
| a constraint to whatever is being engineered. In software
| development this sometimes plays a role too, more so on
| embedded and real-time systems. Real-time systems have a time
| constraints which is a law of physics and embedded software
| development has to incorporate memory, cpu and sometimes
| thermal constraints.
|
| I do consider software for these systems closer to engineering,
| so you might be on to something. That doesn't mean I'd exclude
| other software development but the notions of (law of physics)
| constraints and predictable outcome are important factors.
| 1970-01-01 wrote:
| I've made this question into a poll. Let's vote on it:
|
| https://news.ycombinator.com/item?id=30000645
| andrewla wrote:
| For the life of me I can't get invested in these semantic games.
| The author even acknowledges Wittgenstein!
|
| This question only matters as regarding whether it has
| operational significance, and it's really hard to imagine a
| situation where the term would have any operational significance.
| The author says that we can benchmark against other engineering
| disciplines and look for guidance or inspiration if software is
| engineering. But we can do that whether or not we use the term!
| We can compare software to plumbing, and take away what we can,
| or compare it to law and take away what we can, or compare it to
| electrical engineering and take away what we can. The term itself
| is irrelevant here.
| TheDudeMan wrote:
| We are not. And I'm fine with that. Please stop calling me an
| engineer.
| commandlinefan wrote:
| > getting the wires to bend correctly and the plastic onto this
| shiny piece of anodized aluminium wire. [...] That was the thing
| that took three months in the project.
|
| Well, there you go, that's how I know we're not really engineers.
| Because every software developer working reports to (or reports
| to somebody who reports to) somebody who lives by the maxim "if
| it takes more than an hour to do, it's not worth doing".
| r_hoods_ghost wrote:
| I think this is the key point, and it's one I'd agree with
| "...software engineering is real engineering, but a lot of people
| who write software aren't doing software engineering."
|
| Personally I would probably draw the circle of software engineers
| fairly tightly and acknowledge that the rest of us are
| programmers, or developers, or software architects, or plumbers.
|
| I'd certainly exclude someone like myself from the magic circle
| of software engineer. My career started accidentally in economic
| and environmental modeling (ah GAMS, my psycho ex, how I miss
| you), currently involves creating addons for Blender, went
| through a brief CRUD app phase back when Facebook was young
| (shudder) and has involved random trips into data science at
| various points. I'd also exclude virtually everyone I've ever
| worked with if I'm honest because most of what I've worked on has
| either been bespoke and artisanal and so was been software
| crafting, or it's essentially been plumbing together systems
| designed by real software engineers and then prettying up the
| resultant monster. Despite that I've had the title software
| engineer a few times, as have lots of my colleagues.
|
| I'm not sure that the author is right in saying that it is easier
| for programmers to transform into software engineers than
| tradesmen into real engineers. I definitely think that in both
| cases some seriously heavy training and a lot of unlearning needs
| to be done.
| nicktorba wrote:
| The reason it is easier for programmers to transform into
| software engineers is the same reason we are having this
| conversation. For the most part, I think this is because
| software is so cheap and accessible. Anyone can become a
| software artisan with just a laptop and time. For traditional
| engineering, you need resources. Here's a quote from the second
| post: "When it comes to things like making circuit boards, it's
| pretty common for things not to work the first time. You have
| to do it again, and you have to send it out to the factory and
| do it again. You know it costs you another however many PS1000
| and another two weeks on the schedule. -Mike (electrical)"
|
| If building software was expensive like engineering in the
| physical world, we wouldn't have to have this argument. It's
| too bad that physical engineering is so expensive, because we'd
| probably have a lot more people trying it out.
| jimmyvalmer wrote:
| _Just because we use [discrete, not continuous] math doesn't mean
| we're not doing engineering_
|
| Yes, it does. The analog-digital divide makes engineering that
| much harder than programming where 1's remain 1's and 0's remain
| 0's regardless of real-world curveballs like temperature and fat
| people.
| CSSer wrote:
| Isn't the appeal you're making also refuted by the article?
|
| "not all forms of engineering result in physical processes. In
| particular, industrial engineering rarely does."[0]
|
| [0]:https://www.hillelwayne.com/post/are-we-really-
| engineers/#:~....
| bastardoperator wrote:
| Does it matter if we are or aren't? I think some of us are, I
| think some folks are artists, some are scientist, some are
| laborers. It doesn't really matter because at the end of the day,
| unlike other disciplines all of these people can come together,
| collaborate, and produce things that captivate people, business,
| science, etc...
|
| I tend refer to myself as a generalist because I'm not sure one
| label really fits. I do a bunch of different things, but the
| reality is I'm just trying to add value for myself, my customer,
| my teams and my business and I do it mostly with my thoughts and
| a computer.
| SeanLuke wrote:
| This guy seems to think that engineers only make things that are
| dangerous.
|
| Sure, there are engineers that build bridges. But there are also
| enormous numbers of computer engineers that build custom ASICs
| for, I dunno, TVs and Furbies. There are electrical engineers
| that build RF tag antennae for cartons in warehouses. There are
| chemical engineers who design more tasty marshmallows.
|
| On the other hand, there are also computer scientists who build
| software for nuclear power plants and fighter jets, which must be
| perfect or people will die.
|
| This is the problem with traditional engineering as a discipline:
| they require certification as a gatekeeping mechanism, under the
| pretense that _some_ engineers do things that require safety
| protocols. Thus Real Engineers are certified to do Dangerous
| Work.
|
| To me engineering is simply the application of math and science
| to design and ultimately build. In this respect, computer
| scientists are inarguably engineers.
| Gigachad wrote:
| >To me engineering is simply the application of math and
| science to design
|
| This still excludes the majority of what software engineers do.
| Sure, a little bit of it is carefully designed and applies
| complex math, but the majority isn't really math or science
| related at all.
| hyperpape wrote:
| The article literally spends an entire section rejecting the
| belief that real engineers work only on dangerous things. The
| title is "Engineering is high-consequence", and discusses how
| one of the hardest problems an engineering team dealt on one
| project with was designing the handle for a device.
| writeslowly wrote:
| Sometimes when I read these the discussions I get the
| impression that software engineers think "real" engineering is
| about making life or death decisions all the time, but a lot of
| the work is so systematized it can turn into enormous amounts
| of paperwork. Especially as the things you work on become more
| deadly.
|
| Before I went into web development I worked briefly as a
| mechanical engineer on nuclear power plants, and I feel like I
| more critical thinking when I'm pushing code to prod than I
| ever did reviewing load calculations on coolant pipes (despite
| how important a functioning cooling system might actually be)
|
| Also want to point out that most aerospace engineers have no
| certification outside of a college degree, at least in the US.
| bee_rider wrote:
| People focus on the life-or-death decisions because they are
| more dramatic, but really any time you are making physical
| devices you'd probably prefer a boring design. If you are
| planning to make a billion little computer chips to go in
| silly toys or whatever, you probably want to minimize the
| creativity for most of the design.
| chongli wrote:
| A lot of those other things are (potentially) dangerous too.
| TVs and furbies with electronics in them could give you an
| electric shock or start a fire. Bad marshmallows could poison
| you or give you cancer.
|
| The people writing the software for power plants or jets should
| be licensed software engineers, not coding bootcamp alumni. The
| whole point of licensure is to add a degree of accountability
| to any job which involves danger to the public.
| SeanLuke wrote:
| > TVs and furbies with electronics in them could give you an
| electric shock or start a fire
|
| In no universe will a small low-voltage chip cause a fire
| except in exceptional circumstances. This is a non-dangerous
| product. But you can only design one if you are a certified
| engineer.
|
| Most engineering tasks are harmless. They require
| certification and licensing largely as a gateway mechanism,
| like being a beautician. No one says that people who design
| harmless products aren't "electrical engineers" or "computer
| engineers". Danger certainly isn't the defining feature of
| engineering -- gateway certification might be, but shouldn't
| be.
|
| And on the flip side, it is absolutely the case that for
| designing software which is potentially dangerous should
| require certification and liability considerations. Do these
| guys get to be called engineers then? What if all they do
| with their certification is make video games?
| exdsq wrote:
| I believe the real core part of being a licensed engineer is
| you can be personally liable for mistakes in plans you sign
| off on, and to be able to do this you need to take exams and
| complete training showing you're capable of doing this
| correctly. This isn't a thing in programming.
| chongli wrote:
| It is a thing for software engineering students at
| University of Waterloo. They take physics and chemistry
| courses and learn all about safety and various standards.
| They write exams and at the end they become licensed
| professional engineers with iron rings.
| exdsq wrote:
| But there are very few software projects that have this
| level of rigor that I'm aware of, right? I've not heard
| of a project where a software engineer has had to sign
| off on it like a civil engineer signs off a bridge. Maybe
| they exist! But I've worked on critical systems and yet
| to see this in practice.
| bcrosby95 wrote:
| This is pretty interesting to me.
|
| I think most software developers think of engineering as
| making sure the software will perform under stress. But
| this requirement is (usually) meaningless from a customer
| safety standpoint. Sure it sucks if the system breaks, but
| unless your business model is also safety critical, that
| failure isn't a safety problem.
|
| But leaking customer data is a safety problem. So for most
| people, software engineering should as much (or more) about
| security as things like time complexity tradeoffs.
| sdenton4 wrote:
| This is exactly what's discussed as the misconception
| 'Engineering is high-consequence' in TFA:
|
| "It does mean that the engineers spent a lot of time on
| something that's low-consequence or non-safety critical. In
| retrospect, this shouldn't have surprised me. The world is vast
| and our industry is huge. Someone needs to design the bridges,
| yes, but someone also needs to design all of the little things
| we use in our day-to-day life. Much of the engineering there is
| low-stakes, low-consequence, just like much software is."
| nyellin wrote:
| I think we're more similar to writers. Code can be creative or
| artistic, but structure and discipline are important for anything
| large.
|
| There are technical writers and there are creative writers. You
| can write about math or science or food.
|
| Code has the same range.
|
| Coding is just a form of expression and explanation, but machines
| are the readers not people
| conradludgate wrote:
| I'm a software engineer by day, software craftsman by night.
|
| My own personal work is made with love and care but I won't
| necessarily fret over details like extreme testing, scalability,
| readability of the code.
|
| My paid work is a lot more thorough. Meetings and planning. Group
| work. Testing. My work does have consequences (although I think
| that's not really a prerequisite for the title of engineering).
| While no official board has standards of software. My work
| definitely has standards. My peers and managers have standards
| that we enforce upon ourselves
| conradludgate wrote:
| I think there's one key term that hasn't been mentioned in
| relation to this debate much: accountability.
|
| Engineers are a countable for their work. I am accountable if
| my code fucks up in production. An engineer is accountable if a
| foundation fails. Not "how bad are the consequences", but "am I
| accountable if something does goes wrong"
| dgut wrote:
| There are three types:
|
| - CS person who has in-depth understanding of how computers works
| and mathematics. Typically writes code in a low-level language,
| can write a compiler, mostly will solve computer problems that
| indirectly solve problems at a consumer level.
|
| - Developer person who is analytical and has a good grasp of
| mathematics. Can build tools to be used by other developer
| persons. Uses high-level languages to solve problems at a
| consumer level.
|
| - Hacker person who uses tools built by the CS and developer
| person to solely solve problems at a consumer level.
| bsedlm wrote:
| software engineering is like roman civil engineering
| nicktorba wrote:
| I thought I was over this argument because it always hits a dead
| end, but Hillel took a really entertaining approach with this
| series. Looking back, I'm almost always having this argument with
| other software people, but never traditional engineers. I hadn't
| thought much about how our stereotypes are wrong.
|
| A great example from the second post in the series is how
| software people don't have experience with the unpredictability
| of traditional engineering projects: "Part of this misconception
| comes from us seeing the results of the engineering process, not
| the process itself. We don't see the friction, the overruns, the
| delays that happen because someone built the wall one inch to the
| left, or when a critical supplier goes out of business. To assume
| that software is uniquely unpredictable is a special kind of
| arrogance."
|
| This has me wondering why the software world is so unpredictable
| in the first place and why we aren't working on that? Or at least
| getting better at dealing with it. Also, why are we so inclined
| to think the physical world is so predictable? Probably because
| we spend so much time on our computers...
|
| excited to finish the rest of this series
| mLuby wrote:
| > This has me wondering why the software world is so
| unpredictable in the first place... Also, why are we so
| inclined to think the physical world is so predictable?
|
| Ignoring time spent designing, software's manufacturing time is
| essentially zero. Compare that with days/weeks for devices and
| years for vessels/structures. So because we're used to the
| latter timescale, the pace of software feels like watching a
| video at 100x speed.
|
| If engineers could instantly and cheaply print each new version
| of the airplane or bridge they're tasked with building, they'd
| start looking a lot more like software industry. When software
| doesn't have its rapid/free iteration superpower (as in the
| early days or in must-never-fail situations), it starts looking
| like traditional engineering.
| paxys wrote:
| First define "engineering", then ask that question.
| ineedasername wrote:
| _" this is an important question"_
|
| I'm not so sure about that. I'm not very concerned with the
| labels. I think it's fair to say it might be in a gray area, and
| maybe she me day in the future it will resolve into one or the
| other.
|
| It's probably useful to understand why "engineer" is attached to
| the field in the first place. I think it's because CompSci
| programs often grew of of Electrical Engineering programs: that's
| where a lot of programming started, way back. When Comp Sci went
| it's own way as a distinct field, it kept the "engineer"
| association even though it almost completely ( especially today)
| lost much emphasis on EE. When I was looking at grad programs 20
| years ago, even then a Master's degree at a very good tech
| University only had a single required EE course. Entry
| requirements for those not in CompSci undergrads we're 4 courses:
| discrete math, assembly, a grad-level fast paced intro to
| programming, and a course dedicated to algorithms. EE knowledge
| wasn't required or emphasized at any level.
|
| So programming has strong roots in engineering, but expanded
| beyond it. I'm fine with this gray area.
| [deleted]
| nitwit005 wrote:
| Was going to say the same. The article doesn't back that
| statement up with anything.
|
| Many of us don't have engineer in our job title, and I've never
| heard of anyone being upset at it not being there.
| [deleted]
| ChrisMarshallNY wrote:
| I feel that I am. It doesn't really matter. I tend to work on my
| own stuff.
|
| I started as an EE, and a lot of the discipline from there, has
| traveled with me, in my software adventure.
|
| I don't ship bugs (that I'm aware of). My issues need to be at 0,
| before I will release.
| cbsmith wrote:
| I look at it like "sanitation engineer". That's a real
| engineering job that requires engineering expertise to do right,
| but the term is often used (sometimes derisively) for anyone who
| does anything involving waste/cleaning.
| dekhn wrote:
| I'm a hacker, always have been. Took a detour to be a PhD
| scientist, and another one to be a "software engineer", but I'm a
| hacker. And this hacker can tell you: most (95%) of software
| "engineering" is not engineering, but more or less the equivalent
| of telling anecdotes about your grandparents experiences while
| arguing you have a solution to covid.
|
| That said, there's 5% of software engineering out there that is
| engineering; read the RISKS mailing list archives if you want to
| see some examples (and counterexamples).
|
| If software engineers were engineers, testing would be a higher
| priority, and visible regressions would happen rarely, if at all.
| woah wrote:
| > If software engineers were engineers, testing would be a
| higher priority, and visible regressions would happen rarely,
| if at all.
|
| That would mean they were doing their jobs badly. All
| engineering requires balancing priorities such as physical
| strength (or in software, correctness), and cost. An engineer
| who overbuilds everything 10x will quickly be out of work.
| threatofrain wrote:
| When correctness matters less than business results, then
| your role has passed from engineering into business. Software
| is somewhere in the middle. Software engineers are often
| informally expected to own the results without owning the
| profits.
| veilrap wrote:
| Cost is an important constraint in engineering. Nearly
| every engineering project has cost as a component of the
| engineering process as omitting it yields projects that
| cannot be completed.
| wyager wrote:
| > If software engineers were engineers, testing would be a
| higher priority
|
| Many classes of engineers don't have the chance to test their
| designs. They have to know it will work ahead of time. The
| closest analogy in CE/CS might be formal methods, which (as I
| suspect you would agree) are sorely under-utilized.
| typon wrote:
| In fact we would be using a lot more simulators.
| dekhn wrote:
| Those engineers use tests, their tests just don't operate on
| "full real systems".
| buryat wrote:
| > If software engineers were engineers, testing would be a
| higher priority
|
| testing is not that important for a hacker but important for an
| engineer (although hackers do penetration testing).
| amelius wrote:
| > If software engineers were engineers, testing would be a
| higher priority, and visible regressions would happen rarely,
| if at all.
|
| You say that as if software engineers determine the priorities
| ...
| mrguyorama wrote:
| The difference between a "software engineer" and a real
| engineer like a civil engineer is that when a manager type
| tells a civil engineer to ignore safety or standards for
| profit reasons, a civil engineer gets to tell them to fuck
| off
| chongli wrote:
| It's even more strict than that. A non-engineer is not
| allowed to be a supervisor of a civil engineer. This is why
| civil engineers work in a firm structure: the entire chain
| of command is made up of civil engineers. Any company who
| wants engineering work done must contract with a firm. This
| makes any potential conflicts of interest external rather
| than internal.
| hardolaf wrote:
| This is also why most defense companies are run almost
| entirely by engineers. Even though they're not required
| to be, they organize themselves that way to ensure a
| culture of design excellence. It's better to fail to
| deliver a product than to deliver a product that will
| kill people.
| julienfr112 wrote:
| Boeing and their famous 737 max screwup where run by
| engineers with solid work and engineering ethic ?
| formerly_proven wrote:
| > defense companies ... than to deliver a product that
| will kill people
|
| Isn't that the point?
| amelius wrote:
| Is this what went wrong at Boeing? Also, how is Tesla
| structured? Are software engineers working on autopilot
| functionality managed by true engineers?
| conradludgate wrote:
| You, as a software engineer, should also tell your manager
| to fuck off if they are making bad decisions. No one is
| inherently above you. If they're the kind of management to
| never listen to you then that doesn't make you less of an
| engineer, that makes them shitty managers to ignore these
| important principals behind their systems
| Dma54rhs wrote:
| Many companies have a culture of continuous deployment
| that often means "bugs happen, its part of life around
| here". You would go against the whole mantra of the
| company and industry. Not easy to tell the boss to fuck
| off.
| ipaddr wrote:
| You get fired the real engineer doesn't. You are paid to
| do what management tells you.
| bee_rider wrote:
| I would cast a really wide net and say that an engineer is
| someone who produces designs in compliance with the best methods
| for their particular field. I don't think most of us software
| folks are engineers, because the work-product in this field is
| usually a particular implementation, rather than a design. Last
| time I worked on a big project, the person whose job seemed the
| most engineer-y was the 'Software Architect' but I don't know if
| that title is standardized.
|
| I think our fixation on this title is really silly and strange. I
| did an engineering degree, the math is a little easier than
| physics because we're aiming to get to the sort of standard
| answers, and then there's some extra memorization. I could
| understand people with no technical background at all being
| impressed by the title, but if you've done a CS or a Physics
| degree you've almost certainly seen harder problems. What's so
| cool about it? We just learned how to compose the answers as
| boringly as possible.
|
| Edit: also most of my friends from engineering school went on to
| become programmers because it is more fun and you don't have to
| worry about letting the magic smoke out.
| WalterBright wrote:
| Actually, I am a real engineer, and designing gearboxes for
| airplanes is quite real. So are programmers engineers or not?
|
| Consider real engineering at Boeing. There are engineers and
| technicians (aka draftsmen) working side by side. They are often
| doing the same work. The difference, as far as Boeing is
| concerned, is the engineers have a degree in engineering and the
| technicians do not.
|
| But if they are often doing exactly the same thing, what's the
| real difference?
|
| Think of it another way. Think of an auto mechanic. He can fix
| your car. He can take your car apart and put it back together. He
| can customize it. But is he an auto engineer (who often does
| those tasks, too)?
|
| Nope.
|
| A programmer, technician, mechanic plugs numbers into formulas,
| follows instructions and procedures and practices laid out by an
| engineer.
|
| An engineer derives the formulas, writes the instructions,
| develops the procedures, and refines the practices.
|
| For example, a technician builds a band pass filter by using a
| circuit he's already used before and knows works. Maybe he'll
| tweak the RC values. An engineer will drive the RC values needed
| by understanding the calculation. The technician _may_ use
| calculation (though they rarely do), but they don 't understand
| where the formula comes from. An engineer does.
|
| In software, a programmer calls a sort function from the supplied
| library. An engineer writes the sort function, and can tell you
| its complexity and why the algorithm he chose (or invented) is
| the most appropriate one for the particular sorting task, and
| what the cases are where the sort will perform poorly, and why.
| waynesonfire wrote:
| This is how I was thinking about this as well.
|
| computer programming (e.g. writing code) is not software
| engineering. Any "software engineering" that took place, if
| any, would occur before the first instruction is even written
| for a production system.
|
| a computer program consists of the the instructions to be
| executed by a CPU to manipulable it's state to hopefully solve
| some problem. This serves the same purpose as the plans that an
| engineer would hand to a builder, e.g. place this beam here and
| use these screws to secure it to that pole. After a builder has
| completed the construction of the building, the program has
| finished execution.
|
| The CPU is the builder and the program instructions are the
| plans. The act of writing the program is the same as an
| engineering writing their plans; except instead of code they
| use diagrams or whatever.
|
| the engineering parts came into play in developing those plans.
| that is, before the instructions were written. this is where
| the conversation should begin to explorer what is software
| engineering. we don't know how to engineer software.
| [deleted]
| jolmg wrote:
| > engineers have a degree in engineering
|
| > An engineer writes the sort function, and can tell you its
| complexity and why the algorithm he chose (or invented) is the
| most appropriate one for the particular sorting task, and what
| the cases are where the sort will perform poorly, and why.
|
| So what of the people that can do this but don't have a degree?
| And what of the people that have a degree in engineering but
| can't do this? Are both also engineers, or are neither of them
| engineers, or is one an engineer but not the other?
| WalterBright wrote:
| I said that Boeing defined engineers as having a degree in
| engineering. That is clearly not my definition.
|
| I've known engineers that were no better than mechanics. And
| a couple (very rare) mechanics who could do engineer work,
| and would be engineers in my estimation.
| jolmg wrote:
| Ok. Rather than offering an alternate definition, it seemed
| to me that you were explaining why Boeing's definition made
| sense by leaning on the implication that the possession of
| a degree equaled whether or not you could do such things. I
| misread.
| WalterBright wrote:
| No problem! BTW, I know a very good mechanic who I tell
| him now and then that it's a tragedy he didn't get a
| degree in it. He's a born engineer, held back by not
| having the math training.
| bobsmooth wrote:
| I have an engineering degree but I work as a technician for an
| aerospace company. To me, the difference between an engineer
| and a technician is this:
|
| As a technician, if I see something that looks wrong in a
| product, I point it out and make a report. But it's the
| engineer that makes the decision to fix it or to Use-As-Is. If
| that part fails and kills someone, the responsibility is on the
| engineer that signed off, not me that did the work.
|
| That's the core of being an engineer I think, taking the end
| responsibility for a product.
| robocat wrote:
| > A programmer, technician, mechanic plugs numbers into
| formulas, follows instructions and procedures and practices
| laid out by an engineer.
|
| Engineers do that too.
|
| A structural engineer I know uses software to design beam
| strengths in buildings. He understands what the software is
| doing, but he didn't write the software and he uses the
| outputted parameters at part of his designs.
|
| A mechanical engineer I know needed to design a gear to mesh
| with an outer ring gear. He uses proprietary software to define
| the shape of the gear, entering necessary parameters and the
| output is generated into a CAD file.
|
| Both are real engineers working as independents, but neither
| meets your definition.
|
| I design a JavaScript framework that I use, the process of
| developing that meets my definition of engineering. I call a
| huge variety of functions without needing to know any of the
| internals. If I need to, I can go as deep as I wish to
| understand those internals (my background is assembler,
| followed by an EE degree, followed by embedded software,
| followed by business software). An engineer doesn't derive
| everything from first principles, but they breath compromise
| and parry with conflicting constraints: they have the judgement
| to go down rabbit holes when it is necessary.
| WalterBright wrote:
| > Engineers do that too.
|
| Right, they do. Not everything an engineer does is
| engineering.
|
| > A structural engineer I know uses software to design beam
| strengths in buildings. He understands what the software is
| doing, but he didn't write the software and he uses the
| outputted parameters at part of his designs.
|
| I've worked with formula-plugger engineers, too. But they
| would, now and then, misuse the formulas because they didn't
| understand its limitations. And, if the problem didn't quite
| fit the formula, they were dead in the water. While they had
| engineering degrees, I considered them mechanics.
|
| > A mechanical engineer I know needed to design a gear to
| mesh with an outer ring gear. He uses proprietary software to
| define the shape of the gear, entering necessary parameters
| and the output is generated into a CAD file.
|
| Could he design the gear without the CAD tool? If he could,
| he's an engineer. If not, he's a mechanic.
|
| P.S. I'm all for using labor-saving devices. But they are not
| a substitute for understanding.
|
| P.P.S. The guy who programmed the CAD tool is an engineer.
| WalterBright wrote:
| I remember one formula-plugger "engineer" I worked with.
| His results were off by a factor of two, so I got called in
| to find out what went wrong. I quickly found out that he
| was misusing the formula. I explained to him where he went
| wrong, over and over, but he refused to believe it as the
| formula was king.
|
| Another "engineer" spent a couple weeks trying to eliminate
| the noise in a circuit, essentially trying things at
| random. Finally, an actual engineer was called in. In 10
| minutes, he had calculated an RC circuit to fix it, and the
| noise went away.
|
| Having an engineering degree doesn't guarantee competence.
| monocasa wrote:
| > He understands what the software is doing
|
| That's the key. A structural engineer ostensibly has the
| background necessary to work without the tool, albeit with
| much less efficiency. Because of that they should have a
| first principles understanding of what situations the tool
| won't apply rather than the situation breaking down to
| 'garbage in/garbage out'.
|
| I'll be the first to admit that measuring this in terms of
| education is at best a proxy for that knowledge, and have met
| technicians that truly understand what they're working on
| better than most engineers they worked with, and engineers
| that promptly forgot everything as soon as the exam was over.
| But what is listed above is the underlying piece that's
| attempting to be controlled for. It's a hard concept to
| measure.
| WalterBright wrote:
| That's right.
| notch656a wrote:
| Anyone can be an engineer. If you don't have a PE or an ABET
| accredited engineering degree then you may still be an engineer,
| although most likely you're something closer to a technologist
| (although your skills may be both more valuable and more in
| demand than an engineer's).
|
| I have met maybe two people in my life that have learned the kind
| of first principles physics and mathematics basis outside of
| formal channels of academia or licensure. It's just really
| inconvenient and probably an inefficient use of time for most
| people to learn to be a classical engineer when you can make more
| or better by getting damn good at applying some technology
| (programming, welding, trucking, whatever).
| luisrudge wrote:
| in my linkedin I am :D
| loeg wrote:
| (2021)
| paxys wrote:
| The US Supreme court has ruled that the First Amendment allows us
| to call ourselves engineers, so at least in this jurisdiction -
| yes, we are (if we choose).
| spacemadness wrote:
| Why focus on the argument of "Engineering is Mathematical" and
| ignore "Engineering Uses Scientific Knowledge to Solve Problems?"
| I'm not heavily invested in the outcome I just found it curious
| to only focus on mathematical usage as that's easy to apply to
| software.
| mrwnmonm wrote:
| That Atlantic article is too long and doesn't get to the point.
| Philosophers are faster than this.
| DwnVoteHoneyPot wrote:
| An engineer doesn't say "Move fast and break things".
| [deleted]
| kache_ wrote:
| yes we are
|
| *if we is anything like me
| Tossrock wrote:
| I think the best definition of engineering is that it's a process
| of optimization within a solution space bounded by constraints.
| If you pile up some mud and let it dry, you have made a dwelling
| but you are not an engineer. If you calculate the load
| requirements for a series of I-beams given a certain budget and
| build a skyscraper, you are an engineer.
|
| As the author correctly notes, there aren't necessarily hard
| boundaries on what qualifies as engineering, but I think there
| clearly are axes on which something is "more engineer-y" vs "less
| engineer-y", and as the constraints of the solution space go from
| physical (tension, voltage, pressure) to non-physical
| (interpersonal relations, public perception, aesthetic judgment),
| the activity goes from more engineer-y to less engineer-y.
|
| In software, we're always optimizing on cost / developer time,
| but that's closer to the non-physical side of the constraint
| physicality axis. As you optimize for things like memory usage,
| execution time, binary size, then you get closer to the physical
| end of the constraint-type axis, and are thus more engineer-y.
| d--b wrote:
| > we're always optimizing on cost / developer time, but that's
| closer to the non-physical side of the constraint physicality
| axis
|
| I think this is exactly what the author points out as "software
| engineers don't know real engineering". What makes you say that
| no other engineering practice don't optimize on cost /
| engineering time?
|
| There are degrees of quality in engineering, and one of the
| factors is definitely "time spent on engineering". If you are
| making cheap frying pans, I doubt that you're going to hire a
| rocket scientist to check whether the screw holding the handle
| is strong enough to resist 5000 heating cycles...
| [deleted]
| GrantZvolsky wrote:
| In other words, what all engineering professions have in common
| is that their practitioners solve problems difficult enough
| that merely finding solutions is a substantial part of the job.
| klodolph wrote:
| > ...as the constraints of the solution space go from physical
| (tension, voltage, pressure) to non-physical (interpersonal
| relations, public perception, aesthetic judgment), the activity
| goes from more engineer-y to less engineer-y.
|
| This would put industrial engineering deeply in "less
| engineer-y" territory, IMO.
|
| I think someone is very engineer-y when they pick a simple,
| easy bridge design which requires less skilled labor to
| produce, even if this takes them away from working with more
| juicy physics problems.
| Tossrock wrote:
| I think I would agree with that (industrial / process
| engineering is "less" engineer-y than, say, mechanical
| engineering), but since they're still optimizing against
| measurable physical constraints (how many chiller units can
| we fit in this section of the warehouse, how long does it
| take a worker to move from the freight deck to the storage
| racks, etc), I think they're over my personal line. But of
| course, drawing sharp category boundaries is a losing game,
| which is why I prefer to think in terms of axes / vector
| spaces.
| klodolph wrote:
| I think "drawing sharp category boundaries is a losing
| game" is as close as we are going to get to a clear lesson,
| here.
| tkiolp4 wrote:
| So a plumber is an engineer. It's easy: an engineer is someone
| who has a degree in engineering (whether or not such degrees
| should be degrees on engineering is another question). The
| current trend of calling programmers/developers engineers is a
| pure business trend (it originated in HR departments).
| [deleted]
| AlotOfReading wrote:
| Do you think engineers existed prior to the 18/19th century
| when degrees became a thing? It seems problematic to your
| definition that most of the wiki page on engineering is
| dedicated to things done by non-engineers.
| tkiolp4 wrote:
| It's a simplistic definition. Since the topic of calling
| developers engineers is rather superfluous, I think we
| should go for simple definitions.
| kelseyfrog wrote:
| I can think of many simple yet incorrect definitions.
| They have as much utility as this one.
| a_wild_dandan wrote:
| Also there are people without _any_ degrees that do far
| more engineering than many developers who hold software
| engineering degrees.
| kevin_thibedeau wrote:
| The engineering process is to apply design tools to
| architect a solution with expected performance before
| anything is built. In traditional engineering this
| generally boils down to mathematical models that dependably
| replicate expected behaviors to a known degree of error.
| Building happens after the modeling says a solution is
| possible.
|
| With software, true engineering only happens if the
| development model can follow such a process. Nobody wants
| to put in the work to do this for all code though.
| woah wrote:
| As he says in the article, many engineers in the past had
| neither a degree nor a certification. And they were certainly
| building "real things".
| [deleted]
| Tossrock wrote:
| Depends on what the "plumber" is doing. Certainly there are
| plumbing tasks (eg pipe sizing for a chemical plant) which I
| would qualify as engineering. I would qualify it that way
| because they probably had a series of constraints (must
| transport X liters of substance Y / second at Z temperature,
| fit within service routing of the structure, minimize cost,
| etc etc) which they optimized against. I think a plumber who,
| say, fixes a sink, is not doing a similar process. Between
| those points lies the gray area of subjectivity!
| sudosysgen wrote:
| Many chemical engineers do mostly plumbing. If you're really
| great at optimizing plumbing for a large range of conditions,
| then yes you're doing an engineer's job.
| kevin_thibedeau wrote:
| An engineer doesn't just wing it because they're "really
| great" at it.
| kelseyfrog wrote:
| It's easier than that: an engineer is someone who does
| engineering.
|
| I'm not convinced there is much utility in conferring the
| attribute of engineer to someone who is not practicing
| engineering when it's just as possible to say "She studied
| engineering" or "She majored in engineering" to denote the
| status of having an engineering degree but not engaging in
| the doing of engineering.
| [deleted]
| askonomm wrote:
| I don't think so. Software engineering, and by extension,
| software engineers became a thing in the 60's. Margaret
| Hamilton coined the term ~'63.
| balls187 wrote:
| > So a plumber is an engineer
|
| Yeah, we call them civil engineers.
|
| In the US, in order to be an engineer one either had to have
| a license to call themselves an engineer, or a company could
| confer that title to employees. These days, it's less about
| the specific education, and instead the process of solving
| problems.
|
| Engineering is a discipline which may be applied to many
| domains, including software. I define an engineer as someone
| who uses fundamental principles and processes of science and
| engineering to solve real world problems.
|
| Our customers need to ask a skilled expert a question and
| receive an answer.
|
| If I merely implemented code to achieve this goal, I would
| not consider that engineering, but rather coding.
|
| Instead, if I first defined the problem statement, gathered
| requirements, documented assumptions, broke down the problem
| into discrete deliverables, defined metrics and success
| criteria, and created a plan of record, that would be
| engineering.
|
| I have a formal education in engineering, and aside from the
| mathematical and science fundamentals required for
| engineering, a large portion of my education was dedicated to
| the process of solving problems (also proudly, a good portion
| was dedicated to learning about ethics as well).
| chrisseaton wrote:
| My first computer science degree was a Master of Engineering
| degree. Does that make me an engineer over someone with a
| Master of Science but the same degree course content?
| goodlinks wrote:
| At uni I had one course in software engineering. It was
| different to other courses as it was about defining metrics
| and constraints, measures of success, requirements etc. As
| well as evaluating what building blocks you had available.
|
| To me the term didn't come from HR it came from trying to get
| "programmers" to think in terms of constraints, value, risks
| etc. Seems a pretty clear and simple definition.
|
| The reason I think its not taken off in the same ways as say
| mechanical engineering is because in general customers cannot
| actually see the product, only certain elements of its
| outputs.
|
| If you couldn't see bridges either in use or after a failure.
| You just saw cars disappear at one end and appear at the
| other, not even able to measure the gap or time taken to
| cross in any meaningful way then structural engineers would
| bullshit and self grandise as much as software engineers.
|
| Maybe one day the average person will know enough to hold us
| to account, then we will begin engineering properly.
| ffhhj wrote:
| You know, some programmers build game __engines__...
|
| More seriously, the first programmers were
| electric/electronic engineers, so the engineer title was
| probably inherited. And game engines actually require lots of
| math and physics.
| tkiolp4 wrote:
| I don't doubt working on game engines is hard (I do web
| development). If you build game engines then you are
| probably a game engine developer. I don't hold a degree in
| engineering myself; no shame of not having the "engineer"
| title.
| bmitc wrote:
| > it's a process of optimization within a solution space
| bounded by constraints
|
| That just describes problem solving.
| dpweb wrote:
| Maybe it's the intangibility that lends to an attitude of less
| respect.
|
| Designing something in the physical world like a road you can't
| screw up or people might get hurt. You could say the same about
| software but only in a very few instances. There's no necessary
| reverence for the laws of the natural world. Electricity and
| gravity will kill you.
| phillipcarter wrote:
| Hmmm. I don't necessarily know if I agree with that framing.
|
| I think there's a lot of software out there that could cause
| severe harm if it weren't written well enough, or its use cases
| were not thoroughly thought through. Thinking of all the
| software that runs hospitals, banks, etc. And then all the
| indirect harm caused in consumer software (often among teens).
| Not to mention software written for evil purposes, such as that
| to take down power networks, support child trafficking, etc. I
| think there's a pretty strong case to by made that software is
| serious business. Even if fiddling around with terraform
| providers or whatever feel pointless sometimes.
| empressplay wrote:
| umm 737MAX?
| dvh wrote:
| Watch "Das Boot", the entire ship has one engineer and he
| commands respect in the movie.
| zaptheimpaler wrote:
| > Many people have asked me why I care so much about this
| project. Why does it matter whether or not software is "really"
| engineering? Why can't we just say that "software is software"?
| It's because of these misconceptions. People have a stereotyped
| notion of what engineering looks like. Because software doesn't
| look like the stereotype, they assume that we are wholly unlike
| engineering.
|
| This helped me understand his motivation, although I like to
| frame the problem differently.. more like "why does software
| seemingly fail to learn from other disciplines, or even its own
| history?". IMO the answers are sort of universal - the best
| practitioners do know, but they either can't/won't teach due to
| time or legal constraints, and even if they did no one would
| listen. I've seen good tech-company internal wiki articles that
| are often much more comprehensive and well thought out than a 100
| blog posts. It happens in many other fields like say quantitative
| trading, or law or hardware/semi manufacturing too. There is a
| low base level of public knowledge, say like TA or PE ratios in
| investing, and then real firms are decades ahead. I feel like it
| is the difference between a small, loosely competence based
| hierarchy (like a company) vs. a huge, flat network like the
| internet. Hierarchies are able to continuously build upon a
| structured body of information, even codifying knowledge that
| only a few people within the hierarchy understand. Flat networks
| don't work that way for better and for worse.
| cpach wrote:
| _"We are Devo. D-E-V-O."_
| psyc wrote:
| Are Customer Satisfaction Engineers really engineers? Are
| software architects really architects? Is a Doctor of Philosophy
| a real doctor?
|
| Edit: apparently that should have been "Is a MD a real doctor?"
| TIL :D
|
| The only reason this dumb question refuses to die is that
| software developers _can_ actually borrow and apply approaches
| from "real" engineering. The difference is that "we" do not have
| to, either to be successful, or to be in compliance with any
| regulation or cultural expectation (with exceptions).
|
| I'm also generally annoyed by the retroactive continuity of it
| all. "Software Engineer" started as a job title chosen by HR on a
| per-company, not industry-wide, basis, and not as a flavor of
| Professional Engineering. We're probably closer to that
| aspiration now (unevenly distributed) but it still stinks of post
| hoc justification.
| SeanLuke wrote:
| > Is a Doctor of Philosophy a real doctor?
|
| Actually, a Doctor of Philosophy is the _only_ real doctor.
| chrisseaton wrote:
| Well also Doctor of Engineering etc.
| blippage wrote:
| When you go to the doctors, the title "doctor" is a "customary
| title". They don't hold doctorates.
|
| You'll notice that surgeons are usually called "mister".
|
| Perhaps it stems from how the two professions arose. In ye
| olden days, a lot of surgery was performed by barbers.
|
| So when people ask if someone is a "real" doctor, their actual
| understanding is the wrong way around. In their minds, the
| words "Philosophy" in PhD somehow means they aren't proper
| doctors.
|
| Note that there are also higher doctorates, such as DSc (doctor
| of science, which will be specifically scientific), DD (doctor
| of divinity), etc.. I don't think I've ever met someone with a
| higher doctorate, though.
| philosopher1234 wrote:
| >Is a Doctor of Philosophy a real doctor
|
| Nitpick, but yes, actually "doctor" comes from the latin "to
| teach" and originally refers to doctor of philosophy, and has
| been co-opted for MDs. The real question is "are mds (who dont
| teach) real doctors?"
| jimmyvalmer wrote:
| _actually "doctor" comes from the latin "to teach"_
|
| There's only one robust doctor test and it doesn't involve
| etymology. If someone else's mother refers to you as such,
| then you're a doctor.
| qudat wrote:
| I would argue that physicians are actually engineers. They
| are applying medical sciences.
|
| Just like software engineering is the application of computer
| science.
|
| It's the truest definition I've been able to think of.
| netizen-936824 wrote:
| Physicians are repair techs for humans
| Cd00d wrote:
| That's interesting. Though, I'm not a fan of the notion that
| I'm no longer a Dr. after leaving academia post PhD. But,
| that's just my emotional take, and doesn't counter your
| origination history.
| xtracto wrote:
| Hey, I did my PhD more than 10 years ago, and I've taught
| more in my time in industry than what I could have taught
| in academia.
| Supermancho wrote:
| > I'm no longer a Dr. after leaving academia post PhD
|
| "Does a PhD thesis have to be novel?" - I don't care how
| you slice that answer, even if you were
| confirming/revisiting existing studies. If you have a PhD,
| you contributed to human knowledge in either the master or
| PhD theses, imo.
| klodolph wrote:
| To add to this, you'll see different degrees for research vs.
| professional practice doctorates in various fields.
|
| For example, you can get a Ph.D. in psychology, or a Psy.D.
| in psychology. Generally speaking, Ph.D. is for psychology
| researchers and Psy.D. is for professional psychologists.
| Similarly in law, a J.D. is often part of the process of
| becoming a lawyer, and a J.S.D. is for someone who wants to
| do research.
| psyc wrote:
| > The real question is "are mds (who dont teach) real
| doctors?
|
| This makes my day!
| chrisseaton wrote:
| > Is a Doctor of Philosophy a real doctor?
|
| 'Doctor' means someone who's learned enough to teach. Many
| physicians calling themselves doctor don't actually have any
| kind of doctorate at all and only get the title as a curtesy
| due to their own profession's historical fears of lacking one.
| ratww wrote:
| Interestingly, in Brazil practicing lawyers who passed the
| bar exam are also called "doctors" due to an Imperial decree
| from 1825, that was also a courtesy to them from the then
| Emperor.
| MattGaiser wrote:
| Indeed. Real engineering is mostly defined by regulatory rules.
| Crappy bridges and unsafe factories existed before the
| government regulated it.
| [deleted]
| exdsq wrote:
| You can become a chartered engineer with a background in
| software engineering so it is a 'real flavor' of Professional
| Engineering. I'm studying for the CSQE which is a Certification
| on Software Quality Engineering from the same body that awards
| regular quality engineering certificates and I've been pretty
| surprised/happy with the focus it has on processes that allow
| for reproducible quality, metrics to monitor software
| improvements, and its general depth on testing as a whole (for
| example state machine, property, and model-based testing).
| 4rt wrote:
| Do you have any good links about this please?
|
| It's interesting how the traditional standards bodies are
| adapting to the new tech.
| masswerk wrote:
| The Doctor of Philosophy is a somewhat unlucky example, since
| this really goes back to the original trivium. Medicine, on the
| other hand, is an applied science (so, strictly speaking, if
| you're not bound to teaching...).
| stakkur wrote:
| My father-in-law, a lifelong licensed civil engineer, would (and
| often did) say 'no'.
| mslate wrote:
| Yes, we're all engineers. Some better than others.
|
| A piece of paper changes nothing, only in the legal system in
| which you operate.
| ajkjk wrote:
| I really like the writing style on this. Very practical and
| readable, while getting straight at the interesting philosophical
| questions and not using a bunch of vapid filler.
|
| Also here's a take: yeah, software engineering is engineering,
| it's just really _bad_ engineering which is why we're missing
| most of the things you'd expect to see in an engineer. We're in
| the early days of the craft, like 20% of the way to wherever it
| will end up, and we're doing the equivalent of, say, the
| structural engineering that goes into building a log cabin.
| WalterBright wrote:
| It took an engineer to invent Autotune. A programmer never would
| have been able to.
| zwieback wrote:
| A long time ago when this was discussed someone suggested
| "software gardener" would be a good term. As a professional
| software developer and hobby gardener I kind of agree.
| qudat wrote:
| IMO, Engineering is the application of science.
|
| Software development is the application of computer science.
|
| Using this definition, physicians are engineers, applying medical
| sciences.
| zmmmmm wrote:
| One of the reasons engineers exist is to mitigate a high cost of
| getting something wrong. That's different to saying "people could
| die" ... it can be as mundane as, once we've made a million of
| these widgets there's a very high cost to remake them all because
| something was miscalculated. When software work heavily
| incorporates these elements of process and planning, I call it
| engineering. When it doesn't (for example, when it's built
| entirely agile style with literally no planning ahead beyond what
| we do for the next 2 weeks) I don't.
| jmfldn wrote:
| Absolutely not. My job title is "engineer" but compared to what
| my dad does, mechanical engineering, it's much more an art with
| bits of actual engineering and mathematical rigour sprinkled on
| top. I honestly think I should be called a developer and leave it
| at that. I don't think of myself as an engineer in all honesty.
| amelius wrote:
| We're plumbers, not engineers.
| philipov wrote:
| Or are we dancers?
| mrwnmonm wrote:
| My vote is for this one
| citizenpaul wrote:
| The difference is simple. We are not engineers for the same
| reason cheerleaders are not athletes.
|
| There is too much money to be made by trivializing the industry
| and the players involved benefit greatly by lobbying against it
| being "real" engineering.
|
| Whats the difference between a skyscraper and pool house in terms
| of "real" engineering. Nothing. Whats the differene between a
| spacecrafts code engineering and a website. Nothing.
|
| There are just lower stakes and it is used as a straw-man against
| professionalizing the industry of software.
| pjmlp wrote:
| Given the professional title, in an university approved by the
| Engineering Order, definitely.
|
| Unfortunately not something with the same value everywhere.
| tomc1985 wrote:
| I had the privilege of sharing office space with the engineers at
| a former employer, with at one point sitting next to a chemical
| engineer on my left and a mechanical engineer on my right. The
| former spent all day analyzing formulations and generating test
| data, and the latter spent all day putting together various parts
| and gizmos in SolidWorks. To me the biggest difference between us
| (besides the work itself) was process -- this half of the
| engineering department was full of it. And it was respected.
| There were notebooks describing process for every little thing,
| and so much of the work produced had to be signed off on.
|
| We sometimes worked together closely, as we were building
| machines that were driven by software, and I felt respected by
| them and they seemed comfortable with us being titled Software
| Engineers. We seemed to share a similar mindset and curiosity
| about the world and discussions tended towards the scientific.
|
| Though, I would note that that software org spent a lot of time
| writing things in-house; our department had almost zero
| integration with outside vendors save those that were performing
| some other service for us. I am not sure that this modern flavor
| of "software engineering," where it seems more time is spenting
| thinking about how to glue together various services, resembles
| what we did there.
| monksy wrote:
| I think Hillel is a pretty interesting guy. But I think that he's
| a bit missing the mark here.
|
| It feels like his view of engineers is that they are people who
| can put together a solution and then use a lot of fancy numbers
| and established facts to support their solution. In his oil
| drilling example.. he's not going into the same issues that we
| face. (Is that drilling analyze for failure worth the money in
| investigation, etc)
|
| With software engineering you're putting together instructions to
| fit within a computer's hardware capacity to solve your problem
| in the context that you need to operate it. There are a lot of
| ways about it .. however we have a lot of issues in our field
| surrounding the technical aspect on this:
|
| 1. Academics is dead focused on the hard part of language
| schemas, grammars, correctness-proofs, etc. 2. The research that
| we have about design patterns and their usages are nothing more
| than surveys and try to debunk a negative. (This goes back to the
| whole "academics proved unit tests don't provide value") [The
| results are never influential and they completely ignore the
| quality of the data]
|
| Additionally:
|
| I want to say that as engineers .. at companies, we're put into
| aggressive processes and methodologies that prevent us from
| operating a very high quality output. As a software engineer, you
| should have verification to prove your program works as intended,
| you should have monitoring to validate that constantly in
| production, you should have experience+data that supports the
| design decisions.
|
| There are metrics there to quantify our solutions.. but being
| business and shipping led.. that's forced to the wayside.
|
| ---
|
| Slight addition here: We're in a phase in the industry where
| experience is completely ignored and we're forgoing technical
| "merit"(By that I mean experience, strong practices, discipline..
| not the business says I'm good) in favor of blasting people into
| the door.
|
| We're not getting a lot of people that are willing to learn from
| the methods of old and make constructive commentary, we're
| getting people that are not willing to be disciplined, and we're
| getting people who forgo good practices because "they dont'
| wanna". (You see this all the time with lazy arguments about
| people hating to do unit tests, bad tooling, etc)
|
| TL;DR to my argument, are we engineers right now.. some have the
| privilege to be.. but most are punished for doing so because it
| may annoy the PO. We totally can be engineers, no one really
| rewards you for this.
| throwaway984393 wrote:
| _" Engineers work on predictable projects with a lot of upfront
| planning and rigorous requirements. Software is dynamic,
| constantly changing, unpredictable."_
|
| Ask someone building medical robots if their software is
| unpredictable. Or someone building a car ECU. Or an airplane
| guidance system. Or controls for industrial machinery. Or telecom
| equipment.
|
| Our entire industry literally follows a _manifesto_ whose purpose
| was to _eliminate_ upfront planning and rigorous requirements,
| called "Agile". It was an intentional choice to be
| irresponsible, and we all ate it up because it meant we didn't
| have to do any due diligence. Just churn out software turds as
| fast as you can, get a big smile and a thumbs up from the user,
| and you're done.
|
| Who cares if tomorrow it fails and the thermostats for 10,000
| houses goes out in the middle of winter? At least we didn't have
| to write documentation! Moving too fast over here, can't be
| worried about shit like "making sure it's safe" !
|
| Oh, whoops!, every social security number in the country is
| exposed. But we could never have prevented that, we write
| software, it's inherently unpredictable!
|
| It's all _too_ predictable. The industry is led by children who
| don 't know how to do their jobs, there are no industry
| requirements or certifications, and there is no trade school to
| really learn. Can you imagine an electrician wiring your house up
| after a 6 week "boot camp" ? Or a mechanical engineering intern
| building a bridge?
| Scramblejams wrote:
| I come from an aerospace engineering background (did structural
| engineering on commercial aircraft that were in the design and
| approval stages) and am in software now (games). I've had two
| different takes on this. Neither is perfect. Would appreciate
| comments on them.
|
| (a) If it's regularly expected that you ship bugs, you might be
| in a discipline that is distinct from engineering.[0]
|
| (b) If you can usually reach for an abstraction to save you, you
| might be working in something that isn't engineering.[1]
|
| [0] If software is engineering, then it's the only engineering
| discipline of which I'm aware in which the participants are
| regularly expected to produce deliverables they don't fully
| understand. What do I mean by that? Well, if we software peeps
| fully understood our deliverables, we wouldn't have bugs, or at
| least, we'd always know what bugs are there. If as a structural
| engineer I had delivered a final draft of an analysis document
| which showed that I didn't fully understand the part and how it
| would perform, my boss would not have been pleased. Most software
| bugs are treated more casually than that, so we clearly have a
| tolerance for delivering work that we don't fully understand.
|
| You might take issue with the idea that I "fully understood" a
| structural part. Fair. When I calculated the strength of a beam
| in a thrust reverser I didn't understand the individual molecular
| interactions, I didn't need to know if the metal was of a body-
| centered cubic crystal structure, etc. But this is because I was
| able to apply well-understood and rigorously accepted simplifying
| assumptions that were conservative (from the point of view of a
| factor of safety), and fully encapsulated all the understanding I
| needed to produce a part fit for use.
|
| [1] This feels like the more flawed of the two proposals, because
| I expect EEs can do this. Control systems folks can definitely do
| this, and I would absolutely call them engineers.
| netizen-936824 wrote:
| >When I calculated the strength of a beam in a thrust reverser
| I didn't understand the individual molecular interactions, I
| didn't need to know if the metal was of a body-centered cubic
| crystal structure, etc. But this is because I was able to apply
| well-understood and rigorously accepted simplifying assumptions
| that were conservative (from the point of view of a factor of
| safety), and fully encapsulated all the understanding I needed
| to produce a part fit for use.
|
| While I fully agree with almost everything in your post, this
| sounds an awful lot like an abstraction to me. Perhaps the
| different between creating software and engineering based on
| the physical sciences is the degree in which the abstractions
| are understood and rigorous. Perhaps software engineering is
| simply in its infancy and may eventually lead to more rigorous
| designs with less or no bugs in the future?
| aozgaa wrote:
| In software, the range of correct operation (eg: maximum web
| server load with response time under x ms) is commonly
| unspecified and omitted. The strength of the beam gives a
| conservative estimate of its capabilities. Still a
| model/abstraction, but one with boundaries.
| Dma54rhs wrote:
| I think there are bigger guarantees and checks the beam works
| as it's specified so the next engineer can continue.
|
| Google was using in production (firebase cli) the notorious
| trick the js developer played us other week. I doubt the
| other fields would rely on some random developer from
| Australia who has had a colorful past to provide the beam for
| structural engineer. And there's definetly more testing from
| all sort of parties they work om real life as advertised.
|
| Then again no one is offering free open source beams and you
| can't since you need materials not just one time drawings of
| an idea.
| netizen-936824 wrote:
| The beams may not be open source but the calculations are
| d--b wrote:
| The strength of a beam is an atomic calculation. A software
| engineer should fully understand a function that calculates the
| length of a string...
|
| How is a spaceship blowing up not a bug? These happen fairly
| frequently... Oh, and oil spills? Fukushima? Mines that
| collapse?
|
| Talking about games. The physical equivalent to video games is
| pinball machines. Anyone who has played these can tell that the
| ball sometimes get stuck in weird places. This is exactly the
| equivalent of a software bug. Shouldn't the engineer have a
| total understanding of the machine so that the ball never gets
| stuck? You know, maybe games aren't so important that
| everything must be perfect.
|
| Also, I have a 2 year old. None of his toys have lasted more
| than 3 months. Literally 0 out of dozens. Isn't there a fortune
| to be made by engineering toys that can endure a kid's
| strength?
| cj wrote:
| > This is exactly the equivalent of a software bug.
|
| Not really, because you can usually shake or tilt the pinball
| machine to set the ball free.
|
| > oil spills? Fukushima? Mines that collapse?
|
| These events happen (literally) once every few years or half
| decade. Software bugs happen (literally) billions of times
| per hour.
|
| (I'm not normally this pedantic, but felt the need since your
| comment comes across as knee jerk defensive without a whole
| lot of substance to work with)
| d--b wrote:
| > Not really, because you can usually shake or tilt the
| pinball machine to set the ball free.
|
| That's silly. A bug is an unintended behavior of the
| system. If you shipped a debugger with every video game,
| you'd probably be able to get yourself out of most bugs.
|
| > Software bugs happen (literally) billions of times per
| hour
|
| You're comparing things with different criticality. A bug
| that doesn't prevent you from doing your work is like a
| match that doesn't light up properly. These events happen
| all the time in the physical world.
|
| Bugs that shut down AWS for 24 hours tend to be less
| frequent...
|
| Let's just no enter in a debate about the frequency of
| "physical world bugs".
|
| Yes I admit it was a little knee jerk defensive.
| MisterBastahrd wrote:
| Yeah, oil spills occur because companies make conscious
| decisions to do the bare minimum to operate their
| pipelines. 500K gallons of crude spilled in Louisiana a few
| weeks back and nobody knew about it until cleanup efforts
| were underway. Why did the spill occur? It wasn't because
| the pipeline was engineered poorly. It was because the
| pipeline was not properly maintained. And people wonder why
| there are those who do not want an oil sands pipeline
| carved through an aquifer.
|
| Engineers don't work with infinite budgets and they usually
| are not the people who are making final decisions on either
| maintenance or implementation. Many of these failures occur
| because of budget constraints, time constraints, or
| decision makers who go against the recommendations of
| experts.
|
| IMO, the closest thing to a "software engineer" is a
| software architect. Everyone else is a craftsman.
| skrtskrt wrote:
| > But this is because I was able to apply well-understood and
| rigorously accepted simplifying assumptions that were
| conservative (from the point of view of a factor of safety),
| and fully encapsulated all the understanding I needed to
| produce a part fit for use.
|
| I am not sure how this is different from evaluating a library,
| database technology, or architecture, going through design
| review, learning properties of distributed systems (which have
| corresponding proofs by the way) to understand which properties
| you need to satisfy with a given solution, reading the
| documentation, viewing other open-source code that uses the
| technology, reading publications/testimonials from people and
| companies using it in productions, etc., etc., like we do.
|
| In particular "applying simplifying assumptions" - this is what
| we all have to do particularly in a distributed, cloud-
| computing world where you are essentially purchasing a
| conceptual primitive (like "virtual CPU" or "replicated block
| storage" and building on top of simplifying assumptions about
| how those work, because you can't walk up to the NAS rack and
| start hitting it with a hammer to see if the data can be
| recovered after, the same way you can't hit a steel beam with
| an actual hurricane to know what will happen.
|
| Although if I worked in the datacenter operations team for a
| cloud provider, I would _absolutely_ hope to one day be able to
| test how we handle if I yank some plugs or hit the NAS rack
| with a hammer :)
| slingnow wrote:
| It is absolutely wildly different. "Evaluating a library",
| "reading the documentation", etc., is absolutely NOT the same
| as basing your calculations on a hundred+ years of rigorously
| proven methods and deeper physical truths. How could you
| possibly infer that these are the same thing?
| skrtskrt wrote:
| software engineering is a younger discipline, we don't have
| hundreds of years yet.
|
| You seem to think that our understanding of CPU operation
| or distributed systems isn't based on physical truth and
| rigorous testing.
|
| Also a programming language or library or whatever has
| often been deployed by tens of thousands of organizations,
| across tens if millions of deployments, across trillions of
| discrete times the code path has been hit, and we know how
| it acts. That's rigorous in its own way
| yodsanklai wrote:
| > If it's regularly expected that you ship bugs, you might be
| in a discipline that is distinct from engineering.
|
| Totally disagree. Engineer = design and build things. Whether
| what you build has bugs or not is irrelevant to the definition.
|
| > If you can usually reach for an abstraction to save you, you
| might be working in something that isn't engineering.
|
| All science is based on abstraction. Laws of physics used by
| aerospace engineers are abstractions of some more complex
| reality.
| Scramblejams wrote:
| Is a child performing engineering when they resolve to build
| a tower of blocks and do so? If not, what distinguishes them
| from someone who is performing engineering?
|
| In your view, are simplification and abstraction the same
| thing? Or do they differ, and if so, in what way?
| karaterobot wrote:
| Love this comment!
|
| > (a) If it's regularly expected that you ship bugs, you might
| be in a discipline that is distinct from engineering.[0]
|
| This might arise from the different contexts without implying a
| different activity is taking place. Fixing bugs after launch is
| something you can do in software engineering, but can't really
| do in (say) structural engineering. If they could invisibly and
| safely swap out part of a bridge without stopping traffic, I'm
| betting they'd do it all the time! In software we can, and it
| makes sense to use this feature of digital products as part of
| the engineering process, in order to meet other requirements,
| like time and cost.
|
| (Whether it is overused or not is another question. I consider
| "good engineering" vs. "bad engineering" as distinct from "is
| engineering" or "is not engineering", ymmv)
| varjag wrote:
| From my observations engineers in many disciplines would wing
| it all the time. Sometimes because of time/budget constraints,
| or simply because of lack of established methodology for
| certain corner cases. The scope of 'corner cases' also tended
| to be a lot larger in their disciplines' infancy: things like
| bridges (and yes, aircraft) were regularly built with
| assumptions pulled out of one's asses.
| dataflow wrote:
| How about this one:
|
| (c) If your project assumes the underlying device/system will
| behave _exactly as it is told to_ , then you might be in a
| discipline that is distinct from engineering.
|
| This means "engineering" would include some software projects
| (like fault-tolerant system design), but exclude many others
| (like most desktop/mobile/web apps, perhaps with components
| like databases being exceptions).
|
| My rationale for this is that, best as I can tell, traditional
| engineering is (for the lack of a better phrase) about "taming
| the real world"--which doesn't always behave the way you tell
| it to, because it's inherently uncertain, failure-prone, and
| impossible to model _exactly_. So if your task is dealing with
| that, then you 're doing engineering. Whereas if your main
| problem is coming up with the correct specification--but you
| assume it will be executed faithfully--then it's not really
| engineering per se, but something else (not sure if we have a
| name for it).
|
| Thoughts?
| Scramblejams wrote:
| Intriguing! I'll have to let that percolate...
| chiyc wrote:
| I appreciate you sharing your perspective! Mine's somewhat
| different having worked in another industry.
|
| I worked in semiconductor manufacturing as a process engineer.
| What counts as bug in that setting? It's completely expected to
| have defects in the final wafer. They go through a QA process.
| Some die can be repaired but others are trash. Die also get
| graded and low quality chips go to customers with less mission-
| critical needs. There's also a department dedicated to
| investigating early failures in defective product from customer
| returns.
|
| Personally, I viewed the product that I delivered as the wafers
| coming out of the steps I owned. High volume manufacturing is
| an ongoing process much like software development.
|
| As an individual process owner, I had metrics and goals to meet
| but my processes fit into a larger system I didn't fully
| understand. Process development happened by incremental changes
| much like software feature development. We would convert a
| small percentage of the production line with a new change at
| one step like you might use feature flags, but we sometimes had
| to rollback changes when something unexpected came up at yield
| or test.
|
| It might be more the nature of semiconductor manufacturing, but
| I view failures as part of the engineering process that comes
| up when we're pushing our tools and systems to new limits.
| Scramblejams wrote:
| Yes, (a) doesn't hold up when you're dealing with the
| bleeding edge. Plenty of experimental airplanes, designed by
| highly credentialed engineers, fell out of the sky on the way
| to producing today's safety miracle of commercial aviation.
| Similar story (hopefully usually less deadly!) with other
| miracles, like modern semiconductors.
| garettmd wrote:
| Point a seems more related to the "culture" surrounding modern
| engineering than it does a prerequisite for the discipline
| itself. Looking at how SpaceX engineers produce things looks
| totally different (from my outside perspective) from how a
| civil engineer sitting behind a desk would sign off on designs.
| Engineers at SpaceX seem to be more accepting of failure and
| have the "move fast, break things" mindset that most
| traditional engineers don't have.
| LegitShady wrote:
| engineers at spacex are unlikely to go to jail because one of
| their designs blew up, but most engineers who design bridges
| or vuikdings dont have that luxury.
|
| Move fast, break things, pay for it with someone's life, lose
| your professional accreditation and maybe your freedom.
|
| Maybe they're playing similar but different games rather than
| playing the same game differently.
| jolux wrote:
| > Well, if we software peeps fully understood our deliverables,
| we wouldn't have bugs, or at least, we'd always know what bugs
| are there.
|
| I don't think this is really incompatible with some of what
| Hillel gets at in his post with regards to professionalism and
| quality. I think it's possible for software engineers to have
| much higher confidence in what sorts of bugs their solutions do
| and do not contain, but the practice is mostly tilted towards
| velocity over catching every last bug.
|
| Because not all bugs are the same and not all requirements are
| equally important. Robust software systems are supposed to be
| built to minimize the impact of bugs in individual components
| where possible, with defensive programming techniques and such.
|
| > I was able to apply well-understood and rigorously accepted
| simplifying assumptions that were conservative
|
| I think this is a better candidate for a key difference than
| your other suggestions. We don't have a lot of good ways to
| apply conservative simplifying assumptions once software gets
| to a certain scale. We have abstractions, but where they are
| imperfect, any missed detail is a possible integration flaw.
| Scramblejams wrote:
| Does this imply that the more complicated a stack gets, the
| less engineering can be done, and it devolves into something
| else?
| tester756 wrote:
| Software is built on 150 layers that change incredibly often
|
| new cpus, changes to OS, core libs, frameworks, runtimes, vms,
| language libraries, new protocols, other hardware
|
| the dynamic here is way too big
| chunky1994 wrote:
| I think the difference in [0] is your input variable space is
| much smaller for "traditional" engineering disciplines. To
| grossly simplify: ME? You need tolerances for a specific amount
| of force (in different directions.) EE? You need tolerances for
| specific amounts of current passed through a circuit.
|
| With software your inputs are tremendously varied, because user
| input is not as well-formed as in any other engineering
| disciplines. In fact we deliberately try to find ways to input
| things that are not supposed to be inputs by designers of
| systems (i.e hacking things). If "hacking" bridges was a thing,
| it would be something like people trying to see if they can
| diffuse a thermite solution into the rock-face instead of
| driving a car over it, and I'm not sure any structural engineer
| has planned for that scenario.
| steve76 wrote:
| >(a) If it's regularly expected that you ship bugs, you might
| be in a discipline that is distinct from engineering
|
| A software bug means you can't drag and drop, or have to wait
| to import your contacts.
|
| An engineering risk means the hood of the car decapitates you
| above 30 mph, or the diesel fumes give everyone cancer.
|
| >(b) If you can usually reach for an abstraction to save you,
| you might be working in something that isn't engineering.
|
| Everything's rated. You open a catalog from a supplier. If
| there's any question, go up in size. A lot is skids now. There
| are also trade associations. Dust settles. Products turn from
| novel invention into utility. Existing capacity is built around
| one thing a shop does right, especially the knowledge from the
| workers.
|
| Software is much harder. Go. Just go. Get it done. Get it out.
| Who cares if it's awful code. We need to make money now.
|
| Engineering is the applied science. Applied means you use it.
| You don't create it. If you do create it by chance, it's not
| your responsibility. Ma Bell didn't go into the business of the
| Big Bang when they discovered cosmic background radiation.
| Their job was telephones. Science means consistent observations
| regardless of the environment. Everyone thinks of scientists as
| people in lab coats. Nothing like that. Lot's of reading.
|
| Software is much more focused on engineering. In other
| disciplines you are a cashier at a grocery store. Software is
| much more like Menlo Park. You have a fixed commodity in server
| cost and bandwidth. Add value to it however you can.
| bopbeepboop wrote:
| The problem is that "software" is as broad as "aerospace" or
| "construction".
|
| Some aerospace things are highly engineered -- airplane, rocket
| ships, etc; some things aren't -- kites, paper airplanes, etc;
| and some things are in-between, like gliders or hot air
| balloons.
|
| You get the same in buildings -- which range from sheds to
| houses to skyscrapers.
|
| Also, the end of [0] and your discussion of your usage of
| routine abstractions to solve problems makes me wonder if you
| consider your own job to be (b)-type engineering.
| Scramblejams wrote:
| I do not consider what I do now to be engineering. I'm
| responsible for a product used by my whole studio and I try
| to be very careful and produce a high quality deliverable,
| but I do not think of it as engineering.
| protontorpedo wrote:
| Does it even matter? It doesn't, this is like comparing apples to
| oranges. The biggest reason there is more rigor in other fields
| is because they are less iteration-friendly.
|
| I personally call myself a programmer, even if my job title says
| engineer.
| Barrin92 wrote:
| I'd say the core of what engineering is, is building something
| according to formal specifications and _well-defined_ error-rates
| and constraints. It need not be mathematical in nature but it has
| to be strict and measurable. And as a consequence, almost any
| engineering discipline has well-defined methodologies and
| processes, and engineers are formally trained.
|
| I think this is in line with the intuition of the article.
| Someone who writes software for a spacecraft is an engineer
| because they work within extremely well defined limits and
| towards strictly enforced specifications. People who write
| software for the military or who write compilers probably do too.
|
| I don't think this applies to how most software developers work
| when it comes to the web or just your average project. There is
| in my experience no rigor of that sort. People just write code,
| and sure there's performance considerations but usually not in a
| systematic way, and it's often more tinkering than engineering.
| razzio wrote:
| This makes sense to me as someone educated as an electronics
| engineer. I've since moved over to software development and on
| occasion feel it can be called engineering, but more often it
| cannot.
|
| > building something according to formal specifications within
| constraints...
|
| Yes this is close to what I consider engineering, but maybe it
| is better to say 'design something according formal
| specifications within a set of constraints'. Engineering is a
| process of design. Does this mean implementation is excluded
| from the definition of engineering?
|
| Plumbers and carpenters build according to specifications and
| architects design the specifications yet neither are called
| engineers.
|
| Software development more often than not has little in terms of
| formal specifications and design, and as the article points out
| it is very much a field of change. It also focuses mostly on
| implementation instead of design. That is closer to what a
| plumber, carpenter and other tradesmen do.
| Veserv wrote:
| I think you are largely correct, but I think I would instead
| characterize it as well-defined requirements and guarantees.
| What I mean by these terms is: requirements are a formal
| statement of a problem, guarantees are a formal statement about
| a solution, and a specification is a formal implementation that
| guarantees the requirements are met.
|
| For instance, using the case of a bridge, the requirement might
| be something like: "lasts 10 years, max 10 ton load", the
| implementation might be a steel bridge, and the guarantee of
| the specification might be something like: "lasts 20 years, max
| 20 ton load".
|
| Put another way, the key distinction is that engineering has an
| objective measure of what is considered adequate (i.e. solving
| the problem) and an expectation that only adequate solutions
| should be implemented.
| boringg wrote:
| As engineers in Canada you have a Ritual to Calling which is
| supposed to be similar to an oath to public safety above all. And
| to be a professional engineer you have to go through a training
| period and a final test to be considered. I am mostly talking
| about physical engineers here (Civil, Chemical, Mechanical,
| Electrical, etc)
|
| That said - the term engineer (software engineer specifically)
| has been heavily diluted - same as data scientist - to the point
| of irrelevance or that it points to some basic proficiency of
| understanding and capability and not some level of mathematical
| knowledge. There are lots of exceptions and many people who are
| highly adept and capable but I wouldn't say that is an accurate
| portrayal of the entire class of title-holders.
| ghaff wrote:
| > engineer (software engineer specifically) has been heavily
| diluted
|
| Oh, it goes way beyond that and has for decades. When I was in
| the oil business, you saw all manner of job titles with
| engineer on them like (drilling) mud engineer that people would
| joke were actually mud salesmen which they basically were.
|
| And the computer company I worked for for a long time used
| system engineer for a pre-sales role that supported the account
| reps.
| mrwnmonm wrote:
| off-topic: if you want to read something interesting about the
| effects of abstraction, take a look at this
| https://www.amazon.com/gp/product/B07NS35S76/ref=dbs_a_def_r...
| chiyc wrote:
| Thanks for sharing! This is a great series of articles I've never
| seen before. I'm also a crossover as defined here and agree with
| a lot of the perspectives, particularly about the many
| transferable skills in part three. I think working in a complex
| manufacturing environment helped me develop software debugging
| skills.
|
| I see the licensure argument get brought up a lot. Many people
| working in "traditional" engineering fields never get their PE
| because there's just no need in their industry. Sure, that may
| not make them a licensed "Engineer" in some jurisdictions, but it
| doesn't make their work any less engineering.
|
| The work done by other engineering fields also varies widely.
| Looking back on my work as a process engineer, it's honestly hard
| to say that entailed any more "engineering" than my software
| position does now.
| d--b wrote:
| I agree with the conclusion that we shouldn't shut the door.
|
| It would be stupid to not try and take into account the
| experience of other engineering disciplines, just because "we
| don't fit the mold perfectly".
|
| Sometimes it'll help, and sometimes it won't. What's interesting
| is to engage with other people.
|
| I am lucky in that regard to have been trained in a French
| "engineering school", where I was trained in electrical
| engineering, electronical engineering, signal processing
| engineering, computer science, and logistics. People I was
| trained with work on the electricity grid, others on the noise
| that care tires make. There is no question that knowing concepts
| about electricity or control theory made me a better software
| engineer.
| belval wrote:
| I highly recommend people read the article before jumping to the
| comments because it makes several interesting points.
|
| My personal take is that there is no right answer because the
| definition of engineering is quite wide. Like the author we can
| argue that some work of the software engineering is indeed
| engineering (planning, designing, estimating) whereas the act of
| writing code for a giving feature is more akin to a craft.
|
| That being said, I don't really care and I say that as a Canadian
| software engineering graduate, as opposed to a computer science
| major. If you like the engineer title and you want to use it (and
| it's legal in your country) then you should go for it.
| empressplay wrote:
| I'd say that if you routinely create new applications or
| services from scratch and make all of the design decisions
| (with consultation with colleagues), put them into production
| and take ownership of them, then you're most definitely a SWE,
| even if you do pair programming.
|
| If on the other hand you generally implement small atomic
| changes based on predetermined design decisions not made by you
| and those changes are signed off by other people and you don't
| put them into production yourself, you're probably better
| described as a developer.
|
| I think the distinction is maybe if you're the (an) architect
| or not?
| pjerem wrote:
| Nope.
|
| HRs like to write "Software Engineer" on my payroll.
|
| Good if it pleases them and my ego. But I never graduated from an
| engineering school.
|
| But I do the same mud stacking (that is plugging bricks to do
| CRUDs) as my fellow "real engineers" coworkers.
|
| I have too much respect for anyone designing mechanical stuff to
| call our industry "engineering".
| xtracto wrote:
| > But I do the same mud stacking (that is plugging bricks to do
| CRUDs) as my fellow "real engineers" coworkers.
|
| That's the problem with the current state of the Software
| Development field: Most of the work (90% I'd pull out of my
| ass) can be done by "qualified technicians", what in Germany is
| called Berufsschule, in Mexico "Tecnico Superior" [2] and in
| the US I think it may be the result of studying in a Community
| College.
|
| The work of _Software Engineers_ themselves, that should be
| doing real Engineering work. To prepare the ground and the
| "map" for the Technicians to build. It's the difference between
| an Architect (in an architecture firm) and their armies of
| interns or technicians (don't know the name in English). Or a
| Lawyer and also all the people that work for them (interns).
|
| The thing is, that the Software/Computer/IT Engineer degree has
| been watered down since its inception for 40 years. I think
| mainly due to the huge demand that the Computing field has had
| for developers during this time.
|
| [1] https://eacea.ec.europa.eu/national-
| policies/eurydice/conten...
|
| [2] https://www.sectei.cdmx.gob.mx/oferta-educativa/tecnico-
| supe...
| [deleted]
| blondie9x wrote:
| Doubt it. Mostly we chase TC and forget what actually matters to
| society and the planet as a whole.
| daveungerer wrote:
| > I found in my research that people defending the title
| "engineer" rarely coherently define what an engineer is, usually
| boiling it down to "engineers solve problems". The arguments
| against the title tend to be a little more developed, as are the
| arguments about transcending it.
|
| It's a pity the author didn't go into more detail about why
| problem-solving is not the key defining characteristic of
| engineers. Since the author claims this is somehow not coherent
| enough, I'll share my very strong view that this is exactly what
| separates engineers from programmers:
|
| Engineers apply technology to solve problems. They are rarely
| interested in technology just for the sake of it (that's what
| scientists are for), but rather in what it can do for them.
|
| Most people in our industry today are far from being engineers.
| Engineers don't pick their technologies based on hype (or more
| charitably, excitement), and then try to find problems to solve.
| That's how some companies ended up using machine learning for
| projects where simpler statistical methods would have sufficed.
| It's how inexperienced developers fell for MongoDB's marketing
| and jumped straight to using it without considering whether it's
| better for their use case than the alternatives. It explains how
| at some point a ton of companies were using blockchain for things
| that could have been done with centralised databases (although
| that one's likely more due to company executives trying to
| impress investors).
|
| If you're always focused on using the latest thing, you'll always
| have a solution in search of a problem. Reach for new tools when
| you have or anticipate a problem that you think might reasonably
| be solved by such tools. Do that and you've at least inched a bit
| closer to being able to reasonably refer to yourself as software
| engineer... if that's your thing - I'm generally not a fan of the
| title myself, but the engineering mindset is the most important
| thing I look for when interviewing candidates.
| mkl95 wrote:
| Modern software engineering is mostly abstraction engineering. If
| you can build abstractions on top of abstractions and they are
| profitable, you are probably a good software engineer.
| satisfice wrote:
| See Discussion of the Method by Billy Koen. He was a nuclear
| engineer. His definition of engineering was something like
| applying heuristics to solve problems.
| reaperducer wrote:
| Glad to see this come up, because maybe five years ago I had an
| argument about this with a guy at a tiki bar in Vegas during CES.
|
| I don't remember what argument I made (again, because it was at a
| bar in Vegas), but it was potent enough that he and his
| girlfriend relocated to another part of the bar. People have
| surprisingly strong opinions about this.
|
| The term "engineer" has been bastardized over the last 40 years.
| Housewives became "domestic engineers." Janitors became
| "custodial engineers." Garbage men because "waste handling
| engineers." None of them are engineers. If I was an engineer, I
| hope I'd be more amused than miffed.
|
| But as far as I'm concerned, engineering is a science; software
| is an art. But it's not like "artist" hasn't been bastardized in
| recent years. Witness the Subway "sandwich artist." Renoir tosses
| in his grave. Picasso, not so much.
| poulsbohemian wrote:
| I did a lot of different things in my career... I definitely saw
| engineering or at least saw something that was a gateway to
| engineering, but the challenge was that the vast majority of
| organizations had incentives that went another direction.
| Meaning, for most the cost and time to engage in any kind of
| disciplined behaviors was beyond what they were willing to do. Of
| course, the argument can be made that if they followed
| engineering practices it might have _saved_ them time and money,
| but by and large companies don 't have the _knowledge_ to do
| things differently. You could argue that 's why they hire
| software engineers - to show them how to do it right - but my own
| experiences were that most companies can't get out of their own
| way.
|
| So, sure - there could be such a thing as software engineering,
| we could all be software engineers, but in most places we just
| hack along as programmers trying to hold it together with spit
| and baling wire.
| maxbaines wrote:
| Maybe we should Ask Brunel, or perhaps a little more recently
| dare I say Elon Musk.
|
| https://en.m.wikipedia.org/wiki/Isambard_Kingdom_Brunel
|
| I won't link Elon Musk.
| jrochkind1 wrote:
| Posted a year ago too -- and thanks for re-posting because I had
| been trying to remember the title/author of this to find it again
| and hadn't been able to find it!
|
| https://news.ycombinator.com/item?id=25823907
|
| (Yes, at first I saw Jan 18 2021 and thought it had been
| published yesterday; but it's 2022 now y'all!)
| sorry_outta_gas wrote:
| I'm just me
| ggambetta wrote:
| LOL no. We're artisans and craftsmen.
| FridgeSeal wrote:
| > Pete McBreen and Paul Graham who say that we are not engineers
| because engineering cannot apply to our domain. Engineers work on
| predictable projects with a lot of upfront planning and rigorous
| requirements
|
| This strikes me as a really silly argument, it has an element of
| "we're too good for other engineering disciplines ". I don't
| think it's difference in our specifications, software engineering
| does still apply the same underlying principles and intents in
| solving problems.
|
| Admittedly, software engineering has some way to go to reach the
| same levels of guarantees and rigour, but the fundamentals are
| there.
| alanh wrote:
| I think it's less that software programmers are "too good," and
| more that interesting programming work is too new to have
| established engineering practices/standards/etc
| mikewarot wrote:
| Real, actual, Engineers in my home state of Indiana are required
| to graduate from an accredited 4 year education, and then pass a
| state administered test.
|
| The reason is simple, professional engineers work on things that
| would cause loss of life or grievous injury should they fail.
|
| Because of professional licensure, and all it entails, Engineers
| can give a hard NO to the wants and desires of management.
| Programmers will never have that kind of clout.
| [deleted]
___________________________________________________________________
(page generated 2022-01-19 23:00 UTC)