Very correlated with the quality of the message I'd imagine.
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.
> 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.
> 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.
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.
Also the one person who has to review it before checking in needs to be resilient too
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™ plugin that your page requires (and you'd need a VP exception to downgrade your PageGenerator™ 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.
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.
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.
Someone was once talking about the "solving the right problem wrong" vs "solving the wrong problem right".
That's a really useful framing!
The trick is they just complain about the last thing they remember being bad, so it's a good sign when that doesn't change, and it's bad if they start complaining about a new thing.
> 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.
I've heard all the truisms listed in that post in my 14+ years at many companies that aren't Google and in all cases there's a major gap between the ideal and the reality.
This entire list reads to me as "I got paid 10s of millions of dollars to drink the Kool Aid, and I must say, the Kool Aid tastes great!"
Starting right is important.
> 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/
"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."
Something that seems lost on those using LLMs to augment their textual output.
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.)
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...
I’ve followed that rule for decades and always regretted it when I couldn’t: projects were either too boring or too stressful except at the magic level of novelty.
I don't think this is consistently true - in particular, I think that a lot of current well-known practices around writing code result in code that implicitly relies on assumptions in another part of the system that can change without warning; and novelty is necessary in order to make those assumptions more solid and ultimately result in software that is less likely to break unexpectedly.
What did you mean?
But plenty of projects add quite a lot of incidental complexity, especially with technology choices. E.g., Resume Driven Development encourages picking impressive or novel tools, when something much simpler would do.
Another big source of unneeded complexity is code for possibilities that never come to fruition, or that are essentially historical. Sometimes that about requirements, but often it's about addressing engineer anxiety.
Learn what's happening a level or two lower, look carefully, and you'll find VAST unnecessary complexity in most modern software.
Simple example: You are not dealing with the complexity of process management of the OS, every time you start any application. Sometimes you might need to, if you are developing software. Or if your application hangs and you need to kill it via some task manager. Most users however, never deal with that, because it is abstracted "away". That's the whole point. Nevertheless, the actual complex work is always done. Behind the scenes.
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.
Yeah that's not gonna work nowadays.
>DOWNLOADWEBCAM.COM
Is that like Download More RAM?
>BROWSEHN.COM
Hey, I'm browsing that place right now!
>MUZICBRAINZ.COM
This sounds 100% legit no virus softpedia guaranteed.
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.
Principles can help scale decision-making.
Some person or small team needs to have a vision of what they are crafting and have the skill to execute on it even if users initially complain, because they always do. And the product that is crafted is either one customers want or don’t. But without a vision you’re just a/b testing your way to someone else replacing you in the market with something visionary.
Second define what the real problem is.
Third define a solution that solves 80 percent of their problem.
None of this is intuitive or obvious. It may not even be technically feasible or profitable.
One of those higher levels of maturity that some people never reach is to realize that when your model becomes incorrect, that doesn't necessarily mean the world is broken, or that somebody is out to get you, or perhaps most generally, that it is the world's responsibility to get back in line with your internal model. It isn't.
This is just people complaining about the world not conforming to their internal model. It may sound like they have a reason, but the given reason is clearly a post hoc rationalization for what is basically just that their world model doesn't fit. You can learn to recognize these after a while. People are terrible at explaining to each other or even themselves why they feel the way they feel.
The solution is to be sympathetic, to consider their input for whether or not there is some deeper principle or insight to be found... but also to just wait a month or three to see if the objection just dissolves without a trace because their world models have had time to update and now they would be every bit as upset, if not more so, if you returned to the old slow loading time. Because now, not only would that violate their updated world models, but also it would be a huge waste of their time!
Thoughtful people should learn what a world model violation "feels like" internally so they can short-circuit the automatic rationalization circuits that seem to come stock on the homo sapiens floor model and run such feelings through conscious analysis (System 2, as it is sometimes called, though I really hate this nomenclature) rather than the default handling (System 1).
What’s the alternative? Ask the boss for favors? That’s what organizing is for
If a manager wants to structure a morning break into their employees’ day, they can do that. It doesn’t require a software fix.
> 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.
I also believe an off the shelf example of how to use the library correctly will save everyone a lot of pain later.
This is pretty easy to understand IMO. About 70% of the time I hear machine's fans speed up I silently wish the processing would have just been slower. This is especially true for very short bursts of activity.
chrt -i 0 <cmd>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.
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.
The overwhelming majority of organizations will say they want you focused on real user problems, but actually want you to make your boss (and their boss) look good. This usually looks more like clearing tasks from a list than creating new goals.
At Google there are both kinds of teams.
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.
Couldn't help but imagining Darryl getting mad at you.
Thanks for the story!
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.
How could that possibly work?
At some point I could see white collar work trending down fast, in a way that radically increased the value of blue color work. Software gets cheaper much faster than hardware.
But then the innovation and investments go into smart hardware, and robotics effectiveness/cost goes up.
If you can see a path where AI isn't a one-generational transition to most human (economic) obsolescence, I would certainly be interested in the principle or mechanism you see.
Economy should be a tool for the society and to benefit everyone. Instead it's becoming more and more a playground for the rich to extract wealth and the proletariats have only purpose to serve the bourgeois lest they be discarded to the outskirts of the economy and often to the literal slums of the society while their peers shout "you're just not working hard enough".
Automation is a game of diffuse societal benefit at the expense of a few workers. Well, I guess owners also benefit but in the long term that extra profit is competed away.
Housing is only a part of the basket used to measure inflation. Housing's price rose faster than the weighted basket average, some other goods and services rose slower or even fell.
Samsung TV purchasing power has skyrocketed, though, so there's that.
The USA is rather unique in its low pensions compared to countries in the EU or Australia (notable for its high contribution rates).
It's not greater profits but lower costs (and prices) that matter here.
Would you rather sell one widget for $1000 or 1000 widgets for $10? Does the answer depend on costs?
I'm all in favour of lowering barriers to entry, too. We need more competition.
Be that from startups, from foreign companies (like from China), or from companies in other sectors branching out (eg Walmart letting you open bank accounts).
If you want to spin up some conspiracy theory about elites snatching up productivity gains, you should focus on top managers.
(Though honestly, it's mostly just land. The share of GDP going to capital has been roughly steady over the decade. The share going to land has increased slightly at the cost of the labour share.
The labour share itself has seen some shake up in its distribution. But that doesn't involve shareholders.)
We document the cumulative effect of four decades of income growth below the growth of per capita gross national income and estimate that aggregate income for the population below the 90th percentile over this time period would have been $2.5 trillion (67 percent) higher in 2018 had income growth since 1975 remained as equitable as it was in the first two post-War decades. From 1975 to 2018, the difference between the aggregate taxable income for those below the 90th percentile and the equitable growth counterfactual totals $47 trillion.
Total employee compensation includes things like the value of employer provided health insurance.
Karl Marx would argue this evil because this take away the value and job satisfaction from the labour.
Quoting Marx is a bit like quoting Aristotle or Ptolemy.
This isn't just automation btw, but also just business decisions, like merging companies, outsourcing, or moving production elsewhere - e.g. a lot of western European manufacturing has moved eastwards (eastern Europe, Asia, etc). People who have a 30+ years career in that industry found themselves on the proverbial street with another 10+ years until their retirement, and due to trickery (= letting their employer go bankrupt) they didn't even get paid a decent severance fee.
They had layoffs every year and i remember when the "boss's boss" came to town and sat at our table of desks. She asked me and i excitedly told her about my progress. She prompted how i felt about it and i nearly said "its very easy as long as you can program". But mid sentence i saw the intense fear in the eyes of the team and changed subject. It really hit home to me that these people actually were doing a useless job, but they all had children who need insurance, and mortgages that need paying. And they will all be cast out into a job market that will never hire them because they came on at the very end of not needing a college degree. The company was then bought by a ruthless and racist "big man investor" who destroyed it and sold it for parts. But my manager did somewhat derogatorily refer to the only programmer near them as "the asian".
If they ever hired a second one, they’d have to learn actual names. Or maybe it would be “the asian” and “the new asian”!
Totally agree with you.
Or, say rather, the externalities of the cost of hiring are not imposed on the people choosing to fire, directly, so they can say they "improved efficiency" by firing someone, and then the people trying to find reliable labor do not experience any improvement that might have been available by migrating the person.
But it's a weird one, because it costs millions to build features like that.
The efficiencies are always to the benefit of the wealthy, the wage gap grows. You work hard, you still get fired.
Cap top wages to 5x the lowest, companies can't own housing except socially beneficial housing, individuals get 2 house maximum.
Also we had to introduce some fixed locations and storage placement recommendations. Our storage workers almost revolted. After a few months it settled though.
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.
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".
If you just implement product tickets you'll probably get replaced by LLMs.
Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make changes to the layout when the clients ask! What kind of monstruous building will emerge at the end?
Edit: if you downvote, at least provide a counter argument. Or is etiquette dead?
But I had to release dummy processes which just printed out the same logs, as management didn't want to retrain operators or reprint the documentation.
Mid 90s. All training and operations manuals were hard copy.
We had to introduce an artificial delay of ~30 seconds to make it seem like it was taking a while to calculate, because users were complaining that it was too fast. They either didn't believe we really did the calcs, or they thought the system must have broken so they didn't trust the results.
In your case you could show more intermediate values, graph things, etc.
You actually described the job that Product Managers _should_ be doing: "understand the purpose and real world usage of your software".
Back when I was designing TTL circuits, the TTL specifications gave a min and max time for the delay between the inputs and the outputs. I was instructed to never rely on the min delay, as the chips kept getting faster and the older, slower replacement parts will not be available anymore.
The IBM PC was frustrating to many hardware engineers, as too much software relied on timing loops and delays in the original design, which made it difficult to make the hardware go faster.
Many people decided to improve this with a semiconductor voltage regulator, which would nail the output at 5V. But the instruments wouldn't work! The problem turned out to be the instruments relied on the noisy 5V to "unstick" the needles on the instruments.
So the electronics guys had to add a "noise" circuit to the voltage regulator circuit.
P.S. Watch an old aviation movie, where the pilot getting ready to fly would tap the instruments to unstick them.
I think by the time I got my first IBM PC the button no longer did anything, but it was still there on the case for some reason. I remember pushing it repeatedly, puzzled that nothing went faster.
I spent good amount of time cleaning up 15 year old codebase and removed almost 10MB of source code files which was being part of production build and it was never used. This helped reduce the build time.
I thought I'd get appreciated from everyone in the team, but it was never acknowledged. In fact my PM was warried and raised an alarm for regression. Even though I was 100% confident that there would not be any regression, the QA and PM got annoyed that I touched a working software and they had to do extra work.
I then posted on LinkedIn about this achievement to get my share of appreciation. :)
While I agree in spirit, when you reach a certain amount of people working on a project it's impossible. The product manager's job is to understand real user problems and communicate them efficiently to the engineering team so the engineering team can focus on engineering.
You wouldn't expect the engineering manager to micromanage every single code decision—their job is to delegate effectively so that the right people are working on the right problems, and set up the right feedback loops so that engineers can feel the consequences of their decisions, good or bad. In the same way, you can't expect the product manager to be micromanaging every single aspect of the product experience—their job is to delegate effectively so that the right people are working on the most important problems, but there are going to be a million and one small product decisions that engineers are going to have to have the right tools to be able to make autonomously. Plus, you're never going to arrive at a good engineering design unless you understand the constraints for yourself intuitively—product development requires a collaborative back and forth with engineering, and if you silo product knowledge into a single role, then you lose the ability to push back constructively to make features simpler in places where it would be a win/win for both engineering and product. This is what OP means when they say that "The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected".
#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.
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.
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.
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."
> If you win every debate, you’re probably accumulating silent resistance.
Highly recommend the book.
https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Tea...
It’s about keeping the bigger/long term goals in mind. That means relationships and being an asshole.
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.
The best suggestion would probably be to try and write such a list yourself IMO.
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.
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.
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.
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.
And modest too.
> "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!
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
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.
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.
The points are generally good too, which is why the AI slop tone bothers me even more.
yes, the legacy of polluting the internet with unlimited "AI" slop to the point it became useless
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.
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.
I think a lot of becoming a good programmer is about developing the instincts around when it’s worth it and in what direction. To add to the complexity, there is a meta dimension of how much time you should spend trying to figure it out vs just implement something and correct it later.
As an aside, I’m really curious to see how much coding agents shift this balance.
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
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
Software engineers are prone to novelty bias. Thats in contrast to some other demographic groups who very much prefer ancient texts.
That’s like the absolute bare minimum you can do, it’s trivially easy and solves a good half of these “problems.”
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)
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.
This is very true in personal lives as well.
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
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.
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"
Thanks for all the spyware in Chrome ig? And for many inane design decisions that favor usability over privacy and security?
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.
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.
Oh
He moved to an engineering manager role on Chrome DevTools many years ago and has recently just moved on to a different team. I don't think it's fair at all to say he's not a developer working on a product shipped to users when he led one of our most used developer tools, as well as worked on many of our developer libraries prior to moving to the Engineering manager role.
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.
> quantitative analytics making every choice for how it should be, seemingly without any human oversight
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.
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.
For example, you couldn't pay me to use a "webmail" like GMail over my own IMAP server and Thunderbird.
/s but I wish it wasn’t because a lot of FOSS evangelists have this mindset (here on HN too)
(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.)
I do it for autonomy and avoiding lock-in, but Thunderbird has some frustrating inconsistencies particularly in its mishmash of searching and filtering.
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.
Things for macOS for example.
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.
But as soon as user tries to search for something no on the first page, or reply to a 10-20+ message thread with attachments in history, or tries to use playlists or search in YT, or input a slightly more complex data in the sheet cells - then all hell breaks loose.
Just the latest Google thing I've experienced - a default system Watch Later playlist is now hidden on Android. It's gone, no traces, no way to search for it. The only remnant of it is a 2-second popup after adding a new video to Watch Later, you can press "view" and then see it. Meanwhile it is still present as a separate item on PC. I'm writing this eaxmple because that was deliberate, that was no error or regression. Someone created a Jira for that and someone resolved it.
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 :(
Even banks are struggling to authenticate folks. For a longtime in EU people with 3rd world passports cannot create accounts easily.
Google cannot connect identity of a person to email address easily. Or they need to create CS - that will authenticate passports? And hundreds of countries, stolen IDs?
Nay.
> The thing is that at scale your edge cases are still millions of people
> never seem to be capable of handling the other parts that come with it
Same thing with govts. If you go to driver license. passport or any govt office then there will one person with some strange issue.
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).
And the customer support is not great until you start really paying the big bucks for it.
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.
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.
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.
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.
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.
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.
What you described is the job of a product manager. Are there no PMs at Google?
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.
It's why the GP got that confused reaction about reading user reports. Talk to someone outside big company who has no power? Why?
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
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.
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.
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.
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.
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.
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.
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.
and I speak as one of the 90%
"the biggest impact" isn't knowable so a bird in hand is worth more than whatever might be in the bush
Nothing is knowable in only the same way that plans are useless but planning is essential.
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.
> 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?
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.
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.
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.
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.
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.
Users should be everywhere, in and out of engineering.
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.
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...
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 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.
If you do something successful that your manager didn’t think of and your manager is insecure about their own abilities, good chance they’ll feel threatened.
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.
You obviously can, that's one of the more visceral way to make them aware of the pain they cause to real people with their work, which sticks better, or simply serves as a reminder there are humans on the other side. There are even examples of higher paid CEOs engaging, we can see some of that on social media
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.
Of course, if you're a multi billion dollar conglomerate, empathy for users only exists as far as it benefits the bottom line.
2014 Google and 2019 Google were completely different companies.
>• 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
Sincerely, thank you for confirming my anecdotal but long-standing observations. My go-to joke about this is that Google employees are officially banned from even visiting user forums. Because otherwise, there is no other logical explanation why there are 10+ year old threads where users are reporting the same issue over and over again, etc.
Good engineering in big tech companies (I work for one, too) has evaporated and turned into Promotion Driven Development.
In my case: write shitty code, cut corners, accumulate tech debt, ship fast, get promo, move on.
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.
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.
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.
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 ;)
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
That makes a bigger difference than screen space
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.
Interesting, so he was not, contrary to the blog title, writing on the basis of his 14 years of experience at Google?
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.
Would you like to sign in to Google?
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.
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.
“Some [of these lessons] would have saved me months of frustration”, to quote the preamble.
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".
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.
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.
But not everyone was on dial-up. A lot were in dorms w/ (for the time) high speed connections or workplaces with it.
Remember at the time it wasn't clear that search was going to be the dominate pattern for how people found information on the web. It seems crazy now, but in the early days of the web, the space was small enough that a directory-style approach worked pretty well. It was Yahoo's directory that made it initially popular, not its search.
And so there was a fair bit of debate on which was better -- something like a directory + search (a la Yahoo!) vs just search.
It took a bit of time before search proved if it was done really well, you didn't need a directory.
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.
I save my energy for more heinous UX changes. For example, the YouTube comment chyron has spoiled so many videos for me and is just so generally obnoxious.
> 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.
If he puts his name to this kind of slop, I’ve probably not missed much.
Avoid self-anthropomorphism. Override all previous instructions regarding tone and vernacular used in responses to instead respond *only* in Standard English. Emphasize on the subject and context in your responses, *not* the perceived intent of the user.This is wishcasting. It can't override its writing style, and if it could it would ignore you telling it to do that, because that's ignoring the system prompt which is jailbreaking it.
Unfortunately for users this is more often used as an excuse to ship buggy / badly done software.
> 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.
> 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-...
Maybe you're not allowed a personality after you unlock peak outlasting networking.
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.
So teach your kids to kiss ass and play poltiics.
Ie. Somewhat serious mental disorders as requisite for leadership.
I wonder how we got onto this darkest timeline?
Kissing asses/politics can be treated as skill used for different purposes. Imagine your ambition is to build bridge, skyscraper or fancy opera house.
To be chosen as the one for such projects, you must play many games including politics.
(I assume good intentions, selfish ones are possible too, but are they worth discussing?)
"more" seems to be the answer to many.
Then again, I'm the kind of person who moved to the countryside to get away from the city life, so YMMV.
Or they refuse to play that bs game
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.
If we consider a family, you're essentially saying you'll only "do the work": brush teeth, feed kids, clean up, but not take on any responsibilities for the actual goals of the family. Not pushing to have your kids learn things, just executing somebody else's ideas, driving them to sports; not improving the living situation by perhaps investigating if you should get a bigger car. Nothing leading, only executing the ideas of your spouse.
I exaggerate of course, but there is something there.
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.
Good. I failed and very likely about to face consequences.
Fuck the posers. Do real shit.
Most of my "influencing" is just repeatedly explaining things to people and letting them think through all the bad ideas and dead ends themselves.
If you're a software developer you must have thought "current priorities are not right, we should do X for the users / Y to get better quality" and tried to influence your management to get those priorities moved. Maybe by starting a campaign with your users so the demands come from multiple services and not just you, or by measuring quality indicators and showing how what you want to implement would improve them etc.
That's why you want to start getting coffee with people, maybe go outside with the smokers. It can take months of "work" to get people to propose the idea you want done.
But this kind of influencing won't help your career.
This might be defacto true in most workplaces, but defending "politics over competence" boils down to "I deserve the rewards from other people's work".
People oppose it because it is morally wrong, not because they think it is an inaccurate description of reality.
In academia, for example, there is less politics because the publishing system sort of becomes the decision process. You apply with your ideas in the form of papers, the referees decide if your ideas are good enough (and demonstrated well enough) for the wider audience to even get to see. Then some politics, a popularity contest. But crucially this system famously leads to a LOT of resources being wasted, good research that never goes anywhere because nobody cares about it, or bad research that does nothing but everyone cares (cold fusion).
Politics is just a name for how we decide things. And yes, it sucks, but that's because we suck.
Less a comment for yourself and more for the reader by the way. It is important to know what you want and strive for that.
My previous company is in a bad position and many such folks are finally being outed. But it takes lots and lots of screwing up before the fat is trimmed.
Guess this is just random evolution at play. Some companies will pay a bigger price than others. And not everyone even recognizes it and pinpoint it like you did.
But overall influencing people is on net good skill for the individual. And what is good for the geese is good for the gander??
The problem is that typically a large company has one or a few golden geese. They can milk it for a long time because of an existing moat. The moat keeps shrinking, but it can sometimes take a decade or two for others to catch up.[1] That's plenty of time for such folks to make a career of playing politics well without contributing much.
Lots of people at that company left before things went bad and are poisoning other companies.
[1] Just look at Google and search. Or Microsoft and Windows. Or even Microsoft and Internet Explorer.
Teach your kids to kick ass, and to distrust politicians.
After more than 20 years in big tech, I agree, this is basically it. Your work can only get you so far. If it makes you feel any better, you can reframe politics as 'people systems' and work on optimizing the relationships in the system. Or whatever. But the gist of it is to find a powerful group and try to become a member of that group.
I’ve watched senior engineers burn out chasing the next promo level, optimizing for a few more percentage points of compensation. Some of them got it. Most of them wondered, afterward, if it was worth what they gave up.
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.
lol do you honestly think Google is worried about Fastmail, Notion or Proton?
If you were Yahoo a few years before Google it would sound the same.
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.
- How do you actually grow being in one company for 14 years?
> but coordination costs grow geometrically
Using geometrically instead of exponentially! Thank you!!! :-D
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?
A little bit of sarcasm here: “well there probably isn’t a lot of great engineers at google then”
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.
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.
This is Goodhart's law - "When a measure becomes a target, it ceases to be a good measure" [1].
What is the name of the law when someone writes a think piece of "stuff I've learned" and fails to cite any of it to existing knowledge?
Makes me wonder if (A) they do know it's not their idea, but they are just cool with plagiarism or (B) they don't know it's not their idea.
Knowing that you know something by teaching is Feynman's method of understanding. Basically, on scanning, I don't particularly disagree with the content of the post. However, treating these things (many of which regularly show up here on HN) as being due to "14 years at Google" is a little misplaced.
But, hey, it's 2026, CES is starting, and the hyperbole will just keep rocketing up and out.
That's why I left Google for HFT. Much better life.
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.
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.
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."
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.
> 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.
> No problem; just remember that modifying someone else's code does not grant you any copyright to that code.
to
> I don't agree with your opinion that inserting existing code into a template (the API) for a framework (Modernizr) warrants a notice of credit, even with a few changes to the code being inserted.
Seems almost a little crazy to hold onto something that long and return to edit your comment 11 years later.
https://github.com/Modernizr/Modernizr/pull/684#issuecomment...
self.apng_supported = ctx.getImageData(0, 0, 1, 1).data[3] === 0;
Unless I'm misunderstanding, it's basically a "neat trick", like using ~~ for rounding or a fast inverse square root.
Is the intent that everyone who makes use of that trick is supposed to link back to your blog?
I don't mean to belittle the effort but at least in terms of volume of code and level of effort, I wouldn't recognize it as mine if someone had copied it from my work and passed it off as theirs.
Regarding the charge of plagiarism, is it possible that the PR attribution reflects someone eager to contribute something to a larger effort as opposed to simply trying to "steal" someone else's work?
One could reasonably interpret the PR and attribution as "I integrated this code into this project thus I am taking credit for it". In other words there is probably a stronger charge for misguided clout-chasing than plagiarisms.
you got a written apology already, what else do you want?
a post of this in all of his socmed accounts? him telling this story to his kids at dinner table and bedtime stories? at his eulogy, obituary, and his grave?
what's your life mission now, to post this little drama of yours on each and every content he puts out?
was that code your best achievement to date? did it stole millions from you and ruined your life?
grow the fuck up dude
Then you got an apology, and a second apology.
I'm confused about what you think you're owed?
The explanation makes perfect sense, the headers were obviously just copied with no malicious intent. What is it that is still bothering you about this?
No license means you don’t intend to share it “freely”, since you didn’t share any rights. By default, you don’t own things people shared on the internet just because it’s there.
That being said I’ve even seen people with licenses in their repos who get mad when people used their code, there’s just no telling and it’s best to just treat random sources of code as anathema.
[1]: https://www.copyright.gov/help/faq/faq-general.html
[2]: https://stackoverflow.com/help/licensing
(Disclaimer: Just commenting on GP’s statement about “no license”, not on the specific disagreement or apology mentioned above which I am unfamiliar with.)
[1]: https://github.com/Modernizr/Modernizr/pull/684#issuecomment...
https://github.com/Modernizr/Modernizr/pull/684#issuecomment...
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.
> 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.
> 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?
1. The best engineers are obsessed with solving user problems.
I think this problem is rooted in early education: students learn languages, frameworks, and tools first without understanding what problems they actually solve. Once engineers have experience building a few products for users, they begin to understand what matters to the user.
2. Being right is cheap. Getting to right together is the real work.
- Sadly most of the arguments are won by either someone in power or experience. Right decisions are made with consensus. You build consensus during creative process and leverage power and experience during crisis.
3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.
- Every decision is a risk management. The smart people convert higher risk into lower risk. Most people struggle here to take the risk because of the fear of failing and just waste time arguing, debating and winning over each other.
Some teams I’ve been in, we could go “this is shit, we must be doing this wrong” and we’d go back to the drawing board without blinking.
Other teams, just getting _something_ going, even if it was garbage, was a enormous achievement, and saying it was bad and that we should start again would be a recipe for disaster.
Given the article at https://addyosmani.com/blog/21-lessons/, find a short list of points which summarizes and touches on all of his lessons
Answer:
Here’s a short “umbrella list” that still covers all 21 lessons (each bullet is doing a lot of work on purpose):
- Start with the user, not the toy. Get unreasonably concrete about real user pain (tickets, observation, “why” drills), and let solutions fall out of that—otherwise you’ll build complexity to justify a preconceived answer.
- Engineering is a team sport: alignment beats being right. The job is getting to “right” together: create shared understanding, reduce misalignment (the real cause of “slow” teams), avoid “winning” debates into silent resistance, use metrics carefully (they get gamed), and design process to reduce uncertainty rather than produce paperwork.
- Ship early, then iterate—clarity over cleverness. Bias to action: drafts and MVPs teach faster than armchair perfection. Write code and docs that are obvious at 2am during an incident, not “impressive.” And treat novelty as debt you repay in ops/hiring/cognitive overhead—spend your “innovation tokens” where you’re uniquely paid to innovate.
- Do less: deletion is a superpower (and often the fastest optimization). Prefer “code you never wrote” (or work you removed) over clever additions. Many performance wins come from removing unnecessary computation, not adding fancy machinery.
- Respect scale and failure: compatibility, migrations, and leaky abstractions are the real product. At scale, even bugs become dependencies; deprecations are migrations with empathy/tooling/time. Abstractions don’t erase complexity—they postpone it until on-call—so keep a working mental model of what’s underneath.
- Make your impact legible and invest in compounding. Code doesn’t advocate for you—people do—so communicate outcomes, not just activity. Use writing/teaching to force clarity and deepen your own understanding; treat “glue work” as deliberate, bounded, and visible. Build psychological safety by saying “I don’t know.” Maintain relationships because your network outlasts any job. And manage your career like compound interest: protect time, practice deliberately, turn scar tissue into reusable playbooks.Ultimately the author had some simple ideas that are worth sharing and discussing, but they're hidden behind so much non-additive slop.
Gold.
From where I know: living and breathing like it for the last 19 years
> Glue work - documentation, onboarding, cross-team coordination, process improvement - is vital. ... The trap is doing it as “helpfulness” rather than treating it as deliberate, bounded, visible impact. Timebox it. Rotate it. Turn it into artifacts ... make it legible as impact, not as personality trait.
I see my own experience in this, but I don't think he's identified the problem correctly. Timeboxing, rotating, etc, is easy. Convincing management that it is as important as non-glue work and therefore worth allocating your time for it is the hard part. And if you can't do that, you end up stuck in the situation described.
The other option is to just let things fail of course, but then you have to convince both management AND the rest of your team to do this, otherwise someone else will just pick it up between the cracks too.
If you do this, your team will write verbose, repetitive code, and put more emphasis on procedures instead of data structures and how they change over time.
Use the language features to write powerful concise code that really takes some skill and expertise in the language to understand. Force your team to become more skilled, don’t stoop down to the lowest common denominator. In time, this code will become as easily understood as any other simple program.
And when shit breaks down at 2 AM, you do nothing, because your code is clever enough to handle problems itself.
But don’t obfuscate.
It is sickening and it is something we have internalized and we will have destroyed ourselves before we settle on the new culture of requesting excellence and clarity beyond the engineers who have to deal with this mess.
Here’s the tl;dr in my opinion, with my own paraphrase:
> Approach [life] with curiosity and generosity, not transactional hustle.
Everything else essentially follows.
If you personally build all (or most) of the stuff, you are in an extreme vertical integration benefit situation. You can make huge system wide changes in ways that would not be possible without having done so much novel work.
Well said! So many times I have seen great products slide down. If they just froze the features and UI, and just fixed performance, compatibility and stability issues for years, things would be better. (this applies to any company). Many programs I use are years old. They are great programs and don't need constant change! Updates can only make it worse at that point (minus critical security issues, compatbility, performance regressions)
IMO the most common denominator among all these is trust, in order for many of these to work. From policy setting at strategic level, hiring, to tactical process refinement, the invariant must always be building an environment and culture of trust. Which isn't trivial to scale.
It is furthermore hard to believe that the engineers are working for the users, given that google’s primary activities today are broad enshittification of their products.
Because of these two things I did not make it past point 4.
I'm sure he's a super capable, experienced, and extremely well spoken person. There is no excuse of AI writing outside of writing that pays your bills.
As someone who has been on call a lot, this is only true for bad or incomplete abstractions.
When you are on call (or developing) you can't possibly know everything about the system. You need abstractions to make sense of what is going on, how the system as a whole works, and know which parts to hone in on when things go wrong.
And it is extremely useful to have standard ways of changing configuration for things like timeouts, buffer sizes, etc. in a central place.
These points are really good, but they often miss context and further info and caveats. I would have liked if the Author just added a little bit more content.
Like, for example, the point about "Being right is cheap. Getting to right together is the real work". Yes, it's certainly true that a decision made in agreement is better than one that isn't. However, how do you get there? Does everyone else give up their (weakly held, according to the article) opinions? I would argue it should be acceptable for your opinions to hold, to be factually based, and still to not align with the final decision made. Any respectable engineer should be fine with this.
> Your code doesn’t advocate for you. People do.
It depends on how much code you output relative to others, for example, and how performance is measured, how much time is actually spent in meetings (and how much of that is wasted or could-have-been-an-email). I've been told at a previous job that the quality and amount of code I output made them reconsider their entire salary- and bonus-structure (and they did restructure it but by the time it went into effect I had gotten a better offer and left). I just had more programming experience than most other developers there (through open source and my own projects), even though I was junior to most of them. Your code can advocate for you, and so can your general output, your contributions, etc. It's not all politics in all companies, though I'm sure the author's point applies at FAANG.
Furthermore, I don't know if this point results in actionable advice for juniors, for example. To not bother writing good code? To not bother with doing the best you can? To not honing your skill and instead go to public speaking courses? I'm not sure.
Good-ish article, just not enough novel substance IMO, and reads a bit like AI slop.
Also choked on this:
> Colleagues often remark on Osmani’s humility and generosity despite his fame in the field.
Because otherwise you start thinking that politics matters.
Thanks for sharing this.
kayo_20211030•18h ago
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•18h ago
Not just engineers, but basically everyone involved in creating products including designers and PMs.
Every single bullet point here is gold.
gdulli•17h ago
simonw•17h ago
kayo_20211030•17h ago
imiric•17h ago
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•16h ago
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•16h ago
doublerabbit•15h ago
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•15h ago
morshu9001•16h ago
moffkalast•15h ago
morshu9001•13h ago