4 ms·

Nope I worked with a team of Korean engineers (Samsung) to integrate one of my employer's products (MobiTV) into their first true touch screen phone. This was

Nope I worked with a team of Korean engineers (Samsung) to integrate one of my employer's products (MobiTV) into their first true touch screen phone. This was in 2007 at Sprint's headquarters in Kansas. They all worked very very long hours, will get in around 9-10am and stay until 10pm in the office, with Saturdays being half days. It was cultural to show you working hard, and "sleeping" in your desk was seen as a badge of honor: (so tired form working hard, that I have to sleep on the desk). The code they produced was shit, and full of bugs. For every fix, there was another bug introduced. But whatever, they eventually ended up shipping an "ok" product, but they way they went to it was horribly inefficient. I personally would not recommend. In addition, now that I am working on my own app full time, I have seen that once I start spending a lot of time coding/in front of the computer, my efficiency (amount of work down per hour) goes down. It seems that there is a natural limit on how much 'intelectual' work can be done in a week, and spending more time is counter productive. On the other hand, if the tasks are easy and don't require brainpower (i.e. small UI tweaks, adjustments, etc), spending more time doesn't necessary reduce efficiency. My strategy has been work on the hard tasks first (usually 3-4 hours), then spend the rest of your time on low intensity items.

bonesss 9y ago
> I have seen that once I start spending a lot of time coding/in front of the computer, my efficiency (amount of work down per hour) goes down. In addition to decreasing efficiency at code-production (ie fewer lines being written), the major killer with tired coding is that adrenaline takes over and you get into 'go mode'... suddenly you're punching out widgets and no longer stopping to question your approach. It's doubly bad because that kind of work tends to mate with deadlines to create higher stress and a feeling of having no time to try out alternatives... Head down and plowing though is a good approach to some problems sometimes. But for IT work? There's a good chance that OT work isn't just poor quality and slow, but also contains a lot of unnecessary effort that never needed to be done at all. A good Engineer will solve your problem in 5 days. A great Engineer will spend 4 days figuring out how to solve your problem in 1... A tired Engineer under a deadline will work a 110 hour week cranking out a half-assed bare-minimum solution only to find it replaced in less than 10 hours by someone who was awake enough to consider some alternatives and needed something that worked :/

bonesss 9y ago

> I have seen that once I start spending a lot of time coding/in front of the computer, my efficiency (amount of work down per hour) goes down. In addition to decreasing efficiency at code-production (ie fewer lines being written), the major killer with tired coding is that adrenaline takes over and you get into 'go mode'... suddenly you're punching out widgets and no longer stopping to question your approach. It's doubly bad because that kind of work tends to mate with deadlines to create higher stress and a feeling of having no time to try out alternatives... Head down and plowing though is a good approach to some problems sometimes. But for IT work? There's a good chance that OT work isn't just poor quality and slow, but also contains a lot of unnecessary effort that never needed to be done at all. A good Engineer will solve your problem in 5 days. A great Engineer will spend 4 days figuring out how to solve your problem in 1... A tired Engineer under a deadline will work a 110 hour week cranking out a half-assed bare-minimum solution only to find it replaced in less than 10 hours by someone who was awake enough to consider some alternatives and needed something that worked :/