The quote "Sorry this letter is so long, I didn't have the time to write a shorter one" (Mark Twain, Blaise Pascal, lots of debate) sticks with me over the years. I appreciated the several points from Addy supporting this idea: when writing code has never been easier and faster, it takes even more time to make sure that the code being written is truly useful and necessary.
Lessons from 14 years at Google
631–640 of 732 posts
Re: Lessons from 14 years at Google
#632This feels somewhat hypocritical coming from Addy. Addy Osmani plagiarized my code and 'apologized' years later by publishing an article on his website[1] that he has never linked to from his social media accounts. I cannot accept his apology until he actually syndicates it with his followers. Seems relevant to note this behavior in light of points "6. Your code doesn’t advocate for you. People do.", "7. The best cod…
You posted the code to a public blog page, with no attribution in the code or request of attribution from others, no license, and seemingly intended to share it freely with the world. Then you got an apology, and a second apology. I'm confused about what you think you're owed? The explanation makes perfect sense, the headers were obviously just copied with no malicious intent. What is it that is still bothering you a…
[deleted]
Re: Lessons from 14 years at Google
#633feels LLM assisted, at the very least. > The skill isn’t being right. It’s entering discussions to align on the problem > clarity isn’t a style preference - it’s operational risk reduction > The punchline isn’t “never innovate.” It’s “innovate only where you’re uniquely paid to innovate > This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone > The problem isn’t that engineers…
Even if it is AI assisted, the points are still valid and written in a way that is easy to understand.
Re: Lessons from 14 years at Google
#634Earlier quoted context omitted.
The problem with point 3 is that once you start with a bad draft and everyone starts working on it you're kind of locked in to its trajectory, even when it'd be a lot better if you were to do it another way. You can't start from scratch even if you're feasibly within the window to do so, because now the work has started.
But that is still better than nothing at all, which is the point. The people you want (or want to be) are the engineers who are smart and experienced enough to get a first draft down that is pretty much right without a long drawn out process of figuring out the best way to do X, Y and Z with all the lengthy ADRs, discussions, debates, POCs, revisions etc. over and over again. That may be necessary if you don't have p…
Tell that to Facebook's Metaverse team
Re: Lessons from 14 years at Google
#635Your code is a strategy memo to strangers who will maintain it at 2am during an outage. Optimize for their comprehension, not your elegance. The senior engineers I respect most have learned to trade cleverness for clarity, every time.
YES! And sometimes that stranger is you, 6 months down the line.
Re: Lessons from 14 years at Google
#636Earlier quoted context omitted.
So teach your kids to kiss ass and play poltiics. Or to stay far away and do something useful with their lives.
This is what I really don’t get about these types of folks. Do they really want to remember their life’s work as “kissing ass and playing politics”? I get the “work to live” and all that, but you’re basically tossing away half your life…for what, money? How much money do you need!?
For some, that's not only their competency but they enjoy it.
Is building relationships and status less worthwhile than building code or bridges or houses or painting pictures?
People get to choose the game they play.
Re: Lessons from 14 years at Google
#637My favorite is the first one, "The best engineers are obsessed with solving user problems." and what I hate about it is that it is super hard to judge someone's skills about it without really working with him/her for a very long time. It is super easier said than done. And it is super hard to prove and sell when everybody is looking for easily assessable skills.
This is why (flawed though the process may be in other ways), a company like Amazon asks "customer obsession" questions in engineering interviews. To gather data about whether the candidate appreciates this point about needing to understand user problems, and also what steps the candidate takes to try and learn the users' POV or walk a mile in their shoes so to speak.
Of course interview processes can be gamed, and signal to noise ratio deserves skepticism, so nothing is perfect, but the core principle of WHY that exists as part of the interview process (at Amazon and many many other companies too) is exactly for the same reason you say it's your "favorite".
Also IIRC, there was some internal research done in the late 2010s or so, that out of the hiring assessment data gathered across thousands of interviews, the single best predictor of positive on-the-job performance for software engineers, was NOT how well candidates did on coding rounds or system design but rather how well they did at the Customer Obsession round.
Re: Lessons from 14 years at Google
#638[dead]
Re: Lessons from 14 years at Google
#639>The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected
This one is golden, it should be framed and put in every engineer's office.
>Your network outlasts every job you’ll ever have.
Networking is the real human currency, period.
Re: Lessons from 14 years at Google
#640Earlier quoted context omitted.
When you're not shipping, you're not learning from users. As a result, it's easy to build working, correct, performant code which doesn't fit what anyone actually needs.
Figuring out what is useful for people is not some difficult problem that requires shipping half baked slop. That's just an excuse.
This is analagous to the problem of premature optimization - if you try to optimize performance without benchmarking, you end up eating a lot of time and effort on things that don't matter. Likewise for product: it is very easy to solve the wrong problems.