I can tell that this was written by an outsider, because it focuses on the perks and rehashes several cliches that have made their way into the popular media but aren't all that accurate.
Most Googlers will tell you that the best thing about working there is having the ability to work on really hard problems, with really smart coworkers, and lots of resources at your disposal. I remember asking my interviewer whether I could use things like Google's index if I had a cool 20% idea, and he was like "Sure. That's encouraged. Oftentimes I'll just grab 4000 or so machines and run a MapReduce to test out some hypothesis." My phone screener, when I asked him what it was like to work there, said "It's a place where really smart people go to be average," which has turned out to be both true and honestly one of the best things that I've gained from working there.
A lot of the observations in the article fall out of this, but in ways that are less sound-bitey. Google doesn't enforce set working hours - you can get in as late as you want (the latest I've been in is around 4:15 PM, but that was because I had a DMV appointment, the latest from just not waking up was about 2:00), stay as late as you want (my latest was about 1:00 AM, though I worked from home until 6:00 AM last Thursday), duck out during the day if you're meeting a friend or have a date or need to pick a sick kid up from school, or work from home as necessary. You also don't have a set workload: you do as much work as you think is appropriate and then go home.
The thing is - you are surrounded by incredibly intelligent & fiercely hard-working people. Many of them were used to being top-dog at whatever institution they came from before - hell, many were top dog (we have a lot of ex-startup-founders; there's a good chance that you're working with someone that's founded a company or originated a successful open-source project). And that can be a big adjustment, and the types of folks that Google typically hire usually react to not being on top by working harder. It's up to you to set limits on the amount of time you're willing to spend working, and most new hires at Google are used to being limited by "the amount of work my boss/professor/thesis advisor throws at me", not by the number of hours in the day.
Some kids grow up on football. I grew up on public speaking (as behavioral therapy for a speech impediment, actually). If you want to get radically better in a hurry:
1) If you ever find yourself buffering on output, rather than making hesitation noises, just pause. People will read that as considered deliberation and intelligence. It's outrageously more effective than the equivalent amount of emm, aww, like, etc. Practice saying nothing. Nothing is often the best possible thing to say. (A great time to say nothing: during applause or laughter.)
2) People remember voice a heck of a lot more than they remember content. Not vocal voice, but your authorial voice, the sort of thing English teachers teach you to detect in written documents. After you have found a voice which works for you and your typical audiences, you can exploit it to the hilt.
I have basically one way to start speeches: with a self-deprecating joke. It almost always gets a laugh out of the crowd, and I can't be nervous when people are laughing with me, so that helps break the ice and warm us into the main topic.
3) Posture hacks: if you're addressing any group of people larger than a dinner table, pick three people in the left, middle, and right of the crowd. Those three people are your new best friends, who have come to hear you talk but for some strange reason are surrounded by great masses of mammals who are uninvolved in the speech. Funny that. Rotate eye contact over your three best friends as you talk, at whatever a natural pace would be for you. (If you don't know what a natural pace is, two sentences or so works for me to a first approximation.)
Everyone in the audience -- both your friends and the uninvolved mammals -- will perceive that you are looking directly at them for enough of the speech to feel flattered but not quite enough to feel creepy.
4) Podiums were invented by some sadist who hates introverts. Don't give him the satisfaction. Speak from a vantage point where the crowd can see your entire body.
5) Hands: pockets, no, pens, no, fidgeting, no. Gestures, yes. If you don't have enough gross motor control to talk and gesture at the same time (no joke, this was once a problem for me) then having them in a neutral position in front of your body works well.
6) Many people have different thoughts on the level of preparation or memorization which is required. In general, having strong control of the narrative structure of your speech without being wedded to the exact ordering of sentences is a good balance for most people. (The fact that you're coming to the conclusion shouldn't surprise you.)
7) If you remember nothing else on microtactical phrasing when you're up there, remember that most people do not naturally include enough transition words when speaking informally, which tends to make speeches loose narrative cohesion. Throw in a few more than you would ordinarily think to do. ("Another example of this...", "This is why...", "Furthermore...", etc etc.)
The opposite scenario (sort of), from Michael Lewis' Liar's Poker:
One day earlier in his career Dall was in the market to buy (borrow) 50 million dollars. He checked around and found the money market was 4 per cent-4.25 per cent, which meant he could buy (borrow) at 4.25 per cent or sell (lend) at 4 per cent. When he actually tried to buy 50 million dollars at 4.25 per cent, however, the market moved to 4.25 per cent-4.5 per cent. The sellers were scared off by a large buyer. Dall bid 4.5. The market moved again, to 4.5p per cent-4.75 per cent. He raised his bid several more times with the same result, then went to Bill Simon’s office to tell him he couldn’t buy money. All the sellers were running like chickens.
“Then you be the seller,” said Simon.
So Dall became the seller, although he actually needed to buy. He sold 50 million dollars at 5.5 per cent. He sold another 50 million dollars at 5.5 per cent. Then, as Simon had guessed, the market collapsed. Everyone wanted to sell. There were no buyers. “Buy them back now,” said Simon when the market reached 4 per cent. So Dall not only got his 50 million dollars at 4 per cent but took a profit on the money he had sold at higher rates. That was how a Salomon bond trader thought: He forgot whatever it was that he wanted to do for a minute and put his finger on the pulse of the market. If the market felt fidgety, if people were scared or desperate, he herded them like sheep into a corner, then made them pay for their uncertainty. He sat on the market until it puked gold coins. Then he worried about what he wanted to do.
For those who work inside Google, it's well worth it to look at Jeff & Sanjay's commit history and code review dashboard. They aren't actually all that much more productive in terms of code written than a decent SWE3 who knows his codebase.
The reason they have a reputation as rockstars is that they can apply this productivity to things that really matter; they're able to pick out the really important parts of the problem and then focus their efforts there, so that the end result ends up being much more impactful than what the SWE3 wrote. The SWE3 may spend his time writing a bunch of unit tests that catch bugs that wouldn't really have happened anyway, or migrating from one system to another that isn't really a large improvement, or going down an architectural dead end that'll just have to be rewritten later. Jeff or Sanjay (or any of the other folks operating at that level) will spend their time running a proposed API by clients to ensure it meets their needs, or measuring the performance of subsystems so they fully understand their building blocks, or mentally simulating the operation of the system before building it so they rapidly test out alternatives. They don't actually write more code than a junior developer (oftentimes, they write less), but the code they do write gives them more information, which makes them ensure that they write the right code.
I feel like this point needs to be stressed a whole lot more than it is, as there's a whole mythology that's grown up around 10x developers that's not all that helpful. In particular, people need to realize that these developers rapidly become 1x developers (or worse) if you don't let them make their own architectural choices - the reason they're excellent in the first place is because they know how to determine if certain work is going to be useless and avoid doing it in the first place. If you dictate that they do it anyway, they're going to be just as slow as any other developer.
Curious why he would need to move to a more prestigious position? Most people realize by their 30s that prestige is a sucker's game; it's a way of inducing people to do things that aren't much fun and they wouldn't really want to do on their own, by lauding them with accolades from people they don't really care about.
Yes, at FedEx, we considered that
problem for about
three seconds before we noticed
that we also needed:
(1) A suitable, existing airport at
the hub location.
(2) Good weather at the hub location,
e.g., relatively little snow, fog,
or rain.
(3) Access to good ramp space, that
is, where to park and service the
airplanes and sort the packages.
(4) Good labor supply, e.g., for
the sort center.
(5) Relatively low cost of living
to keep down prices.
(6) Friendly regulatory environment.
(7) Candidate airport not too busy,
e.g., don't want arriving planes
to have to circle a long time
before being able to land.
(8) Airport with relatively little
in cross winds and with more than
one runway to pick from in case
of winds.
(9) Runway altitude not too high,
e.g., not high enough to restrict
maximum total gross take off weight,
e.g., rule out Denver.
(10) No tall obstacles, e.g.,
mountains, near the ends of the
runways.
(11) Good supplies of jet fuel.
(12) Good access to roads for
18 wheel trucks for exchange
of packages between trucks
and planes, e.g., so that some
parts could be trucked to the
hub and stored there and
shipped directly via the planes
to customers that place
orders, say, as late as 11 PM
for delivery before 10 AM.
So, there were about three candidate
locations, Memphis and, as I recall, Cincinnati
and Kansas City.
The Memphis airport had some old
WWII hangers next to the
runway that FedEx could use
for the sort center, aircraft
maintenance, and HQ
office space. Deal done --
it was Memphis.
That's how the decision
was really made.
Uh, I was there at the time,
wrote the first software
for scheduling the fleet,
had my office next to that
of founder, COB, CEO F. Smith.
To avoid network congestion, the TCP stack implements a mechanism that waits for the data up to 0.2 seconds so it won’t send a packet that would be too small. This mechanism is ensured by Nagle’s algorithm, and 200ms is the value of the UNIX implementation.
Sigh. If you're doing bulk file transfers, you never hit that problem. If you're sending enough data to fill up outgoing buffers, there's no delay. If you send all the data and close the TCP connection, there's no delay after the last packet. If you do send, reply, send, reply, there's no delay. If you do bulk sends, there's no delay. If you do send, send, reply, there's a delay.
The real problem is ACK delays. The 200ms "ACK delay" timer is a bad idea that someone at Berkeley stuck into BSD around 1985 because they didn't really understand the problem. A delayed ACK is a bet that there will be a reply from the application level within 200ms. TCP continues to use delayed ACKs even if it's losing that bet every time.
If I'd still been working on networking at the time, that never would have happened. But I was off doing stuff for a startup called Autodesk.
It's nice to hear that in your final paper you acknowledge the earlier discussions. You should link that final version from your author homepages. (The latest versions linked from you and your coauthors' pages, at arXiv [1] and Cornell [2], still have no mention of the earlier discussion.) If the FC14 version [3] is final, it's better, but I still think you're unfairly summarizing the key thread [4].
Every key aspect of selfish strategy is described there, from manipulating 'gamma' via network-tricks, to releasing the minimum number of 'secret' blocks, after each external-block, to maximize the cartel's expected return. ByteCoin's simulations show advantages, and breakeven thresholds with regard to 'override success' ('gamma'), very similar to your paper's calculations. That's why I credit your paper for rigorously describing the situation, under your specific assumptions, but not with the discovery of a previously-unknown less-than-51% attack.
Also, your final paper is simply lying when it says the thread "does not suggest a solution to the problem". It's almost as if your disdain of these 'fringe' Bitcoin fanatics has blinded you to the actual words of the thread.
Two commenters in the December 2010 thread (btchris and RHorning) suggest that preferencing accurate-seeming timestamps can disadvantage cartel-delayed blocks. That countermeasure is likely stronger than your paper's proposed random-choice-between-ties. (Randomization, by pushing gamma to 1/2, could make things worse if, on the real network, the effective gamma for late-releasers was already closer to 0. Preferring realistic timestamps, meanwhile, almost always helps 'honest' blocks, which don't have to guess a future time when they'll be released.)
Note that the last bullet of supposed novelty in your paper – "defending against the attacker requires at least 2/3rds of the network to be honest" – is the exact same best-case threshold as reported by ByteCoin in thread message #36, 2010-12-14. He states: "a cartel with no preferential network access can be profitable with 33% of the generating power"[5]. Same result, 3 years earlier. How can you allege ByteCoin was simulating some other strategy? Wouldn't the slightest difference in block-release-rules result in a different best-case threshold?
Finally, the Bitcoin Talk forums hadn't "CONCLUDED" anything. They're not a deliberative body. Some people were convinced, others weren't. The relevant actors – mining insiders – knew what they needed to know, to either try the attack, or detect it in orphan rates and weird timestamps... and to try countermeasures based on disadvantaging cartel blocks if ever necessary. Meni Rosenfeld also referred back to the matter as a known concern, in an answer on the Bitcoin StackExchange, in October 2011 [6]. So he knew it was an issue, and lots of people trust him about mining matters.
There's no "brigade" out to trash you led by some "failed academic" "Singaporean" "ringleader". Your critics are not the heads of some unified hydra, that you can disregard altogether as the "Bitcoin lunatic fringe" based on a few quotes from particular yahoos. You've made specific claims of novelty, or doom, that were either never true, or disproven by later events. These will be pointed out when you claim to enjoy a "we told you so" record of authoritative insights.
Most Googlers will tell you that the best thing about working there is having the ability to work on really hard problems, with really smart coworkers, and lots of resources at your disposal. I remember asking my interviewer whether I could use things like Google's index if I had a cool 20% idea, and he was like "Sure. That's encouraged. Oftentimes I'll just grab 4000 or so machines and run a MapReduce to test out some hypothesis." My phone screener, when I asked him what it was like to work there, said "It's a place where really smart people go to be average," which has turned out to be both true and honestly one of the best things that I've gained from working there.
A lot of the observations in the article fall out of this, but in ways that are less sound-bitey. Google doesn't enforce set working hours - you can get in as late as you want (the latest I've been in is around 4:15 PM, but that was because I had a DMV appointment, the latest from just not waking up was about 2:00), stay as late as you want (my latest was about 1:00 AM, though I worked from home until 6:00 AM last Thursday), duck out during the day if you're meeting a friend or have a date or need to pick a sick kid up from school, or work from home as necessary. You also don't have a set workload: you do as much work as you think is appropriate and then go home.
The thing is - you are surrounded by incredibly intelligent & fiercely hard-working people. Many of them were used to being top-dog at whatever institution they came from before - hell, many were top dog (we have a lot of ex-startup-founders; there's a good chance that you're working with someone that's founded a company or originated a successful open-source project). And that can be a big adjustment, and the types of folks that Google typically hire usually react to not being on top by working harder. It's up to you to set limits on the amount of time you're willing to spend working, and most new hires at Google are used to being limited by "the amount of work my boss/professor/thesis advisor throws at me", not by the number of hours in the day.