The Friendship that made Google huge (2018) | Hacker News Reader

The Friendship that made Google huge (2018)

newyorker.com

95 pointsrobertkoss45 comments

I like how this digs into pair programming using these two as an example - pair programming, at least when I was coming up, was seen as a panacea to all software development problems. However, in our field, suffice it to say there are "difficult" personalities or people much more comfortable working alone, and in practice, I've rarely seen success with it, personally, more than someone looking over your shoulder every now and then to debug something. As a primary working method, which it seems like the subjects of this article are doing, you definitely need to find someone who thinks like you.

I've had things that were close, but usually devolves into multiple short 10-20 minute meetings, division of tasks, then reconvene, rinse/repeat. That typically works well and I don't have to deal with people nitpicking how I use my editor or how many chrome tabs I have open.

I struggled badly on a pair programming position.

It's not like I don't like reviews or cannot work alongside another person. It's I cannot learn while someone is talking to me or trying to make me place the cursor somewhere.

I'm all in for code review, even in pairs. In fact, I do that with a junior dev I have assigned and it's working well for us. I leave him thinking and come back to evaluate his solution.

I find reviewing him paired, is time saving for me. I make him lead me to the right code spots, rather than finding out on my own. I fire 3 quick questions and we're aligned on the spot.

I'll never work again on a 100% pp position but I think I've found my sweet spot with the technique.

I agree that, if no other safeguards are in place, using pp you can avoid real bad code. But without deep thought, you'll mostly converge to an average solution, when social dynamics are very much leading.

That's funny/sad.

I've never learned so much about programming as during my years pair programming!

I got to see how other people solved problems, and surprisingly often, they have a completely different approach than what I though was the obvious way. Half the time their way was better than mine, and I became a better programmer, and half the time I taught the other person something.

This went on day after day, for years!

There is a technique for pair programming well. I was lucky to join a team of PP pros, and picked it up pretty fast. Sounds like you had worse luck :(

> I cannot learn while someone is talking to me

This sounds strange. Normally people learn by listening to others talking, right?

Seems like your programming partner was particularly micromanagey. When I pair program it's more of a conversation to discover different approaches. If you're having to tell someone where to position the cursor, that's missing the point!

I think that PP is generally talked about backwards. Everyone says that the least experienced programmer should drive while the senior programmer talks. When I was an intern 25+ years ago before pair programming had a name, I sat beside the grey beard who did the typing. I watched him and tried to keep up. For the first couple of weeks, I contributed nothing, but once I started to understand the code and his style, I was able to start seeing simple things, like reminding him to do a null pointer check, and then I started to see more and more stuff and I was able to contribute in real time.

I think this worked because 1) he was comfortable with me staring over his shoulder with neither of us talking and 2) I was comfortable with just watching an learning. I've tried this style with my junior programmers, and I'm too anxious being quiet and coding while someone watches me, and most juniors are also too anxious to prove that they're paying attention so they have to talk, and that breaks the flow.

(former Googler)

It was really special to see how this pair basically laid out the foundations of large-scale distributed computing. Protobufs, huge parts of the search stack, GFS, MapReduce, BigTable... the list goes on.

They are the only two people at Google at level 11 (senior fellow) on a scale that goes from 3 (fresh grad) to 10 (fellow).

(current Googler)

One of my coworkers got assigned Sanjay on one of her CLs recently and she had no idea who he was. I had the pleasure of working with Sanjay as his intern at SRC the summer before he joined Google, and he taught be a lot of cool tricks related to compiler development. Both Sanjay and Jeff Dean are PhDs with PL focuses.

hah, this happened to me recently. I submitted a small CL to a threading lib and suddenly I see some guy named "sanjay" asking for a small change. It's very cool to see how involved he is still!

It's actually quite interesting how many of the early Googlers came from PL research backgrounds, and how it impacted Google's culture. Jeff Dean's thesis on whole-program optimization of Cecil/Vortex [1] was a classic even before Google got big, and eventually he got his boss Craig Chambers hired to write Flume [2]. Urs Hoezle (Google's first employee #9) was the founder of the Self project, which pioneered many of the dynamic optimization techniques that made it into HotSpot. Much of the HotSpot team itself was hired by Google, notably former Search SVP Ben Gomes and several less famous employees. The Plan 9 team (notably Ken Thompson and Rob Pike) went on to create Sawzall and then Go within Google; Ken Thompson was himself famous for creating C before then. Guido van Rossum (Python's creator) wrote Mondrian, the first code-review tool in Google. Lars Bak worked on BETA, then joined Urs to work on Self and Strongtalk before implementing the first version of V8 at Google. Dan Sugalski of Parrot & Perl 6 fame has held a bunch of infrastructure rules within Google.

It's like nearly everyone in a who's-who of the language design & compiler implementation community circa 2002 ended up working for Google, and the few that didn't (notably Chris Lattner of LLVM and Slava Pestov of Factor) ended up at Apple.

[1] https://projectsweb.cs.washington.edu/research/projects/ceci...

[2] https://research.google/pubs/flumejava-easy-efficient-data-p...

And now they can't even build a chat app. So sad how much Google has fallen. That's why research and product should be separate.

They built a ton of stuff after those researchers were hired, including original gchat.

They stopped being able to build a chat app after different people were hired.

IMHO most of Google's woes stem from the promotion system. The incentive is to launch, promote, replace so you can get other people promoted. There's basically zero incentive to build anything durable because if you do, it means your people won't get promoted, they'll leave, your headcount will disappear, and eventually you'll find yourself marginalized and forced out.

I think it's happening at every tech company. They are now being led by tech-illiterate company hopping businesspeople rather than passionate engineers.

Let's not exaggerate. Everything they did was already well-established in academia for decades and what they built was pretty dumbed-down rather than novel, at least conceptually.

Sure, they did good engineering to apply those techniques at Google, but they did not "lay out the foundations of large scale distributed computing".

Academia lags quite a bit behind industry when it comes to software engineering.

That's because academia doesn't actually do software engineering, it does computer science.

(2018)

And 102 comments on HN at the time: https://news.ycombinator.com/item?id=18588697

I don't enjoy these types of lionizing articles, badically these types of articles is what you give $10k-$50k to a PR team and they start to write these articles yo elevate your reputation in the industry ...

Yep, a PR boost is what Jeff and Sanjay need...

In 2018 when the article was written, Jeff was relatively unknown outside distributed research (ie MapReduce) and Google, and Sanjay probably completely unknown.

And they used this PR for what? This isn't a puff piece. Those guys are the real deal.

It elevates Google itself. “It’s a place where people like Jeff and Sanjay work!” Not saying that was the main motivation for producing the article and definitely not trying to question the protagonists’ achievements.

You could say that about any article that is even slightly positive about anyone that works for Google. It's an absurd premise. It prevents the telling of stories that have good outcomes.

Google is already the most known and respected software company in the world, so I doubt that was the motivation.

It elevates a Google of the past, which may no longer exist.

I did enjoy the article.

People forget how influential the architectures these guys came up with were in the industry a decade ago. Its great to read about the human factors behind the advances.

They can't talk about CIA founding so they create stories about heroes. /s

https://archive.md/U8HCQ

“Jeff Dean’s résumé lists the things he hasn’t done—it’s shorter that way.”

Just brilliant. :-)

I don't understand why so many people insist in revering others for what they've achieved.

If you need to revere anything, revere the achievement, not the man that did it.

yeah this is a classic "puff piece" not really about the engineers themselves but a subtle advert for google for being a place where geniuses work. They (and nytimes, wired etc) do the same thing with Geofrey Hinton and a few other key engineers. Matter of fact it happens at other companies as well and unsure if its something the company pays for or something else.

And it’s a happy coincidence that it comes right at the start of their latest and largest antitrust trial! Some contractor in charge of monitoring their mentions is pumping their fist rn at this repost, lol

The article was returning in 2018. The only bias here is from HNers who are massively anti-Google

The first anti trust suit started it's investigation about then.

It's not as if the court trial starts the very day the government notices the issue.

It's not revering a person but a friendship. Anybody reading their code would know what the article is talking about. C++ is not the ideal language to make the hard thing seem easy but they did.

It's perfectly fine to revere people and get inspired. Jeff Dean, Dennis Ritchie, Isaac Newton, Claude Shannon, Stephen Wolfram and others are brilliant thinkers who have impacted the world.

In fact, the higher the IQ, the better you are able to discern true intellect vs loud mouths.

I for one revere Jeff Dean and I'm proud of it. It doesn't affect my life negatively in any way. In fact betting on people that I revere (Jobs, Musk, Zuck, Bezos, Buffett) have profited me immensely

Most achievements are the product of multiple factors meeting at a specific point in time.

In many of the scenarios you hint at, new problems or opportunities arose, and those people were simply well-positioned by chance and circumstance to tackle them.

The problem should take center stage, not the men.

I agree with what you are saying regarding luck and opportunity playing a bigger role in people's success than is often appreciated. But I think it's ok to enjoy and appreciate the existence of a person in the world that was in the right place and right time to solve the problem. The fact that the universe made that occur is just as enjoyable as the problem itself.

What you're saying is closer to the truth, but believing in heroes is more useful for personal motivation. When believing in something untrue is good for them (usually, for their mental health), people usually choose to do it.

It's so they can imagine themselves in that same position one day being the beneficiary of the same uncritical reverence.

If you come to revere a pair of programmers then you've almost certainly missed the actual story of the true achievements or are blinding yourself to the fact that their achievement was only necessary due to the complete engineering failures of the company they were now attached to.

I fail to see why the person should not be revered

If you want to do great things yourself, then it's natural to look for people who have similar things and figure out how to emulate them.

How do you plan to emulate the luck of being in the right place at the right moment?

Ah so it was luck that so many exceptional people ended up at Google [Microsoft, Nvidia, Intel, Sun, AWS, Apple, et al] at a similar time.

As opposed to it being obvious that very interesting things, opportunities, were happening at those companies. With word spreading throughout the industry. Along with talent flight into said companies, so as to pursue said opportunities along with other talent. Employees in tech typically see these things happening, it's not a big secret.

You can in fact do a lot better than blind dart throwing.

Humans have been revering other humans since the beginning of humanity. What's next, "i don't understand why humans envy other humans" ? It's part of the condition.

Reply on news.ycombinator.com