Lessons From 14 Years at Google

But at the same time lessons aren't learned by reading what someone else has to say. They're learned by experience, and everyone's is different. An engineer with "14 years at Google" hardly makes them an expert at giving career advice, but they sure like to write like it does.

This type of article reads more like a promotion piece from self-involved people, than heartfelt advice from someone knowledgeable. This is evident from the author's "bio" page, written in 3rd person, and full of aggrandizing claims of their accomplishments, and photos with famous people they've met. I'm conditioned to tune out most of what these characters have to say.

If this is the type of people who excel in Big Tech, it must be an insufferable place to be.

Not just engineers, but basically everyone involved in creating products including designers and PMs.

Every single bullet point here is gold.

If the team mates have a different mindset, they see it as half baked or hacky. And if there is ever some bad feedback, they just use it as a "I told you so" and throw you under the bus.

In general I think the "ship fast and break things" mentality assumes a false dilemma, as if the alternative to shipping broken software is to not ship at all. If thats the mentality no wonder software sucks today. I'd rather teams shipped working, correct, and performant software even if it meant delaying additional features or shipping a constrained version of their vision. The minimalism of the software would probably end up being a net benefit instead of stuffing it full of half baked features anyways.

I've heard all the truisms listed in that post in my 14+ years at many companies that aren't Google and in all cases there's a major gap between the ideal and the reality.

This entire list reads to me as "I got paid 10s of millions of dollars to drink the Kool Aid, and I must say, the Kool Aid tastes great!"

Starting right is important.

Typing that first character on the page reveals the problems you didn't even know existed. You don't have a keyboard. You do, but it's not plugged in, and you have to move an unexpectedly heavy bookcase to reach the USB port. You need to learn Dvorak. You don't have page-creation privileges and need to open a ticket that will take a week to resolve. You can create the page, but nobody else is able to read it because their machines aren't allowed to install version of the page reader plugin that your page requires. And so on.

All these are silent schedule killers that reveal themselves only once you've shipped one full development (and deployment!) cycle. And as ridiculous as these example problems seem, they're not far from reality at a place as big and intricate as Google.

"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."

https://www.hyrumslaw.com/

I’ve followed that rule for decades and always regretted it when I couldn’t: projects were either too boring or too stressful except at the magic level of novelty.

I don't think this is consistently true - in particular, I think that a lot of current well-known practices around writing code result in code that implicitly relies on assumptions in another part of the system that can change without warning; and novelty is necessary in order to make those assumptions more solid and ultimately result in software that is less likely to break unexpectedly.

Simple example: You are not dealing with the complexity of process management of the OS, every time you start any application. Sometimes you might need to, if you are developing software. Or if your application hangs and you need to kill it via some task manager. Most users however, never deal with that, because it is abstracted "away". That's the whole point. Nevertheless, the actual complex work is always done. Behind the scenes.

https://www.hyrumslaw.com/

> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

Very important with this, is that not every work place sees your job as that, and you might get hired for the former while you believe it to be the latter. Navigating what is actually expected of you is probably good to try to figure out during the interview, or worst case scenario, on the first day as a new hire.

One of my early tasks as a junior engineer involved some automation work in a warehouse. It got assigned to me, the junior, because it involved a lot of time working in the warehouse instead of at a comfortable desk.

I assumed I’d be welcomed and appreciated for helping make their work more efficient, but the reality was not that simple. The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. So the more I reduced cycle times, the less time they had to sit around and chat.

Mind you, the original process was extremely slow and non-parallel so they had a lot of time to wait. The job was still very easy. I spent weeks doing it myself to test and optimize and to this day it’s the easiest manual labor job I’ve ever worked. Yet I as the anti-hero for ruining the good thing they had going.

Developers misunderstand what the users want, and then aren't able to accurately implement their own misunderstanding either. Users, in turn, don't understand what the software is capable of, nor what developers can do.

> Good intentions, hopes of correctness, wishful thinking, even managerial edict cannot change the semantics of the code as written or its effect when executed. Nor can they after the fact affect the relationship between the desires, needs, and requirements of users and the program […] implementation; nor between any of these and operational circumstances – the real world.

https://entropicthoughts.com/laws-of-software-evolution