>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.<p>Management has a vested interest in pushing the meme that there are no 10xers: it gives them an excuse for not paying these engineers what they're actually worth. The rest of us just go along with it because it assuages the inadequacy we naturally feel when we compare ourselves with someone like Linus Torvalds or John Carmack.<p>Clearly there are 10xers, and some of them even post here: Walter Bright, Bryan Cantrill, and Ted Unangst.<p>Edit:<p>I'm also not surprised Seibel would say something like this given his past demonstration of lacking social awareness by titling his book of programmer interviews "Coders at Work"--a title that one of his interviewees, L. Peter Deutsch, rightly objected to, much to Seibel's shock. Deutsch in 1984 co-authored the seminal paper on building efficient virtual machines for dynamic languages through just-in-time compilation and inline caching, techniques which ultimately gave rise to the JVM. He deserves an immense amount of respect for this and other accomplishments, and we do him and our profession a great disservice by publicly referring to him as a "coder" or anything else that elicits something less than awe from the general public.<p>Could you imagine doctors referring to some highly-regarded brain surgeon as a "cutter" or "butcher?" No, instead they talk them up as "brilliant" or even god-like, yet we do the equivalent with "coder" (and allow the media to do it too) all the time.
Nice article, but I can't agree with everything inside.<p>1. Engineers are not computers, so saving 5 minutes a day will not increase productivity by 1%. Most engineers work with passion, and don't look at the clock. They are focused on delivering a certain task, and they will make their best to deliver it, even with the interruptions, even if this will require them to work 10 minutes more at the end of the day.<p>2. The benefit of the tools is a clear win, but as these tools will not change so much over time, after the initial boost of productivity, the effect will no longer be noticeable. You can't increase performance each month compared to the last month just by using the right tools. So I think the EE team make sense to be created "on demand" and not as a permanent solution. Time should be a parameter in the effectiveness model<p>3. If you grow to a large scale enterprise, as the people are not computers and reaching agreement between large number of individuals is not easy, the bigger the number of people in the EE team the harder will be to approach solutions and test them.
I mostly like this post, but there's something that troubles me about it.<p>One of the distinctions I learned from Lean literature was that bureaucracies fall on a spectrum between <i>controlling</i> and <i>supportive</i>. I had honestly only ever experienced the former: rules and mandates to make me do what other people valued. But I came to realize that there are other possibilities. For example, when my team jointly makes a checklist we follow, that's a kind of supportive bureaucracy. I could imagine scaling that up, but it's certainly rare.<p>In this post is a hunger for power that makes me uncomfortable. Sure, any short-term mess can be solved by bossing people around. But I've seen places where centralized quality groups become strongly counterproductive. Every mandate they issue is intended to clean up a mess. But as developers become disempowered, they do less and less cleaning on their own.<p>Hopefully that won't happen at Twitter; there's a theme of wanting to build trust. But there's also the theme of ripping stuff out, of controlling the chaos, of whipping things into shape. That sounds much better to the person holding the whip than to those getting whipped with it.
<p><pre><code> GOOOOAAAAALLLL! Fail Whale.
GOOOOAAAAALLLL! Fail Whale.
</code></pre>
Oh yeah, fail whale. I guess Twitter really has come a long way in the past five years. Despite all of the shit they get for not building out their product in a visually-engaging fashion, I have to say that I can't remember the last time their product failed me. Props.
> Once your engineering org gets to be a certain size the benefits you can obtain by investing in making all your engineers slightly more productive start to swamp the slight gains that one team might get from doing things their own, slightly different way.<p>I like to think of this idea as group vs. individual velocity. Yes, you personally might be able to go faster by introducing new technologies - but everyone else is slowed down by having to learn it. Knowing which few of these technologies will be an overall win is the tricky bit.
This article repeats the assertion that there is no such thing as a 10x engineer but doesn't site anything that shows such. It has become a popular meme but I know counterexamples from people I have worked with that were significantly more effective (10x minimum) engineers than others.<p>Does anyone have anything that shows they don't exist? I'm starting to think it's something average engineers like to repeat to convince themselves that there isn't anyone really 'better' than them. Sort of a reincarnation of the condescending "there are no winners or losers" thing we do with childrens sports.
At first I expected an article on Twitter platform for 3rd parties where 1000 flowers bloom and 999 of them get ripped.<p>Twitter has a horrible, slow moving, bloated interface. I m facing countless examples of disturbances every day.<p>Maybe a single platform based on PHP could be better, if Facebook is so usable?
I strongly suspect the mathematical formula suggesting that 10,000 engineers could be as productive as 45,000 with the right support is a case of "in theory, but not reality."<p>When tree farming was invented, the initial crop was wonderful, but they soon had to come up with a term meaning "forest death" for the sickly, underdeveloped trees that followed. A monoculture of the same plants quickly strips the soil of essential nutrients and if you cannot identify those nutrients and aggressively resupply them, you will soon find that the trees you wanted to grow and harvest will no longer thrive and somnetimes will no longer survive. A forest can produce healthy trees for generations because of the diversity of plants growing therein. Different plants use different nutrients and some replenish the nutrients used by neighboring plants.<p>Obviously, software tools are not plants. But I have my suspicions that the diversity of code he describes developed in part for reasons like "different engineers happened to be experienced with different languages, tools, etc" but there may be cases in there where it developed that way because it was the best way to handle it. So when you start standardizing things, you may be killing off things that are critical to the health of the codebase and the company.<p>I can see value in having someone dedicated to serving the needs of the engineers so they can be more productive. I can see a need to clean things up. But complexity itself often has inherent value that cannot be replaced or improved upon with a simpler solution. Sometimes, simplifying things amounts to throwing the baby out with the bath water. I hope they don't wind up doing that.<p><a href="https://en.m.wikipedia.org/wiki/Forest_dieback" rel="nofollow">https://en.m.wikipedia.org/wiki/Forest_dieback</a>
That was an enjoyable read. As mentioned in the article, here's the link to the same talk he gave at Facebook's @scale [0], though the sound gets ridiculously out of sync after a bit.<p>[0]<a href="https://www.youtube.com/watch?v=8IyXcLFO9ns" rel="nofollow">https://www.youtube.com/watch?v=8IyXcLFO9ns</a>
> Alex Roetter, now our SVP of Engineering, then an engineer, personally led the effort to convert what Scala code the ads team had already written into Java.<p>I'm having trouble understanding why on earth you would rewrite Scala code to Java. The Scala code runs on the JVM and can interoperate with the Java, so what is the point?
<i>> Twitter’s first line was written in 2006 by our now interim CEO, Jack Dorsey.</i><p>Really? Not Noah Glass?<p>Also, no mention of Pivotal Labs role in helping Twitter get rid of the fail whale...
I'm really interested in the "standardization" part near the end. Is the end goal to have Twitter building everything with Java, or everything with Scala, or something like that? It does seem to go against the grain of "use the best tool for the job".
> E = (eng - ee) * (1 + b * ee^s )<p>He posits that model and draws many conclusions from it. But how reasonable is? I would expect the improvements in efficiency factor to decay much faster. If everything is done exactly right, there is an optimal efficiency factor. With no ee's there are deviations from that perfect process. As more ee's are added, more deviations are fixed and you get closer to optimal efficiency. These assumptions would mean that efficiency should converge as number of ee's approach infinity. My model suggestion would be<p>E = (eng - ee) * (1 - b * s^(-ee) )
The article discusses the kinds of problems that wildly successful teams of 1000-s of engineers have. As such it is kind of irrelevant for most of us - not everybody will grow their team to 1000 engineers or assume the role of VP Eng in a large organization. A more practical matter to consider, are these problems worth worrying about from the start or is "let the thousand flowers bloom" strategy part of the twitter's success?
I was discussing this article with another ex-Twitter employee yesterday. I quit in the middle of this monorepo clusterfuck, and my views are very different - I believe most of what happened was a Battle of the Egos. I can name names but its not worth the trouble, Twitter was a generous employer etc.
He remembers most of this as a Battle of the Languages ie. Scala vs Java vs Ruby thing. Seibel has this 3rd version, having joined much later in 2013. The list of ex-Twitter engineers is probably in the thousands at this point, so you are going to hear a whole different set of narratives.Twitter is Roshomon 2.0. One thing is certain. The lack of profitability is very much due to throwing lots of cash at lots of engineers who wrote and rewrote the same bits until kingdom come, driving each other and the market nuts as to what all the fuss was about.
Once you get 4.000 Engineers in EE, it is worth considering creating some tools specifically for EE. Let's call this team Effective and Efficient Engineering, thus EEE.
The question that has been arising for me, is what amount of resources do you devote to engineering effectiveness in a relatively small engineering org (~25 people)?<p>It seems like the presented formula would say to not devote any resources, but there seems to be some good return on some effort put towards it. Right now, I've just considered it some percentage of my job to work on.
Once upon a time, there were multiple repos and multiple tools for different jobs.<p>Then Twitter grew to thousands of engineers, many of whom were from Google. Now everything is being converted to enterprise Java in a single, monolithic repo.<p>Is that an improvement or just bureaucratic standardization and cargo-culting from engineers raised in the google3 monolith?
I was constantly being reminded of Taylor, while reading the
article. Is this the scientific management of software engineering?
It looks a little too constraining for a rapid-changing discipline as SE.
is it just me or this article points to a huge lack of technical leadership inside twitter?<p>I wonder how much allowing things drag for so long cost the company? millions in salaries?
I wish people would learn what the hundred flowers campaign was and not use such dumb and insensitive titles for their blog posts. It's like calling it "the final solution to the twitter problem".