Slashdot Mirror
Twitter's Tech Lead On Making Software Engineers More Efficient
Tekla Perry writes: "Engineering productivity is hard to measure," said Peter Seibel, the tech lead of Twitter's engineering effectiveness group. "But we certainly can harm it." Seibel spoke this week at the @Scale conference in San Jose, hosted by Facebook. He says in large companies one third of software engineers shouldn't be working on the company's products, but should be dedicated to making other engineers more effective. "As an industry we know how to scale up software," he said. "We also know how to scale up organizations, to put in management that lets thousands of people work together. But we don't have a handle on how to scale up that intersection between engineering and human organization. And maybe we don't understand the importance of that. We massively underinvest in this kind of work."
Wait, why should anyone listen to someone at Twitter for how to do anything?
The only thing that's more of a joke than Twitter engineering is Twitter business development.
Motivation is a wrinkled, green thing that sometimes smells faintly of ass.
Sub in game rooms for dancing dogs.
I'm kind of surprised twitter has more than one Software Engineer.. Don't they just send short messages around and count hash tags?
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Ever?
is cost center. Things like this don't exist because the bean counters only understand cost per head and revenue per head. Long term value is an anathema in the world of quarterly profits.
The Mythical Man Month is still extremely relevant on this topic. It's hard for me to take anyone seriously on this topic unless they've read it. Communication is, of course, one of the major challenges with scaling an engineering team.
One thing the MMM points out is that some engineers are 10 times more efficient than others. The obvious solution is to teach the "others" to do the things the efficient programmers do.
"First they came for the slanderers and i said nothing."
HR was the Great Corporate Hope of the '90s. It was going to make the entire corporate workforce happy, productive, creative, and interacting with one another in unexpected, cross-functional combinations, while also recruiting the best and brightest... from diverse backgrounds of course. The head of HR was practically a C-level employee.
Here's what happened to HR, 15 years later.
Don't waste time browsing on twitter.
Observation from an organization filled with computer scientist and engineers. More often that not there are massive amounts of duplication of effort. Many projects focus on the quickest way to get attention and credit at the expense of long term solutions. Disingenuous managers play games with definitions to explain that their project is actuall "different" and they are not competing at all and wasting money.
Some good ideas in TFA for optimizing the process. While all or some of the ideas may not be appropriate in your environment, the article is worth the read to see how others do stuff.
What is most interesting about twitter is that so many people interact with twitter technology on a daily business without even knowing it. Bootstrap is everywhere and beyond twitter.com is the most influential technology that twitter has built for the web.
Probably the biggest productivity killer in west coast development shops. I think they don't use it as universally in other places.
Yes, the company is now profitable and revenue continues to grow, with 2015 revenue expected to be around $2 billion.
I don't get the point of Twitter and don't use Twitter. Having said that, anyone who has thousands of engineers and coders and the project doesn't completely explode has probably learned a few lessons along the way. I'm sure I could learn some things from them. Also, I'm willing to learn from anyone who has brought it billions of dollars.
The attitude of people here suggesting there is nothing to be learned from Twitter's experience is silly - because we've ALL built multi-billion dollar companies around a platfom"with tens of millions of users, right? They only have a few tens of millions of users, they don't know anything about scale. We all know way better than them, because each of has BILLIONS of users on our servers, right?
There are so many times that tooling or system issues get in the way of development - we all know you can get into a nice flow of development and it doesn't take much to bring you to of it.
Someone spending a little time on preparing the runway so to speak, could have a large difference in productivity. He said with ten people you didn't need anyone dedicated to this but I disagree - just make it a rotating position so each person on the team gets a month at a time to fix whatever endemic company system issues bug them the most. You would get some huge gains from software engineers fixing the systems around the software they work on...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Let my manager set my goals, then prevent other groups/managers from wasting my time. I spent 14 years at Qualcomm ('94 to '08), I never worked harder, got more done, and had more fun than those 14 years. The secret? Management was very good at keeping distractions to a minimum.
Sadly, from what I hear now that's no longer the case. At the Parade of Lights last, I dunno, November? I met the new boyfriend of a long time friend. He was in his 50's/60's, spent most of his career in Texas at TI, and had been at QC for a year. He hated it. Why? He didn't want to talk about it and I didn't pry.
About 6 months ago I ran across a guy I knew at QC, he'd been there from the beginning. He said they'd cancelled the Christmas parties (which were epic), and the summer picnics (which were epic if you had kids). He was about to take a 6 month leave of absence and wasn't sure if he'd go back.
Then 2 months ago QC announces a 15% layoff in 2 months. That 2 months hit yesterday. I'm hesitant to contact folks I knew when I worked there, but it sounds like QC has gone from good, engineering management, to bad, MBA/cronyism management.
Choose whatever language you want. None of you are even competitive with me when I choose C# under Visual Studio with a notebook full of pseudocode. Most of these shitty internet companies live and die without knowing the first thing about threading or asynchronous I/O, and they need your millions and billions to run server farms full of slow script kiddie garbage like Python. Go ahead, take your shortcuts, pad your schedules, blame "social noise", leave out error handling because "it's too hard", because in each scenario you leaned on an "easy" language without understanding design. When Moore's Law absolutely ends, inefficient software engineers simply won't exist, they'll be hunted down like the money-murdering swine they are. What a great rant this was, thank you, thank you.
1. Layoff your American Deva
2. Replace them with H1-B visa workers
3. ???
4. Profit
If one third of your engineers are focused solely on improving the "effectiveness" of other engineers, that implies you think you can improve their efficiency by at least 1/3 by doing this. I don't buy it. Furthermore, you don't need an engineer to take care of these problems, you need a project manager. If an engineer is the right person to deal with it, you don't need a second engineer to do it for them.
No you don't. The industry certainly knows how to solve trivial problems in hugely over complex ways, but those mountains of code quickly become unmaintainable. One of the prime examples of this is Android which tries to solve the near trivial problem of "application launcher" with so much code, entering a to long password can trigger an application crash which unlocks your phone.
One of the prime examples of this is Android which tries to solve the near trivial problem of "application launcher"
If it's SO trivial then why has Microsoft re-written theirs a half-dozen times?
If you've got one third of your engineers working at it, why not work on improving the effectiveness of all the employees? It seems like you'd just be locally optimizing and making everything else a bottleneck -- not to mention generating a potential double-ended morale problem where engineers start complaining about the comparative inefficiency of the rest of the company.
The easiest way to improve efficiency for the younger IT crowd is to take their smartphone away.
That way their thumbs can be used on a keyboard instead of in IM's.
Smartphones waste more time than smoke breaks do. I smile every time a tapatalker gets walked out.
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
I work in a company where most of the programmers still only have a single monitor. And where most people don't even attend a single class for the year. Where management is more interested in getting the cheapest consultant instead of the most productivity. A company where the system manager make design decisions over the technical lead.
Marketing reasons, it's not like the Windows 8 "application launcher" is any better than the Windows 95 one, or for that matter the Windows 3.1 one.
Twitter has lost money every quarter of it's private and public existence. They know how to issue stock to pay high salaries and bonuses, but not so much how to make a profit. That part of business must be low priority. Hey, slurp it up, Twitter stock holders. I don't care how you waste your money.
BSD style.' In the NIIGER ASSOCIATION
The article itself makes a lot more sense than the summary.
Lots of people build tools. Lots of people build the parts people interact with. In small shops you do both, hoping to cover enough of each to stay productive. Dedicating some meaningful percentage of a very large staff to doing the first one so that the larger, second set can realize massive productivity gains... that makes a lot of sense. I don't think it's a very radical concept, either.
Let's just get rid of PHP, Javascript, Ruby and all that other poorly typed languages.
It sounds awfully like a rehash of Fred Brooks' surgical team model.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Time for a couple of rants from an old man.
Engineer: I think this word is used far too much. People are not engineers just because they can write code or install applications or whatever. 'Engineer' should describe a mindset, I think: the sort of analytical can-do attitude that some people seem to have quite naturally, which makes them look at structure and seek rational solutions. The archetypical engineer, to me, would be the magnificantly named Isombard Kingdom Brunel.
Effective: This, if I remember correctly, describes the fact that something works. An effective solution is one that gives the desired result - it may not be efficient, though, meaning that it works well, quickly or whatever. No, I couldn't be bothered reaching for one of the countless, online dictionaries, because when you are old, you just know you are right, never mind the facts ;-)
So, that out of the way, and assuming that we are talking about real SW engineers and their efficiency - is that really what holds back projects? Looking at other sectors of production in wider sense, like manufacturing or building construction, the role of the engineer is not actually to whip out as many engineering solutions as possible, but to find the relatively small number of good solutions to structural problems, and to communicate this effectively (and not necessarily efficiently) to the workers. I think it is the same situation we have in software production; calling the everyday coding staff 'engineers' is little more than a bluff - a trick to make people feel they are somehow at a higher level than the common factory worker, so they don't notice how they are actually treated in a rather shoddy way.
Don't get me wrong, though, I think being a SW worker is a very worthy profession; I am one myself, and I think it is something to be proud of. I also think it is a load of nonsense to say that it is somehow our fault that SW projects don't go as well as management would like - at the end of the day, this is a management issue. As a coder, developer, or if you must, engineer, you should be able to rely on managers to make sure that things like good communication and documentation practices as well as other best practices are worked into the team. I think this is what the article is saying as well, although from the 30secs of skimming I didn't see him actually pointing the finger at management as such.
... for Twitter and many others so why don't accept the fact that Ruby isn't some magic programming potion which is going to solve all our development issues and bring world peace.
Well, this is /. after all. What did you expect?
Basically, I come here for some good stories and technical insights now and then, but the attitudes and self-serving closed-mindedness is absolute crap.
200 years ago science had figured it all out. Nothing more to learn. Wait...
I seriously doubt that. Creation of large pieces of software is abysmally inefficient in basically all examples I have seen. The only exception are situations where a small team of up to 5 people does it all, akin to Brook's "Surgical Team'. These small teams are routinely much more efficient and effective than teams of 20, 30 or 50 people. It has been known since Brook's seminal "the Mythical Man-Month" that creating software does not scale and the only way to accelerate a project is to use better people, but not to use more of them after a certain, very low limit.
As to scaling up organizations, measuring things is more difficult here, but my impression is that something very similar applies: In a large organization, bureaucracy, meetings, infighting, careerism, etc. kill so much productivity, that it is often surprising they get anything done at all.
I think this person has no clue what he is talking about.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I couldn't agree more. The industry certainly has the arrogance to overlook its abysmal failings, but that is about where its capabilities end.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Indeed. They had to push some new 'better' thing to make even more money. Remember how DOS used to support slightly larger disks every release and the only way to upgrade was to buy the next version at full price? That is what made Microsoft rich.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
your software engineers shouldn't really be coding but getting the design of the application right before it comes to coding.
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
"In a group of 1000, he suggests, 255 engineers... "
Gah, either you are a computer tech or you aren't! It should be 256 out of 1024!
Damn irrational fractions, how are we to use it in our sub 30 employee company?
Since the mid 1970's every single study shows that the ideal work environment for programmers is a private office (even a very small one) where they can shut the door and mute a phone. Interruptions are the enemy of software productivity. Despite all the evidence, Silicon Valley pushes the open office concept. The rationale is that this improves collaboration, but studies have shown this is another myth and that collaboration isn't really improved by these office layouts.
We all know the reason for this is to save money on office space. But the real question to ask is given the talent shortage and the need to improve productivity is this a "penny wise pound foolish" approach.
Did a bit of research. So 2014 revenue was 1.4 billion (which percentage wise, is quite away from 2 billion). As for profit, in Q2 2015, they lost 136.7 million, which was somewhat better than the 144.6 million they lost in Q2 of 2014.
So to the GPs question and contrary to your response, no, they have never made a profit. Though the revenue did grow faster than expected. But revenue != profit.
Those who have never read "The Psychology of Computer Programming (Weinberg, 1971)" are doomed to re-invent small parts of it over and over and over. http://www.geraldmweinberg.com...
Maybe you should make your SOFTWARE actually efficient.
Twitter is a laggy piece of shit on even reasonably older machines using Chrome and FF.
Stop abusing the DOM, the DOM doesn't like it. She abuses you. Can't you even into BDSM? Damn it Twitter!
Also, make the damn UI consistent. Half the time I don't know what to expect when I click somewhere.
Will this click open up in the page?! Will it open a new page, replacing the old page and making me lose my place on INFINITE scrolling pages?
And on that, to hell with infinite scrolling as well. Infinite scrolling is the worst thing to happen to the web. At least make use of URL anchors like Google do in Gmail. URL editing has been in the damn spec since forever!
Screw making your team more efficient, that doesn't matter to the client-end in the slightest!
Make the damn site better if your team is so wonderful! Maybe then I might actually consider actively using it!
Using the calculations most investors use, they earned 7 cents per share in each of 2015-Q1 and 2015-Q2. See:
http://quotes.wsj.com/TWTR/res...
By GAAP they lost a little bit. GAAP treats certain payments to stockholders as "expenses". Most analysts call it "profit" when investors get paid.
engeniering is very much a research thing , can we do this or taht and how , and anyone who's opened the PMBOK and read a few pages will tell you that you cannot schedule research activities for the simple reason that you have no prior experience doing this work unit therefore cannot say how long it will take or how much it will cost
I never thought I'd see the day where I missed cubicles, but that day has come. At least in a cubicle you can't smell if your neighbor has showered or not.
"First they came for the slanderers and i said nothing."
I did a PC refresh project at one Fortune 500 company where the software engineer had 40 half-empty cups of moldy coffee sitting on his desk. I got permission from my boss to skip upgrading that user's PC, my boss escalated the issue with the client company, and the engineer got fired. A hazmat team had to dispose of the cups and sanitize the cube.
"We also know how to scale up organizations, to put in management that lets thousands of people work together. But we don't have a handle on how to scale up that intersection between engineering and human organization. And maybe we don't understand the importance of that. We massively underinvest in this kind of work."
In other words, you know how to hire more managers to manage managers but have yet to find a reason why you hired all these managers in the first place.
Easy:
1. Allow interface developers TALK TO END USERS, not the department head.
2. Except for show stoppers (i.e., we didn't think of that, and that breaks the whole thing!!!),
NO CHANGES TO SPEC allowed for project being delivered. All enhancements pushed to
the next release, which will NOT be the same day, or the day after, the current version is due.
3. Have at least one actual person who is Q/A/Q/C, and knows what regression tests are.
And have a manager that knows how to divide up the work, so that many people are not working on the same files, same method, at the same time - that indicates that you don't know what you're doing, and are doing *vastly* too much in one method.
mark
2/3rd of the company is building the company.
1/3rd of the company is building customer products/solutions.
Wall Street & SV love 3/3rds building products.... cause in the end it's higher profit margins as operating costs goto zero. Then again, that practice is typically not sustainable.
Mythical Man-Month has stuff that is now common knowledge among everybody,
Sure, name one.
My counterpoint: gweihir had it exactly right; we keep making the same mistakes over and over again.
It sounds awfully like a rehash of Fred Brooks' surgical team model.
Well, Surgical Team was a way of organizing a standing team. I was talking about a group of engineers who would roam around the code base working on reducing technical debt; it has nothing to do with how normal project teams are organized.