> Shorter hours: "It's 5 o'clock and I wish I had this fixed, but I guess I'll try tomorrow morning." The next morning, refreshed, you solve the problem in 10 minutes.
I have too much experience with this. I remember when I was self-employed I humble-brag tweeted about my production deployment ~15 minutes after starting work. A friend of mine asked why I hadn't just deployed last night and the quote above was my first thought (in addition to the fact that you should never deploy to prod then go to bed). I was done with work, so I stopped. It avoids hitting that "grind it out" phase where you're lucky just not to do more harm than good.
Side note, it's no wonder these big games come riddled with bugs these days. Pushing developers to the extreme during crunch time, just to meet a deadline. There is NO WAY they are doing everything correctly.
Grind out fix.. 90% success rate, average time to solve - 1 hour.
Sleep and fix in the morning.. 100% success rate, average time to solve - 15 minutes.
Clearly better to sleep but if something needs fixed NOW... then it's time to grind I guess...
IME, 90% of emergencies are "such-and-such a manager is going to look a little bad in a spreadsheet next Monday".
That doesn't mean it doesn't need fixing, but we should start being honest with ourselves. Defining P1, P2, etc. is useful.
- Grind for 1 hour and assuming 90% success rate, finish the task 9 out of 10 times
- Finish another task in 15 min with, again based on your assumption, a success rate of 100%
In start-ups there is usually a near endless list of tasks to solve so this would be the most productive approach. Again, based on a lot of assumptions.
Basically, you just advocated for crunch time and death marches. Things that are known to not work.
But tl;dr your brain is adept at working on problems in the background after you've defocused on them. Your work is still getting done, even if you cut out of work and unwind, no guilt necessary ;-)
Tech Video: Rich Hickey: Hammock-Driven Development:
- you are working at least 9-3 (or pretending it)
- you are talking to your colleague in the kitchen (in manager terminology: knowledge sharing, my favorite one)
- you are present at unproductive meetings
- you are hitting you keyboard
- you have opened excel sheet, sharepoint, and other required tools major of working time.
I spent almost 6 years in corporate open office plans. Last year was working from home. Now, I am not able to go back to the standard 8 hours open office.
Short bursts are ok, but everyone needs time to recharge.
I also am a firm believer in the power of falling asleep while thinking about a problem, and waking up with a fresh approach on how to solve the problem. Thomas Edison was famous for taking naps with a steel bearing on a plate. Salvador Dali had a similar technique he called "slumber with a key"
To further assure that he would not lapse into sleep, he would hold a steel ball bearing in each hand. On the floor, placed directly below his closed hand would be a metal saucer. If he should fall completely asleep, his hands would relax and each ball bearing would fall to the floor, striking the metal saucer, making a noise loud enough to wake Edison.
Full paper PDF: https://psychology.stanford.edu/sites/all/files/Implicit%20T...
What is the direction of causation?
We champion Newton for his work in gravity, optics, and mechanics.
Not so much in alchemy.
If the field you're plowing isn't fertile, no amount of good agronomy will help you.
Yahoo may not have been abolutely intractable, but it was in a bad position and getting worse. I had no interest in working for the company or using its products, and I'm no particular fan of Meyers (I think she's accomplished a few useful things, may be felt by her absence at Google, and has also done and said some tremendously stupid things as well). But hanging Yahoo on her neck alone is false narrative.
If you don't have that "talent" for long work hours it's probably counterproductive to force yourself into something you just can't do.
A recent example: I couldn't find the right combination of extensions and adapters to get a certain bolt off the transmission bellhousing from below the car, and I couldn't even touch the bolt from above. I spent half a day just getting a socket on there, then couldn't get my wrench to turn it. A couple days later I tackled it again and immediately realized I could remove the lower intake manifold (since I was replacing that part anyway) and get to it from the top. Twenty minutes later that bolt was out. My tired brain couldn't think that far ahead but when I was refreshed it was the first thing I thought of.
This is something many academics learn quickly, as it is important in order to solve deep problems, especially with the workload that is levied on academics.
Myself, I've had many instances where this has happened, including with open source work.
Usually it makes sense to pick a task and finish it before going home. If you stop just because its 5pm, you waste time re-orienting yourself the next day. Worse, you can get into the clock-watching habit.
BUT, if at 4.55 pm, you realise there was some nasty wrinkle in the task and you need to rethink it or go back and do a big prepartory refactor, then you should go home and look at it with fresh eyes in the morning.
Ha ha. Yeah, that never quite works out does it?
I'm fairly sure this insight generalizes outside of programming as well. It's absolutely true for blues dancing, where not being relaxed enough hurts your dancing and having a couple drinks is performance-enhancing.
"It's 16:11, so:
16:11 – 17:00 trying to fix that bug
17:00 short pause
17:05 – 17:45 implement easy feature XY so that I feel
I accomplished something
17:45 – 18:00 wrapping up.
Edit: just noticed similar comment below. Seems common.