Live data from Hacker News

Reversing the effects of long programming sessions

poppastring.com

61–70 of 144 posts

Re: Reversing the effects of long programming sessions

#61
post #55

Earlier quoted context omitted.

All true, but neither should we deny ourselves a long session of "flow" if it makes us happy.

I'm finding that 'flow' is a significant contributor to NIH Syndrome. You can't flow while integrating a third party library anywhere near as easily as you can flow by rewriting half of it (badly) from scratch. Flow is a rush. Anything that is a rush can be indulged in to the point of self- (or other-) harm.

I do not believe flow has any significant relationship to whether the underlying thing you are creating is going to interface with a pre-existing tool or be a new creation.

I frequently need to reach states of deep flow when I am reading large inter-related files for refactoring, or modifying existing code to use a new library, or to follow tutorials for something only tangential, like new deployment tooling.

Reaching states of flow is necessary no matter what you’re doing, and given the insane explosion of modern process overhead and meeting-centric corporate culture, it’s important to protect flow time and make it known how important flow is. Whereas I can see how people might try to use thinking like in your comment to undermine flow time, and falsely act like it’s somehow better to deny developers workspace or blocks of time for getting into flow states.

Re: Reversing the effects of long programming sessions

#62
post #59
post #55

Earlier quoted context omitted.

I'm finding that 'flow' is a significant contributor to NIH Syndrome. You can't flow while integrating a third party library anywhere near as easily as you can flow by rewriting half of it (badly) from scratch. Flow is a rush. Anything that is a rush can be indulged in to the point of self- (or other-) harm.

> You can't flow while integrating a third party library anywhere near as easily as you can flow by rewriting half of it (badly) from scratch. That is not so clear cut, it depends on the library. If the documentation sucks or the library is a mess, rewriting it may both induce flow and be a win for the team.

Especially if you have to make changes to it later.

Re: Reversing the effects of long programming sessions

#63
I have recently been vaping high CBD hemp flower after a long day of programming. I am fully functional while feeling so much better. There is a mild residual feeling the next day, so I don't have to vape daily. I am dreaming again, nightly. I am waking up refreshed the next morning.

I highly recommend people try it.

Mail order to anywhere in the US seems like a legal grey area. There are two, possibly three online farms supplying the market in the US but this space is going to expand very soon. Prices are very reasonable.

Re: Reversing the effects of long programming sessions

#64
I would totally agree with the "playing a musical instrument" as a method to wind down.

My working desk and all my IT gear is on one side of my home office. Behind me, the other half is racks of amps, keyboards and amps. During long compiles, installs or downloads or while waiting for a Slack response from a colleague, I will often just lean back and grab an instrument and play away for a few minutes.

Great way to reset the brain, plus change posture and breathing patterns.

Re: Reversing the effects of long programming sessions

#65
post #55

Earlier quoted context omitted.

I'm finding that 'flow' is a significant contributor to NIH Syndrome. You can't flow while integrating a third party library anywhere near as easily as you can flow by rewriting half of it (badly) from scratch. Flow is a rush. Anything that is a rush can be indulged in to the point of self- (or other-) harm.

I do not believe flow has any significant relationship to whether the underlying thing you are creating is going to interface with a pre-existing tool or be a new creation. I frequently need to reach states of deep flow when I am reading large inter-related files for refactoring, or modifying existing code to use a new library, or to follow tutorials for something only tangential, like new deployment tooling. Reachin…

I have to agree with this. You're either writing assembly code yourself, or you're using code that was invented by someone else (and even the assembly code will have been invented by someone!). If using libraries/frameworks is something you do consistently, you can absolutely reach a state of deep work while working with them.

Libraries should help keep the flow going at a high level by keeping one from being bogged down with having to reinvent the wheel. In fact, if they didn't contribute to flow, I don't think we'd use them!

Re: Reversing the effects of long programming sessions

#66

Earlier quoted context omitted.

I do not believe flow has any significant relationship to whether the underlying thing you are creating is going to interface with a pre-existing tool or be a new creation. I frequently need to reach states of deep flow when I am reading large inter-related files for refactoring, or modifying existing code to use a new library, or to follow tutorials for something only tangential, like new deployment tooling. Reachin…

I have to agree with this. You're either writing assembly code yourself, or you're using code that was invented by someone else (and even the assembly code will have been invented by someone!). If using libraries/frameworks is something you do consistently, you can absolutely reach a state of deep work while working with them. Libraries should help keep the flow going at a high level by keeping one from being bogged…

I think you're confusing using a library you've already been using (in which case I agree) and introducing a new library.

Most people engaging in NIH aren't removing a library that is already being used in your build process. They're deciding it's easier to implement URL processing (spoilers: it's not) than to use a library that already exists.

The exception to that is when the existing library turns out to be a dumpster fire and you rip it out and replace it with something else or a custom version.

Re: Reversing the effects of long programming sessions

#67
post #37
post #4

We need to restrict the amount of hours we spend in front of computers per day and take weekends completely off. There are so many downsides: blue light that damages your vision, lack of exercise, depression and other disorders, missing out on social life, etc. There is a direct relation between productivity and having a life put together. Not taking care of ourselves (programmers) could have lead to disaster: mental…

> blue light that damages your vision Can anyone explain to me how looking at a computer screen is not several times less harmful than spending time outside from a lifetime-blue-light-exposure perspective? The sky is blue and natural light has a blue component in probably about the same proportion as white light from a screen. Maybe I'm wrong — and I'd like to find out if I am — but this whole blue light scare really…

The light & vision story is still being discovered.

"How is the idea of "outdoor time" used for myopia control?

One of the big surprises of recent research is the importance of how increased time spent outdoors helps in preventing myopia. At the present time it appears that 14 hours a week or more outdoors are significantly effective in reducing myopia progression."

http://www.myopiaprevention.org/outdoor_time.html

Re: Reversing the effects of long programming sessions

#68
post #37
post #4

We need to restrict the amount of hours we spend in front of computers per day and take weekends completely off. There are so many downsides: blue light that damages your vision, lack of exercise, depression and other disorders, missing out on social life, etc. There is a direct relation between productivity and having a life put together. Not taking care of ourselves (programmers) could have lead to disaster: mental…

> blue light that damages your vision Can anyone explain to me how looking at a computer screen is not several times less harmful than spending time outside from a lifetime-blue-light-exposure perspective? The sky is blue and natural light has a blue component in probably about the same proportion as white light from a screen. Maybe I'm wrong — and I'd like to find out if I am — but this whole blue light scare really…

I've always read it as the ratio being wrong for our eyes - that the light is simply too high energy, and it needs to be balanced out with red light or filtered away. Sunlight, despite having a much higher amount of blue light, also has more light across the rest of the spectrum, reducing the difference and making it less harmful.

Re: Reversing the effects of long programming sessions

#69
post #37
post #4

We need to restrict the amount of hours we spend in front of computers per day and take weekends completely off. There are so many downsides: blue light that damages your vision, lack of exercise, depression and other disorders, missing out on social life, etc. There is a direct relation between productivity and having a life put together. Not taking care of ourselves (programmers) could have lead to disaster: mental…

> blue light that damages your vision Can anyone explain to me how looking at a computer screen is not several times less harmful than spending time outside from a lifetime-blue-light-exposure perspective? The sky is blue and natural light has a blue component in probably about the same proportion as white light from a screen. Maybe I'm wrong — and I'd like to find out if I am — but this whole blue light scare really…

A cloudless blue-sky day has a lot of blue as well. I haven't heard its bad for you, even if the warm sunset light is prettier.
Post reply on HN