R&D includes both "creating new battery recycling capabilities from scratch" and "redesigning the the rear brake lights to be a deeper shade of red to match the recent coloring trends".
Only one of these has long term impacts but they are both "R&D"
I think that the most important goal of our profession is to find and implement high-level concepts so that our users don't need to worry about tiny details.
As an example: when I buy a back-up hard drive from a typical brick store like Costco, the "back up hard drive" is abstracted away: I don't need to study the USB timing diagrams, or worry about the details of how the magnetic domains are imprinted on the spinning disks, or really any of the chemical details of the surface coating.
This abstracting away of details is AWESOME. I can buy a $150 disk drive after spending less than a minute considering the purchase.
Git, on the other hand...
Let me give a real-life example of where real-life git and real-life published work flows don't work: you can go into GitHub.com, and make a project. And you can write code in Visual Studio, and save it up to your new git project.
Unless, of course, when GitHub.com recommended that you add a license. The instant you add a license, the project isn't "empty", and once the project isn't "empty", you can't trivially push your new Visual Studio project up.
The fix for this is to delete your GitHub.com repo.
I bet you'll reply and say, "that's just real-world problem! I only want to hear about theoretical problems!" -- which, IMHO, is one of the problems my profession faces. Real-world problems are ignored in favor of theoretical ones.
I hate the Hole Hawg story with a passion. Firstly, because it's wrong: the story say things like "it's a cube of metal" and "the handle is not ergonomic".
But look at pictures from the maker. It's not a cube, and the handle is in fact ergonomic. Indeed, I would hope that a drill used by expert for hours every day would be 100% designed to make their jobs easier, and that includes not given them crippling injuries. And it's 100% purchasable from Home Depot. And, looking on Amazon, it's half the price of a truly expensive drill.
But there's another level at which the story is bad. The story feels like a story about gatekeeping: either you're one of the special people, or you're a useless homeowner. Either you have big problems, or you shouldn't be here. Either you've dedicated your life to drilling holes, or you're not welcome.
So, I read the story, and it sounds like both an exciting story of a newbie learning that some profession has unexpected depth. At the same time, it's also a story of a person who wants to be part of the special exclusive club.
From the Judge: releasing the logs may help clarify whether fraudulent activity interfered with the comment period, as well as whether the agency’s decision-making process is “vulnerable to corruption."
My take: I was one of the flesh-and-blood people who commented. when I did that, I also looked up every comment made by a person with my name. Result: every comment by someone with my name was obvious cut-n-paste.
From my POV, it's clear: the FCC site was swamped with fake comments. Their unwillingness to publicly say so is an abomination in a democracy.
We have anecdotal evidence that one hiring manager says that they care about honesty. The same person hasn't said that they have actually had this situation happen, so it's still hypothetical. OTOH, there's also tons of vague anecdotal evidence that some hiring managers are actually kind of self-righteous jerks.
So we're not actually any farther ahead. Personally, the advice I'd probably give a person in this situation: ask a lawyer from the area. Compared to a FAANG salary, it's a cheap investment. I might also recommend paying cash, and not giving a real name.
AFAICT, most of them allow split tunnels for work VPN -- most work VPNs are set up to allow access to corporate resources, not block normal usage. Some places have very high security requirements.
Hey, I get to tell m y own two 1990's era threads story.
First: in Windows 3.1, you got exactly one thread. My former company (BBN Software Products, home of the RS/1 statistical program) managed to get a version of RS/1 on Windows by splitting it into two pieces, each of which ran a single thread. On piece (RS/Client) was the UI; it talked to the "server" using TCP/IP (or a shared memory channel if the client and server were on the same machine)
Second: I also got to help port a networking program over to an SGI box. At the time, the SGI GCC-based compiler could either supports threads, or support exceptions, but not both. (And my "unsupported" I mean, "generated code that would crash even if no exception was ever actually generated"). I couldn't convince the company to keep the threads and dump the exceptions, so instead I had to convert the program to spawn new processes with shared memory (!) to emulate the threads.
TL/DR: actually programming with threads at the time was decidedly unsupported.
Specifically, StreamSocket will happily go through proxies for you, will handle TLS / SSL (either at start up or after the connection is established), does IPv4 and IPv6 transparently. We also do service discovery using DNS-SD, although that's technically in a different class, as is the other network information. The SteamSocket class is designed to be very similar to the other socket-style classes like StreamWebSocket, so your code will (mostly) move from one to the other.
I've found from my own experience that the real key to a smooth network experience is the magic technology called "caring". It's easy to test if your code handles network disconnects; just run your code and yank the ethernet cable (or switch off Wi-Fi).
Source: am PM for the Network Developer Experience team at Microsoft and helped design the socket APIs.