3 ms·
Some of the many reasons: 1) inertia - that's how it's always done; 2) it's easier to make your good employees work harder than it is to recruit more of those
by cjg 10y ago
Some of the many reasons:
1) inertia - that's how it's always done;
2) it's easier to make your good employees work harder than it is to recruit more of those difficult to recruit developers;
3) they would rather you work more hours than you already do - not fewer - after all they make money hiring you, they can make more money if you work more (in some twisted linear productivity logic);
4) some people wouldn't be interested, they don't want to work shorter hours and earn less money, and that reduces the opportunity for discussing this / rolling it out;
5) understanding how productive developers are is very difficult - did that bug take a week to fix because it was challenging or because you were slacking;
6) larger teams are less productive than smaller teams.
- taneq 10y ago(2) is the big one. It's hard and expensive to find software devs who are actually good (ie. smart, skilled, motivated, effective.) Once you do find them, you take another big financial hit to bring them up to speed, which can easily take 3+ months during which they're not only not productive, but they're taking up your other devs' time too. Once they're up to speed, you have to get as much work out of them as quickly as possible because smart, skilled, motivated, effective software developers don't sit still. Even if your company has enough internal career progression opportunities to keep these people around, your team will still be losing them before too long. Another significant factor is that if you're doing something for more than a certain time per day (varies per person, for me it's 6-7 hours) then it gets permanent head-space and you'll find yourself mulling over algorithms in the shower, pondering your caching policies while you lie awake at night, etc. So if you let your devs only work 5 hours a day, you're not getting their shower thoughts for free.