The writing is excellent. Very correlated with the quality of the message I'd imagine.
The blog-post is AI generated or at least AI assisted.
Lessons from 14 years at Google
61–70 of 732 posts
Re: Lessons from 14 years at Google
#62They are pretty insightful. Particularly this one: > 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one. I have my own version of this where I tell people that no amount of good advice can help you make a blank page look better. You need to have some published work before you can benefit from any advice.
It is good only if the whole team believes it. 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.
If your self-esteem is sufficiently resilient, you can exploit the same human tendencies behind Cunningham's Law (the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer). Check your crappy end-to-end proof of concept into the team repository, and your teammates will be so horrified and outraged that they'll fix it faster than any sprint could have planned.
Re: Lessons from 14 years at Google
#63> " Writing forces clarity. The fastest way to learn something better is to try teaching it. " Something that seems lost on those using LLMs to augment their textual output.
This article is partly LLM generated or edited, fairly certain
I think it's inevitable everyone will use LLMs to assist with writing, such as editing, if it hasn't happen already. It's like having a free editor, beyond grammar or spell-checking.
Re: Lessons from 14 years at Google
#64> 4. Clarity is seniority. Cleverness is overhead.
Clarity is likely the most important aspect of making maintainable, extendable code. Of course, it’s easy to say that, it’s harder to explain what it looks like in practice.
I wrote a book that attempts to teach how to write clear code: https://elementsofcode.io
> 11. Abstractions don’t remove complexity. They move it to the day you’re on call.
This is true for bad abstractions.
> The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. (Dijkstra)
If you think about abstraction in those terms, the utility becomes apparent. We abstract CPU instructions into programming languages so we can think about our problems in more precise terms, such as data structures and functions.
It is obviously useful to build abstractions to create even higher levels of precision on top of the language itself.
The problem isn’t abstraction, it is clarity of purpose. Too often we create complex behavioral models before actually understanding the behavior we are trying to model. It’s like a civil engineer trying to build a bridge in a warehouse without examining the terrain where it must be placed. When it doesn’t fit correctly, we don’t blame the concept of bridges.
Re: Lessons from 14 years at Google
#65Earlier quoted context omitted.
> You can edit a bad page, but you can’t edit a blank one.
Ideally, yes, but the final result of LLM assisted textual output by many users shows that they often have neglected the editing part just as much as they have neglected the writing part.
Airplane meme: you only see the bad LLM or obviously LLM-assisted writing.
Re: Lessons from 14 years at Google
#66Earlier quoted context omitted.
I wish Google would be biased a little more towards quality and performance. Their user-facing products tend to be full of jank, although Gmail is quite good to be fair. 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, c…
I wish people who ship crappy software didn't ship it and would let someone else ship something better instead. It really sucks when the first mover / incumbent is some crappy half assed solution. But unfortunately we live in a world where quality is largely irrelevant and other USPs are more important. For example these little weekend projects that become successful despite their distinct lack of quality Linux kerne…
While we're wishing for things that are never going to happen, I wish users would stop adopting crappy half-assed first-mover software, causing them to gain momentum and become the defacto/dominant solution.
Re: Lessons from 14 years at Google
#67[dead]
Re: Lessons from 14 years at Google
#68I think part of the importance of being a senior engineer is not spreading hype through the industry. This appears to be the guy who just posted all over social media that they just got Claude and redid a year long project in a week, followed by tweets from his eng team clarifying its just “demo” grade.
Re: Lessons from 14 years at Google
#69The writing is excellent. Very correlated with the quality of the message I'd imagine.
The blog-post is AI generated or at least AI assisted.
many of the replies in this Hacker News thread read like AI replies too. I think the internet is dead as we know it. ~100% of content will be bots writing for ~100% audience of bots
Re: Lessons from 14 years at Google
#70seems the real lesson would be to not spend 14 years at google
I'm sure he made a killing though