A coworker had this anecdote decades ago.

There's a difference between 10 years of experience and 1 year of experience 10 times.

YOE isn't always a measurement of quality, you can work the same dead-end coding job for 10 years and never get more than "1 year" of actual experience.

For many workers, working towards the goal of making the company profitable would be an improvement.

Many workers primarily work towards helping the boss grow their head count, or helping the middle-manager with their emotional state.

  They have <a really expensive> infrastructure that serves 800 million monthly active <but non-paying> users.

I don't pay Meta any money too. Yet, Meta is one of the most profitable companies in the world.

I give more of my data to OpenAI than to Meta. ChatGPT knows so much about me. Don't you think they can easily monetize their 800 million (close to 1 billion by now) users?

They consistently have the best or second best models.

They have infrastructure that serves 800 million monthly active users.

Investors are lining up to give them money. When they IPO, they'll easily be worth over $1 trillion.

There's price competition right now. They're still surviving. If there is price competition, they're the most likely to survive.

Extreme Programming is about the lightest "methodology". I've seen it used on a team of 30 (20 devs, 10 QA). It scaled that far, but we had a couple of exceptional "XP masters" on our team (just as devs, but they kind of owned the methodology as well).

That eventually fell apart, because upper management couldn't understand agile development, and so they killed it. Never mind that it delivered on time.

But on a small team (4-5 people), I have seen even less process. There was a manager who coded half-time. There was an overall direction, and discussions as needed. Each person had their area of specialty within the code. There were code reviews before checkin, but the code reviews were over-the-shoulder in someone's cube. There was a bug database, but there was no JIRA or other "ticket" system. (There eventually was, after the team grew. And there eventually was a quarterly planning meeting.)

There was a weekly standup for the larger team (20 people). But within the smaller team, each person kept their own to-do list. When your code needed to interface with someone else's, the two of you would hammer out what the interface was.

That won't scale too far. And it risks the mismatch with upper management that the XP team ran into. But for a small team, it can work.

Honestly I think lesson 7 is nobody's normal. All the things the author's noted about interacting with other people - see how weird and rare it was and how long it took to recognize it? See how often it's on your plate to be the one to go zen mode to figure out how to dance with someone? The author isn't normal, they're now skilled. Before, they weren't normal, because they noticed they weren't skilled. Most people don't.