As a software engineer, I never understood this stance.

Engineering is composition. Engineers look in books to figure out which existing construction technique to use for building the bridge. They're there to ensure there is a bridge still standing in a year, and the best way to do that is composition. That requires knowing the tools, techniques and QA requirements, which is what software development is too.

They don't invent new materials and designs. That's what doctors/researchers and architects do. Or computer scientists in our case.

That's a weird definition of engineering. I think you are confusing implementation (construction technique) which is of course valuable, with the more general principle of designing in safety margins, redundancies, and tolerances for specific loads/forces. This is a lot of applied math.

But there's a difference between "I have learned how to use applied mathematics to design a specific physical deliverable while ensuring safety margins and tolerances" and "I am contributing to the state of the art in the general theorems used by my entire industry." Some civil, chemical, mechanical etc. engineers do both! But most engineers spend most of their time on the former.

And what is software engineering but exactly that dynamic? Relational algebra and distributed systems design are most certainly based on applied mathematics, and one uses tooling built around the underlying theorems to ensure that parts mesh together in a reliable way that scales under load. Some engineers take their learnings from specific projects and write papers, and that's amazing, but that doesn't mean that if you don't have an Arxiv account you're not an engineer.

We're not just fire-and-forget script writers; we're engineers and we draw on decades of an industry's worth of deep knowledge to ensure our systems are rock-solid. I hope everyone who considers themselves "just a software developer" finds a team that appreciates this.

Those safety margin and tolerance calculations are based on existing models (what I called "tables"), combined to form a new whole. What I would call composition.

Whether math is being applied doesn't seem like an important distinction to whether something is composition or not. I reason about computational complexity when I build distributed systems, just like civil engineers reason about tolerances. But I'm still assuming a best-of-class sorting algorithm and a reduction of some domain problem into a shortest-path algorithm. The same they do about I-beams and spans.

The same thing can be said about "computer science", perhaps to an even greater degree. Anyone who comes even remotely close to performing CS almost certainly isn't using anything resembling the scientific method, and the difference between engineering and applied CS is blurry to say the least.

Maybe the vast majority of us are just programmers making the internet go.

Calling it a science does seem to have been an odd decision. It looks more like a branch of mathematics, from the outside at least.

Engineering... I dunno. The digital realm doesn't seem, to me, to have enough of a split between "design" and "actual device," so we can't really split the job into the engineer's task and the manufacturer/builder/etc.

One annoying thing about this the whole "software engineering" discussion is that often casts the engineers as gatekeeping or being snooty and not wanting to include the programmers. It just seems like a different type of job, though, still perfectly respectable and decently prestigious. Nobody gets angry that we can't be called "Software Chefs" or "Software Conductors."

> It looks more like a branch of mathematics, from the outside at least.

It was a branch of mathematics!

https://en.wikipedia.org/wiki/History_of_computer_science

> Anyone who comes even remotely close to performing CS almost certainly isn't using anything resembling the scientific method, and the difference between engineering and applied CS is blurry to say the least.

Actually that's one of the things Sussman noted about modern software development: that you have to "perform basic science" on your framework and library code by running experiments, rather than building up things from first principles.

So maybe computer science will become a science, after all!

I suspect that software engineers are not the only engineers who spend most of their time on tasks that you wouldn't classify as engineering.

Agreed. It feels like fitting pre-cut puzzle pieces. Reading code/documentation has become the most important skill.

The amount of working software engineers who don't understand basic things like paging or the TCP/IP protocol or file systems is unnerving.

What could be the reason though? Too much abstraction these days? I have worked with experienced devs that have a background in Computer Science, who don't grasp basic concepts (especially when it comes to computer networking). Could it be that the emphasis in current CS education is more on theory rather than application in the real world? These days, there are more Software Engineering curriculum style studies popping up at Universities that get rid of the hardcore academic CS fluff you'd only need if you plan to stay in academia, and focus on real world applications. Perhaps that would help more.

theres too much stuff to memorize nowadays... its getting more complex every decade. e.g. If you have to load up in your brain XYZ security details about a certain cloud provider, and also understand caching, scaling, load balancing etc in a cloud environment, why would the person actively keep their 'OS paging' knowledge fresh the mind, its wasted real-estate. maybe certain developers with photo-graphic memory can do it, where they never forget _anything_ they learn. but most developers I work with have forgotten what they haven't used in 5-10 years

My point is that many software engineers don't really understand things you mentioned: load balancing, caching, scaling, etc. in depth and proceed with a high-level understanding to use tools that implement the low-level logic without fully understanding it. I'm not saying it's all of them but a significant number of them use the black-box approach.

If you haven’t already, you should read the crossover project by Hillel Wayne in which he interviewed a bunch of engineers that became software engineers. It’s really good. https://hillelwayne.com/post/are-we-really-engineers/

I can't agree with that and think it's too simple of a declaration. I have seen very high level code that is well architected and follows engineering discipline. Whatever is underneath it is no different than what separates an ICE and the buttons you click to change the tune of the engine.

Engineering involves designing within constraints. That's not a thing that makes software "engineering" different.

https://www.teachengineering.org/populartopics/designprocess

It's a mix of composing and plumbing. I wouldn't call it architecting unless there were enough degress of freedom that weren't locked down by earlier choices and designs are over quite coarse operations.

What do you call architecting?

It's akin to an elementary school craft project as well. "When in doubt, use more glue stick." UI design ends up being cutting out more and more interesting shapes from construction paper.

There’s the term software craftsmanship which comes a bit closer to the truth.

So maybe “software engineer” should be deprecated in favor of “software craftsman^H^H^Hperson”. ;)

Writing, perhaps?