You speak about the problem domain, but the primary problem domain we are facing first is programming. And without a shared vocabulary, you can talk with other software developers, but you aren't going to be very efficient in that communication. So going back to the problem domain, as software developers we are supposed to master whatever problem domain we are facing, in order to efficiently communicate with the business side in their own domain-specific language. How are we supposed to do that if we haven't even bothered to learn our own domain-specific language?

But it goes deeper than that. Many software developers these days rely too much on libraries, without knowing how they work. And this hurts them a lot.

This is all about standing on the shoulders of giants. And it all starts from the most basic data-structures and algorithms. BFS is right up there with the characteristics of a List or a Map. It's common knowledge that everybody should know. And this common knowledge is half of "Introduction to Algorithms" by Cormen et al. So instead of reading another fluffy piece on Agile methodologies or on soft skills like the "Pragmatic Programmer", or other such bullshit, maybe people should read this one instead.

One recent problem we had was one of scaling out our micro-service-based infrastructure. And I've heard from colleagues wild ideas like "oh, lets introduce an external queue, like Kafka". DevOps for some reason think external queues are the solution to all problems. Yeah, great, but this isn't a freaking webpage reading from a database, we've got singletons, as in producers of truth that need strong consistency in their decision-making because we aren't that smart and you're just moving the problem around, because locks don't freaking scale, no matter how smart your queue is. Or "we'll just add Akka Cluster or Finagle or whathaveyou, should take care of it". Dude, yeah, we've got singletons, which means we need to do sharding and have a protocol for failure detection, so maybe we should talk about that first.

This is just a recent example. Developers are so eager to jump to the latest fads and the latest cool things, without thinking for a second if those solutions would work, only because they can't imagine how these tools are even implemented. And this isn't something that a superficial Google search can fix, because the unknown keeps piling up, the more complex the system is, until the shit hits the fan and you throw your hands in the air and bring in external consultants to fix it. And if you think the UI is spared from all of these problems, think again. I've seen dozens of Javascript-enabled interfaces with performance issues, only because of the "thundering herd" problem happening due to sloppy event handling. How many UI folks understand how Facebook's React works? Not that many.