Because as browsers became more and more interactive, and computers became more and more interruptive, I found that I started subconsciously confusing the entertainment value of computers with the work value of computers.
Simple solution (for me, anyways): 2 computers at 2 different workstations. One for work, not connected to the internet and the other for the internet only. I used to have them in 2 different rooms, but I have found that that's not necessary. The difference between alt-tab and getting up off my butt is just enough to make this work.
I wasn't clear in my original comment: it's not that I require API docs (though they're nice), it's that I require the API itself, usually a REST web service, or in the case of mapping, a bunch of remote resources (images and JavaScript).
When you say you "download/clone", are you talking about just the docs, or do you actually clone the API locally?
For example, create a local, mock Twitter OAuth API so that you can program against the Twitter API without being online.
I'm genuinely curious. I like the idea of going offline, but it seems like it's not worth the effort if you're working on applications that are codependent on network APIs.
I run into this problem and my solution has been to block distracting sites. This gets me 90% of the value of being offline without taking required APIs offline.
I noticed that whenever I have documentation at the reach of my fingertips (Intellisense, awesome API docs), I'm not going through the effort of really reading the documentation and many times I start cargo-culting.
For instance ... if you need to read the Amazon AWS's docs, maybe you're better off searching for and using something like Boto. If the Boto API is too complex to memorize, maybe you're better off constructing a Facade around it that you can remember without going for the documentation every time you want to open an S3 bucket.
Just saying ... lack of easily accessible documentation leads people to do strange things :-)
He's not talking about documentation. He's talking about making API calls to online services. To test that sort of stuff, you have to be online, and generally you want to test that stuff pretty often as you're building things.
I just did a PayPal API, and the docs were pretty bad/inaccurate, so we had to make frequent test calls to see what the real world behavior actually was.
It gets worse. There are several situations where the docs say one thing, the sandbox behaves a different way, and the live API behaves in a third, different way. It's a mess.
Sure, or use SelfControl (for the Mac) or its equivalent, and turn off all the distracting sites for N hours at a time. Very helpful when your will is feeling weak.
How was the author's productivity doubled? Where is the proof? How long has this been evaluated? Was it more than one day and a few strolls?
It's already known that the brain is a "muscle" and thus needs rest to function properly. What I'd like to see from the author is more about why hourly rests might more positively benefit the brain than some other interval, and why.
I find myself having to wait for the compiler or for the debugger to get to the correct breakpoint, and think that I'll check HN for a moment. 5 minutes later I realize the compiler is long done...
Yes! Imagine the productivity gains if compiler and upload times were reduced to zero. Sure it only took 30 seconds to upload all those files, but it took me 3 minutes to read this thread! :)
Shit, this article reminded me to get back to work!
This guy is on the right track. I'm doing something similar. I only work in 60 minute or 3 hour blocks of time. And during that time the email & phone is off - and the FOCUS is on ONE thing. One client. One project. Or one single objective.
It makes structuring your work week more efficient; as it allows you to schedule in advance the areas in your business life that require focus the most.
I've been using the Pomodoro Technique for a while and it has been helpful. Primarily I use it for trying to stay more focused and overcoming procrastination to get to the level of work I think I should be doing, not really to excel at this point. Being able to look over and see you have 10 min until the next break 1) allows you to work until the next break because there is end in site and 2) makes you work harder to try to complete a task in a work period.
It reminds me of a quote by Royce Gracie on the topic of time limits in mixed martial arts fights... "if I [was to] drop you in the middle of the ocean and you look around and there is only water, most of the people - 99 percent - would drown on the first night. If I drop you in the ocean and fly away but tell you I'm coming back the next day to pick you up, you don't have to go anywhere, just float around the entire day. I'll come back and pick you up and you'll be there waiting for me. That's what the fighters are doing now. They know there is a time limit"
I have been experimenting with using the 30/30 technique posted earlier this week,and I have found to provides an interesting dynamic of carrot/stick. After having rested/played for 30 minutes, I feel guilty about not working so it helps to overcome procrastination. While working, I know I will have a break shortly, plus I want to make use of the time I have.
I have issues with procrastinating and staying focused on work, so I will often wait until the last minute to get something done, and use the pressure of the deadline to help motivate me and keep me working. This seems to help break that cycle.
Interesting take on the problem of productivity. I've also noticed that when I do design work, design work after design work my design just gets ugly. To solve the problem I do the following:
1. Don't design/code for 2 days.
2. After 3 days, find some article that will get you pumped. Read it.
3. Design/code for 1 hour less than you usually would(for instance I usually code/design for 5-6hours a day, I'd do it for 4-5hours MAX here), take a 10 minute break and then continue. You'll get amazing results. I think this is partly because (like the author of this article said) your brain continues working on the problem.
To code quickly you should just code quickly. To code difficult stuff lying on the sofa or talking a walk is an excellent way to "meditate" on a solution. If you think through a problem that way the ensuing coding will be quicker and better and save you some trial and error.
It's too bad that most workplaces arent conducive to that kind of workprocess (try lying in a sofa at work and not be called a slacker :)
Kinda reflects my experience. Get stuck on some problem at work, then leave to home, after 10mins of walking in fresh air, and some kind of new idea springs surely in mind.
I've had the experience of getting completely stuck on a coding problem, wrecking my brain for 3 long work days.
When did I see the solution?
At the end of day 3 when I was cycling home, right at the moment I was crossing a very busy and dangerous road.
It's amazing how the mind works and you'll always remember that moment. This particular moment was 10 years ago.
Anyone else waking up at 3-4 AM and knowing exactly what 1 to change into a 0 or the other way around in 50K lines of code and suddenly getting things to work in the desired way? :D
Our brains are coding, compiling and testing in the background all the time. ;)
Great advice. I run 5 miles at lunch and it clears your head, heart, and really makes you to tired to be frustrated or in the mood to fight with anyone or any code.
Don't assume you're doing anything wrong. Just because this technique works for some people doesn't mean it works for you. Depending on the task, I work best with two or three hour chunks of time where I have a lot of time to ramp up, get immersed, then stay there for awhile (although this still requires removing the external distractions). Depending on what you're working on, 50 minutes isn't enough time to ramp up if you're working on a complicated problem and you have to fit the model back into your head.
This is going to be different for everyone, so these examples should only be taken as different ways to approach your work until you find what works. No single approach will work for everyone. I would go nuts if I had to stop every 50 minutes, personally.
If I'm doing cardio and "in the zone" and feel amazing when my time is up, I don't stop. I take the same approach with programming.
Good post. I haven't set timers, but I've been trying to be aware of when I start to hit my limit. I did about 11 hours of work today - a whole ton of stuff - and then I started flagging towards the end of the day, but I had some more stuff I need to do. So I had a coffee, went for a 20 minute pretty intense swim, and I came back and was ready to go. Did more good stuff.
This has been good for me - the challenge is just self awareness of when things are slowing down and then I'll do something like pack up and go to a cafe, go exercise, come back from the cafe, etc.
I've gotten big gains out of shifting gears once slowdown hits, but maybe proactively scheduling a shift would work better - I'll give it a try.
Simple solution (for me, anyways): 2 computers at 2 different workstations. One for work, not connected to the internet and the other for the internet only. I used to have them in 2 different rooms, but I have found that that's not necessary. The difference between alt-tab and getting up off my butt is just enough to make this work.