On Friday afternoon, we learned that Elon Musk had asked any of the Twitter employees who “actually write software” to “email [him] a bullet point summary of what your code commits have achieved in the past ~6 months, along with up to 10 screenshots of the most salient lines of code.”
As VP of technology at Slate, my first thought when I read this was “what a tremendous waste of engineering time.” Second only to “that’s a lot of bullets to read.”
“Code commits” in software development are the changes that engineers make to a code base. Typically, software engineers use systems called “version control” that keep track of the changes that they make with notes about why they made them (sort of like “Track Changes” in Microsoft Word). Commits in isolation can be pretty boring. For example, here’s one of mine from a few days ago:
As you can see, this code commit changed the word true to false for a configuration of an ad in one of our newsletters. Really gripping stuff!
Not all commits are one line. Some commits are huge! To ship a really big feature on a site or app, you might change thousands of lines of code. Of course, most software engineers will tell you that this is a terrible practice. Ideally, code changes touch as few lines as possible so that when products inevitably have bugs, it’s easier to track down which commit caused the issue and isolate the problem.
If we squint and put on our CEO-of-too-many-companies hats, we can kind of imagine what Musk’s hoping for with his request. It’s like a self-review for software engineers. If you ignore the “code commits” part, you could read this as him asking engineers to talk about their achievements. But we can’t ignore that “code commits” part because then he followed it up with an ask for screenshots.
Being judged by your ability to self-promote is a time-honored American mistake, but adding judgment of screenshots of your code by a guy who has never committed to your code base is an extra level of dumb. There are numerous problems with the idea of looking at a screenshot of a piece of code and then using it to judge an engineer’s abilities.
First, Musk lacks the context for why the code was written at the time it was written and who was writing it. Code written at the last minute to satisfy some advertiser’s specific request is going to be a lot different than code resulting from a multimonths effort to re-architect a system. Code written by a junior engineer probably won’t be as terse as a senior developer’s code.
Code that’s undergone only one iteration will probably look worse than a more mature product that’s been built over time. Often, the first commit for a feature is the simplest version that lets a product team test whether it will work—not whether it’s scalable or bulletproof. Should engineers show that to Musk, or is he after mature code that makes him say “wow”?
There’s also the matter of coding style. As we say in software development, There’s More Than One Way To Do It (or TMTOWTDI, pronounced tim-toady). In practice, teams will often develop preferred ways to do things to keep there from being a dozen variations of the same basic concepts. Some teams are comfortable with terseness where a lot gets done in one line of code (like list comprehensions in Python, for example). Other teams will flag cleverness during code review as hard to read and a trap for more junior programmers when they’re introduced to the code base. Would Musk understand these tradeoffs as he flips through hundreds or thousands of screenshots on his phone while he flies around in his private jet?
Even more fraught, in most real code bases, the same files are touched by dozens if not hundreds of different developers over time. One screenshot is very likely the conglomeration of hundreds of code commits over a dozen years.
This last point is, perhaps, the biggest pitfall to Musk’s approach and telling of what he doesn’t seem to understand at Twitter. Code is written by teams. Musk is asking for presentations from individuals. Many of the engineers at Twitter have worked there a long time with the same teammates. They’ve developed camaraderie, culture, and a way of doing things.
As of Friday evening, this meeting may have already taken place. I can’t help but wonder how this actually went. Did he ask engineers to get up in front of each other and explain their screenshots? Were they even allowed into the building? Did he actually get any value out of this or was it a loyalty test?
In October, there were reports of Musk authorizing Tesla engineers to review Twitter code. Bringing in senior engineers who write software for cars because they are “10x programmers” isn’t necessarily going to make a team more productive. In fact, it might have the opposite effect as those more familiar with the product feel sidelined or like they have to waste their time trying to explain the context for all their coding decisions to someone who is probably aching to type code and not listen to their explanations.
Musk is clearly going with what he knows (code) and not what he should be working on (culture). Assuming that he can read the code of Twitter’s software engineers and use it for any kind of decision making is pure hubris. But what did we expect? This is Elon Musk. He will likely continue to plow headfirst into Twitter pushing anyone out of his way that pushes back. He’ll look at a room full of engineers and silently judge them because he’s sure he’s the smartest one in the room all the while confusing cleverness with wisdom.
Just like Musk said in December 2017, I love Twitter. I hope it doesn’t go away. I’m still not sure I entirely understand what needs fixing about it. But if he thinks Twitter is going to code its way out of its problems or that code was the problem with Twitter in the first place, he’s got some surprises ahead of him.
Future Tense is a partnership of Slate, New America, and Arizona State University that examines emerging technologies, public policy, and society.
