Code Review on Printed Paper: an Excerpt from the Twitoons Comic Book
👋 Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover topics related to Big Tech and startups through the lens of engineering managers and senior engineers. In this article, we cover two out of seven topics from today’s full issue on The Man Behind the Big Tech Comics. To get full issues twice a week, subscribe here.
If you ever worked at Google, I probably don’t need to introduce Manu Cornet. And if you’re not a Googler or a Xoogler, then here’s a short recap of some of his comics. For example, if you don’t know what a Xoogler is (ex Googler) or a Noogler (new Googler) or a Doogler (the pet dogs owned by Googlers) and now you’re wondering why Google has all these terms, Manu created a comic on this:
Today’s issue will be a lot more visual than usual. The topic will also be more lighthearted: Big Tech, Twitter, and comics. Manu recently published his book Twitoons: one employee’s cartoon chronicle of Twitter’s accelerated descent. I read the book: it’s funny! I still can’t decide if it’s funny because of Manu’s style, or if it's funny because it’s true.
Today’s newsletter closes with a full chapter from this book, visualizing when Elon Musk demanded all Twitter software engineers print out their code on paper (!!) and report for code review. But before we get there, we touch on how one of the most referenced Big Tech comics was created. This one.
With this, my questions and comments are in italic, and Manu’s answers in regular fonts.
As usual, none of these links are affiliate ones, and I have not been paid to mention any of them. More on this here.
Drawing the famous Microsoft, Oracle, Amazon, Facebook, Google, Apple comic
How did you come up with the “famous” organizational chart comic that you are most known for?
Initially, the punch line was meant to be Oracle. At the time, this company was suing Google over its use of Java, and I decided to make fun of how Oracle has a much larger legal department than engineering, so I drew this:
To make a good punchline, you need a buildup. So to make this a good comic, I needed to draw other companies for a comparison. So I drew four more:
I still needed one last one, to make it six and make it symmetric. Microsoft was, of course, the obvious missing one. So I researched the culture at Microsoft a little bit and came up with that — now famous — gun drawing:
After you’ve been working on an idea for a while, you completely lose track of whether it’s actually funny or not. After I finished it, I didn’t find it funny. I showed it to my partner at the time, and she didn’t find it funny either. I was very close to not releasing this cartoon, in the end! Then I just published it.
It’s ironic because this comic became probably my most popular comic, and the Microsoft drawing with the guns was the one that people found the most funny. It shows you how clueless I am about predicting what will work!
Code review on printed paper: an excerpt from the Twitoons book
A year ago, the end of October 2022 was a very turbulent time at Twitter. In the article Turmoil at Twitter, we covered both how engineers were told to print out code on paper (!!) for Elon Musk to review, as well as how firings on the spot had started. Manu was one of the several people let go after pulling a 7-day week, working through the weekend.
Manu’s book covers this period with far more detail than we’ve accessed, along with new, previously unpublished illustrations. The below excerpt is from Part 6 of the Twitoons book, from the chapter titled “Code Review.”
Despite the long hours, we were all still painfully aware that the chopping block was dangerously near.
Regardless of how hard we worked, would the dreaded termination email still show up, on a bright Sunday, with the usual (and newly ironic) friendly chime?
Indeed, in parallel with the urgent product changes, Elon Musk kickstarted the dreaded “reduction in force.”. Given that he had clearly stated he wanted virtually no moderation on the platform, it was easy to guess what would happen to all the teams responsible for that: all fired. For engineers, it was a little trickier: he needed at least some of them to keep the site running. But which ones?
One important problem with software engineering is that evaluating workers is extremely difficult. Large technology companies spend an enormous amount of resources trying to monitor, evaluate, and eventually accurately reward contributions from their expensive workforce.
For a team that makes cars in a factory, measuring performance isn't exactly easy, but it's feasible: you measure the number of cars produced per month, you take into account things like customer return rate and mechanical failures, and with a little trial-and-error you can reach something reasonable.
For software, it's foolish to measure quantity: a shorter program (fewer lines of code) is often better than a longer one. You could measure things like bug reports or software crashes, but most projects are so complex and involve so many moving parts produced by different teams and intertwined dependencies that any such attempt usually turns out to be a wild goose chase.
So performance measurement is already difficult in normal conditions, when it serves as an input to decisions affecting an employee's role and career. Now imagine you are part of a team of engineers coming from Tesla, tasked with determining which 20% of engineers Twitter should continue employing, and which 80% it should fire. On top of that, you need to figure it out by next Monday because otherwise they all get more stock options the following week, as planned, and that's gonna cost your boss. And on top of that, consider that the engineers doing the evaluation are not only unfamiliar with the material they need to evaluate (the code that makes Twitter work); they aren't even familiar with the very industry, since the software they usually write is destined for cars. It's like asking a tricycle maker to pilot a spaceship because, well, it's all transportation.
Tesla engineers thus resorted to measuring what most experts will tell you is completely meaningless: the quantity of code contributed to Twitter by each engineer. The number of files they changed, insertions, and deletions (lines of code added and removed). As if these numbers were the only thing that mattered in one's entire tenure, sometimes their entire career.
Given the harsh conditions and time constraints the Tesla folks were under (and had, by the way, probably been under for months or years), it's hard to blame them. Meaningless, but expeditious.
The whole process was dubbed by Mr. Musk a “code review” where each Twitter engineer was asked to pick their own “most salient” code contributions, print them out on paper, and bring them to their interview, nay, their trial, by Tesla engineers. The printing out part caused so much mess and confusion that the process was eventually simplified and people could use a computer screen to showcase the reasons why they claimed they shouldn't be fired.
Let me emphasize that this is a complete perversion of the common expression “code review”: engineers usually review each other's code in a well-established practice aimed at catching bugs, making the code better, and sharing knowledge. Not at selecting people for employment termination.
Oh, and knowing Elon, he might have devised a slightly different flavor of ”reviews” for female employees?
For those who were paying close attention to the timeline of employee terminations, even that raw code quantity number didn't seem to explain it at all. My team's most productive engineer by a long run, in terms of pure quantity, was let go alongside everyone else. There were also petty little arrangements where an engineering director who knew one of Elon's goons requested that employees X and Y should be kept on the payroll, and so on. But to whoever wasn't privy to all this underground barter...
...it all seemed rather random, and it probably was.
The press, who had a good idea of what was happening at the headquarters, sent reporters to camp at the entrance in hopes of getting a quote or a video clip from fired employees. Two pranksters who claimed to be Rahul Ligma and Daniel Johnson showed up with cardboard boxes and were able to temporarily convince the media they were part of the early layoffs, starting a trail of misinformation on social media. Ironic.
As far as I was concerned, I'm glad I didn't have to submit to any of those “code review” sessions, since I was fired on November 1, a few days before the large waves of layoffs. As I was attending a team meeting about a new critically important project, I was kicked out of the meeting, my work email and calendar blanked out, and my work laptop locked itself up. I thought I may have been hacked. It was only half an hour later that I received an actual termination email. It didn't state a cause, but the apparent immediate reason was that I was trying to help my coworkers safeguard some documentation (performance reviews, praises from peers, etc.) that would be valuable should they need to seek employment.
More broadly, did it have anything to do with my critical cartoons? It's hard to tell, since the person who fired me (my boss's boss, a.k.a. director) was also fired the following week (I actually kind of liked him, and still do). So was my direct boss. And the director's boss (I quite liked her, too). And her boss.
Anyway, it's fair to say that I was deemed a little too much of a troublemaker under the new leadership. I don't blame them.
I had been planning to make a cartoon where I would depict myself standing in front of the office entrance, alongside reporters and recruiters. After my termination, the cartoon (you wouldn't think I would stop drawing about Twitter just because I was fired, would you?) took a slightly different meaning, which I quite liked.
This is Gergely again.
If you enjoyed these comics, you can buy Manu’s book Twitoons, here — priced at a modest $12.90 — and the one on Google’s corporate culture, here. You can view more of Manu’s comics on his website. As usual, none of these links are affiliate ones, and I have not been paid to mention any of them. More on this here.
It’s been almost exactly one year that about 50% of the staff at Twitter got fired — Manu being booted a few days earlier than most. I asked Manu if he had received severance owed to him as per his contract: and he has not gotten anything just yet.
Other former Twitter engineers are in the same situation as Manu — waiting on severance overdue. In a smaller win for former emplyoees, the National Labor Relations board issues its first complaint against X Corp for illegally firing Yao Yue, a widely respected principal engineer at the company.
Zoë Schiffer at Platformer reported this in the article How one former Twitter employee could beat Elon Musk in court. Still, this case only goes to trial in January — and Elon Musk’s strategy clearly seems to be to not worry about potentially breaking regulations in the impulse of the moment: instead, deal with these years later, in court. More than 2,000 employees have filed arbitration claims against Twitter: and eventually the jury will get to all of these, and decide on severance due.
Originally, I reached out to Manu intending just to ask for permission to publish a part of his book, as it was quite relevant for last year’s events at Twitter. But as we started talking, I realized I’ve never met a real-life cartoonist before, much less a software engineer cartoonist! So our conversation turned into a lot more than just about the latest book.
In the full issue of today’s newsletter, we dive into several other topics we discussed:
- The motivation to draw caricature comics. How Manu started to draw comics, and why.
- Fourteen years at Google as a software engineer. Getting into Google, spending 8 years on the Gmail team; working on Android and ChromeOS, and what Manu learned from his time at Google.
- Comics at Google. About 1/10th of Google employees subscribed to Manu’s comics. When did Manu get into the most trouble because of comics?
- Working at Twitter. Twitter’s web app and tech stack. Internal tooling at Twitter, versus Google.
- The best and the worst of “old Twitter”. The things “Twitter 1.0” did vey well, and where it clearly struggled — Manu’s insider view.
- How to draw cartoons as a software engineer. The similarities and differences in drawing a good cartoon vs writing good code; Manu’s cartoon drawing toolset; and advice to get started.
Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 tech newsletter on Substack.