Peter Seibel:
How to think about engineering effectiveness
I think a big part of the problem is that we—as an industry—are not very good about thinking about how to make engineers effective. For our software, especially back-end software, we can measure its goodness by the number queries per second it can handle, the number of incidents we experience, and the amount of hardware we have to buy to run it. Those things are easy to measure and even fairly easy to tie to financial implications for the business.
Engineers’ effectiveness, on the other hand, is hard to measure. We don’t even really know what makes people productive; thus we talk about 10x engineers as though that’s a thing when even the studies that lead to the notion of a 10x engineer pointed more strongly to the notion of a 10x office.But we’d all agree, I think, that it is possible to affect engineers’ productivity. At the very least it is possible to harm it.
The Twitter EE motto is: “Quality, Speed, Joy”. Those are the three things we are trying to affect across all of Twitter engineering. Unlike that other famous triple, Fast, Cheap, Good, we believe you don’t have to pick just two. In fact they feed into each other: Building things right will let you go faster. Building faster will give you more time to experiment and find your way to the right thing. And everybody enjoys building good stuff and a lot of it.
This is an interesting way to look at developer productivity. Generally in my experience, when there’s an emphasis on speed in the sense to ship something on a tight deadline, the quality of the project might suffer. However, this isn’t speed in the sense of tight deadlines. It’s speed in the sense of writing code quickly which as Mr. Seibel points out, frees time to experiment and explore better ways of problem solving.
LET A 1,000 FLOWERS BLOOM. THEN RIP 999 OF THEM OUT BY THE ROOTS.