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.
What kind of "routine factory work" you've been doing?
Citation needed.
- 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.
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.
