Twitter's Tips for Making Software Engineers More Efficient | Hacker News Reader

Twitter's Tips for Making Software Engineers More Efficient

spectrum.ieee.org

96 pointsmichakinlabi39 comments

Seems odd to take this advice from a company like Twitter when you compare them to companies like Instagram and WhatsApp. How to keep a lot of engineers busy and burn a lot of money, they could offer lots of good tips there.

Why? Because Twitter as a company hasn't produced effective revenue? Twitter (or their employees personal projects) has brought us Bower, Bootstrap, Typeahead, Flight and many other fantastic open source tools to make devs more productive. I think they are a great company to take advice from in this specific area.

> Why? Because Twitter as a company hasn't produced effective revenue?

Because they're lecturing about engineering efficiency, yet they require 2,000 engineers to support their product. By comparison, WhatsApp scaled to 3X as many active users with a engineering team 1/40th the size. Instagram also runs circles around them in this respect.

For a team so huge and so productive, where is the output? More productivity tools? Maybe Twitter should pivot into that space.

Just the number of active users is a really bad metric in this case. WhatsApps product is much, much simpler than twitters products.

> WhatsApps product is much, much simpler than twitters products.

Can you enumerate Twitter's products?

Perhaps Instagram is a closer comparison -- broadcast photos instead of broadcast 140 characters. And you have a much smaller engineering team, much faster growth, twice as many active users, and far fewer fail whales.

Regardless of the comparisons, 2,000 engineers seems excessive in proportion to Twitter's product, which suggests engineering inefficiency.

Don't forget that Twitter has a comprehensive advertising platform. The partnerships, sales, tooling, and ad auction system themselves are likely just as complicated (or more so) than the basic Twitter product.

Instagram has only recently started to monetize the product -- it's almost unfair to compare the size of the engineering teams supporting the systems.

In addition to advertising and the engineering required around that Twitter has many data product offerings and has recently pivoted to end simple data products to partners (such as selling direct access to the firehose) to more complicated data analysis product offerings (consider the purchase of Gnip last year). Lots of engineering required around building these products.

It still seems bizarre to need two thousand software engineers for something whose functionality is as simple as twitter.

I believe the primary difference can be summarized in two words - data analytics. Twitter has a ton more analytics options for its users than WhatsApp appears to have mostly because, like Google, Twitter is more of an advertising platform than a utility platform as far as its actual business model goes. WhatsApp is potentially b2c as a business while I'd argue Twitter is really b2b. My experience with enterprise businesses makes it hard for me to believe that going b2b is actually efficient as much as it is about revenue assurance and scaling for sales / marketing culture organizations.

The scale and reliability is the challenge. You could probably hack out a client and server on the weekend, but simulate 10 million concurrent users and every single part of your stack will break.

Also, I suspect that their strategic plan is not about minimising the number of engineers. They may want to be able to set up non-public projects which iterate for years or months before becoming visible: frameworks, app ideas, you name it. Their Fabric platform gives them excellent insights into what people are doing on mobile apps, for example. The kind of insights and understanding they have into personal and aggregate app usage is quite frightening when you realise just how much they have instrumented.

Instagram and WhatsApp also benefit from the work of their parent corp, Facebook. I know people who work on Instagram.com and they consider themselves Facebook employees. So I think maybe those companies are not good comps, or at least a poor apples-to-apples comp when doing headcount: product.

That's ... not a ringing endorsement of twitter engineering.

True

However they're much simple products, subject to a lot less load

I think Instagram hasn't achieved the kind of load that Twitter has had a couple of years ago

Whatsapp has a higher bandwidth, however groups seem much simpler to manage (messages stay in small groups)

but isn't instagram effectively the same thing as twitter, with a much smaller team?

How many photos they have per second compared to how many tweets there are per second?

How many API requests happen every second for twitter and instagram?

Instagram has only began support for free format photos now.

So maybe twitter engineering is inflated, but it's a different product beyond the 'stuff in a timeline' description

> However they're much simpler products

Maybe that's the point!

I had the same thought exactly. :)

Twitter != anything related to true software engineering. Twitter == majordomo wrapper.

Nice one, I've never heard it phrased like that.

To me, this is obvious. I find it extremely valuable to spend time making things more efficient and clear. Even if the time spent doesn't save that much time, but makes things less frustrating, it's a big win to me. There's a lot to be said for having processes that are predictable, that don't randomly have issues that require taking time out of your day to resolve before you get to your actual problem. I'd be surprised if there was a significant percentage of companies that don't spend at least some time solving these types of problems. I think the question that this article brings up, is what that ratio should be to actually gain.

Here's the problem with tools and process:

They're a cost center and not a revenue generator.

When you've got a group that provides no measurable revenue they will always be at a disadvantage to the group that provides the money train. This is why you see a systematic de-valuing of tools and iteration improvement despite the massive gains they provide.

Deleted comment

JIRA costs $20k for an organization with 2000 programmers. How much custom development can you fund with that amount? If your programmers earn $100k/y (fully-loaded!), you can't even afford 3 man-months.

I think the point is that JIRA won't do exactly what you need. Using a tool that's "good enough" is the best choice when you've got 5 developers but not when you've got 5000.

Yeah, but when you buy a license, you get access to the full source, which you can adapt to your needs. I think that's a much better option than building a similar tool from scratch.

Good point. It's a good thing that rewriting a commercial tool to adapt it to your needs is so free.

We generate a huge amount of IP at work in a (similar to) engineering effectiveness role. Even the dumbest tools we come up with could be spun off into an ok-ish start-up.

I guess it's a matter of mindset, if you think to make tools which address the issue at hand, you'll end up as a cost center; if you think of products to solve the class of problems the issue belongs to, then you'll be adding value to the company as well as improving effectiveness.

This is why good management is so important.

Tools aren't a money sink, they are a competitive advantage. Effort put into tools isn't a loss, it's an investment.

What if the tools support the money train to generate 100x more money?

Regardless of the coefficient, it comes down to whether or not everyone else in the company realizes that the tools expertise is the secret sauce driving the money train. I think that's what the person you were replying to was getting at.

It is unfortunate, but the reality of our profession is that tools/infrastructure work always has an uphill battle when it comes to justifying engineering time. It's something we all have to fight for when appropriate, and discussing why and how to do that can be super useful.

Working on tools and infrastructure is by definition time spent making things that will help us make things to make money. The people paying us usually would much rather have us spend time making things to make money, rather than making things to make things to make money. If there's not enough trust between the engineer and the nontechnical manager/investor/whatever, it can be hard to get buy-in for time and money spent making something which is essentially an IOU for hypothetical returns later on. Build that trust and have great ideas and hopefully resources can be directed towards indirect (tools/infrastructure/whatever) engineering expenses.

It is always an uphill battle though, I think it's just the nature of the industry, or at least most companies. :( I'm not bitter though, because it really is totally rational if you look at it from the perspective of the stakeholder who would have to approve it. Just part of the professional landscape to be aware of.

Certainly there are people who can calculate the net impact such a group has on revenue or cost of operation?

They may not be revenue generators, but they can be profit generators, by reducing costs.

I didn't realize that that Peter Seibel (author of Practical Common Lisp) worked at Twitter. Neat.

The article is pretty hand wavey, although the point made feels to be along the right lines; I'm left wondering what data supports the claims.

https://www.youtube.com/watch?v=sYsHK81MTHI

Sometimes(read: most of the times) the tech debt and other code issues arise from the last min requirements although as dev. we try make sure the code is robust enough to absorb these changes seldom this happens.

What I have seen is effective for me is to sit down with pen and paper and describe the problem at hand and then think about the solution write up.

Did they pull the scaling out of their hair? I'd like to read about the rationale.

Looking at Whatsapp and Instagram's engineering teams' sizes, could twitter do with less than 100 engineers?

If yes than what justifies having thousands when 50 would do? How does an organization get to that point?

> How does an organization get to that point?

Raise $1B in private capital and another $2.1B in an IPO. Now you have billions to burn and sky-high expectations and no path to profit. Hire lot of people and hope for the best.

But in their defense, Whatsapp and Instagram hadn't demonstrated an viable alternative yet.

I wonder how much of this additional engineering workforce is working on things like Bootstrap, FlockDB, Bower, etc, vs internal tools?

Reply on news.ycombinator.com