by logic on 9/29/15, 6:01 AM with 122 comments
by not-a-10xer on 9/29/15, 9:04 AM
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.
Clearly there are 10xers, and some of them even post here: Walter Bright, Bryan Cantrill, and Ted Unangst.
Edit:
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.
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.
by creyer on 9/29/15, 9:23 AM
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.
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
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.
by wpietri on 9/29/15, 5:50 PM
One of the distinctions I learned from Lean literature was that bureaucracies fall on a spectrum between controlling and supportive. 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.
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.
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.
by aaronbrethorst on 9/29/15, 7:28 AM
GOOOOAAAAALLLL! Fail Whale.
GOOOOAAAAALLLL! Fail Whale.
by bbrazil on 9/29/15, 8:53 AM
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.
by hueving on 9/29/15, 8:31 AM
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.
by CamperBob2 on 9/29/15, 7:47 AM
by diminish on 9/29/15, 8:46 AM
Twitter has a horrible, slow moving, bloated interface. I m facing countless examples of disturbances every day.
Maybe a single platform based on PHP could be better, if Facebook is so usable?
by Mz on 9/29/15, 5:43 PM
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.
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.
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.
by Rifu on 9/29/15, 7:13 AM
by retrogradeorbit on 9/29/15, 10:21 AM
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?
by jackgavigan on 9/29/15, 7:55 AM
Really? Not Noah Glass?
Also, no mention of Pivotal Labs role in helping Twitter get rid of the fail whale...
by davedx on 9/29/15, 9:57 AM
by im3w1l on 9/29/15, 3:40 PM
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
E = (eng - ee) * (1 - b * s^(-ee) )
by dunkelheit on 9/29/15, 11:43 AM
by throwaway4123 on 9/29/15, 10:08 PM
by franciscop on 9/29/15, 7:40 PM
by nowarninglabel on 9/29/15, 8:02 AM
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.
by wpeterson on 9/29/15, 7:22 PM
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.
Is that an improvement or just bureaucratic standardization and cargo-culting from engineers raised in the google3 monolith?
by plesiv on 9/29/15, 9:00 AM
by lucio on 9/29/15, 7:55 AM
by presty on 9/29/15, 10:23 AM
I wonder how much allowing things drag for so long cost the company? millions in salaries?
by anon4 on 9/29/15, 10:21 AM
by jordigh on 9/29/15, 11:52 AM