We have a fairly new bunch of technologies with the internet. We're still at the point where people are exploring the problem space, what our technology can solve, what it can't solve and suggesting future directions. We're looking at the "adjacent possible" to quote Stuart Kauffman.
To put it another way, we have a new tool, all of this is just testing this new tool against the world to see where it works and where it doesn't.
At the end of the day PG is a smart dude and a wealthy dude, but he's not a philosopher or great thinker on social interaction. His essays barely rise above the level of Rush lyrics and angst-y teenage poetry. Use him for inspiration but don't take his BS too seriously.
1. buyers from retail who might "play" a game only at E3
2. Marketing people who are getting a sense for how your game is being received and might never play a game
3. Corporate tools who are checking how things are going and definitely never play games
4. journalists who may or may not play games or understand them.
The goal is not to let someone get lost in the entertainment but to get them to order a million copies in to retail, write a piece that gets everyone to buy the game, get marketing excited, keep your job or get a free trip to LA so you can drink your face off every night on the corporate dime. Plus it's E3, everything is cranked to a million decibels with a continuous strobe of nonsense.
My only bit of advice for the woman writing the article and others: Use Your Words. Tell the dude to go back to picking his wedgie and do your business.
In a video game anything the player doesn't see is a waste of time. In the case of games with large branching story lines it's a tradeoff between putting effort in to content which might be unseen and adding "depth." AI is the same. A genius AI that does all kinds of magic in the background is useless if the player never gets to see the magic.
Games don't want true AI solutions, they want to entertain the player. Put enough veneer on the world to make the player suspend disbelief and move on. Anything else is a waste of money for the most part.
That's the problem though isn't it. The buffers absorb the packets, preventing packet loss, and TCP performance goes down. Adding more initial packets puts more data in flight, more traffic uses intermediate buffers quicker. This tactic seems like it would accelerate buffer issues.
Like someone said in the comments on the article, I'd like to see Van Jacobson's or someone similar's thoughts.
No, TCP performance goes up for the connection in question. Latencies are lower because the packets arrive earlier. Latency (for all protocols) goes down on the whole though due to the backlog.
Balancing these requirements against each other is a really hard problem. TCP slow start is (well, was, c.f. this article) an early attempt to get an auto-tuning solution. But it isn't the only part of the problem, nor is it an optimial (or even "good") solution to its part of the problem. It's defaults are very badly tuned for modern networks (though they'd be a lot better if everyone was using jumbograms...).
I don't think reversing a link-list and removing unique items requires any special Python knowledge. No magical API needs to be used, just the basics.
A white board interview shouldn't exclude naive implementations. After the naive implementation has been done it's reasonable to ask for less naive approaches.
Also the continual whining about white board interviews is tiresome. It's a fact of life that exists in almost any tech interview you do. Practice, get your friends to bust your balls before the fact, write itoa on a white board or detect a loop in a singly linked list and move on with your life.
At some point if you're going to get paid you need to demonstrate your ability, reality says the potential employer decides what type of proof is required.
So you have a legacy system that is being used by other systems, you're the new super genius and can't understand the system, so you rewrite? Discounting the potential release iterations and bug fixes that are in the legacy system? Your "improved" version can't include that knowledge since you didn't understand the legacy system. Also discounting the company wide knowledge of the legacy system, warts and all that exists? Also having two identical systems isn't fantastic. Rewriting a system because someone can't understand it is rarely the correct solution. It most likely means the rewriter doesn't understand the problems that are being solved by the legacy system either.
To put it another way, we have a new tool, all of this is just testing this new tool against the world to see where it works and where it doesn't.