Excellent time to slack off a bit, make a few mistakes, then come next eval you can point to a marked improvement over the intervening six-to-nine months!

The people who did the stuff have either gotten their promotions and moved on or didn't get a promotion and have given up.

:-)

My post is just a speculation, let's wait for the actual technical details doc from Google.

Regarding the technical details doc, Google will never state that outright in individual postmortems. And they will definitely not draw this to the logical conclusion regarding the spiky yearly activity.

Why is it logical? There’s tons of changes being deployed at all times, at all large companies.

Across products, verticals, everything - hundreds of changes at any given point. Some of these changes can introduce hard-to-predict bugs in globally distributed systems. Most of the time, external users don’t even notice before they’re fixed.

Like another commenter said, performance reviews do not coincide with with the year-end at Google and other companies.

Of course, I wouldn't go as far as to call this a "logical conclusion" as the evidence I've seen is very slim.

When are they? My bet is that they're roughly around the same time period, even if they don't start or close on December 31st.

We wrote evals in August. Anybody racing to get things launched before perf did so months ago. The timing described in the top post is just false.

We write the next one in February. We are almost exactly half way between perf cycles. Your hunch that this lines up with the end of the year is false.

I don't know how or if this would impact Google, but I'm sure someone there has at least thought about those dates.

Googler here, that is not when those promotion/perf evaluation windows happen.

I am not sure where to look for it

We barely understand the systems we’re writing code for - I don’t see how you could objectively judge the code to manage those systems without fully understanding the systems first.

You could have wave some metrics like number of bugs or test coverage, but I can’t think of any (aforementioned included) that aren’t subject to tons of confounding variables.

(Googler, opinions are my own)

Google's more interested in placating their primadonna engineers than solving customer problems.

If your company fires people in situations like this, run away and never look back.

People do absolutely NOT get fired over incidents. Making mistakes is human. An incident will prompt a review of the systems and safeguards in place to prevent such an incident, much like an airline incident investigation -

basically "somebody fat-fingered it" is never the answer, postmortems are always blameless

EDIT: now that I think of it, the opposite thing happens after a major incident - a systemic failure should be identified, people are being hired to fix it :)

Why do employees at big tech names (FAANG et al.) are so often so cautious as to include this as a foreword everywhere? Twitter bios are full of that, for instance.

It is crazy to me; who would expect anything else that our opinions being your own and nothing more? Who would expect that your word (with all due respect) is worth anything with regards to the company's PR?

Is there an actual risk in the US? Have there been trials or anything that push people to add such statements?

Basically the company has specially trained people that speak on behalf of the company, and that message should not be confounded by personal opinions of other employees. For example, on the recent FB outage, there was an employee posting inside information on reddit - media companies just took it at face value and ran around with it reporting as it was what FB itself was saying about the outage.

I'm not aware of any actual risks in the US, but then again I'm not in the US. For me this seems a minor point, and I actually enjoy separating my public persona from the company for which I work, being it Google or a small startup.

To be fair, I think the media would have done that even with a "speaking only for myself" disclaimer.

Dont name your company if you intend to speak for yourself.

Though I almost got to be the official spokesperson for British Telecom responding on the alt.2600 news group about the the Met police VMB hack - press office was cool but the internal security was not.

If no, why are you doing this for the company you're trading skills and time against money?

I didn't want to emphasize on that on the first comment yet to be honest, I find it pedantic because it's pointless, legally speaking.

This isn’t just ‘big tech’ - I work at a relatively small tech company, but I’d never want anything I say about the company to be mistaken as some sort of ‘official statement’ especially if it related to an incident that possibly had a financial impact on external parties, and could conceivably be misused in that context in the future.

I go as far as never writing private emails from my work mail for the same sort of reasons - although that is from a possibly over-abundance of caution.

Rumor mill journalists will mine social media and forum comments and write entire articles about "so and so FAANG employee gives hint at future merger" when some dev comments how much they've enjoyed using some library recently.

That's why we constantly get "it's just my opinion" used in reference to type-ii opinions (personal understanding of descriptive fact), when it's only really appropriate to type-i opinions (normative value).

Many conversations would be far clearer if it were abandoned in favour of more precise language, IMPUOTDF.

I think it's a bit over-applied in some cases. Does it not commit you to the theorem that every process can be made so perfect as to be completely invulnerable to one human being making a mistake? (At least, in the form exemplified by the common tweets to the effect that "your processes are to blame for $incident, not your interns/engineers/etc".)

Even if you required two-person auth for every single thing, two people will make a mistake now and then, and in reality - due to our being social animals - the two probabilities are not truly independent.

I just don't see how this is feasible in reality. A more realistic principle feels like: "people will infrequently make mistakes, and that's of course natural and human and forgiveable, but far fewer incidents should be vulnerable to human error than currently are".

$140 billion dollars. On training.

On the one hand... you know what, I'd love to work in an environment like that. Seriously.

On the other hand... what's the argument you make to the CFO in support of this? Honest question, interested to hear answers.

I don't know how much that costs all-in, including the salaries, instructors, facilities, but might be starting to approach a million.

That's valuing training!

For instance, if Google fails and cant profit, it cant just shoot at their client until they pay. Your organisation can.

Well we had to build an Army to win against fascism in the Second World War or we all would have perished.

And 'perished' means literally dead or subject to fascism, not just going out of business.

You want the Army to be... less efficient? Spend more for less capability?

But I'm glad that learning to kill people (military) is not taught that way.

The only time someone should be fired for causing an outage is if they're negligent or sloppy or mess things up all the time. This is rare. Almost always outages in large systems are the combination of many factors — latent bugs, design flaws, abnormal load, etc, any one or two of which wouldn't take the site down. But when the combine in a perfect storm that nobody foresaw things fall over.

100% of all devs make huge mistakes, at least once.

I'm not entirely sure that's always true. For example, i've seen people introduce N+1 issues into a codebase, spend evenings fixing them and refactoring code to fix production issues... just to later introduce those very same types of issues.

Sure, you can learn from mistakes, have post-mortems and so on (provided that your org even does those and that anyone listens and cares about the conclusions from those), but to me it feels like the most foolproof way is to ensure that no-one can make these mistakes again, be it with a checklist (which tend to be ignored, honestly), or better yet, an automated CI step or a new test suite.

In my eyes, it's basically the same as with unit tests - everyone agrees that you need them, but people rarely write enough of them. So if you introduce something to prevent them from not doing what they should, e.g. a quality gate within a CI step which will disallow a merge once the coverage falls below a set margin, suddenly things are a lot better in the long run.

>> a quality gate

Yes, this, also.

Depends on the project, i guess: if you're unlucky enough to be working on a monolith and suddenly a page takes 5'000 SQL queries to load as opposed to 100, because someone thought that initializing data through service/DB calls in a loop is "easier" than writing views in the DB, it might still kill the entire system anyways, depending on the count of users.

And once this data initialization is sufficiently complicated and convoluted for you not to be able to rewrite it and them not wanting to rewrite it, all while "the business" is breathing down on your neck, you might either want to introduce caching (and possibly run into cache invalidation problems down the road), or just freshen up your CV.

I guess i'd also like to expand on the previous suggestion and advise others to consider performance/load testing as well, especially when coupled with APM solutions like Skywalking or even Matomo analytics, both of which can allow you to aggregate the historical page load times, CPM and overall performance of your applications, to figure out what went wrong when.

Also, such cases are rarely the "fault" of a single person. Or, the direct/immediate cause is often not the main one.