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.
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.
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.
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?
Precisely, I don't understand why people get constantly worked up with this.
Is _all_ software development engineering? No, of course not. If you are banging out CRUD clone #432 then no, you are not an engineer, you are more of a technician (a programmer in our case).
But, consider this, could you design all of Google's infrastructure without applying engineering principles (most likely derived from computer science and computer engineering)?
Or perhaps you write and design complex embedded software to fly satellites, where you have to combine knowledge from multiple branches of science. Isn't that engineering?
The answer, as most everything else in life, is "it depends".
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.
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.
> 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.
> 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.
>> 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.
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.
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 :)
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?
> So what if I do know some discrete math and I do know what it means for a language to have a formal semantics?
We were discussing whether the average software developer can be said to 'do math' in the sense that aeronautical engineers do. I think it's plain that the answer is no. Whether it matters is another topic.
As I said above, in terms of market forces, it's fine that most software developers go their whole careers doing no proper math. It's also true that some highly skilled software professionals are expert in the relevant math.
As to Are software developers engineers?, I hope it's uncontroversial to say Some of them are, some of them aren't. What's less clear, and less obvious, is where the bar should be set. Personally I consider only a small minority of software development work to be anywhere near engineering, but like the article notes, I don't have experience in any 'conventional' engineering field.
Given that router-installation technicians are called engineers these days, software isn't alone in its collision with the word.
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.
> 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.
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
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
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.
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.
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.
Boeing ended up getting run by bean counters with the eventual expected results where the bean counters wanted to charge for a safety feature. Magically, the planes with the safety feature (every single plane sold to USA, Canada, and EU based airlines) had no issues. The ones sold to nations where they were trying to save money, had the issues that we all know of today.
As for how Tesla is structured, well it's Musk at the top who delegates everything and spends his time on Twitter trying to boost the stock price to hit his quarterly stock price goals. As for if they're managed by engineers, I have no clue.
> 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.
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.
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.
If you could create and patch buildings incrementally like software, you don't think people would do that?
Correctness in itself is not a meaningful goal. If something works well enough to meet the needs of the user, being more 'correct' doesn't necessarily provide more benefit.
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).
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.
> ...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.
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.
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).
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.
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.
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.
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.
Upfront-heavy design is a cost saving adaptation to the constraint that experimentation with large scale structures is expensive. Even then, traditional engineering disciplines are very much into prototypes, scale models, and intricate test and measurement apparatus.
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!
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.
Unfortunately, an awful lot do, even the licensed/degreed engineers. I have lots of anecdotes from personal experience that indicate many are more technician/tinkerers than engineers.
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.
> 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 trend of giving high sounding titles started decades ago as more and more educated people entered the workforce and involves all jobs.
Manager? Vice president.
Secretary? Executive assistant.
Developer? Engineer.
Reports and collects some data for his bosses? Data analyst.
Warehouse worker? Logistics and distribution specialist.
Not to nitpick your point too much, but VP tends to have a specific meaning, even if its given to many employees. Usually, it means that this employee can sign contracts or make certain regulatory commitments on behalf of the company. Its not always self-aggrandizing.
It absolutely does not usually mean that, there are a ton of finance VPs that nobody would ever let sign anything meaningful without someone up the chain reviewing it. There are also tons of people who sign contracts for companies who are not VPs. There are companies where VP is really just about comp; all jobs above $x/year are some flavor of VP, even ICs.
It doesn't have to always be self-aggrandizing for it to be true that lots of people are now called VP who used to just be middle-managers.
There's a joke in finance that VP is an entry-level job. Largely because that field is very status-driven and people want a glorified title, despite entry-level responsibilities.
In medicine doctors are now “providers” no different than nurse practitioners, physician assistants, RN, PT, pharmacists etc. it’s the opposite, leveling everyone to the lowest common denominator
Is there a foundational body of knowledge for software engineering the way there is for established engineering discipline? Something that can be tested against like the FE and PE in the US? Would the FE, for example, suffice?
If not, then, at least in my mind, it seems difficult to pin down exactly how software engineering can occupy a space in the domain of modern engineering.
NCEES tried a few years back and developed such a curriculum but there wasn't enough interest so they got rid of it. IIRC, something like a total of 6 people were certified as a software engineer in the last year it was available. I don't see required licensure for software engineers happening unless 1) it's driven by employers or 2) it's driven by regulators. I don't see #1 ever happening because it's asking the employers to give more leverage to their employees. I'd personally like to see #2, at least on certain safety critical applications.
I remember software engineering courses to be about the process, the metrics available, the way to mesure and quantify whatever is going on in a project.
As opposed to learn about a type of algorithms, some math, some language or some pattern.
10 years latter, I’m glad for the exposure.
It was more useful to understand and talk to folks on the sides of the dev department : security, ops, qa, support. Heck, even product.
I felt that with those, the dev could monkey patch whatever together and still be part of some engineering process.
I think the difference is one of disposal and retry.
In physical engineering, you really get one chance. If you make a mistake or miscalculation, there is a cost associated with undoing what's been done, as well as trying again.
In software, there is no such additional cost. You can trivially start from scratch, or any point between scratch and here, at any given time. There is no disposal cost.
I think that is a perception, but its driven by not being able to "see" the product of the work.
Security breaches, locked in data (poor dB structure or no direct access) reverse engineering undocumented functionality, even just dismantling supporting infrastructure and migration costs are huge. Another huge factor is when business logic is codified and the knowledge is lost from the business and only temprarily held by transient consultants or developers.
An sap project for a single region for a $1bn per year company can easy cost over $10m and no software is being developed, only config, process change and data migration. Never mind increased staff turnover reduced productivity.
But very few people have the experience and expertise to understand what they are really signing up for.
Just think about a 3d model can do for a construction project and what that would look like for code and you can see how poorly we do this really.
This ignores the vast amount of software that interfaces with physical systems. When software fails and causes a rover to crash into the surface of Mars, there is certainly a cost and one cannot trivially start again from scratch. Same even with software that does not interface with physical systems, like algorithmic stock trading.
I agree, but I think the horse is out of the barn in many respects. It will be very hard to get organizations to adopt such standards without being forced to by some regulatory agency, unfortunately, because that constraints adds cost and impacts schedule.
That's without even considering all the kinds of rules-lawyering that would be applied afterwards.
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).
You've got one of the big words that I would insert into this discussion -- science. I think the two biggest words missing from here are "science" and "risk." As Alan Kay puts it, science is about getting a description elegant enough that, like the Maxwell equations or Lisp's metacircular evaluator, it fits on a T-shirt. And engineering is about taking that T-shirt and building a bigger more ambitious bridge than anyone could have attempted if they didn't know about forces and stresses and scientific metallurgy.
Engineering involves risk tradeoffs, and if your developers are not making your risk decisions then they are not engineers -- and also you're going to spend a lot more money producing software (the authority to do risk assessment should always be as close to the "in the trenches" work as possible, every degree of removal invites the risk decisions to be made on lower-quality more-aggregated more-gutfeel information rather than clear metrics).
Most of computer programming is instead tinkering -- build a proof of concept, put it under stress, see what is being stressed, buttress those parts. The fundamental idea of architecture, "let's add some structure in advance so that we can build a self-sustaining system and take away the scaffolding later," is only really seen today maybe in test suites or so? Those are the scaffolds of our day I think. We're still in very early years for computing as a proper engineering discipline. But at least we do make some simple risk calculations.
> Most of computer programming is instead tinkering
Most of mechanical engineering is still tinkering. Not all problems are solved. Many of the people here pining for "real engineering in software" need more interdisciplinary experience, ffs.
Interdisciplinary experience is something I most engineering educations provide.
I can only speak from my undergrad experience, but almost every engineering discipline took the same background courses, as well as mechanical, thermal, fluid, and electrical engineering classes and from there, went on to take courses related directly to their field.
From my experience, tinkering is another way to say prototyping or building a proof of concept.
As we've gained experience, the need to prototype the same solutions decreases, but when learning new tools and methodologies, experimenting and prototyping is very much part of the engineering process.
We do not. Civil engineer is a specific thing, with training, education, and licensing. The person who designed the system being installed or serviced was likely a civil engineer, the plumber is a plumber. And that's ok, everyone doesn't have to be an engineer. Being an engineer isn't inherently better than being a non-engineer.
> an engineer as someone who uses fundamental principles and processes of science and engineering
Do you see how saying an engineer is someone who does engineering isn't useful to other people? I'm sure you know what you mean, but basically everyone is and is not an engineer according to your definition.
But they cannot stamp a design, meaning it's not legal (depending on scope and permitting requirements). I can tell a person what ails them if they give me a list of symptoms but that shouldn't be conflated with me practicing medicine as a doctor. An HVAC technician can lay out a design for, say an operating room, but a licensed engineer is the only one who can stamp it saying it meets standards for ventilation. This where the fuzzy terms of "engineer-y" can get us into trouble. ~engineerish != engineer
>a good portion was dedicated to learning about ethics as well).
This is the first I've seen this point in the discussion. Engineering is considered a profession, distinct from a vocation. The term derives from professing an oath to serve the public in an ethical manner. If developers had to take a similar oath, I wonder if it would open them up to civil/criminal liability when they acted unethically (e.g., creating code in a social media application with the goal of manipulating behavior for profit)
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?
Depends on accreditation and licensing as recognized by your state more than the words in the name of the degree. There are far more BS than BE programs producing engineers in the US.
I could agree - but I was responding to the parent who said 'an engineer is someone who has a degree in engineering' which seems to not make sense in my case.
Yea, but my point is that even disregarding accreditation a "degree in engineering" is more often BS/ MS and focusing on titles doesn't reliably work.
Every degree in my school's college of engineering was BS/MS. And I think something like 25 of 27 were "degrees in engineering".
If you want to go full circle, they are "degrees in engineering" because they're accredited by ABET, and satisfy the first requirement towards licensure and a PE.
There is no simple definition, which is the whole point of accreditation and licensing boards.
ETA: But if the programs in your hypothetical have an identical curriculum (and both are accredited), then yes, they would equally be "degrees in engineering".
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.
I don't think this is actually useful without strict definitions of what constitutes engineering. If I go to a homeopath who prescribes an herbal tea to cure my cancer are they "practicing medicine"? The law says they are not, and cannot, because of clear definitions of the term.
Plumbers typically don’t have the background to systematically evaluate the solution space and optimize the solution. But chemical engineering looks vaguely like plumbing if you squint.
Plumbers here in Australia are licensed, so if your definition of "engineering" includes being certified by a regulatory body, then plumbers are closer to "real engineering" than software engineers.
(FWIW, I don't subscribe to that notion of what "engineering" is)
I've had to go on HN a bunch to say this. Engineering school is brutal and generally requires passing a great deal of difficult courses that signal to certain employers that you'd be a good fit to design the power grid or components of space shuttles. They also give you a certain framework/toolbox to work with after you've done calculus, differential equations, circuits, dynamics, statics (not statistics), material balances, coding + all the upper level classes. This is different than the framework/toolbox that an economist would get to help recommend policy changes. Economists don't call themselves engineers and engineers don't call themselves economists. I'd actually argue that the mathematical models and econometrics used by economists is closer to engineering than just programming. A programmer/developer also has a very challenging job that involves what is essentially solving a complex technical puzzle under a huge variety of social constraints such as working within a team and meeting project deadlines and making trade-offs (for example, monolith or microservice). It isn't what engineers define as engineering though.
There are quite a few universities that offer courses/degrees in "financial engineering" and they often are in the mathematics/economics colleges and don't have a typical engineering curriculum as you laid out.
Well, plumbers frequently work as contractors to mechanical engineers. Its better to think of them as technicians, even though much of their training and for single family homes/etc the work is basically engineering on a smaller scale (computing gas flow vs pipe size over a run, etc).
I think shat this article fails to note is this engineer light/technician class which tends to be the more hands on portion of "engineering" in the case of sw, they would be more light engineering more programmer less overall design. AKA your systems architect/principal enginner is probably doing "engineering" the software engineers are likely just programmers.
Can only speak for German degrees and while the first part of your answer is correct in spirit, the second one is kinda off.
You can have the exact same curriculum and be called engineer or not be called engineer, depending on the university. You can even learn nothing related to engineering and have an engineer title, or the other way round.
I'm not saying you're wrong (especially the first part), but there's a lot more to it, especially in countries where 'engineer' is a protected name/profession.
Personal opinion: I don't care. My degree is "Computer Science", not "Computer or Software Engineering" and I see myself as a Software Developer (although I will allow programmer)
>an engineer is someone who has a degree in engineering
Some would define it differently as someone who has an engineering license. There are States who have actually presented lawsuits aimed at preventing people from describing themselves "engineer" if they don't have that license. And, while an engineering degree is the more common first step in the licensing procedure, it's possible for one to get a license without an engineering degree. In the legal sense, they are more of an engineer than someone with a degree and no license.
Regarding the plumber, I think the mechanical engineer who designs the plumbing system would be the engineer, while the plumber is the technician. Just like the electrical engineer designs the system but an electrician installs it. Both roles are equally important but shouldn't be conflated.
Yes exactly! The word engineer comes from the latin ingeniare which is partly derived from ingenium which means clever. The entire job of an engineer is cleverly solving problems.
Everyone solves problems in their jobs. Engineers are not the only problem solvers in society.
On another tangent, I wish we’d redefine what it means to solve engineering problems. I have noticed that there’s this property of engineering that as problems are solved, new ones are created. So it’s this never ending cycle of new problems blossoming.
You clearly haven’t met many of ‘everybody’. People of all occupations solve problems, yes. Most humans barely do, though.
In terms of creating new problems, making life better is an under-defined, open-ended problem. There’s always a lowest-hanging fruit, that doesn’t mean we should stop picking them.
> 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...
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.
It shows very clearly why most software devs are not engineers. I know I'm not.
As a field, we don't "optimize within a solution space bounded by constraints".
We throw crap at the wall to see what sticks, hacking up something like what the users said they wanted, then changing it all to do what they ask for once they start using it.
It's normally done as a craft where we're using fuzzy human instincts to get to a good-enough solution and move on.
And for systems where lives aren't on the line, nor millions of dollars every five minutes (financial trading, massive server farms at Google, etc), that is actually the correct tradeoff. Engineering is overkill for most software.
Exactly. Public safety is central to Engineering practice. Bridges and buildings come to mind but many life-critical software projects in aerospace, medical devices, automotive, also have emphasis on safety. The development process is way more controlled in embedded industries compared to web/IT/enterprise.
Even Google and financial services are really just services that scaled and acquired a massive userbase.
“Software Engineering” is really just an application of civil engineering project management to programming projects. The job title of software engineer is used too liberally however.
To me, the difference is that when we're writing software and just trying semi-random UX ideas and implementation approaches out, we don't have any real constraints that we're genuinely bounded to.
So, yes - throwing crap afu the wall is an optimization process.
It's the other half of the above definition that it misses, IMO.
Microsoft definitely needs software engineers. Privacy and security of users is on the line, even if they literally aren't going to die, lives can easily be ruined by a data leak from the wrong company.
Unless you're suggesting that the word "engineer" is entirely meaningless, this doesn't rebut the given objection to the proposed definition. If the word means anything at all, then the question has to be answered: Is the thing that it means that particular thing, or a different thing?
By the definition given - "a process of optimization within a solution space bounded by constraints" - a taxi cab driver is certainly an engineer, with no fuzziness. Nor would it be an extreme case testing that fuzzy borders of that definition.
And that's why herval disagrees with that definition. As do I.
Definitions can also be overly broad, which is why we no longer use the term "star" to refer to planets, nor refer to the sun and moon as "planets". https://en.wikipedia.org/wiki/Definition_of_planet .
While this is supposed to be an argumentum ad absurdum, it's quite great. Makes you consider that anything from dentistry to sanitation could really be thought of as similar to engineering and gives a nice healthy kick to the ego of an engineer.
In my region we always called softies lightweight engineers, although that term is proposed to be claimed by engineers in the field of energy and resources. I think it is still a good fit. Engineer is a very broad term, the knowledge of electrical and mechanical engineers overlap to some degree, but the focus is very distinct.
Otherwise engineer is just a title too, so I guess it is mostly meaningless?
The engineering part is purely virtual for software developers I guess. While there is some basic physics in most curricula, most computer scientists are a bit "lightweight" on topics usually associated with engineering.
"Computer science" is sort of a different thing and not necessarily engineering, even though the typical software engineer's formal degree is in "computer science" (and also people don't use the terminology totally consistently). But as for software engineering, I think the article makes a really solid case that electrical, chemical, and industrial engineering don't have anything relevant in common that software engineering doesn't, so putting the latter in a separate "lightweight engineering" category just isn't right.
Engineers can both perform the problem solving and design for desired projects and...
AND...
If need be reduce it down to the underlying science and mathematical principles from which it came from, and because of that can analyze why things are "good" or "bad" at a much more fundamental level.
Practitioners/Crafters are repeating "recipes" with far less comprehensive knowledge of the principles that led to those recipes. They may know historical evolution and practical reasons why one recipe is better than another, but their depth of knowledge is far less.
So getting back to software, you can see two types: people that know algorithms and can mathematically design and analyze problems. Or you have people that are just following the api docs and basic examples of loops + if-then but don't know how CPUs work inside, how OSs work, and why.
And do you need full engineers for a website layout or ruby on rails site? No. But if you are scaling or have complex data models or will have actual load, then ... you need engineering.
This is roughly how I explained it to my mother. I told her that no, I'm NOT an engineer and I used this analogy:
An engineer is a guy who measures stuff upfront to create a plan of action (like measuring how much concrete we need if need a bridge to carry 500 cars). He never gets his hands dirty nor does he build the actual bridge. He has a ton of responsibility and must call on vast knowledge to know what patterns will be needed and if they will cope with the loads.
On the other hand, programmers are more akin to gardeners (my mom is super into gardening) and carpenters - we have to get our hands dirty and build the thing. We have to use and stay true to the spec (from the engineer above) as close as possible, measuring a piece of wood 3 times before we cut it (not the fail fast nonsense) and carefully plant new plants that won't kill the whole garden. We also need to pull out weeds and prune the bushes and so forth. With a bit of careful implementation you can have a gorgeous garden and bird/insects/squirrels visitors and so on.
Software Developers I would say, is then a combination of the above, depending on your experience you might lean more toward one side or the other. The best developers have a good balance of Knowing stuff and Doing stuff.
Engineering encompasses both. Does someone dictate literally every action of yours in great detail? No? You're an engineer and must exercise engineering acumen.
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.
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.
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.
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?"
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.
> 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.
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.
‘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.
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.
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…).
They exist in the US too. There ain't nothin' wrong with an EngD, it's a great terminal degree. But the Doctor of Engineering is not a doctor in the sense being discussed here. Why? Because the definition of a doctor is (or was) someone with a license to teach at an institution of higher learning. That's not the aim of an EngD, at least in the US and many other places: its goal is explicitly to produce an engineer who will use his knowledge in the real world.
The same thing goes for EdD, DPA, etc. These are professional degrees, not teaching/research degrees.
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).
I worked in manufacturing and there were P.Eng. holding mechanical and industrial engineers that held ASQ certifications on top of but not as substitutes for their P.Eng.
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.
It takes years to become a plumber. Plumbers have to hold a high school diploma, enter a trade program, begin an apprenticeship that can take up to five years to complete (required to be able to work as a plumber), pass a state exam and become licensed, and join a trade association. They have to follow codes and standards, and often work with other trades like architects putting together blueprints. Plumbers are business people, too; they have to get clients, keep up with them, get paid, and survive on their reputation. And for all that, they make on average $57k a year in the US.
We're artisan primadonnas who get paid three times that of a plumber, with literally no requirements to do so. There are people working at online banks who haven't completed high school.
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.
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.
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.
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.
The only formal specification of a software is the software itself. If there would exist a way to specify exactly what a program should do formally you wouldn't need the programmer: you already have the formal specification, can't you just compile that to executable code?
A formal specification doesn't make a lot of sense, if no sense at all. It's a waste of time and you will end up doing the work two times, one to write the specification and then to translate that specification in a real programming language.
The most difficult part of the job of the programmer is not into writing the code, it's into translating the informal specification from the customer to a formal specification in the form of computer code.
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.
> 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.
> 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".
410 comments
[ 0.18 ms ] story [ 299 ms ] threadI 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.
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.
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?
Is _all_ software development engineering? No, of course not. If you are banging out CRUD clone #432 then no, you are not an engineer, you are more of a technician (a programmer in our case).
But, consider this, could you design all of Google's infrastructure without applying engineering principles (most likely derived from computer science and computer engineering)?
Or perhaps you write and design complex embedded software to fly satellites, where you have to combine knowledge from multiple branches of science. Isn't that engineering?
The answer, as most everything else in life, is "it depends".
I guess because many of those who call themselves engineers are exactly those who bang out CRUD clone #423.
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.
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.
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.
> 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.
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/
We were discussing whether the average software developer can be said to 'do math' in the sense that aeronautical engineers do. I think it's plain that the answer is no. Whether it matters is another topic.
As I said above, in terms of market forces, it's fine that most software developers go their whole careers doing no proper math. It's also true that some highly skilled software professionals are expert in the relevant math.
As to Are software developers engineers?, I hope it's uncontroversial to say Some of them are, some of them aren't. What's less clear, and less obvious, is where the bar should be set. Personally I consider only a small minority of software development work to be anywhere near engineering, but like the article notes, I don't have experience in any 'conventional' engineering field.
Given that router-installation technicians are called engineers these days, software isn't alone in its collision with the word.
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
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.
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.
You say that as if software engineers determine the priorities ...
Isn't that the point?
As for how Tesla is structured, well it's Musk at the top who delegates everything and spends his time on Twitter trying to boost the stock price to hit his quarterly stock price goals. As for if they're managed by engineers, I have no clue.
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.
Correctness in itself is not a meaningful goal. If something works well enough to meet the needs of the user, being more 'correct' doesn't necessarily provide more benefit.
It's one of the things that Engineers got pretty good at, because people died over and over.
testing is not that important for a hacker but important for an engineer (although hackers do penetration testing).
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).
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.
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.
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.
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.
Being a good engineer is adopting the right combination of methodologies to fit the problem space.
Being a good software engineer means knowing what you should plan out in advance and what you need to test and design as you go.
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.
The trend of giving high sounding titles started decades ago as more and more educated people entered the workforce and involves all jobs.
Manager? Vice president.
Secretary? Executive assistant.
Developer? Engineer.
Reports and collects some data for his bosses? Data analyst.
Warehouse worker? Logistics and distribution specialist.
It doesn't have to always be self-aggrandizing for it to be true that lots of people are now called VP who used to just be middle-managers.
If not, then, at least in my mind, it seems difficult to pin down exactly how software engineering can occupy a space in the domain of modern engineering.
Some sort of specific liability in the legal code could make sense, though.
As opposed to learn about a type of algorithms, some math, some language or some pattern.
10 years latter, I’m glad for the exposure.
It was more useful to understand and talk to folks on the sides of the dev department : security, ops, qa, support. Heck, even product.
I felt that with those, the dev could monkey patch whatever together and still be part of some engineering process.
Now I don’t know. I sure do push code around.
In physical engineering, you really get one chance. If you make a mistake or miscalculation, there is a cost associated with undoing what's been done, as well as trying again.
In software, there is no such additional cost. You can trivially start from scratch, or any point between scratch and here, at any given time. There is no disposal cost.
Security breaches, locked in data (poor dB structure or no direct access) reverse engineering undocumented functionality, even just dismantling supporting infrastructure and migration costs are huge. Another huge factor is when business logic is codified and the knowledge is lost from the business and only temprarily held by transient consultants or developers.
An sap project for a single region for a $1bn per year company can easy cost over $10m and no software is being developed, only config, process change and data migration. Never mind increased staff turnover reduced productivity.
But very few people have the experience and expertise to understand what they are really signing up for.
Just think about a 3d model can do for a construction project and what that would look like for code and you can see how poorly we do this really.
(Make software actually be engineered)
That's without even considering all the kinds of rules-lawyering that would be applied afterwards.
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).
Engineering involves risk tradeoffs, and if your developers are not making your risk decisions then they are not engineers -- and also you're going to spend a lot more money producing software (the authority to do risk assessment should always be as close to the "in the trenches" work as possible, every degree of removal invites the risk decisions to be made on lower-quality more-aggregated more-gutfeel information rather than clear metrics).
Most of computer programming is instead tinkering -- build a proof of concept, put it under stress, see what is being stressed, buttress those parts. The fundamental idea of architecture, "let's add some structure in advance so that we can build a self-sustaining system and take away the scaffolding later," is only really seen today maybe in test suites or so? Those are the scaffolds of our day I think. We're still in very early years for computing as a proper engineering discipline. But at least we do make some simple risk calculations.
Most of mechanical engineering is still tinkering. Not all problems are solved. Many of the people here pining for "real engineering in software" need more interdisciplinary experience, ffs.
I can only speak from my undergrad experience, but almost every engineering discipline took the same background courses, as well as mechanical, thermal, fluid, and electrical engineering classes and from there, went on to take courses related directly to their field.
From my experience, tinkering is another way to say prototyping or building a proof of concept.
As we've gained experience, the need to prototype the same solutions decreases, but when learning new tools and methodologies, experimenting and prototyping is very much part of the engineering process.
We do not. Civil engineer is a specific thing, with training, education, and licensing. The person who designed the system being installed or serviced was likely a civil engineer, the plumber is a plumber. And that's ok, everyone doesn't have to be an engineer. Being an engineer isn't inherently better than being a non-engineer.
> an engineer as someone who uses fundamental principles and processes of science and engineering
Do you see how saying an engineer is someone who does engineering isn't useful to other people? I'm sure you know what you mean, but basically everyone is and is not an engineer according to your definition.
Or a plumber can just be a guy following a plan and cutting and gluing pipes together.
Yes. That is the joke (among non-civil engineers with civil engineer friends).
> Do you see how saying an engineer is someone who does engineering isn't useful to other people?
No. Because that is not what I wrote.
I also provided a concrete problem, along with an engineering and non-engineering approach to solving it.
This is the first I've seen this point in the discussion. Engineering is considered a profession, distinct from a vocation. The term derives from professing an oath to serve the public in an ethical manner. If developers had to take a similar oath, I wonder if it would open them up to civil/criminal liability when they acted unethically (e.g., creating code in a social media application with the goal of manipulating behavior for profit)
Every degree in my school's college of engineering was BS/MS. And I think something like 25 of 27 were "degrees in engineering".
If you want to go full circle, they are "degrees in engineering" because they're accredited by ABET, and satisfy the first requirement towards licensure and a PE.
There is no simple definition, which is the whole point of accreditation and licensing boards.
ETA: But if the programs in your hypothetical have an identical curriculum (and both are accredited), then yes, they would equally be "degrees in 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.
I don't think this is actually useful without strict definitions of what constitutes engineering. If I go to a homeopath who prescribes an herbal tea to cure my cancer are they "practicing medicine"? The law says they are not, and cannot, because of clear definitions of the term.
(FWIW, I don't subscribe to that notion of what "engineering" is)
>Economists don't call themselves engineers and engineers don't call themselves economists.
There are quite a few universities that offer courses/degrees in "financial engineering" and they often are in the mathematics/economics colleges and don't have a typical engineering curriculum as you laid out.
I think shat this article fails to note is this engineer light/technician class which tends to be the more hands on portion of "engineering" in the case of sw, they would be more light engineering more programmer less overall design. AKA your systems architect/principal enginner is probably doing "engineering" the software engineers are likely just programmers.
If you design pacemaker software, you're an engineer. If you build RESTful websites, you're not. I say that as someone who builds RESTful websites.
The reason engineers need difficult certification exams is, so they don't destroy lives or expensive property.
There was a programming PE (USA) at some point, but it was closed.
You can have the exact same curriculum and be called engineer or not be called engineer, depending on the university. You can even learn nothing related to engineering and have an engineer title, or the other way round.
I'm not saying you're wrong (especially the first part), but there's a lot more to it, especially in countries where 'engineer' is a protected name/profession.
Personal opinion: I don't care. My degree is "Computer Science", not "Computer or Software Engineering" and I see myself as a Software Developer (although I will allow programmer)
Some would define it differently as someone who has an engineering license. There are States who have actually presented lawsuits aimed at preventing people from describing themselves "engineer" if they don't have that license. And, while an engineering degree is the more common first step in the licensing procedure, it's possible for one to get a license without an engineering degree. In the legal sense, they are more of an engineer than someone with a degree and no license.
Regarding the plumber, I think the mechanical engineer who designs the plumbing system would be the engineer, while the plumber is the technician. Just like the electrical engineer designs the system but an electrician installs it. Both roles are equally important but shouldn't be conflated.
That just describes problem solving.
On another tangent, I wish we’d redefine what it means to solve engineering problems. I have noticed that there’s this property of engineering that as problems are solved, new ones are created. So it’s this never ending cycle of new problems blossoming.
In terms of creating new problems, making life better is an under-defined, open-ended problem. There’s always a lowest-hanging fruit, that doesn’t mean we should stop picking them.
What if their solution is non-technical, still an engineer?
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...
This is a fantastic definition.
It shows very clearly why most software devs are not engineers. I know I'm not.
As a field, we don't "optimize within a solution space bounded by constraints".
We throw crap at the wall to see what sticks, hacking up something like what the users said they wanted, then changing it all to do what they ask for once they start using it.
It's normally done as a craft where we're using fuzzy human instincts to get to a good-enough solution and move on.
And for systems where lives aren't on the line, nor millions of dollars every five minutes (financial trading, massive server farms at Google, etc), that is actually the correct tradeoff. Engineering is overkill for most software.
NASA needs software engineers. Microsoft doesn't.
Even Google and financial services are really just services that scaled and acquired a massive userbase.
“Software Engineering” is really just an application of civil engineering project management to programming projects. The job title of software engineer is used too liberally however.
To me, the difference is that when we're writing software and just trying semi-random UX ideas and implementation approaches out, we don't have any real constraints that we're genuinely bounded to.
So, yes - throwing crap afu the wall is an optimization process.
It's the other half of the above definition that it misses, IMO.
I'm not great at typing on my smartphone.
Microsoft needs a _few_ software engineers.
Most of their developers won't be and shouldn't be, though.
Conversely, NASA will have plenty of software systems that have nothing to do with spaceflight, like their website.
They shouldn't be paying software engineers to engineer those systems, but rather software developers to build and maintain them.
That's just regular old optimization. There's no point in optimizing anything that doesn't have constraints, because there aren't any bounds.
Edit: I think you're conflating unbounded and unconstrained.
By that definition, almost any profession - from surgeons and taxi drivers to construction workers and cooks - are all doing "engineering"?
By the definition given - "a process of optimization within a solution space bounded by constraints" - a taxi cab driver is certainly an engineer, with no fuzziness. Nor would it be an extreme case testing that fuzzy borders of that definition.
And that's why herval disagrees with that definition. As do I.
Definitions can also be overly broad, which is why we no longer use the term "star" to refer to planets, nor refer to the sun and moon as "planets". https://en.wikipedia.org/wiki/Definition_of_planet .
Otherwise engineer is just a title too, so I guess it is mostly meaningless?
AND...
If need be reduce it down to the underlying science and mathematical principles from which it came from, and because of that can analyze why things are "good" or "bad" at a much more fundamental level.
Practitioners/Crafters are repeating "recipes" with far less comprehensive knowledge of the principles that led to those recipes. They may know historical evolution and practical reasons why one recipe is better than another, but their depth of knowledge is far less.
So getting back to software, you can see two types: people that know algorithms and can mathematically design and analyze problems. Or you have people that are just following the api docs and basic examples of loops + if-then but don't know how CPUs work inside, how OSs work, and why.
And do you need full engineers for a website layout or ruby on rails site? No. But if you are scaling or have complex data models or will have actual load, then ... you need engineering.
An engineer is a guy who measures stuff upfront to create a plan of action (like measuring how much concrete we need if need a bridge to carry 500 cars). He never gets his hands dirty nor does he build the actual bridge. He has a ton of responsibility and must call on vast knowledge to know what patterns will be needed and if they will cope with the loads.
On the other hand, programmers are more akin to gardeners (my mom is super into gardening) and carpenters - we have to get our hands dirty and build the thing. We have to use and stay true to the spec (from the engineer above) as close as possible, measuring a piece of wood 3 times before we cut it (not the fail fast nonsense) and carefully plant new plants that won't kill the whole garden. We also need to pull out weeds and prune the bushes and so forth. With a bit of careful implementation you can have a gorgeous garden and bird/insects/squirrels visitors and so on.
Software Developers I would say, is then a combination of the above, depending on your experience you might lean more toward one side or the other. The best developers have a good balance of Knowing stuff and Doing stuff.
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.
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.
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.
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?"
"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.
This makes my day!
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.
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.
Just like software engineering is the application of computer science.
It’s the truest definition I’ve been able to think of.
Engineers design and create, physicians fix problems and do maintenance.
‘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.
Actually, a Doctor of Philosophy is the only real doctor.
Non-phd doctorates I'm aware of would be MD, Psy. D, JD.
The same thing goes for EdD, DPA, etc. These are professional degrees, not teaching/research degrees.
It's interesting how the traditional standards bodies are adapting to the new tech.
It's not equivalent to a software engineer in Canada: https://www.egbc.ca/Registration/Individual-Registrants/How-...
This may be different in other countries.
I worked in manufacturing and there were P.Eng. holding mechanical and industrial engineers that held ASQ certifications on top of but not as substitutes for their P.Eng.
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.
Will I? So far I haven't...
(I'm in the US, though, and from your comment history I think you might be in the UK? Does it differ between countries?)
It takes years to become a plumber. Plumbers have to hold a high school diploma, enter a trade program, begin an apprenticeship that can take up to five years to complete (required to be able to work as a plumber), pass a state exam and become licensed, and join a trade association. They have to follow codes and standards, and often work with other trades like architects putting together blueprints. Plumbers are business people, too; they have to get clients, keep up with them, get paid, and survive on their reputation. And for all that, they make on average $57k a year in the US.
We're artisan primadonnas who get paid three times that of a plumber, with literally no requirements to do so. There are people working at online banks who haven't completed high school.
Unfortunately not something with the same value everywhere.
I personally call myself a programmer, even if my job title says engineer.
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.
> 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.
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.
A formal specification doesn't make a lot of sense, if no sense at all. It's a waste of time and you will end up doing the work two times, one to write the specification and then to translate that specification in a real programming language.
The most difficult part of the job of the programmer is not into writing the code, it's into translating the informal specification from the customer to a formal specification in the form of computer code.
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.
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.
https://en.m.wikipedia.org/wiki/Isambard_Kingdom_Brunel
I won’t link Elon Musk.
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".