5 ms·
Oh my god yes. Actually we should work 6 days a week, imagine how fast the new Iphone would come out!!
by dasanman 8y ago
Oh my god yes. Actually we should work 6 days a week, imagine how fast the new Iphone would come out!!
- de_watcher 8y agoIs it a good thing?
- mberger 8y agoI'm pretty sure parent posts are sarcastic.
- adrianN 8y agoHave you considered what would happen if we added meth to the drinking water? People wouldn't sleep and could work twice as long!
- the_clarence 8y agoI thought we had already five that by making coffee mainstream?
- trinitry3 8y agoDid we just seriously compare coffee to meth?
- ashelmire 8y agoDo you want reavers? Because that's how you get reavers.
- prolikewh0a 8y agoI wouldn't doubt this idea has come up at least once in some shareholder meeting.
- lolive 8y agoDidn't they use meth during WW2 on the russian front?
- jrockway 8y agoIt does. I think apenwarr has a good outlook on this: "maybe we can just have the engineers work weekends or something? Well, I think most of us know that's a losing battle. First of all, even if we could get engineers to work, say, on Saturdays without any other losses (eg. burnout), that would only be a 20% improvement. 20%? Give me a break. If I said I was going to do a talk about how to improve your team's efficiency by 20%, you wouldn't even come. You can produce 20% more by hiring one more person for your 5-person team, and nobody even has to work overtime. Forget it. https://apenwarr.ca/log/?m=201712 https://apenwarr.ca/log/?m=201712
- adrianN 8y agoIf only hiring 20% more people would mean 20% more efficiency we would have a lot fewer problems.
- jrockway 8y agoSure, but there are a lot of efficiency killers to look for before you need to worry about individual hours worked. Adding 20% more people doesn't make the software come out 20% faster because: 1) Multiple people need to work on the same critical section of the code, and then there are merge conflicts. (Or people disagree on the design, or refactoring becomes a higher priority than doing what users want, etc.) 2) People work sloppily and omit relevant tests, only for someone else to have to re-discover the bug, fix it, and write the tests (trading productivity from one person to another). 3) People work on the wrong tasks, adding 20% more technical debt but not fixing 20% of the highest-priority bugs. 4) People take 20% less responsibility so you end up with "someone else will handle that (where "that" is usually documentation, monitoring, deployment, or anything else not explicitly captured in your list of bugs/priorities). It is very interesting to me how internal software development often fails (I'm sure I've been the point of failure before), but software development CAN scale. I use AWS, for example, and I'm sure their software engineering teams are messing with products/features that my team uses. But they don't make me 20% slower. Ultimately, overly-tight coupling gets you every time. But on the other hand, too much isolation can also be a problem (time spent overengineering). If you find that balance, you can scale your team infinitely ;)
- goliatone 8y agonot the greatest source but still informative https://www.sciencedaily.com/releases/2015/02/150220083916.htm https://www.sciencedaily.com/releases/2015/02/150220083916.h...