The Effects of Computer Programming on the Brain (2012)

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?

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.

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.

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.

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.