This. I'm surprised how often people try to copy Google practices because Google can't be wrong.
My bet is that Google is one of the worst places to learn anything, be it product, management or programming. You will only learn how to solve problems the Google way, and that is only applicable at Google.
It's like learning to govern from Xi Jinping. Sure, there probably are some interesting experiences to observe. But few will claim that let's say Norway will be better off implementing China's political system.
Looking at feedback loops means being honest with yourself and accepting you don't know everything. And for most people that's hard to admit. Surely if you got into Google you know almost everything. You just need a little bit of money to execute.
Only if you very narrowly define real engineering.
Google, collectively, may be among the best (I'm not hazarding an opinion) at solving technical problems.
I, however, expect good engineers to help with product vision, understanding and addressing customer pain points, and amongst the senior engineers especially, be effective at communication and helping manage upwards to achieve those ends. Somewhere, Google engineers are dropping the ball there, or are so detached from those problems that their abilities in those skills are untested.
Yeah, that's fair. I'm just trying to discern between building a distributed database system with 5 9's and writing a crud app I guess. I agree "real" isn't the right term for that difference, I don't know what is.
Nah, it's not. Consultants pump out CRUD apps with 4th rate engineers left and right.
About 10 people on planet earth could have come up with Spanner.
I'm just talking about engineering. I'm not talking about building products which get market acceptance, which is a lot more than engineering, and might be your point.
> About 10 people on planet earth could have come up with Spanner.
I'm not convinced. I've worked in many industries and many company sizes and I've met smart people everywhere. I think a lot of devs who are busy pumping out CRUD could create these kind of systems if they were in a situation that called for them (hell, it gives you a chance to actually use all that stuff from your CS degree), just as I know for sure that a lot of devs who are busy pumping out CRUD are more than capable of creating a programming language. The bottleneck isn't technical ability, it's being in an environment that will actually pay you to work on that stuff.
Some people convince themselves that Lebron isn't that good, that the guy at the high school across town was almost as good. Or that they can hit a 90 mph fast ball. Or that they could take Mike Tyson. There are all these funny stories of guys wanting to fight Mike, race Michael Johnson etc. They really just can't see how far they are away from the really freakishly talented folks.
Folks like Jeff Dean at Google are really out there. He built a number of systems that very few people were capable of. But you have to be at a certain level to even see it.
some of the most valuable companies on earth are "just CRUD apps", which was the point of the comment above. Knowing what to build is important, which google fails at in most cases. Google has incredible engineers working on stupid projects
> Running marathon is way harder than running 100m. Most people are not even capable of doing marathons.
> But that doesn't mean that winning 100m is easier than winning a marathon. Might even be the opposite, because of harsh competition.
If we go much, much farther into this analogy, it tells us that for any given agent, one of these races is always going to be much easier than the other one.
If you want to be competitive in marathons at a world level, you need to be East African. If you want to be competitive in 100m sprints, you need to be West African. Which race is easier? That depends who you are.
> "I, however, expect good engineers to help with product vision, understanding and addressing customer pain points, and amongst the senior engineers especially, be effective at communication and helping manage upwards to achieve those ends."
Not necessarily. FAANGs have an army of product/project/program managers, market researchers, and other analysts and experts to handle product vision, etc. for the engineering team. That's the big advantage of being a megacorporation: they can afford the overhead of having their employees be narrowly focused specialists.
(It's also why one sometimes see people who leave FAANGs stumble when they join a startup; they're used to having all that infrastructure supporting them and have to adjust to an environment where it isn't there.)
Yes necessarily, as I'm defining my expectations. If Google has made it so engineering doesn't participate at all in product direction, that means they're not letting their engineers work optimally in accordance with my expectations (whatever those are worth); the 'untested' case I mentioned before. Which, as you note, is why in other companies those individuals may not be as able to shine, since they're being measured against a number of other skills that form the holistic whole of "solving business problems", rather than just the subset of "solving technical problems".
And yet those minds managed to build the most hated frontend framework. Not just bad or mediocre. The most hated one.
Now, I'm not denying they are super smart. But you need a mix of book smart and street smart to be successful. Google seems to only focus on books. They are incredible at solving problems. But they suck at picking which problems to solve.
A front-end framework isn't exactly the kind of thing the engineers I'm talking about work on... there are 10's of thousands of engineers at Google. A good number of them aren't building systems per se. But if you want to learn how to build systems, some folks in there are crazy good.
Might be a bit anecdotal, but I actually hired ex-Googlers for two different startups in the past. I would be hesitant to do it again.
They can indeed be good at building complex systems.
But when we needed simple systems, they would still build complex systems.
When we needed to ship product, they would still build complex systems.
Twice I had the experience where an ex-Googler would promise to rewrite a piece of software from scratch because it had a bad architecture, only to quit/get fired few months later (obviously the big rewrite was not finished by then).
As a Xoogler, Google is an "engineering-first" company and in practice doesn't consider "product/program management" to be part of engineering. Ironically, the origin of formal methods used in program management come from operations research and engineering management -- they are part of engineering, but not seen that way at Google.
Engineering leadership is not judged for their acumen in these areas, as they are separate job ladders, and thus to no surprise there is little cultivation of this knowledge or skill.
Before ~ 2007, Google didn't believe in project managers. There were actually no project managers roles (even though some people were probably doing considerable amounts of project management) and the expectation was that engineers would know enough to structure efforts and timelines.
That evolved into a situation where program managers (mostly - programs have a sense of scale right??) exist in most orgs and are critical to keep things aligned. There were (are still?) even internal conferences just for program managers.
And when you refer to pm-Ing in this way I’m reminded of the guy in San Francisco that did all the management for a huge eve online guild and he didn’t play the game he managed all their affects in a spreadsheet and whatever they were using to chat…. And he was making a boatload of human money a month…
Which metrics would you use to compare one infrastructure to another? Or one eng practice to another.
For example I heard multiple times that in a lot of projects at Google shipping something can take months (and I'm not even talking about search/ads). Compared to let's say Github, that deploys multiple times a day.
Deploying multiple times a day doesn’t necessarily mean “slow to ship”. That’s just how fast your commits make it out. Actually shipping software is almost always not CI bottlenecked but slowed because of social problems.
My bet is that Google is one of the worst places to learn anything, be it product, management or programming. You will only learn how to solve problems the Google way, and that is only applicable at Google.
It's like learning to govern from Xi Jinping. Sure, there probably are some interesting experiences to observe. But few will claim that let's say Norway will be better off implementing China's political system.