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.
Amen. Preach it.
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.
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.
That's exactly what I came here to say. It's really that simple. Stick me in an office (preferably with one other, two will do). Keep things quiet, but with a rubber duck available if you really need it, that'll make me 10 times more productive.
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.
gee, that's great. now get your code running on MSP430 and PIC32. Can you have it working by morning?
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!
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.
gee, that's great. now get your code running on MSP430 and PIC32. Can you have it working by morning?
Gee, that's great. An embedded processor with 2-16K of RAM using C. An environment that's the epitomy of Rapid Application Development. Can you have any non-trivial code working by morning on that thing?
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.
An environment that's the epitomy of Rapid Application Development. Can you have any non-trivial code working by morning on that thing?
i made no such assertion, but the parent did
An environment that's the epitomy of Rapid Application Development. Can you have any non-trivial code working by morning on that thing?
i made no such assertion, but the parent did
Uhhhh... I see no such assertion in the parent either. If by that you mean the "having something working by morning" part. No timelines whatsoever stated or implied. If by that you mean C# being a productive language for RAD environments, then yeah, that's arguably a point he's making.
But its a stretch to the point of being obtuse that you would introduce an embedded environment as required platform in a topic that clearly refers to web technologies. I guess the next time someone deploys a server farm to host a continuously evolving web application using only embedded processors, you're the guy for the job.
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.
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 the time spent programming is thinking (if it's not, you're spending too much of your time writing boiler-plate code). If you think it's the language that makes you a 'fast' programmer, then you are not good enough, and I will code circles around you with assembly and a decent macro library.
"First they came for the slanderers and i said nothing."
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.
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.
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 the time spent programming is thinking (if it's not, you're spending too much of your time writing boiler-plate code). If you think it's the language that makes you a 'fast' programmer, then you are not good enough, and I will code circles around you with assembly and a decent macro library.
Of course the language has a part to play. If you don't believe this then simply write a program in C# then write the same program in INTERCAL, MALBOLGE or BRAINF*CK. Who is not good enough now?
The libraries and your knowledge of them are even more important. If you don't believe this then simply write a webservice in C# and then write it in assembly. I doubt there are macros for webservices.
I doubt there are macros for webservices.
You can call functions from assembly, you know.
The biggest thing you lose with assembly is type safety, so you have to be extra careful that your objects are what you think they are.
"First they came for the slanderers and i said nothing."
It sounds awfully like a rehash of Fred Brooks' surgical team model.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Being a wiz at C# under Visual Studio is absolutely useless except for Windows application development. That's a relatively small fraction of all programming activity in the world, yet they act like it's the entire world.
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.
Being a wiz at C# under Visual Studio is absolutely useless except for Windows application development. That's a relatively small fraction of all programming activity in the world, yet they act like it's the entire world.
Windows is certainly the favorite target for C# apps, but it's not absolutely useless for everything else. While it's also not the panacea the GP is suggesting, it does encourage and support sound engineering practices, alongside many other languages in the same category (Java, et al).
As for a language representing a small minority of development, yet having a vocal, myopic developer base, one could argue that for many, many languages. C# most certainly does not have a monopoly on that.
BTW, I've done a number of commercial-grade applications in C#, and like a lot of what is has to offer. I also realize that it's one of many options, and would no more suggest C# on a PIC than I would suggest assembly for a web front-end. Lest I be painted as yet another narrow-minded, no-nothing Microsoft apologist (not that that ever happens on Slashdot).
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.
I'd think that mandatory overwork would be right up there also. Try to get forty hours a week or so out of your developers, let them get away to refresh, and they'll work well. Last week off I took, I left for the vacation with no idea how to do something. Come the first day of work, despite being woozy from dental work, I knew exactly what would work.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
"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.
C# only runs on Windows though, except for Mono which is only used by people anxious to prove that C# is available outside of Windows.
I'm not saying this because of the culture of C# users, but because Microsoft created C# when they were thwarted at their attempts to embrace/extend/extinguish Java. If Mono ever took off and became popular, Microsoft would change C#.
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.
At my previous job, I used C# under Visual Studio for web development (ASP.NET). As much as I loathe Microsoft's business practices, I have to admit C# is pretty nice to program in.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
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.
Try to get forty hours a week or so out of your developers
Not even close. Study after study (IBM's was the most authoritative) has shown that expecting more than 6-6.5 hours/day of productivity is unreasonable. Pushing for more than 8 is the surest path to hell: requiring rework, increased introduction of bugs and lower quality.
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.
My apologies, I was unclear. Forty hours max, with the understanding that they're not going to be actually productive all that time. I tend not to hit 6 hours of serious productivity, but I'm sufficiently productive then that nobody seems to mind.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes