Here's a good explanation.

https://www.bradrodriguez.com/papers/moving1.htm

For more direct help I believe Beej's guide to network programming is greatly recommended https://beej.us/guide/bgnet/

Where does one even start? Even finding the original paper seems a challenge, news articles mention one and then just to another news article. If I search the web for the title and author it feels like most websites are just rehosting the content, like with manuals/datasheets. Not sure how to get started here but your comment makes me think you might know some resources.

Your anecdote suggests this is a truth about all engineers and while I cannot disprove that I might as well counter with my personal anecdote.

In my experience, engineers tend to be very sensitive to the environment they work in. When unsatisfied with the workplace environment, they might go off on side quests but trying to "fix" that with tightly controlled process is fighting symptoms, not causes and will generally result in an even more unsatisfied engineer who appears more valuable because they've learned how to hide the unproductiveness. I've seen this happen and it definitely didn't add any value for the business.

The real solution is to try and create an environment where people have trust in each other and are committed to a common goal. I've been lucky enough to experience these kind of jobs where it's just professionals committed to a product they believe in. We're all adults so if someone disappears on a side quest that's hurting the team we talk about it. Maybe someone just got distracted and needs someone to point it out, a simple mistake which is ok every once in a while. Maybe someone is having a bad time and needs to take a vacation, understandable and also ok since we're humans first, engineers second.

But most importantly: if someone is regularly hurting the team's goals and isn't willing to improve the situation or acknowledge it then it's simply not a good engineer/colleague/asset to the company. No amount of process is going to change that and even if it does you're probably losing productivity from the rest of the team because they were productive in the old approach. A flat tire doesn't mean cars are a bad mode of transportation and switching to a horse is not going to get you to your destination any faster. Why not replace the defective tire instead?

If the situation I described above sounds unrealistic to you maybe the companies you've worked for need to review their hiring process. If you don't trust the engineers you've hired with the process you'd be doing yourself a disfavor by trusting them to do the job they were hired to do.