an engineer is more like a plumber than an inventor though.

you don't need to design a new type of screw to make a one off aquaduct, you don't need to design new bearings to make a gear box, you don't need to design a new opamp to make an amplifier, nor do you need to design a new MVC framework to make a one off CRUD app.

You use off the shelf parts and combine them with your knowledge and skills to produce and effective solution for your constraints. If you can't do it with existing stuff, then you design something new that can do it.

The point is that for most things, there were no such off-the-shelf parts in software engineering until recently. You had to invent each screw and bearing yourself, because you couldn't just order a bunch of screws and bearings. Nobody sold them.

Moreover, the difference is that today's technician-programmers don't know how screws and bearings work at all. The engineer who uses prefab screws and bearings still understands them in detail and knows when to deploy them and when not to. Rather than understanding what bearings are for, the technician-programmer has a problem X, reads a blog post that says, "I solved Y by adding some bearings," and thinks, "gee, X is similar enough to Y that adding some bearings may work."

They add some random bearings, some screws, some cams and driveshafts here and there, without any deep understanding at all of why you ought to use these things in a design... and over time build a Rube Goldberg monolith with 10,000 moving parts sticking out randomly that nobody actually understands at all, so as a result everyone is terrified to work on any part of it for fear of inadvertently breaking the other 60 hidden dependencies of that piece.

Bravo. Saving this comment.

For substance: Consider how this is all part of the effort by management to make programmers feel as interchangeable and insignificant as possible.

And it's not even in the name of quality. Plenty of software out there breaks because of its multiple single points of failure in the form of dependencies.

Yes, totally. I can understand why management does this. Coders have a very high turnover rate as a profession. When your genius Clojure or Rust programmer leaves, it's much harder and more expensive to find a replacement than when your PHP or Rails programmer quits.

This then incentivizes new coders to take up one of the popular languages, because that's what most of the advertised jobs are for, creating a self-reinforcing positive feedback loop.

The thing is, it actually doesn't matter. No one needs to be a certain way. Cool things will be done by people that can and will do those cool things. In the end the prescriptivity of this whole space is only ascribed by people internal to the whole system: externally nothing is 'supposed' to be done. This is just a symptom of more people programming.

The thing that will speak the loudest is actions and results. If people don't like depending on modules, don't. If you do, do. Eventually everything will be lost and forgotten like teardrops in the rain.

This "that's just like, your opinion, man" attitude may be fine if you have no worldly goal affinity and are planning on spending the rest of your days in a remote mountain monastery. If you don't care about achieving any particular goal, then yes, all possible attitudes are equivalent. But that sort of handwavey quietism is not actually relevant to almost all people's situations.

If you do have specific short term goals -- such as, say, "building a profitable software product before we run out of money" -- then all methods of approaching the task are demonstrably not equal. Some will work much better than others in terms of achieving that goal.

We can study the empirical results of the numerous attempts already made by other people and thus avoid repeating their mistakes.

This makes sense. But I don't think the two are mutually exclusive. I think goal-motivation is different from goal-attachment. Being attached to "I will do my best to make x happen" rather than x itself focuses on actions and growth (within realm of control) than consequences (often outside of realm of control). Like a product failing because people are just not into it.

I think we can avoid those mistakes but what I see here is people telling other people what to do in a way that sounds unconditional: "x is better regardless of your situation." Some techs are better for x, other for y. Merging someone else's experience tree into your own is good, but it must be contextualized by their perspective--they're working on mobile embedded soft vs. you are on web, maybe, for instance. Or games vs. databasey things. Or their job is a performance engr but you are UI...

What would you recommend to a junior CS major to avoid falling into this pattern?

Specialize. Pick a subfield of CS that you really enjoy, that really resonates with you -- machine learning, NLP, algorithms, whatever -- and become an absolute expert at it. Know your subfield inside and out.

Start thinking about what specialty you want now, today. Do some research, talk to professors and other students, etc. By the time you are a senior, you should know what you want to specialize in and be well on your way.

Then, you can get a job that actually requires deep knowledge. Since you actually care about this, you'll quickly become bored and frustrated if you take a standard startup code monkey job where you are expected to write Rails or PHP code all day, but then that's the only experience you'll have. You'll also be competing with less well educated programmers who are willing to work for less.