This has good and bad results. It means I not only can, but wish to code for long continuous stretches (about 40-50 hours has been my max before burning out, with a few 5-20min food/unkink/bathroom breaks) and I have difficulty programming for less then 5 hours in a stretch. It means that when I finish something, or find myself without an active project then I go a bit nuts: I tend to write a first few thousand lines of a GA or Chat-bot until I get my fix and can stop (and normally chuck the resulting code). It means I do a lot of "code-katas". It also means I am very frustrated in team scenarios where I have to often "come up for air" to communicate with teammates as this diminishes the pain-avoidance. It means I do not spend a lot of time on design and documentation, I just dive in and start writing code and actually enjoy the process of spending hours fiddling with things until they work.

In fact, my addiction to programming is likely a core factor in my choice of education and career. With this moment of reflection, I get to ask myself a question: Is the fact I do what I do largely as a symptom of addiction a bad thing? At minimum is a strike against my self actualization. Is an addiction that people will pay you to feed a bad thing?

I've been there, there is no saying how great an impact pain has on your quality of life, your thinking, your family, your dreams, everything. Guess what I want to say is that you're incredibly lucky to cope with your pain just by programming, but I think you shouldn't call it nasty - exactly because something like programming helps.

The first few years of these pains were exactly like you described. I was constantly suffering and it was breaking me down. I was mostly non-functioning and barely able to keep up with high-school. After three years of nonstop pain I realized my life was not going to go anywhere until I had made some changes. I decided I was going to strive to not suffer from my pain. That is an impossible challenge. It is not 'coping' per say, as I do not hurt any less but it is coping in the sense that I decided to put on the strong facade of not hurting to the majority of the world.

I've been neurologists, on multiple medications. The few medications that did work (Topimerate for example) lessened and even stopped the migraines, but with bad cognitive effects (short term memory issues and shortening of my attention span). Right now I am unmedicated and working on my PhD. My end solution to the pain is to work so much that I don't have much energy left for suffering. It's not fun, but it is better then wallowing and I'll take that.

My polyneuropathy is one of things like this - I was able to put a strong facade for five years, until it worsened to the point where I couldn't anymore. And that was just the beginning, because it went downhill from there.

It's good to be "strong", but it's stupid to be stubborn and when the pain becomes too much taking medications is the right way. Even if you become a bit dumber because of them. At least that's what I did and having felt relief I can't imagine suffering once more like that. I have nightmares about that.

A few years ago I was researching diseases that could be causing my type of pain. Neuropathy was something I knew I did not have, but reading about it gave me a bit of confidence. It was one of the few chronic pain issues I deemed clearly "worse off than me" and the fact there were people without it out there leading productive lives gave me a lot of encouragement that I could do it myself.

You could rephrase "addicted" as "passionate". As the writer explains, passionate programmers want to get new puzzles all the time and get bored solving old puzzles. This is a very logical process. When somebody got bored with an old puzzle, it means he/she gained more knowledge/experience and has become a better programmer.

When you become a better programmer and you notice you're getting bored with your current work, it means you should move on. If your current job doesn't offer you anything more interesting you should get another job.

That's my "remedy". It would be such a waste if you would say to yourself: "I shouldn't become a better programmer, I should go on with coding boring stuff and finish my projects". If you do this you'd better just become a sales person (or something else boring).

Of course, it can happen that you have an exiting project but there are some less exiting puzzles in the project that you avoid doing all the time. I think you can easily solve this with project management (indeed, as the writer suggests). If the puzzles aren't that challenging, then the time to solve it won't be very much either. And if you work in teams, you can devide this stuff equally. This is just a manner of discipline.

So please guys, go on being addicted! It's awesome to be a programming addict! Just don't forget to satisfy your boss once in a while!

If that's the case, a lot of programmers (including me) are extreme and unhealthy. I've lots of unfinished projects that I stopped working on right after the interesting bit was done or almost done.

Don't agree. This implies that it is healthier spending your life doing things that are uninteresting.

> If that's the case, a lot of programmers (including me) are extreme and unhealthy. I've lots of unfinished projects that I stopped working on right after the interesting bit was done or almost done.

Me too. Prioritizing doing stuff about which you are passionate is much healthier. Of course I am probably in denial...

I've been at it for ~30 years now, and I notice the same effect - iff I spend too much time reading short-form content. Being able to deal with long-form content requires practicing interaction with long-form content. As it turns out (lately), I more and more often deliberately turn off network connectivity, having pulled major references I need offline. For exactly that reason - the scanning through garbage is disruptive to my ability to focus.

Otherwise, I seem to have survived programming fine ;)

I don't see coding as an addiction. Sure, it is a time sink and feels good, but after a focused coding session the results are (usually) constructive and I learn new things along the way.

This is different from addictions which are usually a way of instant easy satisfaction, a "high", after which you feel useless and down when it weans off. Programming is nothing like that at least for me.

I don't understand, how do you use HN then? I take a look at a front page and open interesting comments pages in background tabs. Then I close the front page and proceed to comments. There is frequently more than 100 comments on interesting topics and many of them long, involved and worth reading. I'm done with one page after some time, from 10 to 30 minutes. Then I sometimes read the article (if the comments convinced me to) or just go straight to the next tab with comments. A single comment may be worthless, but it's then short and easily identified as such, reading them hardly takes 15 seconds. On the other hand, long comments tend to form threads, which I then read as an essay, which takes much longer than 15 seconds.

So, how do you use HN to have your attention split into 15-seconds spans?

"15 second spans" was exaggerated, this is not Twitter. However reading these kind of sites causes a lot of context switches between topics and articles that seem interesting, or make me want to argue, but a few hours later I cannot really remember anymore what they were about.

It's a very fragmented experience with no clear narrative (at least, that my brain bothers remembering), but it does wear me out.

In any case, it's not that I don't have it under control, but to me it feels more like a potential addiction than coding ever did.

The real problem? Working in an environment where the first and foremost goal is to "get shit done" and deliver a product. Programming in such sense is outright boring, because the fix comes from solutions which require deep digging, reseach and some creativity rather than readig a spec and implementing it.

Did I miss something? There is no research here, just a flight of fancy. We shouldn't discuss or upvote such garbage.

For the record -- if PG is reading -- I enjoyed your essays on the first reading, but seeing the exact same ideas keep repeating in posts is kind of weird...

Real addiction is defined by severe life consequences: jail, death, destroyed relationships. Describing an employee who struggles to do boring tasks and focuses on fun ones as a troubled "addict" is just severely, incredibly stupid.

Though I agree that avid learners new to programming concepts may experience anxiety or euphoria depending on the problems which they are working on defeating. I wouldn't necessarily call it an addiction; no more than I would suggest that a musician is addicted to playing their instrument or writer is addicted to creating prose.

The art of programming in which begins with exploring computational programming models and processes ultimately ends with the craft in which itself is as fluid as a master composer composing whom subsequently is also a master musician.

Though it's that "Teach Yourself Programming in Ten Years" which may be what TFA is referring. Not everyone programs inside skinner's box, even in their early years of programming. There is better research on the subject than this generalized blog post which is far from aphoristic of the effects of computer programming on the brain.

The addiction comes when you don't have any other fun games to play where you get into flow. For example: sex, reading, outdoor activities, building art cars...

Nevertheless it does raise some interesting thoughts on motivation, self-reward of the brain, etc. Which are not specific to programming per-se. You also have this in sciences, math, etc. Programming is just very immersive in the way that you do not have to leave your desk.

The addiction part is really questionable since you cannot discuss addiction without defining what you mean by addiction, etc.

I think many of us can relate to what is being discussed. I, for one, get a huge kick out of trying to write concise, clever code to solve problems, but that often leads to a lot of time spent on something insignificant. I'm trying to train myself to A) finish projects I start & B) become OK writing code quickly and not worrying if it's less than perfect.

Like in writing on paper with pen. These qualitative subjective judgments are not coming from programming per se but rather a style of programming. Think: continental versus American styles of philosophy. Programming as we know it is arguably Western (structured, "precise" and all that hooplah). Programming itself isn't inherently Western, even if ARPANET was a US Grant, if you get my figures of speech, and grant me poetic license (which you probably won't do).

But I quickly realized when using it that the project could not live up to my earlier ambitions. The problem was that I hadn't foreseen the problems in not being able to overload JS operators: something like half of the Promise library just wrapped the JS operators, so that `this.gt(that)` becomes a deferred representation of `this > that`. This kind of worked, but I began to lose interest in this general approach when I started to struggle with how to idiomatically represent (a) variables, (b) if-then-else constructs, which are right now of the form promise.then(promise_if_truthy, promise_if_falsey), and (c) composite statements.

Fortunately, I found the right thing to study, and off-and-on for the past year I've been studying it. The right thing to study in this case is Haskell, because the way that Haskell reduces 'do notation' to a pure sequence of function applications is precisely what you need above to solve (a) and (c) at least.

Another idea was to take a revision control system like Darcs and try to move it, as much as possible, out of the realm of IO so that it could work on an arbitrary in-memory data structure as well. (I might then try to move it back into IO by storing the internal representations in a database, which would probably look a lot like a graph database or like Datomic) This is a great idea but it has stalled because the handling of dictionaries requires 'confluently persistent tries'. There's a great paper on these by Erik Demaine et al., where basically they make functional link/cut trees and build the system out of those, then optimize them to languages which aren't functional as well. I say 'there's a great paper' on it but actually that paper is an incremental result, not a tutorial -- so while it looks really interesting it's required me to learn a tremendous amount of new concepts before I can even implement it.

What I am trying to say is this: is this a code addiction? Probably, but that's not why the projects are stalling. The projects are stalling because my Master's degree and interest in physics have become more important. Computer programming has only a second-order effect on the brain; the first-order effect is distractions. We should not write articles on the problems of being addicted to computer programming, the time I spent programming yesterday, while substantial, is about as long as I've spent typing this comment today. This comment (or other distractions which might replace it, TV or comparative religion podcasts or whatever) is more of the problem than the programming.

I wish the things that competed for my attention had a simple ordering relation.

Let's say you have a web idea, its so "simple".

So you code it and do a "proof of concept".

Then you start coding, you think you have it nailed, you predict you can do this thing in a few thousand lines of code using bla bla framework.

So you write those few thousand lines of code. Its done. It works.

Except, it doesn't scale, it has no security, you have no hosting, load balancing, failover, replication, user authentication, marketing, no decent website, no android or iOS presence, no enterprise customers, it looks like crap, you have no graphic artists, you have no CSS experts, you do OK on those but its not professional.

And then the features: the "real" product you wish you were building is beyond your means.

Sure you can try to patch it together, but your "few thousand" lines of code delusion is just that.

That's a sure sign of code addiction. And Ive been there myself. Its not that you CANT do all of those things. Its that you spent your time ignoring all of those things to justify coding. And when you hit that wall, you will most likely stop in your tracks and ditch your idea and the work you put into it, to focus on your next "thing".

As a musician I practiced 4-8 hours a day for 15 years.

As a software engineer I have had coding durations for much longer periods with more time in between due to burn out.

I think as in any pursuit, we can sometimes delude ourselves, that the more we do something whatever it is, the better we will get at it.

Its not true. In any performance related field, its acknowledged that there CAN be too much of a good thing.

And too much coding is just as bad for you as too much high-jump practice.

You will end up with a lot more text files expressing your desire, but you will not be improving.

So at some point we as software engineers have to make decisions and choices about how we spend our time and effort without making ourselves robots, pursuing ever diminishing returns, to the exclusion of our personal happiness and fulfillment.

I like to think of this as an analogy to how the brain processes (what we call "having a thought"), in that our most widely used metaphor is of a light show or fire crackers going on in a cloud of smoke. The beams of light, when taken as groups arranged over time, or distributions, represents the neurotransmitter, the statistical distributions of light give us a concept map or ontology of thought.

Sometimes I close all of my terminal splits on accident with an ending of "Aha!"

Do this because you believe in semiotic alchemy, and for no other reason. There should be 10-15 physical programmers, if that. Anything more is excess.

1. Writing code in vim.

2. An attempt to extend a common philosophical image in cognitive neuroscience ( http://youtu.be/Bm40BSZJRck?t=48m28s ) which involves the behavior measurement of phenomenological experience, like perception. The description in terms of temporal modality is precise, however a grammar (set of valid images) is necessary to enable the merger of these data into public consciousness. So, I'm using the event of spotlights or firecrackers flashing in smoke as an analogy.

If you look at LightTable, perchance you'll understand ? And if you split more often, and employ many IDE-ish tools in vim ? I am a coder trying to relate my experience of Flow to you.

What does it matter if anyone is addicted. Addicts talk about addiction.