How Twitter Manages Engineer Effectiveness
Peter Seibel, author of Coders At Work and Practical Common Lisp, is the director of engineering effectiveness at Twitter and wrote a nice blog post about what it takes to improve and manage the effectiveness of software engineers: http://www.gigamonkeys.com/flowers/
Twitter’s Engineering Effectiveness department has the motto “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.
He suggests that improving tools and processes, such as reducing build times from 20 minutes to 2 minutes, can improve the flow of developers. Flow state is important for getting any work done as a software developer. With constant interruptions, it’s difficult to finish any task. With faster tools your flow is less interrupted by those tools. With quality tools, you aren’t wasting minutes or hours or days debugging issues. This increased level of flow state leads to joy. It all fits into the Twitter Engineering Effectiveness motto! Cool.
Mr Seibel goes on to say that like in Dune, fear is the mind-killer and he states that the biggest fear for software engineers is technical debt. His dream is to have a group of developers who are in charge of removing and refactoring technical debt so that other developer groups can be more effective:
We haven’t gotten there quite yet but one of my dreams for EE at Twitter is to establish a standing cruft slaying army. These would have to be experienced, senior folks with the chops to dive into a section of the code base and make both the code and the people working on it better.
This idea echos Michael O. Church’s idea that any team dealing with legacy code or technical debt has to have lots of skill, experience and has to have the authority to make the changes necessary to remove the technical debt and fix the issues in the legacy code.
Standardization is where the most effective gains happen for a software development organization (and most companies are software development organizations now). Things like standardizing on the build processes that each team uses, and the way they write code in certain formats and standards, are very important for improving productivity.
In order for engineering effectiveness engineers to be able to boost effectiveness across all of engineering, things need to be standardized. As we just saw, the big investments in engineering effectiveness work only starts to pay off when you are doing the work for lots of engineers.
The simplest case of this is for the build process. If everyone is able to build a virtual machine and compile the software using Vagrant or Docker or some other tool, they will be able to get up and running faster. You can experience the gains from this even if you’re only hiring one new software engineer every three months. If that engineer is able to get up and running within a few days rather than a few weeks, you bought yourself more weeks of development time.
Another case would be standardizing on IDE or text editor. This is highly controversial, but I’ve found that when you work with others who use the same tools or same class of tools (like VIM and Emacs and command-line versus Eclipse/Visual Studio), you get lots of productivity gains. You get to share information about the IDE and keyboard shortcuts and other settings that can improve productivity and it’s easier to do that with a coworker than to wait a few days for that on StackOverflow.