Hacker News Reader

Comment by Tossrock | Hacker News Reader

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.

View on HN

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.

It’s a simplistic definition. Since the topic of calling developers engineers is rather superfluous, I think we should go for simple definitions.

I can think of many simple yet incorrect definitions. They have as much utility as this one.

Also there are people without any degrees that do far more engineering than many developers who hold software engineering degrees.

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.

Upfront design is one of the methodologies of engineering but so is trial and error.

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.

As he says in the article, many engineers in the past had neither a degree nor a certification. And they were certainly building "real things".

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.

An engineer doesn't just wing it because they're "really great" at it.

I don't know what part of "optimize for a large range of conditions" sounded like "wing it". You can't do that by winging it.

Projection, probably. ;)

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

In some countries some profession names are reserved. There you know that a doctor is a doctor, not a guy who went to a hygiene bootcamp.

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.

If engineering is applied science with gatekeeping, I'm frankly not interested.

Some sort of specific liability in the legal code could make sense, though.

Isn't the gatekeeping standardized verifiability and liability? Those are sorely needed in a lot of software endeavors.

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.

Now I don’t know. I sure do push code around.

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.

In some ways physical engineering is more forgiving. Consider the cost of a security breach. A bridge can be rebuilt, but data cannot be unpublished.

The people who were on it when the bride collapsed are pretty tough to restore from tape...

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.

If Iec 61508 was applied to all software that would also do it.

(Make software actually be engineered)

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.

I don't think so. Software engineering, and by extension, software engineers became a thing in the 60's. Margaret Hamilton coined the term ~'63.

> So a plumber is an engineer

Yeah, we call them civil engineers.

In the US, in order to be an engineer one either had to have a license to call themselves an engineer, or a company could confer that title to employees. These days, it's less about the specific education, and instead the process of solving problems.

Engineering is a discipline which may be applied to many domains, including software. I define an engineer as someone who uses fundamental principles and processes of science and engineering to solve real world problems.

Our customers need to ask a skilled expert a question and receive an answer.

If I merely implemented code to achieve this goal, I would not consider that engineering, but rather coding.

Instead, if I first defined the problem statement, gathered requirements, documented assumptions, broke down the problem into discrete deliverables, defined metrics and success criteria, and created a plan of record, that would be engineering.

I have a formal education in engineering, and aside from the mathematical and science fundamentals required for engineering, a large portion of my education was dedicated to the process of solving problems (also proudly, a good portion was dedicated to learning about ethics as well).

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 call them civil engineers.

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.

A plumber with enough experience can do engineer-y things, e.g. design an appropriate plumbing system for a house or renovation.

Or a plumber can just be a guy following a plan and cutting and gluing pipes together.

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

> We do not. Civil engineer is a specific thing, with training, education, and licensing.

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.

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

>an engineer is someone who does 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)

In the same way that a professional is someone who gets paid, yes.

a plumber is actually a civil engineer, and I doubt one would get a degree for plumbing...

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.

I agree with almost all of your point, but a small nit pick:

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

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.

I'm with you on this. My personal definition of an engineer involves designing systems that can potentially kill humans or other creatures.

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.

Actually I believe the term "software engineer" was coined by Margaret Hamilton while at NASA in the 1960s. Her Wikipedia article has some relevant quotes and references: https://en.m.wikipedia.org/wiki/Margaret_Hamilton_(software_...

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)

I have studied computer science and have a master of engineering.

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

> it's a process of optimization within a solution space bounded by constraints

That just describes problem solving.

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.

I would definitely say anyone who cleverly solves technical problems is an engineer.

Now we just need to define "solve", "cleverly", and "technical".

What if their solution is non-technical, still an engineer?

> it's a process of optimization within a solution space bounded by constraints

By that definition, almost any profession - from surgeons and taxi drivers to construction workers and cooks - are all doing "engineering"?

Categories are made up and don’t exist at the end of the day. Even the difference between marketer and engineer can be fuzzy.

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?

Literally all categories describing real-world phenomena are fuzzy at their extremes. Reality itself is fuzzy at extremes

Then what job isn't 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 .

You are right. The output they work towards is a longer lasting item (system).

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?

What's the difference between a lightweight engineer and the other kind?

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.

Which other fields of engineering are "lightweight"? Industrial? Chemical?

No, I guess it is only applied to computer science. Most people sort it more towards math than 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.

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

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

I think "drawing sharp category boundaries is a losing game" is as close as we are going to get to a clear lesson, here.

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.

> I think the best definition of engineering is that it's a process of optimization within a solution space bounded by constraints.

This is a fantastic definition.

Optimization? "An engineer is someone who can do for 10 cents what anyone could do for $1."

It is.

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.

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.

But what is numerical optimisation if not throwing crap at the wall to see what sticks? Do you only count analytical optimisation as optimisation?

That's a good question.

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.

...crap at the wall, sorry.

I'm not great at typing on my smartphone.

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.

Yes, that's a good point and I overstated.

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.

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.

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.

> a process of optimization within a solution space bounded by constraints

That's just regular old optimization. There's no point in optimizing anything that doesn't have constraints, because there aren't any bounds.

this is wrong. unconstrained optimization is done all the time. One quick and easy example is mean-variance optimization.

Edit: I think you're conflating unbounded and unconstrained.

Reply on news.ycombinator.com