Google had (has?) a tongue-in-cheek achievement system built into the employee directory. Anyone can define a new achievement and award it to whomever, provided they can create (or pirate) a neat little icon for it. Lots of people have over the years – there must be thousands of distinct achievements possible, at this point.
It’s typical for a long-time Googler to have achieved hundreds of these. Nooglers used to compete with each other to earn as many as possible, or to specifically seek out rare or notable achievements.
Many of the ‘achievements’ were just sentimental milestones, e.g. for having submitted at least one code change. Others were basically just random, e.g. having entered a valid OTP code that’s all zeroes.
My favourite was the Evil Pacman.
Artists rendition. I don’t have an actual screenshot, alas.
This was awarded if you broke 75% (IIRC) or more of Google’s post-submit checks with a single change.
Most of Google’s code lives in a single repository – a vast “monorepo” that spans most of the company, storing billions of lines of code from hundreds (thousands?) of different projects & teams. It’s an incredible feat technically – it started as Perforce but was seamlessly replaced with an in-house reimplementation that scales better (among other major benefits) – and to this day it’s by far my favourite version control implementation.
One of the many benefits of that approach is that you can very easily share code. You can have a basic library for e.g. common string helper functions, that lives in a single location in the repo and is used by tens of thousands of engineers. You can know that at any given point in time the entire company is using the exact same version (at least in source control – obviously deployment is separate) and that everything is working perfectly.
Well, technically you ‘only’ know that every test is passing. But at Google there was (is?) a strong culture that tests define requirements – you couldn’t complain if someone broke your code, if you didn’t have a test that would reveal the breakage. Or, as it was most often put:
No dealing with countless independent repos and the nightmare that is dependency upgrades and integration testing (sigh, Git).
But one downside is the potential to break a lot of stuff at once. It’s not trivial to do so, of course – before any code change is submitted it nominally has to run all affected tests and pass all of them – but there are ways. 😈
Of course, breaking changes are rapidly reverted and no real harm is done, which is why this achievement can be viewed with perverse pride and not actual shame.
By my recollection few people had (have?) this achievement. Most folks don’t really get out much – they potter away in their little world, working on team-specific code, and so have little to no opportunity to break anything at scale (nor have a positive impact at scale, by the same token). I took an interest in lower-level libraries and large-scale refactoring initiatives, which is how I ultimately scored this achievement.
