[creyer]

Nice article, but I can't agree with everything inside.

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.

[creshal]

> 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.

I'd say giving your engineers 10 minutes more free time at the end of the day will give long-term returns too. Engineers are not computers, they need time to unwind after work like everyone else.

[pc86]

You're missing the point entirely.

[AnimalMuppet]

creshal has a different point. That does not mean that he/she missed the other point.

[Retric]

Saving 5 minutes of BS a day can increase passion which might be worth far more than a 5%.

[icoder]

Yet saving 5 minutes of FS (F for Fun) can decrease passion, causing a net negative effect.

In other words, maybe you're both right and it's not about saving time per-se, but about cutting BS.

[panic]

As organizations grow, it can also become harder to maintain the passion you mention. This is a huge factor that people usually don't account for in their models.

[zaphar]

    after the initial boost of productivity, the effect will 
    no longer be noticeable

But the purpose of the team isn't just to get the initial boost but also to prevent a continual loss of productivity as the tooling inevitably bitrots. When you hit a certain size that bitrot happens much faster than you might think. It makes sense to keep an EE team on just to do maintenance. And support future changes to workflow. New languages and frameworks. Large scale refactorings happen more and more frequently as you hit walls that weren't there a month ago.

[jules]

Argument #1 does not really make sense, since by repeatedly applying the same logic it implies that engineers will work an infinite number of minutes each day. A variant of this argument that I've often heard is this:

"My decision to take the plane does not negatively impact the environment, since the plane would fly with or without me in it."

[creyer]

The point I was trying to make is that for engineers you can't do a simple math from minutes to productivity. The interruptions are big productivity killers, but all engineers take voluntary breaks. A break helps productivity, but there is a limit, above that it harms. The same with the interruptions, some might help, too many will not.

[zaphar]

A break the engineer chooses is chosen and is unlikely to interrupt flow. An interruption caused by the tooling is not chosen and is more likely to interrupt flow.

Tooling cruft also increases the startup cost of some tasks. Where the amount of pain you will experience trying to do it may inhibit your desire to dig in.

The author was generalizing he wasn't assuming perfect accuracy. But in an engineering organization the size of Twitter the productivity gains of a dedicated tooling team add up fast. Much faster than you might think.

[Lawtonfogle]

I could see people seriously agreeing with the plane argument.

I think to spin it even worse, replace it with some sort of group crime. I joined the riot, because there would be a riot with or without me. I join the drive by shooting, because there would be a drive by shooting with or without me.

I think that would have less people agreeing with it than the plane argument.

[littlewing]

> I think the EE team make sense to be created "on demand" and not as a permanent solution

For the size and intensity of effort going on at Twitter, I respectfully disagree.

Once the team gets large enough, NMP ("Not My Problem" mindset) comes into play, and unless you have the culture from the beginning to always be making the development process better, and acquisitions and new management has never changed that, which is highly unlikely, then having a dedicated person or team to help make other developers jobs easier is a great idea- after the team gets to a certain size. What that size is depends on what is being done, though.

[jlarocco]

> 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.

Right...

First, IME engineers aren't any more passionate about their jobs than anybody else. Even for people who are passionate, the majority of their day is unlikely to be 100% dedicated to the things they're passionate about. Nobody I've ever met is passionate about digging through their inbox in the morning, or going to scrum meetings, or doing sprint planning, etc.

Second, engineers are also the ones who get most upset and demotivated by the pointless waste of time. If you can speed up my compile by 5 minutes, then do it. If you can speed it up by 5 seconds, then do it. There's nothing the engineers I know hate more than wasting time on tasks that could be automated or made to run faster.

[SZJX]

I think the team could very well exist permanently. It's just that their aim would then not be to unify tools, but to ensure code quality and work efficiency of various teams, as the author already stated in the article. Quality assurance and checking can be beneficial all along the way, as long as it's not overdone.

[gull]

Saving 5 minutes a day every day for a year will increase productivity more than 1%.

[mesozoic]

Oh I look forward to your paper detailing the studies and data that led to these completely objective conclusions.