views:

442

answers:

11

As a student, my available time slots for programming range from all night sessions to all weekend events for personal projects, homework, etc. Generally for my coding session to be successful, I'll need at least a block of a few hours. I've found that programming for extended sessions lasting longer than 8 hours can be fairly draining. However, It's hard to close shop for a night when I'm on a roll. Often times I'll continue thinking of ideas post session which are begging for me to code.

What advice do you have for:

  • Keeping marathon programming sessions productive?
  • How long is too long?
  • Tracking your programming ideas away from the keyboard
  • Any other advice relating to marathon programming
A: 

Take breaks/naps. Don't pull all nighters, pull almost-all-nighters. Even 2 hours of sleep will do wonders for you. Occasionally get up and take a walk around, go get some fresh air. Then get back in the game with a fresh perspective. I'd say take a break at least every few hours.

Doug T.
+8  A: 

Keeping marathon programming sessions productive?

Eat occasionally. Notice when your brain it puttering out and take a short break, nap, walk, whatever that clears things out. I have become aware of when my 'problem scope' has shrunk to the point that I become confused & ineffective. Know your limits...anything beyond that is hubris and a waste.

Keep a pillow and blanket in your office space, and nap on the floor. Your bed is not your friend.

How long is too long?

Highly individual. Take note of past performance, work from there.

Tracking your programming ideas away from the keyboard

I like to write on big flip charts and boards, even in the crudest form. Baring that, a paper notebook.

Any other advice relating to marathon programming

People and talking and other interruptions will cost you valuable time. "The Flow" as a wise man (DeMarco?) once called it, can be destroyed with just a minute or two of distraction.

Stu Thompson
Mr Flow is Mihály Csíkszentmihályi (now try to pronounce that!). http://en.wikipedia.org/wiki/Flow_%28psychology%29 DeMarco and Lister e.g. in Peopleware referenced to it as well
laalto
+2  A: 

Java (the liquid one)

Roalt
+2  A: 

Here's what I try to do:

  1. Makes notes on your plans for your programming time. I use a text file, but paper works well too. Use these to budget your time and plan your day so that you're effective.
  2. Restrict your time at the computer a little bit, so that you have motivation to spend your time wisely.
  3. Don't let yourself stay up all night unless you absolutely have to. Even if you get a lot done that night, it can ruin your productivity for a few days afterwards because you're tired. You'll also wake up excited to get back to work if you don't wear yourself out.

I'm usually not happy if I make myself stay up all night, because I need my sleep. There are other ways of trying to remain productive other than staying up all the time, and if you ever want to have a life outside of programming time-management is important.

James Thompson
+2  A: 

Try to set yourself frequent, small objectives. They give you something to focus on right now and the satisfactions of hitting measurable milestones will keep driving you on. They also provide you with good checkpoints to review your progress and test your code. Nothing's worse than coding for sixteen hours straight and finding that nothing works at the end of it!

Midpoint
+5  A: 

In a way, staying with running analogies, these marathons are not really marathons but sprints. You can sprint for a while but if you sprint for too long, you'll get exhausted and cannot run at all.

Some points of advice:

  • Remove all sources of interruptions. Close your phone. Close all programs not related to your project. Close all reminders for e.g. new email. Close your door.

  • Don't force it. If you get stuck on a problem, it probably means you should sleep on it. However, do get all the problem inputs into your brain and then let the subconscious brain to do its magic when you're doing something completely else.

  • Splitting the work to ~30 minute mini-sprints (using the agile term here) like Pomodoro may help you further get away with the interruptions.

  • When not programming, take care of your physical health. Exercise. Eat well. Sleep well. Get laid.

  • Coffee/caffeine works for some but not everyone. For example, for me it just keeps the sleep away. I can think longer but not any better. Most parts of programming require high quality thinking.

laalto
I really like this analogy!
Jason Rikard
+2  A: 

Make sure you know what you are programming. By that I mean have a design! If you are coding on the fly you will get yourself into situations where you spend a long, long time on problems or situations you did not anticipate. As has been said, there is nothing worse than spending hours coding to find you haven't really got anywhere.

When I am coding I like to get out trusted pen and paper and work out what I need to achieve and how I think [at the time] it should be done. It is at this stage you will - hopefully - spot other tasks you may need to do.

A real life example of mine when I didn't plan ahead was when a particular method required random numbers to deal with some data. I needed each random number to be unique and half way through coding I realised that the classes/methods provided by the language didn't have the option to provide unique random numbers... so I got distracted into writing my own class which did just this. Then once I had done that I had to test etc. A few hours later I came to realise I had gone about the original method all wrong and no longer needed my shiny new class. Bugger.

If I had planned ahead I may have spotted that I was going about things the wrong way before I even typed a line of code, at the very least I could have predicted the need for a custom class and planned accordingly.

Peter Spain
A: 

I remember in my uni student days I used to break up the long programming sessions with a game of Counter-Strike! Nothing like shooting a few mates online after a bit of C++ at 3 in the morning :)

Chalkey
+1  A: 

In the history of computer programming there is the legend of the "marathon session." One famous example is Bill Gates writing Basic for the Altair in a hotel room in Tuscon. There is a counter-narrative though and it's worth considering. The idea, associated with the 37 Signals company is that marathon sessions are neither productive nor healthy. Over time you will be more productive and write better software if you work a normal workday or even less. The idea is to be alert and well-rested, and you will make fewer mistakes, waste less time going down false paths. Focus on wringing every bit of actual working and tested code out of each six to eight hour period, then go see a movie, spend time with family, pursue other interests.

On the other hand, there are times in life when you just have no choice. Sometimes the deadline is in two days. Sometimes you're a student. In that case, take plenty of short breaks, stay hydrated, don't drink coffee past the point of diminishing returns, and go for a short, brisk walk every few hours or so. Good luck!

Ethan
A: 

Sleep well, eat well and get fresh air taking breaks regularily.

That allows you to keep the highest pace.

Thorbjørn Ravn Andersen
+2  A: 

you can apply Pomodoro pretty well in crush coding sessions.

fuzzy lollipop