4 ms·

Many programmers (at least me) have varying levels of peak output in a day. Some times I literally can't make my brain work after 2 - 3 hours of in-the-zone wo

by zanny 13y ago

Many programmers (at least me) have varying levels of peak output in a day. Some times I literally can't make my brain work after 2 - 3 hours of in-the-zone work. I just can't read lines off a screen anymore. Other times I can go 24+ hours without breaking a sweat. I think in practice your average programmer can't operate on the 40 hour a week traditional work schedule and actually output solid performance for all 40. On average, at least. So maybe the first businesses to start introducing meetings and such were attempting to pace their SE staff and actually saw positive results, since they still got whatever the maximum output one engineer could put out before their brain went to mush in a week but also had them talking to clients or discussing other things. It is just the industry latched on to bureaucracy without postulating why it might be useful. You want your SE coding whenever possible.

dubcanada 13y ago
That's pretty much the same as me. But I do know people who can do the 7 hour full force ahead. And interrupting those people generally results in very little getting done. For the rest of us there is always code reviews and emails and other fun things that needs to be handled and requires less brain power (well code reviews should require more but let's ignore that).
yeukhon 13y ago
+1 here. There is also a pressure to get things done when I don't feel like getting things done - as in I don't have the inspirations to write that piece of code / that code is so ugly and hard to write. Then a day or two later I would come up with a better solution and boom, milestone achieved.
- Swizec 13y ago
  But without forcing yourself to write that code, the breakthrough wouldn't come in a day or two. The breakthrough will never come. Writing that crappy code that feels like pulling barbed wire through your brain forces you to think about the problem. To look at the corner cases, to really figure out a solution. The breakthrough in a few days is just a cleaner solution you were able to come to after a deep understanding of the problem.
  - yeukhon 13y ago
    True and a quiet day might be enough as an pill. Or at least sitting at home can help for some people.
    - dasil003 13y ago
      Not sure why someone downvoted you. While it's true that not all work is pleasant and sometimes we have to force ourselves to get things done, I think it's equally true that for solving difficult problems reflection is necessary. Especially as I get older and more experienced, I feel like my brain has more fodder for solutions but it takes more time to tumble around and fall into place. A lot of things besides actually sitting down and coding can help: getting 8-9 hours of sleep, talking over the problem with someone (even non-technical), getting some exercise, mind-mapping / wireframing, staring into space for hours at a time, etc.
legacy2013 13y ago
I completely agree. I'll have a day at work where I just do not want to code, and anything I create will be garbage. Sometimes I'll do a rough prototype of what actually needs to be done, which will get my brain thinking. A day or two later, everything clicks into place in my brain and I go through, rework the prototype, and create a great piece of code I'm happy to turn in. If I get interrupted during that period of programming though, I usually lose my train of thought which make me stumble to catch up again. The prototype helps because I can see what I was doing if I was interrupted
aidenn0 13y ago
This is the reason why my productivity has gone down since going from single to having a family. When I was single, I would just cut out early on the days I wasn't in the zone, and get some errands or housework done. When I was in the zone, I would stay at work until right before I would go to bed. This way I would spend nearly all of my "in the zone" time doing work. Now that I have kids and such, I leave at 6 every day regardless of my productivity level, so even though I spend only slightly less time at work, my net productivity is way lower.
- dasil003 13y ago
  In the same situation I think my productivity is actually equivalent with fewer hours after having kids because it has created an ongoing sense of urgency to get done what I can in the 8:30-5:30 window. In the old days, 4pm was almost like the half-day mark, which personally led to a mental slackness about how much time I had left to accomplish a given task that day. These days, I sometimes get cut out of the zone by quitting time, but more often than not I am mentally exhausted and ready to go. I'm sure that this would not apply to the most focused and driven programmers, but I'm also sure that a lot of young startup types are fooling themselves that the long hours they put in are giving them better returns than they would get with a bit more sleep, a bit more exercise and a bit more downtime.
- javajosh 13y ago
  Anyone can take a great photograph. The professional photographer learns techniques to take great photos more frequently. In a sense, "professionalism" in any field implies a certain "frequency of success". For a programmer, that means learning techniques to accomplish tasks even when you aren't "in the zone". This means learning to get in the zone, how to stay in the zone, and learning to produce when you're nowhere near the zone. This requirement is universal to all professionals, including all professional programmers[1] I would add that learning to approach your work even when you don't feel like it can sometimes yield surprising insights. Your brain is recoiling from work, but only as it approaches it from certain directions. It is possible to approach a problem from other angles, and getting "in the zone" from another angle can sometimes yield unexpected improvements to the product for the simple reason that you're looking at it in a new way. [1] There are two categories of professional programmers, the hired guns and the artists. They both want to build great things. The hired-gun wants to build things faster and to spec. To him, "great things" is unambiguously defined as 'the things that will satisfy the customer'. All businesses love a speedy, accurate programmer - especially if they can be speedy and accurate in a non-disruptive way. Such programmers are very good at understanding existing codebases, processes, and doing the minimum work to get the job done. Often they simply do not care about technical debt - (indeed, they are incentivized the other way, to maintain (and even increase) technical debt, every bit of which only improves their negotiating position with the client.) Meanwhile the artist-programmer success is not defined by conformance to a spec. Success is harder to define - but the artist can define success as getting the time to perfect his creations, traveling ever higher up that diminishing returns curve, going higher than most people are willing to go. This kind of programmer is the dreamer, the architect, the creative. This can be a backend architect, or a front-end perfectionist. They share the common goal of mastery and beauty. Most, if not all, programmer heroes come from this category. And rightly so, I think.
jw_ 13y ago
I find that meetings kill productive time later, especially ones that are pure bureaucracy/managerial dickwaving. It's certainly the case that I can't grind out code 40 hours per week, but I don't think that sticking meetings in the "unproductive" time helps matters at all.
eric-hu 13y ago
My current company has engineers pair-programming full time. On first reaction, engineers and managers tend to think that results in 50% net productivity. My experience has shown that people tend to average each other out. There are days where I'm well aware of how poorly I'd program, but I can still navigate my pair out of the pit of despair. It also tends to cut down on meeting times because two sets of eyes are usually looking at any given piece of code, so knowledge disperses among the team organically so long as we swap pairs regularly.

by zanny 13y ago

dubcanada 13y ago

That's pretty much the same as me. But I do know people who can do the 7 hour full force ahead. And interrupting those people generally results in very little getting done. For the rest of us there is always code reviews and emails and other fun things that needs to be handled and requires less brain power (well code reviews should require more but let's ignore that).

yeukhon 13y ago

+1 here. There is also a pressure to get things done when I don't feel like getting things done - as in I don't have the inspirations to write that piece of code / that code is so ugly and hard to write. Then a day or two later I would come up with a better solution and boom, milestone achieved.

Swizec 13y ago
But without forcing yourself to write that code, the breakthrough wouldn't come in a day or two. The breakthrough will never come. Writing that crappy code that feels like pulling barbed wire through your brain forces you to think about the problem. To look at the corner cases, to really figure out a solution. The breakthrough in a few days is just a cleaner solution you were able to come to after a deep understanding of the problem.
- yeukhon 13y ago
  True and a quiet day might be enough as an pill. Or at least sitting at home can help for some people.
  - dasil003 13y ago
    Not sure why someone downvoted you. While it's true that not all work is pleasant and sometimes we have to force ourselves to get things done, I think it's equally true that for solving difficult problems reflection is necessary. Especially as I get older and more experienced, I feel like my brain has more fodder for solutions but it takes more time to tumble around and fall into place. A lot of things besides actually sitting down and coding can help: getting 8-9 hours of sleep, talking over the problem with someone (even non-technical), getting some exercise, mind-mapping / wireframing, staring into space for hours at a time, etc.

legacy2013 13y ago

I completely agree. I'll have a day at work where I just do not want to code, and anything I create will be garbage. Sometimes I'll do a rough prototype of what actually needs to be done, which will get my brain thinking. A day or two later, everything clicks into place in my brain and I go through, rework the prototype, and create a great piece of code I'm happy to turn in. If I get interrupted during that period of programming though, I usually lose my train of thought which make me stumble to catch up again. The prototype helps because I can see what I was doing if I was interrupted

aidenn0 13y ago

This is the reason why my productivity has gone down since going from single to having a family. When I was single, I would just cut out early on the days I wasn't in the zone, and get some errands or housework done. When I was in the zone, I would stay at work until right before I would go to bed. This way I would spend nearly all of my "in the zone" time doing work. Now that I have kids and such, I leave at 6 every day regardless of my productivity level, so even though I spend only slightly less time at work, my net productivity is way lower.

dasil003 13y ago
In the same situation I think my productivity is actually equivalent with fewer hours after having kids because it has created an ongoing sense of urgency to get done what I can in the 8:30-5:30 window. In the old days, 4pm was almost like the half-day mark, which personally led to a mental slackness about how much time I had left to accomplish a given task that day. These days, I sometimes get cut out of the zone by quitting time, but more often than not I am mentally exhausted and ready to go. I'm sure that this would not apply to the most focused and driven programmers, but I'm also sure that a lot of young startup types are fooling themselves that the long hours they put in are giving them better returns than they would get with a bit more sleep, a bit more exercise and a bit more downtime.
javajosh 13y ago
Anyone can take a great photograph. The professional photographer learns techniques to take great photos more frequently. In a sense, "professionalism" in any field implies a certain "frequency of success". For a programmer, that means learning techniques to accomplish tasks even when you aren't "in the zone". This means learning to get in the zone, how to stay in the zone, and learning to produce when you're nowhere near the zone. This requirement is universal to all professionals, including all professional programmers[1] I would add that learning to approach your work even when you don't feel like it can sometimes yield surprising insights. Your brain is recoiling from work, but only as it approaches it from certain directions. It is possible to approach a problem from other angles, and getting "in the zone" from another angle can sometimes yield unexpected improvements to the product for the simple reason that you're looking at it in a new way. [1] There are two categories of professional programmers, the hired guns and the artists. They both want to build great things. The hired-gun wants to build things faster and to spec. To him, "great things" is unambiguously defined as 'the things that will satisfy the customer'. All businesses love a speedy, accurate programmer - especially if they can be speedy and accurate in a non-disruptive way. Such programmers are very good at understanding existing codebases, processes, and doing the minimum work to get the job done. Often they simply do not care about technical debt - (indeed, they are incentivized the other way, to maintain (and even increase) technical debt, every bit of which only improves their negotiating position with the client.) Meanwhile the artist-programmer success is not defined by conformance to a spec. Success is harder to define - but the artist can define success as getting the time to perfect his creations, traveling ever higher up that diminishing returns curve, going higher than most people are willing to go. This kind of programmer is the dreamer, the architect, the creative. This can be a backend architect, or a front-end perfectionist. They share the common goal of mastery and beauty. Most, if not all, programmer heroes come from this category. And rightly so, I think.

jw_ 13y ago

I find that meetings kill productive time later, especially ones that are pure bureaucracy/managerial dickwaving. It's certainly the case that I can't grind out code 40 hours per week, but I don't think that sticking meetings in the "unproductive" time helps matters at all.

eric-hu 13y ago

My current company has engineers pair-programming full time. On first reaction, engineers and managers tend to think that results in 50% net productivity. My experience has shown that people tend to average each other out. There are days where I'm well aware of how poorly I'd program, but I can still navigate my pair out of the pit of despair. It also tends to cut down on meeting times because two sets of eyes are usually looking at any given piece of code, so knowledge disperses among the team organically so long as we swap pairs regularly.