Having done the EE curriculum and then gone to program instead (to make my bias apparent), IMO the engineer’s distinction is that they work in a model, the bounds of the model are well known, the model isn’t all of physics, and the model is simplified enough that work can be checked within it. The brilliance of engineering is that you can do productive work, on hard tasks, without being brilliant.

Rigour in these industries appears to be just "build broken stuff slowly then blame someone else".

The primes are expensive not because they're rigorous but because they're good at government contracting. They're going to get outcompeted soon. SpaceX and Tesla have shown that there is an opportunity in government contracting. Now, newer organizations are going to be "rigorous" in their own ways.

Do you have any evidence for that claim? (And don't point me to the two Shuttle explosions. Neither of those were a software failure.)

Also you can go to computer science conferences such as ACM conferences.

Unfortunately, when I was in undergrad, my school and other schools didn't understand that most incoming students needed "software engineering" instead of "computer science." Although there is a lot of overlap; misunderstanding the intention and purpose of students made it very hard to learn the skills we were there to learn.

Whatever you decide to call these two things anyone who has onboarded a new grad/intern has observed this distinction because its a different skill set.

It takes a long while for you to be able to go from fuzzy feature request to fully fledged product, people without experience need A LOT of handholding to be productive and that is fine, no one is born knowing everything and if you're going to hire people without experience you should EXPECT to invest time in training them.

I worked on a small team at a government contractor that never used version control and deployments were an rsync from the lead engineer’s laptop to the cloud, this was in 2020.

There’s a lot of industries like bioinformatics or journalism where there’s people who are adept at writing code but who are not doing software engineering.

In the same way that being able to play on a little league baseball team and being able to make it to the majors are different skill sets.

Which is to say that it is the same essential skills, just varying degrees of proficiency.

So while your experience in carefully crafting a viable design and erring on the side of caution would have been appreciated decades ago, it's just not the nature of the game today. Just take heart that your approach is that of a true engineer and not someone who will cheapen their work by slapping on something that works in a sandbox type of env.

Actually I think the article is using modern terms, but seems right.

From what I remember from the early days, you had "System Analysts", "Programmers" and "Key Punch Operators". Key Punch and Programmers were considered Low-Level and was not paid much more the the US average salary, Programmers a bit more than Key Punch people. System Analysts was where the money was. But seems during the 80s, the 3 jobs merged into one.

By then, I use to program and work directly with the Business in the 80s and 90s. Sometimes the Business person would be sitting next to me while I showed then the changes and how it worked. Changing the program based upon their comments while they were there. Fun times, and yes even did this directly in production :)

Then it seems in the late 2000s, they started to split again giving us Business Analysts (BA) and Programmers (Coders).

The people who write code in the demo scene traditionally call themselves 'coders', and those are pretty much the best of the best (and quite a few 'proper' software engineers among them).

You see similar with cook versus chef. I'm sure the same distinction exists in near any work where a surprising amount of what needs to get done is far more mechanical than people admit.

It doesn't help that it is often loaded with loaded nonsense about worth.

Now, agreed in startup land junior members are responsible for design more than people ack.

I like programming because it’s easy to ignore labels and just look at output to see if they are terrible or decent. Takes some time to distinguish decent or great, but it’s easy to see if someone is just horrible.

I’ve never cared if I’m programmer or coder or developer or engineer. It’s not like there’s legal differences like medicine or law (some places do have engineer labels, but no states where I’ve worked). I really care about ability to make an impact and compensation. Some of the stupidest titles I’ve had were most interesting work.

It seems odd to try to pick the right term as even for recruiting it’s probably better just to state the label, duties, and skills required in order to attract people.

the focus of TFA is much more on how there used to (at least) two distinct tasks which got different names (and had socio-economic and gender implications); following the development of "automatic programming" (what we would call compilation today), this distinction went away, but the two terms stuck around.

From what I understand, the work of a licensed engineer is not much different from that of unlicensed engineers, it's mostly a liability and compliance thing. That's not a dig at licensed engineers, by the way. Being legally liable for your engineering work translates to requiring more rigor and attention to detail than it would when you're not on the hook for failures. One of my professors in college was a licensed engineer. He said it was a colossal PITA to maintain his license, so he let it lapse.

  1. Software architect
  2. Software engineer
  3. Programmer
  4. Coder

When you go higher, you have the more elite "programmer" who does the exact same thing as the coder but is more elite because he calls what he does "programming" instead of "coding"

The next level is the Software Engineer who is even more skilled then the programmer because although he does the exact same thing as both the coder and the programmer he calls what he does "engineering" which he deems equivalent to what rocket engineers do when they "engineer" a rocket that flies into space, but instead of a rocket it's some website. Keep in mind that as amazing as rockets that carry humans into space are, it is not as amazing as some plain website because these "software engineers" likely get paid waay more then rocket engineers.

The final, highest level is the software architect who's power is so high he doesn't even "code", "program" or "engineer" stuff anymore. Instead the software architect has the skill of "big picture reasoning" which is the skill of being able to draw boxes and circles on a white board and also drawing lines between those shapes. This is what we term "software architecture" and this is the epitome of software skill. The software architect is basically a god among software engineers.

My goal in life is to become a master at drawing circles and boxes and lines. I admire these people so much.

Not all software engineers write websites. I don't understand where in the lexicon this distinction has been lost. Also, there's a wide variety of website, some of which are just user interfaces for very complicated services.

Apparently it is also the case that not all HN commenters can spot a blatant joke.

Who cares? What difference does it make?

These guys aren't called software engineers. Like I said above, we refer to these people as "coders". "Software engineering" is mainly about making a website like petsmart.com or facebook.com.

Oooh. I see what you're saying. But these people aren't called software engineers either. They're called "programmers".

>These are engineering heavy challenges and absolutely software engineering. This is exactly what I'm talking about... no one sees the invisible software that rarely ever fails. Yeah, petsmart.com has errors, but it's incredibly unlikely it's due to a routing stack software failure (failure, not misconfiguration).

Software engineering is about solving problems. For example the problem of attention was solved by people on tik tok. Or the modern dating problem was solved by people who work on tinder. These are what I term "real" engineering problems. Something like CAD software or OS's are more ephemeral stuff that nobody ever thinks about so these kinds of things relegated to programmers or coders.

While typing this comment, I hit a bug in my browser? phone? not sure which, but anyway, in the year of our lord 2024, showing an onscreen keyboard at the appropriate time is not yet a fully solved problem. Such is the rigor of our “engineering” discipline.

> The final, highest level is the software architect who's power is so high he doesn't even "code", "program" or "engineer" stuff anymore.

Why drive when you can be driven?[0]

> My goal in life is to become a master at drawing circles and boxes and lines.

A previous employer sent me to a multi-day whiteboard training class once. I’m not sure if they were really stupid, or if they just thought I was really stupid[1]. The people running the class were exactly how you would expect them to be.

0 - https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

1 - at least it wasn’t just me they sent, but also a few hundred of my coworkers.

Predating software touch keyboards, I await:

1. The ability to pay for something on the web without a reliably posted critical reliance on not hitting the back button.

Someone should document the 5-why’s to a solution. (It might have ”stacked” up to 50-why’s at this point.)

2. For Apple TV to consistently fill in the about-movie blurb & pic (a few kay?) at better performance ratios than 1:1,000,000 relative to the speed & latency of the associated preview & video streams (geebees and also geebees).

Did you know the casual verbal abbreviation of kilobytes is a tribute to Alan Kay, inventor of the first working ten-bit address register? /h

These are my two long-time favorite canaries for some hoped for future deep software engineering progress.

In the meantime, I try my best to laugh a lot and be grateful for what we have.

Bingo. The (very American) dilution of the title "engineer" has been sad to see.

“Developers” create value, I.e. they “develop” raw things.

Not necessarily further up the skill mountain, but managing more of the economic to technical, back to economic, process stream.

So maybe it’s a more encompassing general term, rather than a skill or activity pole position?

What if it's embedded software that goes into, for instance, a rocket? Engineer?

Or mechanical engineering that goes into a door knob. Engineer still?

Reminds me of sitting in a draft paper review in my adviser's research group in graduate school when his final advice to the authors was "and you need to add a figure with boxes and arrows in it"

Find me a rocket scientist that could implement an unbounded model checker.

Of course not! Software engineering is waaaay harder than rocket engineering. That's why there's so many rocket engineering bootcamps all over the place. Just grab some book or join a bootcamp and you can build rockets that fly into space in less than 6 months!!

That's what I did, I was a major in poetry and I worked in HR. Then I joined a online bootcamp for rocket engineering and became a rocket engineer for spaceX in less than a year! I got super bored with it and I wanted to try software. When I did the switch to software engineering I couldn't find a single bootcamp in the country. You have to get a PHD in software architecture in order to do this stuff. Super hard! I'm now an expert at drawing lines and circles!

There aren't, because the demand for space rockets is very low and they're extremely expensive.

Software isn’t like this hence why boot camps are more possible. Advanced concepts in CS aren’t practical. Automata theory? Not needed. You literally don’t even need a bootcamp for software tbf.

They're at least as practical as rockets that go into orbit.

And software is absolutely like rocket science in that you need to learn a lot of foundational stuff to do the really advanced rocket science.

If you want to do very basic model rocketry then the barrier to entry is pretty much as low as learning Python or whatever.

Places where somebody does architecture without programming are dysfunctional (anything takes forever).

Understanding why there even were two terms is actually quite interesting, and of value for all those pontificating on what they think current use of these terms ought to be.

In present times, the complete road map is something like this:

coder -> Programmer -> Developer -> Engineer (Analyst) -> Architect

More like:

    Programmer ─┬──→ Programmer
                │
                └──→ Project Manager

It is a bit of an interesting observation though. One of the main distinctions that come to mind when thinking of engineers is that typically they belong to professional societies with ethics codes that would seem to preclude working on some of these user-screwing features, if taken seriously.

https://brajeshwar.com/2007/are-you-a-programmer-or-a-coder/