[warkdarrior]

> Treating devs like they are on a production line building cars is backward toilet sitting behaviour.

Citation needed. At this point in time, unless you are doing groundbreaking work writing/using new software, most software engineering is really like routine factory work ("combine SDK A with library B, then plug in component C and connect to service D") and should be measured as such.

[yihtserns]

"...combine SDK A with library B, then plug in component C and connect to service D..." is "really like routine factory work"?..

What kind of "routine factory work" you've been doing?

[nine_zeros]

> Citation needed. At this point in time, unless you are doing groundbreaking work writing/using new software, most software engineering is really like routine factory work ("combine SDK A with library B, then plug in component C and connect to service D") and should be measured as such.

Citation needed.

[RHSeeger]

This was my first thought. I don't think I've ever worked in anything "ground breaking", but I've never had work that was just "connect A to B with no thought". I mean, even if it _is_ connect A to B, you still need to consider

- Is the client (internal, external, whatever) asking for what they really want?

- Is the client asking for what they really need?

- Am I correctly understanding what the client is asking for?

- Does building this make sense for the product as a whole?

- What As and Bs can accomplish what I'm looking for (assumes they exist, per the initial assumption)

- Of those As and Bs, which ones won't run into conflicts with the project

- Of those As and Bs, which ones are well supported

- Of those As and Bs, which ones are likely to continue to be supported (long enough for our needs)

- Of those As and Bs, which ones mesh well with the current coding/development style of the project (maintainability)

- How can I best use A and B in a way that is easy to understand (maintainability)

- How can I best use A and B in a way that I can test my code without having to write 1000 lines of mock (maintainability)

- and the list goes on and on and on

Unless you're a VERY low level developer, most software development requires a large amount of thought, both analysis and planning. It is very much _not_ like routine factory work.

Heck, I spend a fair amount of my day not even looking at my screen, as I ponder how best to solve "easy" problems.

[Clubber]

He's role playing the manager role in the article, hopefully sarcastically.

[poincaredisk]

How does "fixing a tough bug for a week" fit into the factory analogy? What about "designing a new feature by drawing abstract diagrams"? These are examples taken from the beginning of the article.

[ActionHank]

If this is the type of work you are doing, your job is 100% going to be replaced by AI.

[atoav]

This is naivity on "cryptobro"-levels.

If security, reliability, performance and maintainability matter (and they do, always) you need to plan your software to be data-centric. I don't see how plugging together a few libraries solve that for you. Btw: external libraries are written by developers as well. And your developers have to not only read that code and documentation, but consider each of those a liability and a future maintenance issue. Most software engineering isn't bolting libraries together, most software engineering is about knowing how data is stored, how it is flowing, how much risk is involved with using which dependencies, who has access to what if they exploit any given section of code, and much, much more. That is why only morons think no-code tools can replace capable developers: the hard bit isn't writing the abstract cryptic text — that is in fact the easy bit — the hard bit is not shooting yourself into the foot as the complexity grows and finding a solution where all the above mentioned qualities are not in conflict with each other.

Do you work in marketing? Cause your stance would make me think your shop is a bottom-of-the-barrel bordering-to-fraud el-cheapo software house that customers instantly regret to having worked with. This is at one level with the infamous "my teenage kid can do graphic design" — which tells you more about what that person thinks about graphic design than about graphic design itself. If you are a manager you'd be wise to realize a serious software project yourself at home, this might teach you a thing or two.

[OutOfHere]

says the person who never devised a clever algorithm in his life