[HN Gopher] Lessons from 14 Years at Google
___________________________________________________________________
Lessons from 14 Years at Google
Author : cdrnsf
Score : 666 points
Date : 2026-01-04 15:23 UTC (7 hours ago)
(HTM) web link (addyosmani.com)
(TXT) w3m dump (addyosmani.com)
| kayo_20211030 wrote:
| Every engineer should read this. It's a wonderful collection of
| heuristics that might seem banal, but which are shimmeringly
| true.
|
| The two that stand out are
|
| > Novelty is a loan you repay in outages, hiring, and cognitive
| overhead.
|
| and
|
| > Abstractions don't remove complexity. They move it to the day
| you're on call.
|
| as a warning against about being too, too clever.
| pcurve wrote:
| Agreed.
|
| Not just engineers, but basically everyone involved in creating
| products including designers and PMs.
|
| Every single bullet point here is gold.
| gdulli wrote:
| There's rarely a bullet point advantage that some new language
| or tech stack can offer me that would outweigh ten years of
| observation of how a familiar setup behaves in production, such
| that the space of unknown unknowns is reduced to almost
| nothing.
| simonw wrote:
| My personal rule is that the new technology stack item needs
| to either make is possible for me to build something that I
| couldn't have built without it, or needs to provide a
| productivity boost significant enough to overcome the
| productivity lost by straying from the more familiar path -
| even harder for team projects where multiple people need to
| learn the new component.
| kayo_20211030 wrote:
| Yeah. I'm in agreement there. I guess that it's an
| application of The Law of Least Surprise for a future
| developer (who might actually be me, which it often is)
| imiric wrote:
| Eh, sure.
|
| 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, 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.
| doublerabbit wrote:
| Mood. As someone who normally leaves after two years because
| the opportunity never raises to what was offered in the job
| spec these really don't for for me these bullet points as
| well wouldn't work for office culture in the EU.
|
| 15 Years worth of jobs and none gel. I'm a contractor now
| which feels more me. I have a contract length, don't have to
| deal with red tape political bullshit.
|
| Turn up, do work and leave when contract had ended.
| willi59549879 wrote:
| If you can easily acquire new projects and are happy with
| what you do, that can be very nice. I would probably fail
| at selling myself
| doublerabbit wrote:
| I've never needed to sell myself. $corp will advertise
| needing a contractor and you apply as usual. If you have
| the skills and experience you tend to get hired.
|
| The only difference is you don't get job security,
| pension or any perks. But you do get a lump sum though.
| Where you can then decide what's best.
| gosub100 wrote:
| And google wasn't founded by people who just kept their heads
| down and employed the simplest, most direct solution to the
| problem. If they had done that, google search would have been
| done on a super-fast server or mainframe using an RDBMS.
| morshu9001 wrote:
| Google still suffers the most from not understanding those two.
| Probably more than other companies.
| moffkalast wrote:
| Have they ever had an outage in recent years though? Pinging
| 8.8.8.8 is the gold standard of making sure there's internet
| in my book.
| morshu9001 wrote:
| GCP has had some multi-region outages
| apsurd wrote:
| The writing is excellent.
|
| Very correlated with the quality of the message I'd imagine.
| spiralcoaster wrote:
| It is very heavily filled with LLM-isms. The writing is bland
| AI output.
| apsurd wrote:
| how do you know?
|
| in the first item, LLMs don't use incomplete sentence
| fragments?
|
| > It's seductive to fall in love with a technology and go
| looking for places to apply it. I've done it. Everyone has.
| But the engineers who create the most value work backwards:
| they become obsessed with understanding user problems deeply,
| and let solutions emerge from that understanding.
|
| I suppose it can be prompted to take on one's writing style.
| AI-assisted, ok sure, but hmm so any existence of an em-dash
| automatically exposes text as AI-slop? (ironically I don't
| think there are any dashes in the article)
|
| EDIT: ok the thread below, does expose tells.
| https://news.ycombinator.com/item?id=46490075 - yep there's
| definitely some AI tells. I still think it's well
| written/structured though.
|
| > It's not X... it's Y.
|
| That one I can't unsee.
| croemer wrote:
| And have a look at the bio: https://addyosmani.com/bio/
|
| > His story isn't just about writing code, but about
| inspiring a community to strive for a better web. And
| perhaps the most exciting chapter is still being written,
| as he helps shape how AI and the web will intersect in the
| coming decade. Few individuals have done as much to push
| the web forward while uplifting its developers, and that
| legacy will be felt for a long time to come.
| rvz wrote:
| The blog-post is AI generated or at least AI assisted.
| paulpauper wrote:
| 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
| firefoxd wrote:
| They 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.
| rapidfl wrote:
| 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.
| sowbug wrote:
| 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.
| rapidfl wrote:
| yeah there are ways, but is it good for your career lol
|
| Also the one person who has to review it before checking in
| needs to be resilient too
| songodongo wrote:
| Bad feedback can be more helpful than good and is often the
| only type of feedback a product gets. And you may not have
| received that feedback if you didn't ship. It's better to get
| that information early.
| rapidfl wrote:
| I personally agree with the premise to ship early, with
| some rough edges, etc. But teammates may not be supportive.
| You need the whole team to have that mindset/culture.
| sowbug wrote:
| I liked that one, too, but for an additional reason.
|
| 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 the version of the
| PageReader(tm) plugin that your page requires (and you'd need a
| VP exception to downgrade your PageGenerator(tm) toolchain to
| their version). 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.
| llmslave2 wrote:
| 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, 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.
| samiv wrote:
| 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 kernel - free Unix.
|
| JavaScript - scripting in browser
|
| Python - sane "perl"
|
| Today on GitHub alone you can probably find 100 more featured
| and higher quality projects than any of these were when they
| launched but nobody cares.
| ryandrake wrote:
| 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.
| samiv wrote:
| That's the other side of the value added coin. Users
| sometimes find value even in the half assed software.
|
| Someone was once talking about the "solving the right
| problem wrong" vs "solving the wrong problem right".
| disqard wrote:
| > "solving the right problem wrong" vs "solving the wrong
| problem right".
|
| That's a really useful framing!
| willi59549879 wrote:
| how does the Linux kernel lack quality?
| ghaff wrote:
| It did in the early days, especially up until 2.4 which
| was generally considered the first enterprise-ready
| kernel version. (You can argue about whether the old
| "enterprise-capable" definitions still applied but they
| were a benchmark for a lot of people.) Of course, lots of
| ancillary stuff too in userspace and outside the kernel
| related to filesystems and the like.
| websiteapi wrote:
| existing is better than not existing and those who move
| fast and ship crappy software first will win. learn the
| lesson :)
| ghaff wrote:
| WRT Linux. Sure, 1991 or really even mid-90s Linux was
| clearly immature. But Wall Street was adopting it instead
| of Solaris by the turn of the century. Plus "open source"
| so it wasn't the case of a new proprietary Unix just
| emerging from the sea foam which no one wanted anyway but
| Linux becoming the good enough Unix standard which is what
| people did want.
| sdenton4 wrote:
| 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.
| anonymars wrote:
| I think you can also learn from users when they complain en
| masse about the current atrocious state of software
| quality. But I guess that doesn't show up in telemetry.
| Until it does. Looking at you, Microsoft!
| otterley wrote:
| I believe one of the main reasons why Windows 11 is
| getting so much vitriol is that Microsoft is focusing on
| _customers_ , which aren't always identical to users.
| Most of the time, when you buy a Windows-based device,
| you're not their customer: you're the OEM's customer, and
| for the OEM, every nickel of expenses counts. On the
| other hand, direct Microsoft licensees, such as corporate
| ("enterprise") customers, get much more attention from
| the company and a significantly better experience.
| llmslave2 wrote:
| Figuring out what is useful for people is not some
| difficult problem that requires shipping half baked slop.
| That's just an excuse.
| websiteapi wrote:
| ridiculous.
|
| > Figuring out what is useful for people is not some
| difficult problem that requires shipping half baked slop
|
| what have you shipped? paying sees literally hundreds of
| thousands of dollars a year to ship out fledged out
| software that no one wants is exactly why Stadia lasted
| both way too long and got cancelled anyway.
|
| figuring out what is useful is the hardest problem. if
| anything that's Google's biggest problem, not shipping
| fast enough, not iterating fast enough.
| llmslave2 wrote:
| Yeah if only Google shipped more crap software that they
| then go onto cancel, their software would be so much
| better!!!!!
| tjwebbnorfolk wrote:
| Same. Mine is: existence is the most important feature.
| crystal_revenge wrote:
| The problem is I've worked at at least 5 companies that
| professed a strong "bias for action" and it nearly _always_
| meant working nights and weekends to ship broken things that
| ultimately hurt the user and then moving on to the next big
| leadership project to do the same thing again, never looking
| back. The exception of course would be when leadership finds it
| 's broken in 5 months and complains about poor engineering
| practices and asking why engineers can never get things right.
|
| 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!"
| nickcw wrote:
| I like this one
|
| > At scale, even your bugs have users.
|
| Something I discovered the hard way over many years of
| maintaining rclone. Fixing a bug has consequences and there are
| sometimes users depending on that bug!
|
| xkcd: https://xkcd.com/1172/
| baal80spam wrote:
| Thank you for your work on maintaining rclone! It is a
| wonderful and very underappreciated piece of software.
| davelee wrote:
| I know this as Hyrum's Law (which also comes from a Googler):
|
| "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/
| davidw wrote:
| It's a good one: but it's also good to see that most of these
| are applicable to all kinds of organizations, not just "Google
| Scale" places.
| ThrowawayR2 wrote:
| > " _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.
| NitpickLawyer wrote:
| > You can edit a bad page, but you can't edit a blank one.
| ThrowawayR2 wrote:
| 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.
| paulpauper wrote:
| Airplane meme: you only see the bad LLM or obviously LLM-
| assisted writing.
| AnimalMuppet wrote:
| My father-in-law did a fair amount of editing back in the
| day (on paper, with red pencil/pen). He said that, when you
| saw something that had "blood" (red) all over it, that
| meant it was _good_. When things are bad enough, it becomes
| hard even to edit it.
|
| It may not be just that people _don 't_ edit LLM output. It
| may be that the stylistic blandness is so pervasive, it's
| just too much work to remove. (Yeah, _maybe_ you could do
| it. But if you were willing to spend that kind of effort,
| you probably wouldn 't have an LLM write it in the first
| place.)
| aprilthird2021 wrote:
| This article is partly LLM generated or edited, fairly certain
| paulpauper wrote:
| 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.
| aprilthird2021 wrote:
| The AI slop voice is grating to me and many others. If you
| can avoid it or make it not feel like slop or make it feel
| unique, people will like it more. I don't care how you do
| that tbh
| goostavos wrote:
| If the only reason you write is as a means to and end,
| sure. Inevitable. If you pursue it as a craft then the
| struggle and imperfections are part of the process. LLM
| usage would sand away those wonderful flaws.
| simonw wrote:
| I first learned about the "innovation tokens" idea in "Novelty is
| a loan you repay in outages, hiring, and cognitive overhead" from
| this, still one of my favorite essays on software architecture:
| https://boringtechnology.club/
|
| Likewise, "Abstractions don't remove complexity. They move it to
| the day you're on call." made me think of this 23 year old
| classic from Joel Spolsky, the Law of Leaky Abstractions:
| https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
| trescenzi wrote:
| > At scale, even your bugs have users.
|
| First place I worked right out of college had a big training
| seminar for new hires. One day we were told the story of how
| they'd improved load times from around 5min to 30seconds, this
| improvement was in the mid 90s. The negative responses from
| clients were instant. The load time improvements had destroyed
| their company culture. Instead of everyone coming into the
| office, turning on their computers, and spending the next 10min
| chatting and drinking coffee the software was ready before they'd
| even stood up from their desk!
|
| The moral of the story, and the quote, isn't that you shouldn't
| improve things. Instead it's a reminder that the software you're
| building doesn't exist in a PRD or a test suite. It's a system
| that people will interact with out there in the world. Habits
| with form, workarounds will be developed, bugs will be leaned for
| actual use cases.
|
| This makes it critically important that you, the software
| engineer, understand the purpose and real world usage of your
| software. Your job isn't to complete tickets that fulfill a list
| of asks from your product manager. Your job is to build software
| that solves users problems.
| jacquesm wrote:
| For close to a decade my business revolved around a common bug
| in both Microsoft and Netscape, the dominant browsers of the
| day. With every release we were thinking 'this time they'll fix
| it' and that would have caused us some serious headaches. But
| they never did!
| Donald wrote:
| I was curious what the commenter's business was, and found
| this post about HTTP protocol latency:
| https://jacquesmattheij.com/the-several-million-dollar-bug/
| hbs18 wrote:
| So what is the correct solution to that specific problem then,
| adjust loading time per customer?
| damethos wrote:
| Probably just let them vent until they adjust their habits
| and just chat with their co-workers, without the need to use
| this as an excuse. Then, they can enjoy the fast loading
| times :)
| ramijames wrote:
| Ignoring the users is the correct solution. Defining company
| culture through software loading is ridiculous.
| dchftcs wrote:
| Their bosses are likely happier for the lower downtime
| required to run the software anyway.
| DenisM wrote:
| What about the second order effects?
|
| Ignoring the customers becomes a habit, which doesn't lead
| to success.
|
| But then, caving to each customer demand will make solution
| overfit.
|
| Somewhere in there one has to exercise judgement.
|
| But how does one make judgment a repeatable process?
| Feedback is rarely immediate in such tradeoffs, so
| promotions go to people who are capable of showing some
| metric going up, even if the metrics is shortsighted. The
| repeatable outcome of this process is mediocracy. Which,
| surprisingly enough, works out on average.
| andsoitis wrote:
| > But how does one make judgment a repeatable process?
|
| Principles can help scale decision-making.
| alex1138 wrote:
| https://xkcd.com/1172/
| thelastgallon wrote:
| Hyrum's Law: https://www.hyrumslaw.com/
| kyrra wrote:
| This was well talked about in Hyrums Law, which came from a
| Googler as well.
|
| 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.
| mjevans wrote:
| I believe it.
|
| I also believe an off the shelf example of how to use the
| library correctly will save everyone a lot of pain later.
| TacticalCoder wrote:
| Craziest I got was users complaining their laptops were getting
| too hot / too noisey because I correctly parallelized a task
| and it became _too efficient_. They liked the speed but hated
| the fans going on at full speed and the CPU (and hence the
| whole laptop) getting really warn (talking circa 2010). So I
| had to artificially slow down processing a bit as to not make
| the fans go brrrrr and CPU go too hot.
| johannes1234321 wrote:
| That is https://xkcd.com/1172/
| kqr wrote:
| Lehman talked about the developer-software-user triad. Each of
| the three have a different understanding of the problem to be
| solved.
|
| 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
| embedding-shape wrote:
| > Your job isn't to complete tickets that fulfill a list of
| asks from your product manager. Your job is to build software
| that solves users problems.
|
| 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.
| Aurornis wrote:
| > The load time improvements had destroyed their company
| culture. Instead of everyone coming into the office, turning on
| their computers, and spending the next 10min chatting and
| drinking coffee
|
| 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.
| wiether wrote:
| > So the more I reduced cycle times, the less time they had
| to sit around and chat.
|
| Couldn't help but imagining Darryl getting mad at you.
|
| Thanks for the story!
| vkou wrote:
| > 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.
|
| The faster the LLM spits out garbage code, the more time I
| get to spend reviewing slop and dealing with it gaslighting
| me, and the less time I get to spend on doing the parts of
| the job I actually enjoy.
| devsda wrote:
| > Your job isn't to complete tickets that fulfill a list of
| asks from your product manager. Your job is to build software
| that solves users problems.
|
| The main benefit of understanding the purpose and real world
| usage of your software is that you can ask the right questions
| while planning and implementing the software/feature/bug-fix
| and that you don't make any wrong assumptions.
|
| In a situation where you have conflicting requirements or
| concerns regarding the change, you'll eventually be hit with
| "PM knows the product & customer better" or the explicit "your
| job is to deliver what is asked".
| taklimakan wrote:
| Yes nice but also very naive. Most developers do not have that
| level of ownership, nor know how their users interact with the
| software. Their job is _precisely_ to complete tickets from the
| product manager. The product manager is the one who should be
| in charge of UX research and "build a software that solves
| users problems." Sure, in abstract that is the mission of the
| developers too, but in any structured (and hopefully
| functional) team, product strategy is not what the software
| engineer should be concerned with.
| lukeschaefer wrote:
| Absolutely - one of my favorite bug with users was an
| application we had made in which the loading of a filtered view
| was so slow, that results would come in one-at-a-time, such
| that clicking 'select all' would only select those ones. When
| this was removed, users complained until we added shift-
| clicking to select groups of items
| xnx wrote:
| Nothing novel, but all true, well expressed, and worth repeating.
| This should be part of every CS curriculum.
|
| #2 and #14 are tough pills to swallow. It's not enough to be
| right, or even have a long track record of being right. You
| usually have to convince others that it was their idea all along,
| but still advocate for yourself at performance review time.
| api wrote:
| The biggest one that resonates with me is that cleverness is
| overhead.
|
| My #1 issue with mid level engineers is that they like complexity
| and find complexity fun and interesting.
|
| An experienced engineer knows that complexity is irritating and
| frustrating and that a simple solution is harder and superior.
|
| A solution that simultaneously solves the problem _and_ reduces
| complexity is almost the definition of genius. If you are good
| you will do this a few times in your whole career.
| elktown wrote:
| > A solution that simultaneously solves the problem and reduces
| complexity is almost the definition of genius.
|
| Well put. Chasing "How simple can we make this?" is a large
| part of what makes this job enjoyable to me. But it's perhaps
| not a good career advice.
| api wrote:
| Yeah, "resume driven development" is a second major force
| pushing complexity that I didn't mention. People want to be
| able to get experience with as many buzzwords and
| technologies and stacks as they can for obvious personal self
| interest reasons.
|
| The incentive is real. A great programmer who does a great
| job simplifying and building elegant maintainable systems
| might not get hired because they can't say they have X years
| experience with a laundry list of things. After all, part of
| their excellence was in making those things unnecessary.
|
| It's a great example of a perverse incentive that's
| incredibly hard to eliminate. The net effect across the
| industry is to cost _everyone_ money and time and
| frustration, not to mention the opportunity cost of what
| might have been had the cognitive cycles spent wrangling
| complexity been spent on polish, UI /UX, or innovation.
|
| There's also a business and VC level version of this. Every
| bit of complexity represents a potential niche for a product,
| service, or startup. You might call this "product portfolio
| driven development" which is just the big brother of "resume
| driven development."
| unlimit wrote:
| I am going to file this line
|
| > If you win every debate, you're probably accumulating silent
| resistance.
| ronbenton wrote:
| That one makes me uncomfortable, which is a bad sign...
| edonhametsu wrote:
| I'd say it's a good sign - at least now you're aware it might
| be happening. A worse sign would be thinking you're
| definitely not that sort of personality; you'd be accruing
| silent resentment from both being loud _and_ clueless.
| sseagull wrote:
| This is one of the Five Dysfunctions of a Team (fear of
| conflict, caused by absence of trust).
|
| Highly recommend the book.
|
| https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Tea...
| matwood wrote:
| Sun Tsu said you have to either give your opponent an out or
| completely destroy them. I've always said that you can only
| skin a sheep once but can shear them over and over. Or to be
| more blunt, it's better to be effective than right.
|
| It's about keeping the bigger/long term goals in mind. That
| means relationships and being an asshole.
| geodel wrote:
| Seems reasonable. Many points maybe more applicable
| Google/Google-like companies. With layoffs and overall job
| shortages a lot of workplaces are having a cake and eating it
| too. They demand fast delivery and taking shortcuts (calling it
| _creative thinking_ ) and once things blow up directly due to
| shortcuts put blame on developers / testers for taking shortcuts
| and compromising quality in the process.
| igtztorrero wrote:
| Great post, Years following Addy. I wonder know how he manages
| his time, in addition to being a leader at Google, and writing
| such a valuable blog.
| sefrost wrote:
| Unsure why this comment appears to be downvoted!
|
| I have followed him for a long time and learned a lot too. I
| always wonder the same thing about the "tech influencers" and
| I'd love to know more about how they structure their days.
|
| I find it difficult recently to sit down and complete a
| meaningful piece of work without being distracted by
| notifications and questions. In the last year this has been
| exacerbated by the wait time on LLMs completing.
|
| I would love to know how top performers organise their time.
| ethagnawl wrote:
| 14 years? Wild. I remember when Addy came into the scene hot with
| a new jQuery tutorial (what seemed like) every few days. To be
| clear, that's not a knock despite how it may read in 2026.
| sublimefire wrote:
| I'd agree on most of these but the biggest value in such a list
| is for the writer to actually put it on paper. You have to
| reflect on multiple aspects in your career and synthesise those.
| Reading them is close to useless, like scanning a page full of
| news, it all just evaporates once you start your daily work
| routine.
|
| The best suggestion would probably be to try and write such a
| list yourself IMO.
| suralind wrote:
| Thank you for sharing this. Well articulated.
| GuB-42 wrote:
| > At scale, even your bugs have users
|
| Also known as ossification. It is a term most often heard in the
| context of network protocols, but it applies more generally to
| every system where users depend on unspecified behaviors and even
| bugs.
|
| Reading about HTTP/3 and QUIC is interesting in that aspect. I
| first didn't understand the insistance on encryption. Turns out
| it is not just security and privacy, but by encrypting everything
| that is not strictly necessary for proper transport, you make it
| impossible for any "middlebox" to make assumptions they shouldn't
| make.
|
| I think similar approaches can be used by APIs. Never expose more
| than what is specified, treat the ability to access internal
| state as a bug, not because it is secret, but because if users
| start relying on it, internal changes that shouldn't break
| anything will.
| venkyvb wrote:
| Similar to Hyrum 's Law for APIs
| adamnemecek wrote:
| > Abstractions don't remove complexity. They move it to the day
| you're on call.
|
| Then they are bad abstractions. I get where he is coming from,
| but the entire field is built on abstractions that allow you to
| translate say a matmul to shuffling some electrons without you
| doing the shuffling.
| croemer wrote:
| I clicked through to the bio and am super confused. Third person,
| extremely long, lots of pictures with CEOs and smelling of LLM
| writing.
|
| Here's a sample:
|
| > His story isn't just about writing code, but about inspiring a
| community to strive for a better web. And perhaps the most
| exciting chapter is still being written, as he helps shape how AI
| and the web will intersect in the coming decade. Few individuals
| have done as much to push the web forward while uplifting its
| developers, and that legacy will be felt for a long time to come.
|
| https://addyosmani.com/bio/
| nostrademons wrote:
| He led Chrome DevRel for many years - if you were learning
| about new web platform technologies circa 2010-2015 you
| probably ran across his writing.
|
| The bio is cringe, but the important thing to realize about
| these professional-networking bios is that they are sales
| pitches, intended to sell a person (and specifically, their
| experience and connections) to a large corporation who will pay
| them even more money. An ordinary person, with ordinary
| authentic emotions, is not the intended audience. They're
| specifically selling to people whose job is to deal with
| bullshit.
| bakugo wrote:
| The linked post itself also reeks of LLM writing (negative
| parallelisms in every other paragraph). But sadly, it seems
| like this is just the new standard for highly upvoted front
| page posts.
| youngtaff wrote:
| Reading that bio makes you wonder if anyone else works at
| Google...
| jimmyl02 wrote:
| Usually there are nuggets of wisdom in lists shared like this but
| I feel like every lesson shared here has immense value.
|
| > "remain skeptical of your own certainty" > "Model curiosity,
| and you get a team that actually learns."
|
| These are two lessons that typically require battle scars to
| learn. For such big ideas to be summed into two sentences is
| pretty remarkable and puts to words lessons I wish I knew how to
| share. Amazing article, thanks for sharing!
| DougN7 wrote:
| I was going to skip the article until I read your comment, and
| wow! You're totally right - my hard won understanding is there,
| including things I sort of knew but couldn't put into words
| before. Going to share this with my adult kids.
| naijaboiler wrote:
| same usually, i read this and see this some flawed or hackneyed
| tripe. But these ones are actually true and anyone who has had
| a long career and led people and product will resonate with
| many of them.
| ronbenton wrote:
| >Abstractions don't remove complexity. They move it to the day
| you're on call.
|
| Damn that's a real one. Nothing like struggling through a bunch
| of indirection to figure out what the heck a clever abstraction
| was supposed to do
| nemo1618 wrote:
| 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 can't write code or use AI to do so.
| It's that we're so good at writing it that we forget to ask
| whether we should. This isn't passive acceptance but it is
| strategic focus. This isn't just about being generous with
| knowledge. It's a selfish learning hack. Insist on
| interpreting trends, not worshiping thresholds. The goal is
| insight, not surveillance. Senior engineers who say "I
| don't know" aren't showing weakness - they're creating
| permission.
|
| I'm so tired bros
| spiralcoaster wrote:
| Thank you for doing this. It allowed me to skip reading the
| article altogether immediately knowing it is AI generated slop.
| Usually I'm a little ways into it before my LLM detector starts
| going off, but these "This isn't X. It's Y." phrases are such a
| dead giveaway.
| papacj657 wrote:
| So glad I'm not the only one that noticed that.
|
| There's some really solid insights here, but the editing with
| AI to try to make up for an imperfect essay just makes the
| points they're trying to convey less effective.
|
| The lines between what is the author's ideas and what is AI
| trying to finish a half or even mostly baked idea just removes
| so much of the credibility.
|
| And it's completely counter to the "clarity vs cleverness" idea
| and the just get something out there instead of trying to get
| it perfect.
| aprilthird2021 wrote:
| It's just so disrespectful. I put my time in reading this. You
| (author) couldn't put some time into reading this once over
| before publishing?
|
| The points are generally good too, which is why the AI slop
| tone bothers me even more.
| ryandrake wrote:
| We should not bother to read things that the author didn't
| bother to write.
| misterchocolat wrote:
| that was an amazing read
| blibble wrote:
| seems the real lesson would be to not spend 14 years at google
| paulpauper wrote:
| I'm sure he made a killing though
| mgrat wrote:
| It isn't just that he made a killing -- Osmani helped
| conceive a broader vision of blogging as a fusion of human in
| the center writing and AI agents.
| croemer wrote:
| Or to say it in his own words: "Few individuals have done
| as much to push the web forward while uplifting its
| developers, and that legacy will be felt for a long time to
| come." source: https://addyosmani.com/bio/
| blibble wrote:
| > and that legacy will be felt for a long time to come
|
| yes, the legacy of polluting the internet with unlimited
| "AI" slop to the point it became useless
| surajrmal wrote:
| I don't quite understand how that is your take away. Could you
| clarify?
| johnmwilkinson wrote:
| > 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.
| kenferry wrote:
| I agree with you re: abstraction - one of the author's only
| points where I didn't totally agree.
|
| But also worth noting that whenever you make an abstraction you
| run the risk that it's NOT going to turn out increase clarity
| and precision, either due to human limitation or due to changes
| in the problem. The author's caution is warranted because in
| practice this happens really a lot. I would rather work with
| code that has insufficient abstraction than inappropriate
| abstraction.
| joshribakoff wrote:
| I 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.
| magicalist wrote:
| > _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_
|
| It would take less time than it did to write this comment to
| look it up and see that these are two different people.
|
| _Google engineer [Jaana Dogan] says Claude Code built in one
| hour what her team spent a year on_
| https://news.ycombinator.com/item?id=46477966
| AndrewKemendo wrote:
| This has to be the 50th or 100th version of this article that
| repeats the same thing
|
| Every single point in this article was already explicitly
| described between roughly 1968 and 1987: Brooks formalized
| coordination cost and the fallacy of adding manpower in The
| Mythical Man-Month
|
| Conway showed that system architecture inevitably mirrors
| organizational communication structure in 1968
|
| Parnas defined information hiding and modularity as
| organizational constraints, not coding style, in 1972
|
| Dijkstra *repeatedly warned* that complexity grows faster than
| human comprehension and cannot be managed socially after the fact
|
| None of this is new, reframed, or extended here; it is a faithful
| re-enumeration of half-century-old constraints.
|
| These lists keep reappearing because we refuse to solve is the
| structural one: none of these constraints are enforceable inside
| modern incentive systems.
|
| So almost like clockwork somebody comes out of nowhere saying hey
| I've I've observed these things that are consistently documented
| in history of organizational management and specifically
| computing and software management look at this list.
|
| It's so Exhausting
| DenisM wrote:
| The fact that people don't learn from the older books is
| somewhat annoying, but rewriting them makes sense precisely
| because people will likely trust it more.
|
| Software engineers are prone to novelty bias. Thats in contrast
| to some other demographic groups who very much prefer ancient
| texts.
| AndrewKemendo wrote:
| Well both of them are wrong because they can't walk the
| middle path
| dasil003 wrote:
| Yeah but what do you want to do about it? The engineers I see
| making these mistakes day-to-day are not going to connect the
| dots if I just point them to the seminal writings. Heck, half
| of their complaints are of the same form as yours: if only the
| majority of [engineers, colleagues, stakeholders] were aware of
| [A, B, C principles] then we could avoid repeating [X, Y, Z
| failures]. Yeah it's exhausting, life is exhausting, and it
| doesn't inherently get better with knowledge and experience as
| the gap to the lowest common denominator only increases; the
| only balm I've found is focusing on what I can control.
| AndrewKemendo wrote:
| Well for starters I literally organized our company and all
| engineering around Conway's law and it's working great
|
| That's like the absolute bare minimum you can do, it's
| trivially easy and solves a good half of these "problems."
| dasil003 wrote:
| How big is your company?
| AndrewKemendo wrote:
| A better question is how quickly are we growing...
|
| We're currently around 30 in engineering full time and 40
| if you include ops, logistics etc...with new funding and
| coming out of stealth etc we expect to hit the dunbar
| number (~150 this year)
| cmrdporcupine wrote:
| It's funny that I agree with most or all of these principles but
| don't feel like my 10 years at Google accord with most of this. I
| wouldn't say I learned these things at Google, but learned them
| before (and a bit after) and was continually frustrated about how
| many of them were not paid attention to at Google at all?
|
| Incentive structure inside Google is impaired.
|
| I do think Google engineering culture does bias against excessive
| abstraction and for clean readable code and that's good. But
| acting in the user's interest, timely shipping, etc... not so
| much.
| mji wrote:
| Maybe OP learned these things precisely because he saw the
| consequences of them not being done
| green_wheel wrote:
| #12 is so simple yet so true. Great list thanks for sharing.
| MinimalAction wrote:
| > _If you win every debate, you're probably accumulating silent
| resistance._
|
| This is very true in personal lives as well.
| petermcneeley wrote:
| This is actually slave morality:
| https://en.wikipedia.org/wiki/Master%E2%80%93slave_morality
|
| According to Nietzsche, masters create morality; slaves respond
| to master morality with their slave morality. Unlike master
| morality, which is sentiment, slave morality is based on
| ressentiment--devaluing what the master values and what the
| slave does not have. As master morality originates in the
| strong, slave morality originates in the weak. Because slave
| morality is a reaction to oppression, it vilifies its
| oppressors
| lukasb wrote:
| Wish I'd read this _before_ I started at Google.
| Scubabear68 wrote:
| > 1. The best engineers are obsessed with solving user problems.
|
| The author lost me right here.
|
| Not because he's wrong about this in general - he is not. But it
| seems to not be any kind of differentiator at Google. Maybe the
| opposite is true- make it as screwed up as physically possible,
| then make it a little worse, then release it - that seems a lot
| closer to the lesson Google engineers learn. As long as you are
| "first" and shipped it.
|
| Then get promoted, move on and meanwhile your crap code
| eventually gets the axe a decade later.
| ThinkBeat wrote:
| > First do it, then do it right, then do it better. Get the ugly
| prototype in front of users.
|
| Great, give users something that messy, horrible and not fully
| functional. Customer who spend big for production environments
| are exploited to "be the outsourced QA"
| morshu9001 wrote:
| It's ok if the users are internal
| drnick1 wrote:
| > Addy Osmani is a Software Engineer at Google working on Chrome
| and AI
|
| Thanks for all the spyware in Chrome ig? And for many inane
| design decisions that favor usability over privacy and security?
| hansmayer wrote:
| Not looking to dismiss the authors long tenure at a major tech
| company like Google, but the first point kind of stuck like a
| sore thumb. If the Google culture was at all obsessed about
| helping users, I wonder why Google UX always sucked so much and
| in particularly in the recent years seem to be getting even
| worse. Every single one of their services is a pain to use, with
| unnecessary steps, clicks - basically everything you are trying
| to do needs a click of sorts. Recently I was writing an e-mail
| and noticed I misspelled the e-mail address of the recipient,
| which I rarely do. So, I should just be able to click the address
| and edit it quickly, right? Wrong - now you have a popup menu and
| inside of it you have to search for "edit e-mail" option. Most of
| the rest of his lessons while valuable in their own right, are
| not something I would put under the headline of "after X years at
| <insert-major-tech-company>", as they do not quite seem to be
| that different from lessons you pick up at other companies ? I'd
| more interested to hear about how the culture was impacted when
| the bean-counters took over and started entshittifying the
| company for both the users and the employees too.
| embedding-shape wrote:
| > If the Google culture was at all obsessed about helping users
|
| It's worth noting that Osmani worked as a "developer
| evangelist" (at Google) for as long as I can remember, not as a
| developer working on a product shipped to users.
|
| It might be useful to keep that in mind as you read through
| what his lessons are, because they're surely shaped by the
| positions he held in the company.
| hansmayer wrote:
| Ah, I see. I did notice it looked a bit too long-winded and
| fluffy for a developer-written text.
| drewda wrote:
| Fair point. "User" as developer rather than "user" as person
| clicking buttons in Gmail, Google Maps, etc, etc
| luckylion wrote:
| I think that's more "this sounds great" than "our users are
| developers". Google's services also aren't aimed at
| developers, the APIs are often very bureaucratic and not
| very well done (there's no way to list the available google
| sheets documents in the sheets api, I need the drive API
| and a different set of permissions? please.)
|
| It reads exactly like what you'd expect from a "I want to
| be considered a thought leader" person: nothing you haven't
| read a hundred times but it sounds nice so you can nod
| along.
| techsystems wrote:
| >Osmani worked as a "developer evangelist" (at Google) for as
| long as I can remember, not as a developer
|
| Oh
| embedding-shape wrote:
| That's not a fair reading, he's as much of a developer as
| anyone else. But he wasn't (AFAIK) working on user-facing
| products specifically.
| alemanek wrote:
| I think it is more the point that the users for his job
| were external developers. The role is inherently user
| facing and user focused. I don't think anyone was trying
| to say he wasn't a developer just that his job wasn't to
| directly develop products
| embedding-shape wrote:
| Yeah, I guess I just wanted to add that because of the
| way that quote was cut at the end, made me believe that
| the person quoting me thought Osmani "isn't a developer".
| steve-atx-7600 wrote:
| You can learn something at a company by observing it's
| weaknesses as well as strengths
| RamblingCTO wrote:
| And material UI is still the worst of all UIs. Had the pleasure
| of rolling out a production oauth client ... jesus christ. Only
| worse is microsoft in UX. You don't want me to use your
| services, do you?
| embedding-shape wrote:
| > And material UI is still the worst of all UIs
|
| I'm not sure how that got approved either, but at least we
| now know what would happen if a massive corporation created a
| UI/UX toolkit, driven only by quantitative analytics making
| every choice for how it should be, seemingly without any
| human oversight. Really is the peak of the "data-driven
| decisions above all" era.
| websiteapi wrote:
| which company's product has great UX? I'm always seeing people
| hating on things without showcasing examples of what they think
| is exemplary
| addaon wrote:
| Omni Group. Wolfram. Parts of Apple. Rhino3D. Parts of
| Breville. Prusa (on device, not on desktop). Speed Queen
| (dial-based). Just from applications I currently have open
| and devices I can see from where I'm sitting.
| websiteapi wrote:
| I mean something that has a clear Google analog/equivalent
| that way can compare on. I personally think Wolfram Alpha
| (assuming that's what you're talking about) isn't any
| better than Google.
| addaon wrote:
| Never really used Alpha, was talking about Mathematica.
|
| I don't the the web is compatible with good UX, but that
| doesn't mean good UX isn't possible -- it just means that
| the companies that are successful at UX build native
| applications, or physical objects, or both.
| ajross wrote:
| No one's. Everyone sucks. Find a product and you'll find a
| population collating complaints about it. Whining about
| interface design is like the cheapest form of shared currency
| in our subculture.
|
| Fundamentally it's a bikeshed effect. Complaining about hard
| features like performance is likely to get you in trouble if
| you aren't actually doing the leg work to measure it and/or
| expert enough to shout down the people who show up to argue.
| But UI paradigms are inherently squishy and subjective, so
| you get to grouse without consequences.
| drnick1 wrote:
| None. A great UX nowadays is open source software running on
| your own hardware.
|
| For example, you couldn't pay me to use a "webmail" like
| GMail over my own IMAP server and Thunderbird.
| websiteapi wrote:
| why would a great UX be tied to the source being open or
| not?
| haunter wrote:
| Because if you don't like the UX you just edit the source
| code yourself and make it better /s
|
| /s but I wish it wasn't because a lot of FOSS evangelists
| have this mindset (here on HN too)
| fwip wrote:
| More seriously - open source software is resistant to
| enshittification. It's obviously not a panacea, but the
| possibility of forks (or just the user deciding not to
| update), combined with the difference in profit motive,
| tends to result in software that respects the user.
|
| (Taken holistically, the UX of software does not just
| mean the UI, or the moments when you are using the
| software. It also includes the stability of the software
| over time, including whether or not you are able to
| reject new versions whether you do not like.)
| whyagaindavid wrote:
| Wow.. you are the one loving thunderbird. The ridiculous
| idea of removing menubar and if you enable that - it wastes
| valuable screenspace.
| dystopiandevel wrote:
| How's that? VLC, GIMP, Ubuntu search and settings.
| Terrible. Great products, awedul UX.
| drnick1 wrote:
| VLC is great I think.
| Terr_ wrote:
| As somebody who already does this, I wouldn't say the
| _Thunderbird 's UX_ is the real motivation.
|
| I do it for autonomy and avoiding lock-in, but Thunderbird
| has some frustrating inconsistencies particularly in its
| mishmash of searching and filtering.
| Supermancho wrote:
| For the all the necessary complexity and race-to-the-bottom
| features, I am a fan of Jetbrains. I like using Uber, Twitch
| (wrote a plugin for it one weekend to integrate with chrome),
| Netflix, Discord. There are plenty of companies that manage
| to be enjoyable to end users and expose apis without the
| inscrutable abstractions and terminology I encounter using
| google products. It feels the same as working with Oracle.
| TeMPOraL wrote:
| > _Netflix_
|
| Netflix? The barely functional video player accessed via
| excessively bloated thumbnail gallery? About the only good
| thing to say about this is that all the other movie
| streaming platforms _somehow are even worse_.
| danielscrubs wrote:
| I would say basically everything that has won a an Apple
| Design Award before 2020.
|
| Things for macOS for example.
| hansmayer wrote:
| Its not hating - just stating the facts. Most companies
| unfortunately dont have a nice UX these days, because common
| UX practices like not making user think (i.e.
| overcomplicating the UIs) and not blocking users (showing
| annoying popups in the middle of UI workflows) somehow became
| a lost art. Some products are inherently easy to use like
| draw.io for example. I really like the UX on Stripe, in
| particular their onboarding process. There is also a semi-
| famous e-commerce company, in the furniture space. I forgot
| their name (something with W?), but I ordered something once,
| and was really impressed by how smooth and uncomplicated the
| process from browsing the inventory to checkout and delivery
| itself was.
| Aurornis wrote:
| The short answer is that the UI isn't optimized for users like
| you.
|
| I haven't worked for Google specifically, but at this scale
| everything gets tested and optimized. I would guess they know
| power users like you are frustrated, but they know you'll
| figure it out anyway. So the UX is optimized for a simpler
| target audience and possibly even for simpler help documents,
| not to ensure power users can get things done as quickly as
| possible.
| dtech wrote:
| I feel like you're giving too much credit here. I don't know
| if it was a leak or an urban legend, but I remember the awful
| win 8 "flat boxes UI" being that way because it could be
| designed by managers in PowerPoint that way
| rustystump wrote:
| This is almost certainly not the case. The larger the company
| the more change is viewed as a negative. Yes people may hold
| titles to do the things you describe but none are empowered
| to make change.
| hansmayer wrote:
| The specific feature in question...there is nothing "power"
| about it. It was a non-feature for decades essentially, I
| dont recall ever not being able to simply change an e-mail
| address by moving the cursor and typing in something else.
| How on earth is this something tested and optimised, for whom
| exactly?
| ignoramous wrote:
| > _wonder why Google UX always sucked so much and in
| particularly in the recent years seem to be getting even worse_
|
| UX? Google doesn't even bother helping folks locked out of
| their Gmail accounts. For people who use Android (some 3bn),
| that's like a digital death sentence, with real-world
| consequences.
|
| It is almost comical that anyone would think Google is
| customer-focused, but might if they were being paid handsomely
| to think otherwise, all the while drinking a lot of kool-aid.
|
| https://news.ycombinator.com/item?id=36024754 The top comment
| there is from a Xoogler which sums it up nicely:
| The thing is that at scale your edge cases are still millions
| of people. Companies love the benefits that come from scale,
| like having a billion people use their service, but they never
| seem to be capable of handling the other parts that come with
| it :(
|
| Google rakes in $100bn a quarter; that's $1bn every day.
| hansmayer wrote:
| That is a great point too. For a company which effectively
| does not have a customer service, how can they claim to be
| obsessing about helping users at all?
| stefanfisk wrote:
| Hell, in my experience they often don't even help ad
| customers that are having issues that prevent them from
| buying ads.
| dijit wrote:
| > If the Google culture was at all obsessed about helping
| users, I wonder why Google UX always sucked so much
|
| Ok, I mean this sincerely.
|
| You must never have used Microsoft tools.
|
| They managed to get their productivity suite into schools 30
| years ago to cover UX issues, even now the biggest pain of
| moving away is the fact that users come out of school trained
| on it. That also happens to be _their best_ UX.
|
| Azure? Teams? PowerBI? It's a total joke compared to even the
| most gnarly of google services (or FOSS tools, like Gerrit).
| hansmayer wrote:
| I do agree with you. Teams are a cancer and Azure UI sucks
| too. I do not use much MS products since essentially Win7 I
| have mainly used Linux as my work environment. But one thing
| MS used to be good at at least, was the documentation. If you
| are that old, you will remember each product came with
| extensive manuals AND there was an actual customer support.
| With google its like...not even that.
| ghaff wrote:
| There was also MSDN. But it was also a different world at
| the time.
| datadrivenangel wrote:
| With continuous delivery and access to preview and beta
| features, the documentation is fragmented and scattered and
| half of it technically is for the previous version of the
| product with a different name but still mostly works
| because microsoft can't finish modernizing most software...
|
| And the customer support is not great until you start
| really paying the big bucks for it.
| dijit wrote:
| > If you are that old, you will remember each product came
| with extensive manuals AND there was an actual customer
| support.
|
| But even then, contemporaries outclassed Microsoft by a
| lot.
|
| It was _culture_ back then to provide printed user manuals,
| I still have some from Sun Microsystems because it was the
| best resource I found to learn how storage appliances
| should work and the technical trade-offs of them.
| hansmayer wrote:
| Fair enough, everyone delivered software in boxes and
| with 500 page manuals. I still maintain MS did invest a
| lot in the quality of their documentation and they cared
| about developers - otherwise the Petzold series would
| have never happened (or the MS Press for that matter).
| dijit wrote:
| Ah yeah, fair, the Microsoft Press had some absolute
| bangers.
| hnlmorg wrote:
| I hate Microsoft with the passion of a thousand burning
| stars, yet even I still think Google products have worse UX
| than their Microsoft counterparts.
|
| MS Teams is definitely terrible. But I'd take that over
| Google Meets.
|
| Google Docs isn't even remotely as good as Office 365.
|
| And Azure, for all its many faults, is still less confusing
| than GCP.
|
| Thankfully I seldom have to touch either other these
| companies half-baked UIs.
| dijit wrote:
| > I'd take [teams] over Google Meets
|
| What? Why?
|
| Honestly your entire comment is almost exact polar opposite
| to how I feel.
|
| GCP Makes total sense if you know anything about systems
| administration, Google docs is _limited_ for things like
| custom fonts (IE; not gonna happen) but it 's simple at
| least and I can give people a link to click and it's gonna
| look the same for them.
|
| But, honestly, the Teams one is baffling. I can't think of
| a single thing Meet does worse than Teams.
| ipdashc wrote:
| Yeah that seriously whiplashed me too, I'm genuinely
| confused. Google Meets has always worked completely fine
| for me, good performance, works well on mobile, Firefox,
| etc. Nothing special but it works. Probably my favorite
| of all the meeting apps.
|
| Teams meanwhile is absolutely my least favorite, takes
| forever to load, won't work in Firefox, nags me to
| download the app, confusing UI. I don't think I've ever
| heard anyone say they like teams.
| kiwijamo wrote:
| I've used Meet a few times for video calls and I was
| amazed at how poorly it worked given the amount of
| resources Google has at their disposal. I've never had a
| good video call on Meets. I've had a few Meet calls where
| over time the resolution and bitrate would be reduced to
| such a low point I couldn't even see the other person at
| all (just a large blocky mess). Whereas Teams (for all
| its flaws) normally has no major issues with the video
| quality. Teams isn't without its flaws and I do
| occassionally fall back to ZOom for larger group video
| calls but at the end of the day Teams video calling sort
| of just works fine. Not great but not terrible either.
| YMMV of course.
| dijit wrote:
| I've had the complete opposite experience. Meet has been
| rock solid for me whilst Teams has been an absolute
| nightmare.
|
| The thing is though both Meet and Teams use centralised
| server architectures (SFUs: Selective Forwarding Units
| for Google, "Transport Routers" for Teams), so your
| quality issues likely come down to network routing rather
| than the platforms themselves. The progressive quality
| degradation you're describing on Meet sounds like
| adaptive bitrate doing its job when your connection to
| Google's servers is struggling.
|
| The reason Teams might work better for you is probably
| just dumb luck with how your ISP routes to Microsoft's
| network versus Google's. For me in Sweden, it's the
| opposite ... Teams routes my media through relays in
| France, which adds enough latency that people constantly
| interrupt each other accidentally. It's maddening.
| Meanwhile, Meet's routing has been flawless.
|
| But even if Teams works for your particular network
| setup, let's not pretend it's a good piece of software.
| Teams is an absolute resource hog that treats my CPU like
| a space heater and my RAM like an all-you-can-eat buffet.
| The interface is cluttered rubbish, it takes ages to
| start up, and the only reason anyone tolerates it is
| because Microsoft bundled it with Office 365.
|
| Your mileage definitely varies... sounds like you've got
| routing that favours Microsoft's infrastructure. Lucky
| you, I suppose, but that doesn't make Teams any less
| dogwater for those of us stuck with their poorly-placed
| European relays.
| jwr wrote:
| I was also surprised to read this. I have terrible problems
| with all Google UIs. I can never find anything and it's an
| exercise in frustration to get anywhere.
| gniv wrote:
| I have an issue with the first point as well, but differently.
| Having worked on a user-facing product with millions of users,
| the challenge was not finding user problems, but finding
| frequent user problems. In a sufficiently complex product there
| are thousands of different issues that users encounter. But
| it's non-trivial to know what to prioritize.
| mike_hearn wrote:
| _> If the Google culture was at all obsessed about helping
| users, I wonder why Google UX always sucked so much and in
| particularly in the recent years seem to be getting even
| worse._
|
| There was no beancounter takeover and it never was so obsessed.
| I worked there from 2006-2014 in engineering roles and found
| this statement was particularly jarring: _" User obsession
| means spending time in support tickets, talking to users,
| watching users struggle, asking "why" until you hit bedrock"_
|
| When I worked on user facing stuff (Maps, Gmail, Accounts) I
| regularly read the public user support forums and ticket queues
| looking for complaints, sometimes I even took part in user
| threads to get more information. What I learned was:
|
| * Almost nobody else in engineering did this.
|
| * I was considered weird for doing it.
|
| * It was viewed negatively by managers and promo committees.
|
| * An engineer talking directly to users was considered
| especially weird and problematic.
|
| * The products did always have serious bugs that had escaped QA
| and monitoring.
|
| In theory there were staff paid to monitor these forums, but in
| practice the eng managers paid little attention to them - think
| "user voice" reports once a quarter, that sort of thing. Partly
| that's because they weren't technical and often struggled to
| work out whether a user complaint was just noise or due to a
| genuine bug in the product, something often obvious to an
| engineer, so stuff didn't get escalated properly.
|
| This general disconnection from the outside world was
| pervasive. When I joined the abuse team in 2010 I was surprised
| to discover that despite it having existed for many years, only
| one engineer was bothering to read spammer forums where they
| talked to each other, and he was also brand new to the team. He
| gave me his logins and we quickly discovered spammers had found
| bugs in the accounts web servers they were using to blow past
| the antispam controls, without this being visible from any
| monitoring on our side. We learned many other useful things by
| doing this kind of "abuser research". But it was, again, very
| unusual. The team until that point had been dominated by ML-
| heads who just wanted to use it as a testing ground for model
| training.
| p1esk wrote:
| _Almost nobody else in engineering did this._
|
| What you described is the job of a product manager. Are there
| no PMs at Google?
| Xorlev wrote:
| There are, and often times they're stuck in a loop of
| presenting decks and status, writing proposals rather than
| doing this kind of research.
|
| That said, interpreting user feedback is a multi-role job.
| PMs, UX, and Eng should be doing so. Everyone has their
| strengths.
|
| One of the most interesting things I've had a chance to be
| a part of is watching UX studies. They take a mock (or an
| alpha version) and put it in front of an external volunteer
| and let them work through it. Usually PM, UX, and Eng are
| watching the stream and taking notes.
| stefan_ wrote:
| PM is a fake job where the majority have long learned that
| they can simply (1) appease leadership and (2) push down on
| engineering to advance their career. You will notice this
| does not actually involve understanding or learning about
| products.
|
| It's why the GP got that confused reaction about reading
| user reports. Talk to someone outside _big company_ who has
| no power? Why?
| kmoser wrote:
| I've had the pleasant experience of having worked for PMs
| at several companies (not at Google) who were great at
| their jobs, and advocated for the devs. They also had no
| problem with devs talking directly with clients, and in
| fact they encouraged it since it was usually the fastest
| way to understand and solve a problem.
| potatoproduct wrote:
| Sounds like you just got stuck with a shit PM to be
| honest.
| lovich wrote:
| Almost every job in the US is primarily about pleasing
| leadership at the end of the day.
|
| If companies didn't want that sort of incentive structure
| to play out then they would insulate employees from the
| whims of their bosses with things like contracts or
| golden parachutes that come out of their leaderships
| budget.
|
| They pretty much don't though, so you need to please your
| leadership first to get through the threat of at will
| employment, before considering anything else.
|
| If you're lucky what pleases your leadership is
| productive and if your super lucky what pleases them even
| pleases you.
|
| Gotta suck it up and eat shit or quit if it doesn't
| though
| javawizard wrote:
| Xoogler here.
|
| When you get to a company that's that big, the roles are
| much more finely specialized.
|
| I forget the title now, but we had someone who interfaced
| with our team and did the whole "talk to customers" thing.
| Her feedback was then incorporated into our day-to-day
| roadmap through a complex series of people that ended with
| our team's product manager.
|
| So people at Google do indeed do this, they just aren't
| engineers, usually aren't product managers, frequently are
| several layers removed from engineers, and as a consequence
| usually have all the problems GP described.
| jedberg wrote:
| > only one engineer was bothering to read spammer forums
| where they talked to each other, and he was also brand new to
| the team
|
| This revelation is utterly shocking to me. That's like anti-
| abuse 101. You infiltrate their networks and then track their
| behavior using your own monitoring to find the holes in your
| observability. Even in 2010 that was anti-abuse 101. Or at
| least I think it was, maybe my team at eBay/PayPal was just
| way ahead of the curve.
| mike_hearn wrote:
| Well, the 101 idiom comes from US education, it's a
| reference to the introductory course. Part of the problem
| with anti-abuse work is that there's no course you can take
| and precious little inter-firm job hopping. Anti-abuse is a
| cost of business so you don't see companies competing over
| employees with experience like you do in some other areas
| like AI research. So it's all learning-by-doing and when
| people leave, the experience usually leaves with them.
|
| After leaving Google the anti-abuse teams at a few other
| tech companies did reach out. There was absolutely no
| consistency at all. Companies varied hugely in how much
| effort and skill they applied to the problem, even within
| the same markets. For payment fraud there is a lot of money
| at stake so I'd expect eBay would have had a good team, but
| most products at Google didn't lose money directly if there
| was abuse. It just led to a general worsening of the UX in
| ways that were hard to summarize in metrics.
| jeffbee wrote:
| I seem to recall sitting in weekly abuse team meetings
| where one of the metrics was the price of a google
| account on the black market. So at least some of these
| things were tracked and not just by one individual.
| damethos wrote:
| Hey Mike! Alex from GR here. Good to see you around :)
| moffkalast wrote:
| > User obsession means spending time in support tickets
|
| That's really funny when Google's level of customer support
| is known to be non-existent unless you're popular on Twitter
| or HN and you can scream loudly enough to reach someone in a
| position to do something.
| avidiax wrote:
| Every previous job I've had has a similar pattern. The
| engineer is not supposed to engage directly with the
| customer.
|
| I think there are multiple reasons for this, but they are
| mostly overlapping with preserving internal power structures.
|
| PM's don't want anecdotal user evidence that their vision of
| the product is incomplete.
|
| Engineering managers don't want user feedback to undermine
| perception of quality and derail "impactful" work that's
| already planned.
|
| Customer relations (or the support team, user study, whatever
| team actually should listen to the user directly) doesn't
| want you doing their job better than they can (with your
| intimate engineering and product knowledge). And they don't
| want you to undermine the "themes" or "sentiment" that they
| present to leadership.
|
| Legal doesn't want you admitting publicly that there could be
| any flaw in the product.
|
| Edit: I should add that this happens even internally for
| internal products. You, as a customer, are not allowed to
| talk to an engineer on the internal product. You have to fill
| a bug report or a form and wait for their PMs to review and
| prioritize. It does keep you from disturbing their engineers,
| but this kind of process only exists on products that have a
| history of high incoming bug rate.
| martinpw wrote:
| Engineers have a perception that most other roles are
| lesser and if only they were allowed to be in charge things
| would go better. I certainly used to be this way. When I
| was an engineer I used to regularly engage directly with
| customers, and it was great to be able to talk with them
| one to one, address their specific issues and feel I was
| making a difference, particularly on a large product with
| many customers where you do not normally get to hear from
| customers much. Of course once these customers had my ear,
| the feature requests started to flow thick and fast, and I
| ended up spending way too much time on their specific
| issues. Which is just to say that I've changed my views
| over time.
|
| In retrospect, the customers I helped were ones that had
| the most interesting problems to me, that I knew I could
| solve, but they were usually not the changes that would
| have the biggest impact across the whole customer base. By
| fixing a couple of customers' specific issues, I was making
| their lives better for sure, and that felt good, but that
| time could have been used more effectively for the overall
| customer base. PMs, managers etc should have a wider view
| of product needs, and it is their job to prioritize the
| work having that fuller context. Much as I felt at the time
| that those roles added little value, that was really not
| true.
|
| Of course agreed that all the points made above for PMs,
| managers, support having their reasons to obstruct are true
| in some cases, but for a well run company where those roles
| really do their job (and contrary to popular opinion those
| companies do exist), things work better if engineers do not
| get too involved with individual customers. I guess Google
| might be a good example - if you have a billion customers
| you probably don't want the engineers to be talking to them
| 1:1.
| wood_spirit wrote:
| It's oblique but this puts me in mind of an old adage I
| recently heard about war: Of 100 men, one should be a
| warrior, nine should be soldiers, and 90 shouldn't be
| there at all.
|
| I think this is true of software developers too: only in
| companies, the 90% don't really know they shouldn't be
| there and they build a whole world of systems and
| projects that is parallel to what the company actually
| needs.
| librasteve wrote:
| this
|
| and I speak as one of the 90%
| liveoneggs wrote:
| every customer complaint is N customers lost who don't
| say anything
|
| "the biggest impact" isn't knowable so a bird in hand is
| worth more than whatever might be in the bush
| majormajor wrote:
| If you have M customer complaints, and each one risks a
| differently-sized N customers... you better try to triage
| that vs just playing whack-a-mole with whatever comes to
| a random engineer first. I've never seen engineers plow
| through a bunch of 0-or-1-customers-would-actually-churn-
| over-this papercuts because it was easy and it feels good
| - the customer mentioned it! i fixed it! - while ignoring
| larger showstoppers that are major customer acquisition
| and retention barriers.
|
| Nothing is knowable in only the same way that plans are
| useless but planning is essential.
| Rapzid wrote:
| This reads like it was written by a PM. You lacked higher
| level context and prioritization skills early in your
| career so the take away is it's best to divest agency to
| others?
|
| There is a whole modern line of thinking that leaders
| should be providing the context and skills to give high
| performing teams MORE agency over their work streams.
| majormajor wrote:
| There's not enough hours in the day for everyone to do
| everything.
|
| > There is a whole modern line of thinking that leaders
| should be providing the context and skills to give high
| performing teams MORE agency over their work streams.
|
| Yes, this is great for agency over implementation,
| because leaders do not have context to decide and dictate
| the What/How of implementing every single change or
| solution to a problem. And the implementers need to know
| the context to ensure they make decisions consistent with
| that context.
|
| But "leaders providing the context" is very different
| from "everyone researching the context on their own." So
| where are leaders getting this context from? A not-very-
| differentiated pile of 1000 generalist engineers-who-
| also-talk-to-customers-frequently-and-manage-their-own-
| work-streams? Or do they build a team with specialists to
| avoid needing the majority of people to constantly
| context-switch in a quest to be all of context-gatherers,
| work-prioritizers, market-researchers, and
| implementation-builders?
| andrewprock wrote:
| There are many leaders that use information as a tool
| that serves their own needs.
|
| They may have the context, but they are either too
| focused on their own job to share it, or actively manage
| dissemination so they can manipulate the organization.
|
| In my experience, this is the typical operating mode,
| though I do not think it is sinister or malicious - just
| natural.
| Rapzid wrote:
| Poor leaders gonna lead poorly.
| avidiax wrote:
| I think he has a point. These power structures exist for
| some good reasons as well.
|
| The opposite thing (engineers engaging directly with
| customers) can eventually lead to customer capture of
| your engineering org. You shouldn't have a small group of
| existing, noisy customers directly driving your
| engineering to the detriment of other existing or future
| customers.
|
| Microsoft had customer capture institutionally: the
| existing big corporate customers were all that mattered.
| It lead to rebooting Windows CE into Windows Mobile way
| too late to make a difference, for example. But it also
| meant that backwards compatibility and the desire to ship
| Windows XP forever were sacred cows.
|
| There are also nasty games that can be played by
| soliciting negative feedback for political advantage.
|
| Dysfunction can exist with any structure. It's probably
| best that there's some small amount of direct user
| feedback as well as the big formalized feedback systems,
| at least so that one is a check for the performance of
| the other. If the user engagement team says everything is
| good, but there are massive Reddit threads about how
| horrible the product is to work with and the engineers
| know it could be better, it's time for engineering to
| start addressing the issues alongside feedback to the
| user engagement teams.
| palata wrote:
| > Engineers have a perception that most other roles are
| lesser
|
| Do they? I always felt I was at the bottom of the chain.
| "Moving up" means leaving engineering and going into
| management.
|
| > and if only they were allowed to be in charge things
| would go better.
|
| Could this be an oversimplification? Engineers understand
| how the product is built because they are the ones
| building it. And sometimes they are exposed to what other
| people (e.g. product people) have decided, and they know
| a better way.
|
| As an engineer, I am always fine if a product person
| listens to my saying that "doing it this way would be
| superior from my point of view", somehow manage to prove
| to me that they understood my points, but tell me that
| they will still go a different direction because there
| are other constraints.
|
| Now I have had many product people in my career who I
| found condescending: they would just dismiss my opinion
| by saying "you don't know because you don't have all the
| information I have, and I don't have time to convince
| you, so I will just go for what you see as an inferior
| way and leave you frustrated". Which I believe is wrong.
|
| Overall, I don't make a hierarchy of roles: if I feel
| like someone is in my team, I play with them. If I feel
| like they are an adversary, I play against them. I don't
| feel like I am superior to bad managers or bad product
| people; I just feel like they are adversaries.
| mixmastamyk wrote:
| An org can always go too far in the opposite direction,
| but this is not an excuse to never talk to the customer.
| The latter is much more likely, so the warning to not get
| "into bed" with the customer falls flat.
|
| This is a common pattern here. Alice says 0 degrees is
| too cold, I prefer 20C, Bob chimes in "100C is too hot,
| it'll kill us." Ok, well no one said or implied to crank
| it to one hundred.
| majormajor wrote:
| There are very good less-cynical reasons. I've also seen
| companies with the opposite problem, where the engineers
| constantly shoot down real, important feedback brought by
| customer support in order to preserve the superiority of
| engineering over support.
|
| If you have ten engineers and even just 100 customers, you
| have a very high number of conversational edges. Good luck
| keeping things consistent and doing any sort of long-term
| planning if engineers are turning the output of those
| conversations directly into features. "Engineers talking to
| customers but not making any changes" would be more stable,
| but is still a very expensive/chaotic way to gather
| customer feedback.
|
| Additionally, very few of those single engineers have a
| full knowledge of the roadmap and/or the ability to
| unilaterally decide direction based on some of the customer
| feedback or questions. "Will this get fixed in the next two
| weeks?" "Will you build X?" etc. You don't want your
| customers getting a bunch of inconsistent broken promises
| or wrong information.
|
| The best-managed orgs I've seen have pretty heavy
| engineering and user experience in their product and
| support orgs. You need people in those roles with knowledge
| of both how it's built AND how it should be used, but you
| can't continually cram all that knowledge into every single
| engineer.
|
| A startup should start with the builders talking directly
| to the customers. But at a some point, if successful,
| you're going to have too many people to talk to and need to
| add some intermediaries to prevent all your engineering
| time going to random interrupts, and centralization of
| planning responsibilities to ensure someone's figuring out
| what's actually the most important feedback, and that
| people are going to work on it.
| andrewprock wrote:
| On the contrary, the best products are typically built by
| the users of the products. If you are building a product
| you don't use, it will be worse than if you used it.
|
| Users should be everywhere, in and out of engineering.
| azangru wrote:
| > The engineer is not supposed to engage directly with the
| customer.
|
| I don't know if companies have finally stopped pretending
| to be "agile"; but if not, this is such a clear
| demonstration of how they are anything but.
| imperio59 wrote:
| The sad thing is it doesn't have to be this way.
|
| I worked on an internal tools team for a few years and we
| empowered engineers to fix user issues and do user support
| on internal support groups directly.
|
| We also had PMs who helped drive long term vision and
| strategy who were also actively engaging directly with
| users.
|
| We had a "User Research" team whose job it was to compile
| surveys and get broader trends, do user studies that went
| deep into specific areas (engineers were always invited to
| attend live and ask users more questions or watch raw
| recordings, or they could just consume the end reports).
|
| Everyone was a team working together towards the same goal
| of making these tools the best for our internal audience.
|
| It wasn't perfect and it always broke down when people
| wanted to become gatekeepers or this or that, or were vying
| for control or power over our teams or product. Thankfully
| our leadership over the long term tended to weed those
| folks out and get rid of them one way or another, so we've
| had a decent core group of mid-level and senior eng who
| have stuck around as a result for a good 3 years (a long
| time to keep a core group engaged and retained working on
| the same thing), which is great for having good
| institutional knowledge about how everything works...
| jordwest wrote:
| > Every previous job I've had has a similar pattern. The
| engineer is not supposed to engage directly with the
| customer.
|
| Chiming in to say I've experienced the same.
|
| A coworker who became a good friend ended up on a PIP and
| subsequently fired for "not performing" soon after he
| helped build a non technical team a small tool that really
| helped them do their job quicker. He was wasn't doing
| exactly as he was told and I guess that's considered not
| performing.
|
| Coincidentally the person who pushed for him to be fired
| was an ex-Google middle manager.
|
| I've also seen so commonly this weird stigma around
| engineers as if we're considered a bit unintelligent when
| it comes to what users want.
|
| Maybe there is something to higher ups having some more
| knowledge of the business processes and the bigger picture,
| but I'm not convinced that it isn't also largely because of
| insecurity and power issues.
| globalnode wrote:
| Theres another thread on HN at the moment about legislation
| being written by industry and rubber stamped by law makers.
| What hit me about this discussion and that one is that
| there's a lot of self interest out there with very little
| scrutiny or auditing. It boils down to that basically. If
| we want to fix problems at the top there needs to be
| independent auditing, reporting and consequence for people
| that do the wrong thing. But we all know thats not going to
| happen so buckle up and learn to live with broken laws and
| broken software.
| hansmayer wrote:
| Thanks for sharing your valuable insights. I am quite
| surprised to learn that talking to customers was frowned upon
| at Google (or your wider team at least). I find that the
| single most valuable addition to any project - complementary
| to actually building the product. I have a feeling a lot of
| the overall degradation of software quality has to do with a
| gradual creep in of non-technical people into development
| teams.
| agumonkey wrote:
| I love reading this insights in a corp structure. Especially
| the sociological aspect of it (like "* It was viewed
| negatively by managers and promo committees."). Thanks a lot.
| multjoy wrote:
| It is an almost universal fact that dealing with retail
| customers is something that is left to the lowest paid,
| lowest status workers and often outsourced and now
| increasingly left to LLM chatbots.
|
| While you obviously can't have highly paid engineers tied up
| dealing with user support tickets, there is a lot to be said
| for at least some exposure to the coal face.
| beloch wrote:
| "10. In a large company, countless variables are outside your
| control - organizational changes, management decisions,
| market shifts, product pivots. Dwelling on these creates
| anxiety without agency.
|
| The engineers who stay sane and effective zero in on their
| sphere of influence. You can't control whether a reorg
| happens. You can control the quality of your work, how you
| respond, and what you learn. When faced with uncertainty,
| break problems into pieces and identify the specific actions
| available to you.
|
| This isn't passive acceptance but it is strategic focus.
| Energy spent on what you can't change is energy stolen from
| what you can."
|
| ------------------------
|
| Point 10 makes it sound like the culture at Google is to stay
| within your own bailiwick and not step on other people's
| toes. If management sets a course that is hostile to users
| and their interests, the "sane and effective" engineers stay
| in their own lane. In terms of a company providing services
| to users, is that really being effective?
|
| User interests frequently cross multiple bailiwicks and bash
| heads with management direction. If the Google mindset is
| that engineers who listen to users are "weird" or not
| "sane"/"effective", that certainly explains a lot.
| zelphirkalt wrote:
| If an engineer talking to users is considered problematic,
| then it is safe to assume, that Google is about as fast away
| from any actually agile culture as possible. Does Google ever
| describe itself as such?
| abustamam wrote:
| Having only ever worked for startups or consulting agencies,
| this is really weird to me. Across 6 different companies I
| almost always interfaced directly with the users of the apps
| I built to understand their pain points, bugs, etc. And I've
| always ever been an IC. I think it's a great way to build
| empathy for the users of your apps.
|
| Of course, if you're a multi billion dollar conglomerate,
| empathy for users only exists as far as it benefits the
| bottom line.
| fooker wrote:
| The beancounter takeover was after you left.
|
| 2014 Google and 2019 Google were completely different
| companies.
| Bombthecat wrote:
| It's not just Google, the UX is degrading in... Well
| everything. I think it's because companies are in a duopole,
| monopole etc position.
|
| They only do what the numbers tell them. Nothing else and UX
| just does not matter anymore.
|
| It's like those gacha which make billions. Terrible games,
| almost zero depth, but people spend thousands in them. Not
| because they are good, but because they don't have much choice
| ( similar game without gacha) and part the game loop is made
| for addiction and build around numbers.
| Terr_ wrote:
| To offer some additional causes for the degradation of UX:
|
| 1. An increasing part of industry profits started coming from
| entertainment (or worse, psychological exploitation) instead
| of selling the customer a _useful tool_. For example, good
| budgeting-software has to help the user understand and model
| and achieve a goal, while a "good" slot-machine may benefit
| from confusion and distraction and a giant pull-handle.
|
| 2. "Must work on a touchscreen that fits in a pocket" support
| drags certain things to a lowest common denominator.
|
| 3. UX as a switching-cost for customers has started happening
| more on a per-product rather than a per-OS basis. Instead of
| learning the Windows or Mac "way" of screens and shortcuts,
| individual programs--especially those dang Electron apps--
| make their own reinventions of the wheel.
| whyagaindavid wrote:
| This is definitely an edge case. Most UI/UX from Google is very
| consistent and just works. Otherwise they won't be in this
| market.
|
| Only UI/UX issue is that most experienced users want to not
| adapt to change. It is like people always telling Windows 7 is
| the best. Don't keep reinventing.
|
| Another one that irks me is every UI/UX dev assumes people have
| 2 x 4K monitors and menu items overflow.
| hansmayer wrote:
| > Only UI/UX issue is that most experienced users want to not
| adapt to change
|
| Users will not only adapt, but will even champion your
| changes _if_ they make sense to said users. For example the
| web checkout or to name a more drastic example, iPhone and
| fingers as user interface devices. Once you start convincing
| the users that the interface is great, but they are too
| resistant to changes /dumb/uncreative to know how use it...
| its a different story I'd reckon ;)
| lkjdsklf wrote:
| I think the UX issues you're describing are less related to
| culture changes in companies and more just in the industry in
| general
|
| UX are designed by and for people who don't really use
| computers. They use mobile devices and tablets
|
| It's an industry wide phenomenon
| hansmayer wrote:
| You are onto something there, if you mean, the design roles
| being taken over by the people who are not techies - like the
| POs. But if you just refer to UX being designed for mobile
| devices - that is not an excuse for an even worse UX on the
| mobile. If anything I would have expected more effort put in
| there, given how many more issues the limited screen estate
| can cause...
| lkjdsklf wrote:
| It's designed for virtual keyboards rather than real ones
|
| That makes a bigger difference than screen space
| foobarian wrote:
| As a developer I took the writer's point to refer to "users"
| generically, so that even if you work on some internal tools or
| a backend layer, you still have users who have to use your app
| or consume your API and there is a lot of learning possible if
| you communicate and understand them better.
| bitexploder wrote:
| There is a lot of nuance to their point. They are saying, in
| the long run, career wise, focusing on the actual user matters
| and makes your projects better.
|
| Google UX is decent and the author was not trying to comment on
| UX as a thing at Google. More that, if you follow the user what
| you are doing can be grounded and it makes your project way
| more likely to succeed. I would even argue that in many cases
| it bucks the trend. The author even pointed out, in essence
| there is a graveyard of internal projects that failed to last
| because they seemed cool but did nothing for the user.
| hansmayer wrote:
| > Google UX is decent and the author was not trying to
| comment on UX as a thing at Google.
|
| Interesting, so he was not, contrary to the blog title,
| writing on the basis of his 14 years of experience at Google?
| bitexploder wrote:
| Read their point 1 carefully. They are saying, when you are
| building something or trying to solve a problem (for
| internal or external users) if you follow the user
| obsessively you will have a far better outcome that aligns
| with having impact and long term success. This does imply
| thinking about UX, but transitively, IMO.
| hansmayer wrote:
| I am not sure I follow - is he, or is he not, writing
| about his experiences from 14 years at Google? The title
| suggests he does, yet you suggest that he does not?
| d0gbread wrote:
| His _learnings_ from 14 years at Google. Surely we 've
| all learned things working for employers or with
| engineers that don't do a thing well.
|
| In 14 years he probably also experienced great engineers
| come and go and start other successful businesses they
| very likely did not run exactly like Google.
| lostlogin wrote:
| > Every single one of their services is a pain to use
|
| Would you like to sign in to Google?
| sfmike wrote:
| I see it differently then UX at all. I find the need for better
| customer support 1000x more pertinent to helping users.
| kmoser wrote:
| > Recently I was writing an e-mail and noticed I misspelled the
| e-mail address of the recipient, which I rarely do. So, I
| should just be able to click the address and edit it quickly,
| right? Wrong - now you have a popup menu and inside of it you
| have to search for "edit e-mail" option.
|
| I just tested this out and I don't think that's a particularly
| good example of bad UI/UX. Clicking the email address brings up
| a menu with options for other actions, which presumably get
| used more often. If, instead, you right-click the email
| address, the option to edit it is right there (last item on the
| bottom, "Change email address"). I don't see this as a huge
| penalty given that, as you said, it's rarely used.
|
| There's also the "X" to the right of the email address, which
| you can use to delete it entirely, no extra clicks required.
| hansmayer wrote:
| > I just tested this out and I don't think that's a
| particularly good example of bad UI/UX
|
| Luckily for both you and me, we dont have to rely on our
| _feelings_ of what is good UX or not. There are concrete UX
| metholodogies such as Hierarchical Task Analysis or Heuristic
| Evaluation. These allow us to evaluate concrete KPIs, such as
| number of steps and levels of navigation required for an
| action, in order to evaluate just how good or bad (or better
| said, complicated a UX design is).
|
| Lets say we apply the HTA. Starting from the top of your
| navigation level when you want to execute the task, count the
| number of operations and various levels of navigation you
| have to go through with the new design, compared to just
| clicking and correcting the e-mail address in-place? How much
| time does it take you to write your e-mail in the both cases?
| How many times do you have to switch back and forth between
| the main interface and the context menu google kindly placed
| for us? Now, phase out of your e-mail writing window and
| evaluate how many various actions you can execute in the
| Google Workspace. Most of them are likely to have a few
| quirks like this. Now multiply the estimated number of
| actions with the number of quirks and you will slowly start
| to see the immense cognitive load the average user has to
| face in using, or shall I rather say "combating" the google
| products' UX.
| sans_souse wrote:
| To me; point #3 is the big one and it is in conflict with point
| #1
| d0gbread wrote:
| How so? Those two together is literally agile; not as I've
| seen it done, but as it's intended. Learn, iterate, repeat.
| inopinatus wrote:
| To be fair, it reads precisely "1. The best engineers are
| obsessed with solving user problems". This doesn't say those
| engineers are working at Google, just that it's something the
| author learned whilst _they_ worked at Google.
|
| "Some [of these lessons] would have saved me months of
| frustration", to quote the preamble.
| nabbed wrote:
| I was going post exactly this! He was talking about those
| engineers that really exemplified, from his point of view,
| good engineers.
|
| And dealing with engineering managers that didn't see much
| use in such activity might be part of "figur[ing] out how to
| navigate everything around the code: the people, the
| politics, the alignment, the ambiguity".
| Hatrix wrote:
| I'd like YouTube to add a button to stop showing scam ads from
| people outside my country.
| seanmcdirmid wrote:
| Is there a big tech company that actually has good UX, besides
| maybe Apple?
| d0gbread wrote:
| I know Apple has a reputation for good UX but I think it's
| carry over from a different era and it's trending down.
|
| I bought my kid an iPad for Christmas and set up parental
| controls, then could not disable it without another iPad
| (which I don't have).
|
| There are many forum threads concluding you just have to
| factory reset.
|
| I couldn't believe how many little unintuitive things I
| bumped into setting it up.
| wdr1 wrote:
| > I wonder why Google UX always sucked so much
|
| It depends on how you define "suck."
|
| When Google first launched it's homepage, its emptiness (just a
| logo & search box) was a stark contrast to the portal pages
| popular, which were loaded with content.
|
| Some thought the Google homepage "sucked" whereas other liked
| it. (I was in the latter.)
|
| Likewise, the interface for Gmail. Or the interface for Google
| Maps. Or the interface for Chrome.
| varjag wrote:
| I remember when Google appeared and literally can't recall
| anyone who thought it sucked. There statistically have to be
| some people who hated it. But everyone I knew was either on
| dial-up or low bitrate leased line and it was impossible to
| dislike that design.
| deepsun wrote:
| > very single one of their services is a pain to use
|
| Uhm, no? Google Cloud Platform is way more convenient to use
| than AWS, the IAM is way better designed, and documentation is
| leagues ahead of AWS.
| inglor wrote:
| Addy's users have been developers and Google has been very
| responsive in the past. I was usually able to get a hold of
| someone from teams I needed from Chrome DevTools and they've
| assisted open source projects like Node.js where Google doesn't
| have a stake. He also has a blog, books and often attended
| conferences to speak to users directly when it aligned with his
| role. I agree about the general Google criticism but I believe
| it's unjustified in this particular (admittedly rare) case.
| shultays wrote:
| Probably the users he is talking about are not the end users
| like you and me. It is one team using the tools/software of the
| other team and so "users" for that other team are the members
| of the first team.
| j3s wrote:
| feels 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 can't write code or use AI to
| do so. It's that we're so good at writing it that we forget to
| ask whether we should.
|
| > This isn't passive acceptance but it is strategic focus
|
| > This isn't just about being generous with knowledge. It's a
| selfish learning hack
|
| "Addy Osmani is a Software Engineer at Google working on Chrome
| and AI."
|
| ah, got it.
| joduplessis wrote:
| oh shit. actually, yea
| throwaway132448 wrote:
| I'm stunned at the reception this is receiving, it's LinkedIn-
| tier slop.
| bencornia wrote:
| I got the same feeling. The writing is too punchy.
| bmink wrote:
| > Bias towards action. Ship. ...The quest for perfection is
| paralyzing.
|
| Unfortunately for users this is more often used as an excuse to
| ship buggy / badly done software.
| jama211 wrote:
| I feel like the best lesson in here wasn't numbered, but in the
| opening statement:
|
| > the longer I've stayed, the more I've realized that the
| engineers who thrive aren't necessarily the best programmers -
| they're the ones who've figured out how to navigate everything
| around the code: the people, the politics, the alignment, the
| ambiguity.
|
| I have been banging on about this for _years_. I've seen
| engineers much smarter than me and who write much better code
| fall afoul of this too. Being personable and easy going and
| insightful for one hour in a meeting can do more for your
| reputation within a company than a month of burning yourself out
| completing more tickets than anybody else. I really wish more
| people understood this.
|
| At the end of the day, a manager or a project director who
| _wants_ you to join a meeting just because you're a joy to be
| around and you may have some insight, shows you're more valued
| than the best coder on the team if they're a pain to bring into a
| meeting because they're hard to talk to.
| GoToRO wrote:
| I manager that invites people in meeting based on how obedient
| they are, is a bad manager. Multiplied by the number of
| reports. Fix that.
| cletus wrote:
| I'm going to pick out 3 points:
|
| > 2. Being right is cheap. Getting to right together is the real
| work
|
| > 6. Your code doesn't advocate for you. People do
|
| > 14. If you win every debate, you're probably accumulating
| silent resistance
|
| The common thread here is that in large organizations, your
| impact is largely measured by how much you're liked. It's
| completely vibes-based. Stack ranking (which Google used to have;
| not sure if it still does) just codifies popularity.
|
| What's the issue with that? People who are autistic tend to do
| really badly through no fault of their own. These systems are
| basically a selection filter for allistic people.
|
| This comes up in PSC ("perf" at Meta, "calibration" elsewhere)
| where the exact same set of facts can be constructed as a win or
| a loss and the only difference is vibes. I've seen this time and
| time again.
|
| In one case I saw a team of 6 go away and do nothing for 6 months
| then come back and shut down. If they're liked, "we learned a
| lot". If they're not, "they had no impact".
|
| Years ago Google studied the elements of a successful team and a
| key element was psychological safety. This [1] seems related but
| more recent. This was originally done 10-15 years ago. I agree
| with that. The problem? Permanent layoffs culture, designed
| entirely to suppress wages, kills pyschological safety and turns
| survival into a game of being liked and manufacturing impact.
|
| > 18. Most performance wins come from removing work, not adding
| cleverness
|
| One thing I really appreciated about Google was that it has a
| very strict style guide and the subset of C++ in particular that
| you can use is (was?) very limited. At the time, this included
| "no exceptions", no mutable function arguments and adding
| templtes had an extremely high bar to be allowed.
|
| Why? To avoid arguments about style issues. That's huge. But also
| because C++ in particular seemed to attract people who were in
| love with thier own cleverness. I've seem some horrific uses of
| templates (not at Google) that made code incredibly difficult to
| test for very little gain.
|
| > 9. Most "slow" teams are actually misaligned teams
|
| I think this is the most important point but I would generalize
| it and restate it as: most problems are organizational problems.
|
| At Meta, for example, product teams were incentivized to ship and
| their impact was measured in metric bumps. But there was no
| incentive to support what you've already shipped beyond it not
| blowing up. So in many teams there was a fire and forget approach
| to filing a bug and forgetting about it, to the point where it
| became a company priority to have SLAs on old bugs, which caused
| the inevitable: people just downgrading bug priorities to avoid
| SLAs.
|
| That's an organizational problem where the participants have
| figured out that shiping is the only thing they get rewarded for.
| Things like documentation, code quality and bug fixes were paid
| lip service to only.
|
| Disclaimer: Xoogler, ex-Facebooker.
|
| [1]: https://www.aristotleperformance.com/post/project-
| aristotle-...
| jackblemming wrote:
| This sounds like an accumulation and reiteration of other peoples
| ideas and blogs, barely changing or adding anything. Fair, but I
| was interested in the author's own ideas or how those ideas
| they're reiterating matter within the context of Google.
| gijoeyguerra wrote:
| lgtm
| lofaszvanitt wrote:
| Seems like the author had lost his personality during that 14
| years trying to appease the strange people at the top or figure
| out the allpermeating bs they force on people.
| riazrizvi wrote:
| This is a good list. Original, evidence to me that the author is
| the real deal.
| imiric wrote:
| There's hardly anything original here. These are regurgitated
| points you'd see in any article of this type. In fact, your
| favorite LLM can give you the same "lessons" from its training
| data.
| throwaway132448 wrote:
| The first paragraph reads like LinkedIn slop, so I scanned the
| rest of the titles - they indicate that the rest of the article
| reads the same.
| bigcloud1299 wrote:
| 15 years in leadership worked at 3 jobs lead major
| transformations at retail where nearly 100B of revenue goes
| through what i built. Ran $55-$100M in a yearly budget... over
| 300 FTEs and 3x contractors under my or my budget,...largest
| retailer in google at that time...my work influenced GCP roadmap,
| Datastax roadmap, ... much more all behind the scenes.... besides
| your capabilities and ability that had to be there to get you in
| those positions - but once you are in those positions - only that
| mattered is politics and asskissing. I know so many people
| smarter than me, always stayed lower b/c they didn't know how to
| play politics. Only reason i never got higher was I didn't know
| how to play politics and kiss ass any more or any better.
|
| The top people are all who kissed each others ass and looked out
| only for their cohort (e.g. people who were in same positions as
| them in early 2013). So teach your kids to kiss ass and play
| poltiics.
| spicyusername wrote:
| So teach your kids to kiss ass and play poltiics.
|
| Or to stay far away and do something useful with their lives.
| k8sToGo wrote:
| >b/c they didn't know how to play politics
|
| Or they refuse to play that bs game
| geodel wrote:
| True. I used to count myself in that category. Do the work
| and stay away from games. I was also thinking of myself as
| clever, self-respecting by doing hard work and leaving daily
| politicking for others. And now sometime back I got like 2-3
| dressing downs from managers, reason being I am not taking
| _leadership feedback_ seriously enough and mending my ways.
| This despite I am only one with left with knowledge of legacy
| system. Clearly I am pretty dispensable while thinking
| otherwise all along.
|
| No outside prospects considering market situation, miserable
| current workplace ultimately due to my choices. So in end
| just no winning for me by not playing game.
| naijaboiler wrote:
| we are human being interacting with other human beings. what
| you call "kissing ass" is just learning to influence and work
| with other humans. It is by far the most useful skill to have
| in workplace. But don't worry. continue your disdain of it,
| includeing calling it negative names, and watch your career
| stagnate.
| dijit wrote:
| Sometimes.
|
| Sometimes it's just _bullshit_.
|
| Learn the lingo, the language, the proper way of posturing
| and the _correct_ way to shirk responsibility and that 's
| what matters in certain orgs.
|
| I sound really bitter, but I'm not, I'm actually quite good
| at the game and I've proven that, I just don't really like
| the game because it doesn't translate into being able to take
| pride in what I've done. It's all about serving egos. Your
| own and others.
|
| Every french multinational I've worked for is _entirely
| built_ on this.
| geodel wrote:
| > I'm actually quite good at the game and I've proven that,
|
| Good. I failed and very likely about to face consequences.
| dijit wrote:
| Nobody that actually matters will hold it against you.
|
| Fuck the posers. Do real shit.
| joduplessis wrote:
| > 1. The best engineers are obsessed with solving user problems.
|
| Complete bullshit. Sorry, but the reason why people use Google is
| because of the ecosystem + value proposition. Google Drive &
| Calendar are some of the most outdated pieces of SaaS software
| that only gets used because of the greater ecosystem they live in
| - and price. They (along with the other Google products) are also
| some of the poorest designed user interfaces online. Let's cut
| the crap for once here. If I were Google I would be worried
| because companies like Fastmail, Notion & Proton are quickly
| catching up.
| websiteapi wrote:
| > If I were Google I would be worried because companies like
| Fastmail, Notion & Proton are quickly catching up.
|
| lol do you honestly think Google is worried about Fastmail,
| Notion or Proton?
| joduplessis wrote:
| > are quickly catching up.
|
| If you were Yahoo a few years before Google it would sound
| the same.
| websiteapi wrote:
| the writing was already on the road w.r.t to user mindshare
| among normies. I see no evidence of the same happening with
| fast mail. why would anyone switch from gmail to fast mail
| other than privacy, which regular people couldn't care less
| about?
| joduplessis wrote:
| Privacy, as well as overall product experience. Btw, I
| didn't just mention Fastmail.
| gosub100 wrote:
| Thats a poor characterization to choose 2 of the least talked
| about apps from that company. Also your response to the claim
| "the best engineers do X" is logically flawed. Maybe google
| doesn't use their "best engineers" to build out those cherry-
| picked examples? maybe they used them for Search or
| infrastructure or something else?
| joduplessis wrote:
| I'm commenting on the article, and the first point in the
| article doesn't sound like search or infra. Maybe read that
| before assuming things. And why would it be "logically
| flawed"?
| gosub100 wrote:
| google has a lot more products besides the 2 you picked.
| Some of them are wildly successful, even. Maybe they use
| their "best engineers" on the more successful products?
| tsoukase wrote:
| There are many big bosses under the Google CEO that lead hordes
| of developers to specific targets-to-meet. Eventually they
| prioritise their bonuses and the individual goals deviate with
| every iteration. So the quality will diminish continuously.
| lazarus01 wrote:
| excellent article and appreciate the author sharing his
| perspective which is very valuable.
|
| For me the main lesson is, don't let your ego develop from
| success. Any human is vulnerable to narcissism. It is an
| interesting phenomenon, where you can originate as a humble
| person who becomes successful, only to lose your great qualities,
| when your identity changes. With success you attract different
| people in your life who may be attracted only to your success and
| who don't have the stones to confront you on your bs.
|
| Developing healthy self awareness comes from surrounding yourself
| with people that love you, but are not afraid to keep you honest
| if you do something out of character.
| RomanPushkin wrote:
| Interview voice:
|
| - How do you actually grow being in one company for 14 years?
| foobarian wrote:
| Best part of the article?
|
| > but coordination costs grow geometrically
|
| Using geometrically instead of exponentially! Thank you!!! :-D
| dullcrisp wrote:
| Yes this is an exponentially better word choice!
| dcminter wrote:
| > _In large organizations, decisions get made in meetings you're
| not invited to, using summaries you didn't write, by people who
| have five minutes and twelve priorities. If no one can articulate
| your impact when you're not in the room, your impact is
| effectively optional._
|
| Very true in large organisations. But... in a company whose
| stated mission is to " _organize the world 's information and
| make it universally accessible and useful_" ... this feels like a
| failure.
|
| When a truly data driven company manages to quantify impact by
| more than the volume of hot air emitted :) then it's going to eat
| the world.
|
| Perhaps it's for the best that nobody does that?
| richtersand wrote:
| GREAT ARTICLE!
| gosub100 wrote:
| It's frustrating to read this advice, which to me can be
| summarized as "don't think too hard, dumb it down, keep it
| simple, be a people-person" and then look at their hiring process
| full of advanced data structures and algorithms. Why hire top
| tech talent if you just need to keep a simple vibe and not over-
| think clever solutions?
| d--b wrote:
| > 1. The best engineers are obsessed with solving user problems.
|
| A little bit of sarcasm here: "well there probably isn't a lot of
| great engineers at google then"
| capr wrote:
| I don't believe any of this.
| RobRivera wrote:
| Number 14 really speaks towards the subtle difference between
| being domineering in conversation and genuinely a sme in an area
| with little overlap in other people's domain knowledge. I feel
| like being extremely transparent in explaining the rationale and
| to a degree teaching really reinforces that boundary.
|
| If you get to a point of silent resentment 'debt' in spite of
| efforts to empathise, consider perspective, and provide clarity,
| then you have a collaboration problem on the other end. How you
| choose to address that is dependent on your political capital,
| and sometimes you need to accept it.
|
| Young me naively believed people were like rational automatons
| who would speak up when appropriate, not take thinga personal,
| and aspire to the true north that I aspired to as a colleague,
| and that is no baseline for a healthy collaboration.
| weslleyskah wrote:
| >Your job isn't forever, but your network is.
|
| I'm very suspicious of this working in the modern technological
| age. Even in university I'm feeling this: it is hard to create a
| bond with real friends, but extremely easy to regress to
| anonymity and become a loner.
| qwertyforce wrote:
| it's sad that startups become corps and decay. this article is
| the perfect illustration, from the bio, to the llm slop content
| of the article. Just sad it has to be this way
| andyjohnson0 wrote:
| > 15. When a measure becomes a target, it stops measuring.
|
| This is Goodhart's law - "When a measure becomes a target, it
| ceases to be a good measure" [1].
|
| [1] https://en.wikipedia.org/wiki/Goodhart%27s_law
| masondunn wrote:
| > Focus on what you can control. Ignore what you can't.
|
| That's why I left Google for HFT. Much better life.
| einpoklum wrote:
| Where you can serve corporate interests more directly and with
| less overhead? (:shrug:)
| neilk wrote:
| Read it carefully.
|
| He's not saying that these are all common values or practices at
| Google.
|
| He's saying he learned those lessons while working at Google.
|
| Despite the metaphor of a "lesson", a "lessons learned" post is
| almost never about something the author was explicitly told. It
| was something that you had to learn from experience, or at best
| from informal advice. Where you had to swim against the flow of
| your circumstances.
|
| I neither think Osmani means to say that Google is _against_
| these lessons. Every organization as big as Google has a lot of
| accumulated wisdom that will help you. These are just the things
| which remain hard, and some of which are even harder in a large
| organization.
| seattle_spring wrote:
| Here's the lessons all ex-Google colleagues I've worked with have
| brought with them to their new jobs:
|
| 1. Use Bazel for everything. Doesn't matter that the
| documentation sucks and it's unbelievable bloat for smaller
| companies: use it anyway. Use it for everything.
|
| 2. Write things from scratch. Need a protobuf parser in C? Just
| write one up instead of using any of the battle-tested open
| source options.
|
| 3. Always talk down to frontend engineers and treat them as
| lesser/ not real engineers. _Real_ engineers are backend
| engineers. Frontend is so easy that they can do a perfectly fine
| job if needed. Make sure to use Bazel for all frontend builds.
|
| 4. Did I mention Bazel? It's the solution to all problems for all
| companies.
| charlieyu1 wrote:
| Worked at an AI training company for a few months.
| Enshittification is real. Idiots who never deserved to be here
| coming up with new policies every week, sometimes twice a week.
| Absolutely spineless when receiving nonsense from the client
| which is one of FAANG but will screw colleagues with no remorse.
| Sephr wrote:
| This 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 code is
| the code you never had to write.", and "14. If you win every
| debate, you're probably accumulating silent resistance."
|
| 1. https://addyosmani.com/an-apology-to-eli/
| zhouzhao wrote:
| Jesus, bro.
|
| Let bygones be bygones. How long is this ago? It's just code.
| And what the code did, is not even fundamental. It's not like
| you cured cancer.
| 0______0 wrote:
| FWIW, the actual apology is well written.
| decimalenough wrote:
| Although little note at the very end explains why:
|
| > _This note is in response to emails from Eli Grey to Chrome
| leadership from October, 2023_
|
| In other words, he wrote this because he was forced to.
| timzaman wrote:
| Reading this makes me so happy I'm not at google anymore
| keeda wrote:
| Aren't #2 and #14 mostly the same point? And they seem to
| indicate a rather unhealthy cultural dynamic. Amazon's "Disagree
| and commit" is a much healthier dynamic than "Pretend to agree
| and then silently sabotage."
|
| I think there's a valid middle ground in finding a path that
| works well for everybody, but this does not seem to be the right
| way.
|
| I wonder if this is a common thing at Google because I recall
| another interview (can't find now, I think in the context of
| WebRTC??) from many years ago where an engineer proudly described
| how he conspired against a major technical decision because it
| didn't align with his personal preferences. I was a bit shocked
| to see someone admit something like that so publicly.
| titzer wrote:
| > 3. Bias towards action. Ship. You can edit a bad page, but you
| can't edit a blank one.
|
| > First do it, then do it right, then do it better. Get the ugly
| prototype in front of users. Write the messy first draft of the
| design doc. Ship the MVP that embarrasses you slightly. You'll
| learn more from one week of real feedback than a month of
| theoretical debate.
|
| > Momentum creates clarity. Analysis paralysis creates nothing.
|
| I've met Addy and I'll be generous, but strong disagree here, and
| this really shows a huge blind spot in how software is being
| developed today that hurts everyone.
|
| There aren't two extremes between "theoretical debate" and just
| shipping the first crap you can slap together. Software
| engineering will _never_ become a real discipline when industry
| keeps ignoring the lessons of every other field of engineering:
| gather some requirements first.
|
| Want to know what users want? How about asking them? What about
| doing some research on what tools they are using now (or not) and
| finding out what's wrong with them. What about doing a user
| study? What about analyzing competing and previous products?
|
| How about then drawing up a list of things that _say what the
| thing will do_? You can keep the list short, sure. Build a
| prototype (maybe for internal use)? Sure. No need to have every
| piece of functionality there.
|
| But there's an enormous blind spot here I'd be remiss to point
| out. Back in the shrink-wrapped software days, back when products
| took months and sometimes years to develop, man, people really
| planned out what they were going to build! And I'm not just
| romanticizing that era--there was a lot that could go wrong, and
| many misses--but _tons_ of software developed in that manner
| sticks with us today, not just the designs and usage patterns,
| but big chunks of the code too. It 's not all legacy cruft;
| people actually thought about what they wanted to build, and then
| laboriously built and tested it--with crappier tools, longer
| build times, and many disadvantages like huge teams, crappier
| communication, and a whole lot less computational power.
|
| There are other things in this list that are good advice, but I
| felt like this cannot possibly be the whole truth to 14 years of
| experience. In other words, please don't just ship your crap to
| us the first time it functions.
| etamponi wrote:
| > The engineer who truly understands the problem often finds that
| the elegant solution is simpler than anyone expected.
|
| > The engineer who starts with a solution tends to build
| complexity in search of a justification.
|
| I do agree this is a good point, I just find it funny that it
| comes from "staying 14 years at Google".
|
| This is literally the reason why I left Google first, and Meta
| second. Finding simple solutions will get you absolutely nowhere
| in a place like those. You have to find complex solutions with a
| lot of stakeholders, alignment, discussions, escalations... Why
| ship one button if you can ship 100 and get you, your team and
| your manager promoted in the process?
| asim wrote:
| This is good. I worked at google and lasted less than 2 years.
| Many other things happening in that time - came in via
| acquisition, worked on backend for that, dad died, transitioned
| teams, etc. But I was 27-28 and couldn't really navigate that
| world after my first job at a startup. In some ways, I wish I'd
| found a way, but in other ways, I know it wasn't meant to be.
| It's a good list, if you want to do 10 years at Google or
| elsewhere, internalise that list and it's lessons.
___________________________________________________________________
(page generated 2026-01-04 23:00 UTC)