What on earth do you mean by this? It sounds rather like advocating just doing the minimum you can, for the sake of harmony.
What I speak is about individuals trying to compete against its own team to defeat them in some unnecessary priority rather than collaborate and play all together.
For example, I’ve seen diffing / recomputation code operating in O(n^3) or O(n^2) where O(n) or O(1) is possible and necessary for reasonable performance. I’ve also seen extremely poor use of network requests (multiple serial requests) that happen because the developer doesn’t understand network latency and networking performance (in this case with a single data center in the world).
I can't tell you how many times I've seen people "make it work" and create a mess that has to be rewritten later with much greater difficulty than if even the slightest amount of forethought had been given before hand.
The focus for me is really building appropriate abstractions over the work I do so that people can focus on improving only the vertical slice they need to.
https://blog.codinghorror.com/regular-expressions-now-you-ha...
Much of programming is encoding what you want to computer to achieve and is therefore a rather long process, but not necessarily hard. Precisely specifying how a GUI should look has a substantial amount of necessary complexity, and writing that out doesn't fall into 1, 2 or 3.
In Computer Science, there are 3 kinds of problems:
1. The problems that Math gives you: algorithms, data structures. These are the problems you think you're going to solve and sometimes you do, but often we just need a few really smart programmers to solve this and the rest of us can just use those solutions.
2. The problems that Physics gives you: hardware, device drivers, network latency. Sometimes you do systems programming and work close to the hardware. But once again, once one engineer has solved this, most of the time we can just use those solutions.
3. The problems that other engineers give you.
And that is where you're likely to spend most of your time: gluing APIs together, reading code and documentation, and arguing about code formatting.
This is why in so many ways computer science is a social science. Certainly "software engineering" is. Everything you do is going to be about communication. When you write code, you're not just communicating with the compiler and the machine, you're communicating with other engineers. You're going have to craft smart documents, emails and collaborate. Any nontrivial solution will require these skills, so you better start investing in them.