To code quickly, you must quit coding | Hacker News Reader

To code quickly, you must quit coding

whattofix.com

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.

Otherwise, most of this is pure speculation!

I have this problem: http://xkcd.com/303/

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.

4. Go to step 1.

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.

What kind of work do you do that allows you to code without an Internet connection?

These days, I can't go more than 10 lines of code without having to call some API* that requires me to be online.

* Examples from just yesterday: Amazon, Twitter, Facebook, PayPal, GData Contacts, GData Maps, Bing Maps, YouTube.

Sometimes I download/clone all I need, then go offline. I'm always amazed by how good it feels to go offline!

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 wrote this to help: https://github.com/bradjasper/focus

I was talking about the documentation - but for APIs, I create mocks.

For instance my work last week relies on an API that requires a VPN connection AND a windows machine.

I tested and mocked the API on windows, and now work offline, without the VPN nor Windows.

Download the documentation using `wget`.

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.

RE: PayPal.

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.

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 saying he actually needs to make the API calls, not that he needs to look up the API docs.

If you're building a Facebook app, for example, you need to have Facebook available at all times or it just won't work.

Surprisingly, there are still applications being written which do not require an internet connection at all times.

1. Download docs.

2. Code for a day offline with the docs.

3. Test your code (online).

4. Submit a ton of bug reports for the docs.

5. Yay, improved documentation!

6. Don't receive any monetary compensation for this.

7. Get outstripped by competitors.

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.

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 :)

I don't want to code quickly, I want to code effectively.

Other than that, we already knew that the subconcious mind needs time to process problems..Now excuse me, I'm gonna go get some fun done.

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.

Why would you buy a physical stop-watch if there are any number of stopwatch web applications and desktop utils?

timer-applet for gnome seems more appropriate.

I wish I were that disciplined... but I have weak will power and basically will keep coding for hours (once started...).

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.

I used to do that at work with a software timer. Sprints of 20 to 40. The thing is, you still need to pace yourself.

It inspire me an app :

- I'll give it the task I'm going to do

- 1H after I start the task, it asks again

Now I can work in 1H period and it fills my hourly log...

do you mean that's a bad idea ? why ?

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.

Reply on news.ycombinator.com