Benjamin Gibbs

Today's Pragmatic Engineer newsletter [t.ly/ltiYl] was talking about Meta's misguided attempt to fire everybody and replace them with AI. Zuch was evididently thinking (if you can call it that) that mass layoffs would make them look more like a startup. The attached image👇 is instructive. Meta is on the left and a typical startup is on the right. That smaller team is presented as "AI Native," but the fact is that most effective software organizations, not just startups, have had that small-team structure long before AI was on the scene. It's just a more effective way to work. 10-20 person teams is insanely large—the communication overhead enough will kill you, and many of the roles have a large bureaucratic component that doesn't help one iota in geting software out the door. On the smaller teams, people have flexible roles and everybody is entirely focused on getting a product out the door rather than bureaucracy. It's—dare I say it—agile. And, yes, it will work much better. That's not because of AI, though, it's because of the flexibility and the focus. AI is just a tool that team can use to be more effective. It does not replace people. Thinking you can make a large team more effective by firing half the team reminds me of the thinking—popular years ago—that if you bought lots of books, your kids would somehow become smarter, through osmosis I guess. The thinking confuses corelation (smart kids come from homes with lots of books) with causation (the mere presense of books makes kids smarter). It's not the decorating decision, of course, it's the parents who are reading the books that are the key factor. If you fire half the team without getting rid of the bureaucracy and ineffective ways of working those people supported, you'll just burn out whoever's left. That's exactly what happened at Meta. It's not the size of the team that makes it better; rather, effective teams don't carry the overhead and bad ways of working, so are naturally smaller. Start by fixing the way you work. The team size will take care of itself.

When it comes to APIs, most people get things backward. The best way to create an API or any other interface is to start with the code that uses the interface. Write a program that uses the interface that you wish existed—an interface that makes your life easier and lets you do things painlessly with minimal work. Only when you have that down solid does it make sense to implement that interface. Starting with the component that exposes the interface is just guesswork. Those guesses about how the component will be used are usually wrong. This rule applies recursively, from customer-facing APIs to entire platforms down to the set of public methods on a class (which are the class's interface, whether or not you use an "interface" keyword).