281–290 of 319 posts
Page 17 - "any employee can nominate any other employee for a 'peer bonus' - a cash bonus of $100 - up to twice a year..." Is there a hard cap/limit on this policy now? I might have to take the rap for that, having peer bonus'd my entire office on my last day there back in 2012. My bad.
Earlier quoted context omitted.
At Google you are expected to exceed expectations. But seriously, you are evaluated against the role description (software eng? product mgmt?) and your level. If you exceed expectations consistently over several review cycles, you are encouraged to apply for a promotion. The goal is to get you promoted into a role and level where you can consistently meet expectations.
Ahh the Peter Principle. https://en.wikipedia.org/wiki/Peter_principle
Roles/levels are calibrated so that expectations at L+1 are generally speaking aligned with strong performance at L.
So, the thing that is still buzzing in my head now and not mentioned in the article (maybe I didn't read carefully enough), what actually gets released into prod after a change is reviewed and merged. If the monorep contains let's say five different products and in a day only one of them gets a merge, then Blaze still builds all five and all five are released (based on successful integration testing)? OR only release…
Releases are done by each team. Look into blaze/bazel. It allows me to say "I depend on these sources only". So a day with only one change, you might only build and release the changed artifact (in practice this never happens).
Canarying:
More mature teams do a lot of complex stuff. Large teams may have multiple stages of canary, multiple canaries, feature experiments, etc.
Earlier quoted context omitted.
Yes, there are many legitimate reasons to rewrite like dieng frameworks/languages. However we are discussing here the case where reason proposed for the rewrite is solely to satisfy physiological need of some developers to work on code they can call it their own. A lot of things can be done by refactoring but the devs with these issues often just start new projects of their own that does same thing. In companies like…
Do you mean psychological or really physiological? I get the former, the latter seems dubious at best.
Earlier quoted context omitted.
I’m not convinced this works so great for Google. Some rewrites are very noticeable as a user, and things in the UI frequently shift around for no discernible reason. Perhaps worse, they seem unable to get below a certain level of bugginess in products like Google Maps and Gmail. Perhaps because a new round of rewrites always introduces new bugs before all of the old ones ever get fixed. Perhaps their metrics tell th…
I saw this a BT where on system was rewritten in OWS (Oracle Web Services) used 15 Person Years and around a Million Quid - Not the best use of shareholders money. But some one got to tick some boxes on there promotion track
Earlier quoted context omitted.
My experience is that the difference in raises between an employee that got an “Exceeds Expectations” and one that “Meets Expectations” isn’t significant enough to be worth wasting the time worrying about it. The best way to make more money is to change jobs. Google may be different.
10s of thousands of dollars per year difference in bonus, stock refresh, forget about salary. From personal experience having been at both meets and exceeds as a senior engineer.
If you are at an appropriate tier company for your skill level/aptitude then you likely will have to work a lot of extra hours to be (and to be seen as) an 80th percentile performer.
You won't know if that time investment gets you anything until the end of the year. You won't even know what the bonus pool will be or if you'll even have the same manager by the end of the year.
All for an extra 10-30k a year (pre-tax)?
Your time is probably better spent building your reputation in the industry and trying to get a higher paying job.
Earlier quoted context omitted.
This makes sure there is never 1.0 ever. I think this is one of the biggest mistake in software. We just keep rewriting things that are already doing what they supposed to. Like the Gmail UI. It got rewritten 3 times already and every iteration it gets shittier.
> every iteration it gets shittier I like how you state this like it's an objective fact. I've always been happy with the gmail UI and the latest iteration is great too. Outlook on the other hand...
The protocol buffers stuff seems pretty cool. At my last job (small web dev shop), we had constant headaches over the class definitions of endpoints changing and some js file not having its model updated to correspond. I thought we should be writing XML files that both ends could be reading in - we never got up the political will to make that big change though. https://developers.google.com/protocol-buffers/
Yep, protocol buffers are like a cross-language type system for the data that moves between systems with the side benefit of compact serialization. They're awesome and definitely a big productivity boost above a certain scale.
Earlier quoted context omitted.
So this is identical to squashing and rebasing your feature branch?
Technically yes, but people don’t use it and think about it this way. Changelists are supposed to be small, couple hundreds of line changes at most. You don’t develop a complete feature of thousands of lines in a single CL, that would be insanely hard to review. What happens is that work gets split into small chunks, and each one is submitted separately, not to feature branch, but straight to head.
The protocol buffers stuff seems pretty cool. At my last job (small web dev shop), we had constant headaches over the class definitions of endpoints changing and some js file not having its model updated to correspond. I thought we should be writing XML files that both ends could be reading in - we never got up the political will to make that big change though. https://developers.google.com/protocol-buffers/