3 ms·
For all of you crapping on Peter and his team: What if the employees were founders with equal shares of the company, and they launched a product and it fell ov
by ispivey 14y ago
For all of you crapping on Peter and his team:
What if the employees were founders with equal shares of the company, and they launched a product and it fell over? Would you blame them for pulling an all-nighter to scale it up in the face of unexpected traffic? Should they give up at 10pm? Midnight? 5AM?
If they're not equal partners, should they immediately give up? What if they own 10%? 1%?
What if they don't have much on their resumes and are excited to make this a successful project, instead of a laughingstock that fell over in the face of scaling challenges? What if they care about each other and want to make this a success for their friends and coworkers?
What's the function into which you plug all these variables and decide when to go home?
It's not black-and-white, pun intended, and if you think it is you're being obtuse. I hope they feel happy and like they accomplished a lot in the face of long odds, and you should too.
- Deestan 14y agoI'd rather have a colleague come in to work drunk than pull an all-nighter to work on core functionality. Yes, we really need to get this thing improved as soon as possible, but having effectively brain-damaged people introduce bugs all night and then be utterly useless the next day is not helping. Take your financial lumps and get over it instead of burning out everyone and ruining the codebase. These kind of masochistic hero stories perpetuate the destructive belief that every hour your face is planted in front of the monitor is equally productive.
- vidarh 14y agoIf someone I worked with tried pulling a 36 hour shift I'd physically throw them out of the building. In my mind, odds are 90%+ that'd they'd do more damage (more bugs, slowing down other people) than they'd do good in aggregate over that 36 window, and odds that they'd be more productive in a single 36 hour bout than doing shifts with proper sleep windows is pretty much 0. More than 14 hours or so in a single stretch is highly unlikely to be beneficial to the company/project, with rest in the middle. More than just being in line with research, this is in line with what I've seen over and over again in real projects, where best project during crunch time is generally had by ensuring people leave and rest. Sure, do longer hours for a short period. Sure, ask people to cut down on time off or alternate work/sleep shifts. But the moment your developers hits 18-20 hours, I could talk most of them into making horrifically bad decisions and have them think they were logically sound - your ability to reason goes out the window pretty quickly. I don't want people in that kind of state anywhere near projects I work on, because I've seen what they can, and will, do in the belief they're helping out. > What if they don't have much on their resumes and are excited to make this a successful project, instead of a laughingstock that fell over in the face of scaling challenges? What if they care about each other and want to make this a success for their friends and coworkers? Then learning to understand that there's nothing smart about pulling stunts like this unless you're doing menial work that you can still do reasonably reliably with next to no concentration or short term memory is even more important. > I hope they feel happy and like they accomplished a lot in the face of long odds, and you should too. No, I shouldn't, because if they feel that way they've learned the wrong lesson. They'd also most likely be wrong in terms of their relative productivity with more rest. Unless they were all on illegal stimulants, or his staff consists of mutants, it is simply not worth spending much time even considering the option that this might somehow have been the best way for them to spend their time.