How Long do You Code Per Coding Session?

I was working on getting the latest DataStax Enterprise 6 up and running via the Docker Image offerings today and I stumbled across a site called hashnode.com. On that site was a harmless little question but something I realized I ponder a lot, and even find myself in conversation about on a regular basis. The question (link) is posed,

“How many minutes/hours do you really sit to write code at a particular moment?

I’m not saying the total summation of hours you code a day. When you really sit down to write a code for a particular task at a moment, how many minutes/hours (at worst case) do you normally sit down before you get tired? I know some take break, some say it depends on the task or the individual, I would love to hear them all, and what you do to keep your brain refreshed before getting back to coding. Thanks…”

This question, in normal coder fashion, has one simple answer the belies the actual complexity of the individual complex answers, “it depends“. So that’s the first answer, but here are some of the other answers for me. As with many of these types of questions and answers, many individual characteristics come into play for each of us, so this is indeed anecdotal scenarios for myself and very specifically YMMV for yourself!

Answer 1 – Ideal Long Coding Session

When I really need to get something done, I try to break a problem apart where the largest segment of time I’ll need to sit and work on a piece of code is about 4 hours. Not that I’ll only be there working on the code for 4 hours, it could be longer, or much shorter, but that’s about the longest segment of time I’ve found that works most effectively. If I go much longer than 4 hours several negatives hit me:

  • My mind starts to wander significantly and I start to lose track of what I’m writing, thus – not efficient use of the time.
  • The lethargy of sitting, or standing, or sitting and then standing and then sitting and then standing, as I do with the sit stand desk that I have, gets to a point that I just need to go for a walk. Better yet, it’s a good time to go for a bike ride and just crank hard. That gets my blood flowing and then I can dive right back into another coding session in another ~20-45 minutes.
  • I realize at about 4 hours that I’ve mismanaged the chunk of work. If I’m still working on it this long after the matter, I start to worry as much about the mistake, or the lack of understanding the problem enough to break it apart, that I really start to lose focus on and must shift back to the larger problem to see how it really should be broken apart.

Answer 425 – Ideal City Bus Coding Sessions

Sometimes I’m in the situation I’m about to jump aboard a bus for the commute, or to travel somewhere within the city. I absolutely abhor wasting time “driving” or even “ubering” to the next location when I can instead board a bus in 5-10 minutes and actually code in between my starting location and my destination! In this situation I routinely whip out the laptop and sling some code. I try to keep a lot of little busy tasks that can be completed in 5-10 minute chunks specifically for this scenario. Something that may require Internet access that would be acceptable at questionable tethering speeds and connectivity.

Answer 6 – At The Office

Offices with lots of mixed groups of functional teams and such usually just abhorrently suck for actually getting good, effective, high quality, and SOLID code written. The interruptions are many, the distractions are everywhere, it’s just super rough. But alas, we coders often exist in these damnable office environments where some boss person thinks it’s more important for a warm body to be in a chair pretending to code than to actually productively get things done and be smart. In those situations I like to find ways to break away to conferences rooms, toss on the headphones, or maybe even find a good partner to pair program with. These scenarios I routinely have been able to luck out and get a solid 30-120 minutes coding sessions in. These scenarios aren’t ideal, but they’re absolutely necessary if one actually wants to get something done!

Answer 2 – Ideal Long Session on a Hard Problem

In answer 1, I described the scenario if I have some idea of the problem and can break it apart. But what happens when I need to code a little and then review the problem and then test and review and then code and review and so on? Well those coding sessions, are technically dozens and gazillions of shorter coding sessions, but, overall this type of overall session could be many hours. It’s ideal to get into the proverbial “zone” and then just hack at it for hours while everything is in one’s mind. This can be lots of fun, but progress on the problem has to be kept in mind too. In these scenarios the individual coding sessions are problem 5-75 minutes long at the most, but the overall session might be 4, 5, 8, or even longer hours of just sitting and coding. One needs to make sure to have appropriate drinks, food, and other survival gear ready for this type of coding session as it can be hard on the body!

Answer 42 – Answer to It All

You’re done, you’ve found the answer, it’s 42. So moving along.

Answer 9 – Sometimes Fear is the Appropriate Response

9

Best to just go watch the movie.

Answer 5 – Those Paired Programming Sessions

Ideally another programming technique I like to use is pair programming. Pair programming with someone else forces one to break down the work pretty effectively and then divide it into chunks that often can be built in 15-30 minute segments. Sometimes even less. When it’s a known problem realm, the problem has been described enough to break apart, and I have a solid cohort to pair with, this is easily one of my favorite ways to build software – or as I might say sometimes “sling some code“.

Those are some of my answers, and I’m already thinking about a part II. But throw some of your own thoughts and suggestions at me on the Twitters @Adron. I’ll bundle up suggestions and add them in round two of this series. Cheers!