Comment by rayiner | Hacker News Reader

Comment by rayiner | Hacker News Reader

Parent Full thread

Of course deals would get done if bankers couldn't work at night, but they'd take longer. To put it in programming terms, it's about latency not bandwidth. In many cases, reducing latency will make tasks complete faster even if it comes at the cost of bandwidth.

Deals involve a tremendous amount of back-and-forth, changing deal terms, changing financing details, etc. Bankers could simply go home at 6 pm and get to requests the next day, but that would make deals take longer. While a deal is in progress, it's fragile. Parties can decide to back out, prices can go up, third parties can swoop in. That's the sort of thing that causes shareholders to get pissed, lawsuits to get filed, etc, and is generally to be avoided. Also there are the usual deadlines of corporate life: we want to get this off the books this quarter, we want to get the merger done this fiscal year, etc. All that results in C-suite execs picking bankers who will turn things around as quickly as possible.

So why not have team members work shifts? Get 24 hour coverage in the office without having frazzled people making poor decisions. Besides, the people making the decisions aren't these banking interns nor the junior associates. The more junior guys and gals are, from what I understand, mostly just doing grunt work.

Why don't programmers work in shifts? You work on a module for eight hours then someone steps in at 6 and picks up where you left off?

Juniors don't make decisions, they do analysis to support the decision makers. If a decision maker proposes something in the afternoon, he wants the analysis by morning to make the decision.

Programmers do work in shifts. They are not crazy like bankers...

> Why don't programmers work in shifts? You work on a module for eight hours then someone steps in at 6 and picks up where you left off?

Good point. That's a good way to put it. Depending on task, unfortunately not everything is parallelizable.

But quite often, culture is the problem as well. If performance bonuses are large enough, people will compete with each other and will be at each other's throats over control of projects. Machismo and cowboy-like behavior is to be expected in some environments. I personally think those environments are toxic.

Anyway I see the a point about some tasks not being easily de-composible, but I think culture plays a significant role here as well.

> Why don't programmers work in shifts? You work on a module for eight hours then someone steps in at 6 and picks up where you left off?

We sorta do in some cases. If you've ever worked closely with an outsourced team (in my case, India) handling support cases, this ends up being almost exactly like working in shifts. We make sure to commit our code and update the bug/client ticket before leaving. Then someone on the India team can pick up the work from where we left off.

Of course, this was only used specifically for high priority cases that came directly via a client rather than a normal bug fix or feature request. But I think this reflects exactly how and when shifts should be used. Work that can wait until tomorrow doesn't need to be handed off to someone. Work that is urgent can be handled in shifts.

>but they'd take longer.

They would take less time because people involved would be getting adequate amounts of sleep and as a result would be able to function normally.

People who insist that other people work absurdly late hours are demonstrably not interested in efficiency or thoroughness and are actually interested in making themselves feel powerful and important by forcing other people to adhere to irrational standards.

Reply on news.ycombinator.com