mikevin
Here's a good explanation.
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.
A ticket that takes 2 minutes to create is just distracting from tickets that provide real value to my colleagues. We're here to work together and improve something, not to babysit each other's schedules.
"Visibility into what I'm doing" as a reason to create a ticket is relevant for micromanagement, not for a team of professionals that trust each other's commitment to the job.
If my teammember decides documentation needs updating he should go ahead and update it. Tickets and PRs are for thing that need planning and reviewing. I trust my colleagues to know when that is the case and decide accordingly. If any of us messes up we talk about it and improve.
In reality this means that many, if not most, things still get tickets / PRs because it helps but the fact that it's not simple ceremony makes sure everyone knows their importance and saves time when they aren't needed.
SEO spammers decided to improve their tools/techniques. Google realized they could earn just as much by replacing their grep-for-the-web search-engine with some NLP, ML and fuzzy matching on what I strongly suspect to be a tiny subset of the index they had before.
I understand the reasoning and I admit it does a really good job at correcting mistakes but I often wonder if anyone working on the search-engine actually uses it to find development related information.
Maybe I'm in some kind of A-B testing hell but my results often show 1 relevant random url and a tiny a stackoverflow box with other relevant information and then always the same 10-20 stackoverflow/github copycats. Scrolling down just loops those same sites over and over again. Similarly I've never had Google link to the official python docs, it's always some spammy website that copy pasted a docstring and decorated it with ads/share buttons.
I don't understand how that's not bothering people that actually work on the search-engine.
to make sure you don't end up with something like urxvt-readline(1)
I should look into contributing I guess