I work as a swe in a company dominated by EEs and civil engineers, and while you’re not wrong in theory, the author’s point resonates a lot with me.

Civil engineers mostly plan ahead and try to follow that plan, and having to adapt to too many unforeseen issues is a sign of failure (which is not surprising, since planning is a small fraction of the cost).

In software engineering, the opposite is true: large big-design-upfront projects are usually a trainwreck.

In my experience, it is pretty hard to explain the difference to civil engineers that evolved into leadership.

In SWE, software is the plan.

Anything before that is drawings on napkins.

Yes, that's the point. The planning stage takes months to years, while the building stage takes seconds to hours and doesn't require any labor.

There are no other engineering areas with a similar ratio. And yet, SWE planning and design does look like planning and design on any other area.

> [complexity...] Author seems to imply that this is something unique to computing.

The unique part of computing is that complexity can grow way higher and faster than complexity in physical based engineering because it does not suffer from physical limitations and all the NN relations between pieces of shared code and data grow out of hand quick.

Creating something complex in physical realm is hard, and it essentially means doing more work to make something complex rather than simple. The common challenges are rather often about fitting the achieved complexity either in a small physical space (like an engine bay) or building it all out into large installments that look complex (like a nuclear plant). Yet many things in physical based engineering aren't inherently* hard but it will be hard to make it all into something that both fits in a practical enclosure and actually works reliably in practice.

But creating something complex in the realm of compute is rather the default offering. If you just put things together into a program then, in the classic rookie intern fashion, very soon you have something that mostly actually works but is implicitly so intertwined that nobody can understand the resulting interactions and can no longer start depicking the mahjongg of corner cases. Senior-level software engineering could actually be said to be primarily about managing complexity and whatever remains left after that effort can be used to build products and develop the trade. The reason we love abstractions is that they reduce complexity and make things manageable at all. There would be no progress in software engineering without abstractions.

If you were building an analog circuit that is, complexity-wise, on par with writing software systems you'd basically have to write software to design the circuit in somewhat manageable way. That's how software itself is written.

It's both the ego and arrogance of the software developer.

Like there's like nothing on people management in orgs. Like treating engineers like robots as though they'll unquestioningly follow what the author prescribed.

This criticism strikes me as lazy: it zeroes in on some casual introductory remarks made by the author which are intended to serve as a general guideline or frame of reference for understanding the concepts which follow, then invents a premise which is not in the article (that engineering doesn't contain discovery) and uses that to falsely demonstrate the weakness of the rest of the article.

How can you read this article and your takeaway is that "the author is arguing that engineering does not have abstraction or discovery"? How can you read this insightful article and think "this is extremely poor understanding" because the author does not discuss how "all engineering is full of discovery" when that is not even relevant to the topic of the article? Clearly their point is that engineering does have discovery, and they give examples specifically from the domain of software engineering.

If you think that discovery in all fields of engineering is an interesting topic, go ahead and write your own article about that topic. Show examples from plumbing, electrical engineering, and material science. It would be fascinating, it really would be! But that is not this article, nor is it at odds with what the author of this article is saying.

It's difficult to write an article like this. It takes time and consideration, organization and work. Nit-picking generalization which are not core to the argument of the article, on the other hand, is easy. Anyone can do it.

Every engineering discipline has its own flavor of discovery, especially when you're working near the edges of what's known or what's been done before