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.

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...

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.

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.

The best suggestion would probably be to try and write such a list yourself IMO.

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.

> 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.

> 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.

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.

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.

Here's a sample:

> His story isn’t just about writing code, but about inspiring a community to strive for a better web. And perhaps the most exciting chapter is still being written, as he helps shape how AI and the web will intersect in the coming decade. Few individuals have done as much to push the web forward while uplifting its developers, and that legacy will be felt for a long time to come.

https://addyosmani.com/bio/

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.

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.

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.

This one is golden, it should be framed and put in every engineer's office.

>Your network outlasts every job you’ll ever have.

Networking is the real human currency, period.

> If you win every debate, you’re probably accumulating silent resistance.

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.

#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.

This is Goodhart's law - "When a measure becomes a target, it ceases to be a good measure" [1].

[1] https://en.wikipedia.org/wiki/Goodhart%27s_law

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.

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"

> 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?

This is very true in personal lives as well.

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?

YES! And sometimes that stranger is you, 6 months down the line.

Something that seems lost on those using LLMs to augment their textual output.

Thanks for all the spyware in Chrome ig? And for many inane design decisions that favor usability over privacy and security?

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.

> "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!

Unfortunately for users this is more often used as an excuse to ship buggy / badly done software.

> 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.

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.

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

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)

> Senior engineers who say “I don’t know” aren’t showing weakness - they’re creating permission. When a leader admits uncertainty, it signals that the room is safe for others to do the same. The alternative is a culture where everyone pretends to understand and problems stay hidden until they explode.

It's interesting to contrast this with Sean's statement here www.seangoedecke.com/taking-a-position/

> At that point, you need to take a position, whether you feel particularly confident or not.

> If you don’t, you’re forcing people with less technical context than you to figure it out themselves

To square the circle, I think the lesson is hide uncertainty to higher-ups, but don't to peers/ other ICs.

Of course, the challenge is that often, unfortunately, both the manager and the other ICs are in the same meeting.

Probably this is one justification of one reason why I hate meetings that include managers.

They heard about opportunities first, could build bridges faster, got recommended for roles, and co-founded ventures with people they’d built trust with over years.

Your job isn’t forever, but your network is. Approach it with curiosity and generosity, not transactional hustle.

When the time comes to move on, it’s often relationships that open the door.

Thanks! I used to think writing code was the easiest and most enjoyable thing in the world. Interacting with people? That’s always been the hard part. Guess it’s high time I changed my mindset now.

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've come to realize that not all skills can stand the test of time.

Some things were very useful initially but quickly plateaued. Some felt like they were moving at a slow speed, but were quietly compounded a year after.

I always return to a rough outline.

Quickly acquainted with tools, frameworks, and specific stacks.

Slow skills: judgment, problem framing, communication, taste.

The gradual changes are often unnoticed daily but become apparent over time.

Projects become unclear.

Pile up constraints.

Being right is less important than the trade-offs you make.

I’d be interested to know what you think.

Which skills were more useful than you anticipated?

What’s something you over-invested in early on that didn’t compound?

What would you choose to learn more slowly if you had a second chance? ~

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.

> 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-...

[0]: https://news.ycombinator.com/item?id=46469877

The hardest part is that user focus is sometimes at odds with technical cleanliness. You can ship something inelegant but useful, or elegant but slightly off from what people need. Most orgs mess this up by choosing elegance.

Thanks for sharing this.

> 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/

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.

   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.

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.

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.

> but coordination costs grow geometrically

Using geometrically instead of exponentially! Thank you!!! :-D

> 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.

Gold.

* Don't work "off the clock", no matter how strong the urge: There's nothing managers hate more than surprises. Even good ones! If you've got some idea to work on, discuss it and get buy-in early. If you're spending a lot of your own time on something, that means it's probably low-value and you subconsciously know it, or it's stepping on somebody else's toes, or it's something that you're the only one who cares about. Once you're done, all your manager is going to say is "why were you doing that instead of <other higher priority thing>", and if it creates a bug or user complaint or anything else, you'll be on the hook. Save your creativity for personal projects.

* Get fast feedback. This kind of relates to the above, but more generally, iterate quickly at every scale. If testing your changes takes more than one button click and a couple seconds, whether compile time, staging deployment time, etc., fix it. Find out how others are automating their dev flows. A tiny bit of improvement here cascades greatly. Get fast feedback on designs: don't spend a ton of time writing a long doc and waiting for approval; send out a 1-paragraph summary or whatever you think the minimum is, get signoff, get done and move on. Do document, but don't overdo it. Get fast feedback on ideas; don't wait until code review time to find out that the team was planning a different direction. Yes, this does kind of suck if you're naturally introverted and prefer just coding, but it's part of the job.

* Set an extremely low bar for each day, but meet it. We aren't all superstars all the time. There'll be times when you're burnt out or blocked by something you really don't want to deal with, and making progress can seem overwhelming, so "I'll just surf the web for a while" turns into all day, which can turn into all week or all month of excuses about how little progress you're making, and the anxiety and guilt becomes more overwhelming than even the work. Avoid this by setting an easily achievable goal: a couple lines of code, a quick chat with someone who might know how to unblock one thing, whatever. That way you're not letting the anxiety build, you're not waking up the next day in the same state that you were the previous day, you at least have something to talk about during standup, and it's one less thing to deal with. Oftentimes it creates some momentum, and turns into a fully productive day! But be okay if it doesn't: the goal is just to get that one thing done, and anything else is purely optional: sometimes it's good to have an off day to recharge, so long as you're not starting the next day in the exact same position.

From where I know: living and breathing like it for the last 19 years

- How do you actually grow being in one company for 14 years?

Because otherwise you start thinking that politics matters.

A little bit of sarcasm here: “well there probably isn’t a lot of great engineers at google then”

> 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.

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.

That's why I left Google for HFT. Much better life.

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.

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.

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.

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.

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.

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

i mean, addy has literally been at google 14 years, i think internal network has outweighed the external one here

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.

Addy Osmani plagiarized my code and 'apologized' years later by publishing an article on his website[1] that he has never linked to from his social media accounts.

I cannot accept his apology until he actually syndicates it with his followers.

Seems relevant to note this behavior in light of points "6. Your code doesn’t advocate for you. People do.", "7. The best code is the code you never had to write.", and "14. If you win every debate, you’re probably accumulating silent resistance."

1. https://addyosmani.com/an-apology-to-eli/

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.

Very correlated with the quality of the message I'd imagine.