This is almost disturbingly accurate to how I feel in the "zone" as well. A consequence of this is it's hard to have a healthy life as a self-employed programmer. If I want the app I'm working on finished faster (and I do or I'll run out of money), I must stay in the zone as long as possible. Which means I must ignore people as long as possible and put off eating/exercising as long as possible as well.
Putting off exercising and eating may work short term but I don't think it's a good idea to do long term. In the long run you need to find a sustainable rhythm.
The first sentence in the article reads: "In positive psychology, flow, also known as the zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity."
Also: "Achieving flow is often colloquially referred to as being in the zone."
I get this too, but it's very draining - similar to doing an intensive workout, or given a talk at a conference.
The negatives are obvious; less sociable, more easily irritated, wanting to be by yourself. After you've spent a day in the zone, you're not really "party material".
The positive (apart from being very productive) is that I use it to get my negative feelings out of the way - anything that is bothering in my life is somehow gone when I am in "the zone" - it is truly a zen feeling as the author explains.
It's also important to mention that you can't force yourself to be in the zone. It comes and goes, with very little control on your behalf. People that try to force themselves in the zone by working harder, are not truly in the zone. It happens seamlessly without you even knowing or wanting it.
For instance, I'm hardly in the zone. It happens probably once every two weeks, if not less - it also depends on what I'm working on; if it's something new and exciting I'm more predisposed to get in the zone.
Being in the zone is like getting an adrenaline rush - you can force yourself to do it more often (go skydiving for instance), but if you do it too often you'll quickly drain out and not enjoy it as you used to.
> It comes and goes, with very little control on your behalf.
As anecdata makes the data, here's mine - you have a lot of control of it.
If you can control your environment (audio, light, temperature, food, exercise, communication, interaction, ...), you can get in the zone too just by virtue of almost exclusively focusing on some type of work you get in the zone for in the first place.
Same here. I can almost say it becomes somewhat of a problem to keep a normal day schedule. It takes 2 minutes and I'm gone for at least 12 hours.
It happens about 3-4 out of 5 times just because I real like the software I'm building or because I get thrilled about how to make something 'boring' a masterpiece to look at or even because I know there is something I don't understand.
It's almost like a drug to keep coding en digging deeper every day. To a point where I even feel somekind of a huge pressure in the middle of night to 'profit' very hard of the last minutes i' m awake.
Doesn't feel healthy anymore haha. But I just love to much somehow
It takes some effort but you can trigger the zone. I put on my favorite programming song (looped). Turn on “Freedom” to block the web. Exit every unnecessary app. Then finally do meditative breathing. Usually within 10 minutes I’ll be in the zone. The only caveat is that it is much harder for me to get into this state if I’m debugging.
I've found I sometimes just need to do something to get there.
I just had what I consider to be the single most productive day in the past few months, and I started it feeling like I wasn't going to get anything done. But I decided to golf a regex in our codebase and I had that feeling of motivation and jumped right into actual work.
But funnily enough I find debugging to be the most fun when I'm in the zone (assuming I know the codebase). Something about being able to get really deep into a problem and having all the tools and programs and hardware open and running and all setup correctly.
Right. I only drink coffee anymore for these occasions, put in repetitive music and certain short phased annoying urgent Non coding chores must be done and out of the way, so they don't pollute my mental horizon. It works. Most of the time.
No amount of control of my environment will put me in the zone when I'm working on boring code. Crud framework? I'll be reading HN while going through the motions. Code review? Time for some stimulating music (though not too stimulating, I do need to pay attention to the code review).
But give me something interesting - a real challenge - and I'm able to get into the zone, the hours flying by like they were minutes. My brain has to be able to fully engage with the problem to hit that zone.
Of course, I'm a technical lead in my group, so the ability to control my environment is limited. So I get up absurdly early just to get work done before I have to be available to be interrupted.
During my about 11 years of experience as a web dev, I rarely got to do any repetitive and boring tasks. When I got them, I made them interesting by thinking of ways to automate as much as possible of the implementation process.
Or negociated a higher pay, so it becomes non viable financially for the employer to use me as a resource to do the routine stuff. This doesn't apply to code reviews though.
Time to sit down for 11 hours and learn 5/6, weeks of diffeq for an exam. Eyes burning. Member disappearing into my body. Digestive system not functioning.
But then it's done. And then you forget all the mass information you absorbed and shat out onto a page.
As an ADD person who has to take it regularly, I can say that it can just easily focus you on replying to anything of interest on Hacker News... so no, doesn't work this way.
Yeah I've lived it. You have to get to work right away so when it kicks in otherwise you'll generally keep doing whatever you were doing when it did. It can turn you into a god of productivity if you use it right or a degenerate jacking off for 12 hours straight.
As another anecdata, the only way I've landed there more intentionally is with the two beer buzz. Working late on a project that is behind and you grab two slices and a six pack. Two beers in (and one every hour) and all of a sudden you just start tearing through code. I've had this happen to me countless times. I think it is because a lot of engineers have a brain that is spinning 1000% all the time and a couple of beers slows it down just enough for it to focus on what you are working on. All the other distractions fall away.
I feel exactly the same way when I'm white water kayaking. As you are reading the water and choosing your line and focusing on executing it, everything else in life falls away. You almost can't be distracted. The interesting thing is that at the end of a run, I never feel mentally exhausted despite all the intense focus, only physically drained. Of course, ymmv.
Oh yeah! Cycling fast gets me there too. It's weird, just put your brain in a position of risk and your get pretty quickly to focus zen. I wish I had a a simple formula like this to get in the zone more often when programming.
> Being in the zone is like getting an adrenaline rush
Really disagree here, I find it's the total opposite more like a serenity and calmness. I also can get into it easily enough if I sit down with a plan of action and am not just writing code blindly and getting frustrated. If I find I can't enter the 'zone', it's usually because of some distraction (meeting coming up, feeling ill, not happy with the work, noisy open office work environment etc).
> if you do it too often you'll quickly drain out and not enjoy it as you used to.
Somewhat agree, but I think you mean here that you spend too much time in front of the PC and not enough time tending to your other needs? In which case I definitely agree; I notice a marked increase in productivity if I make sure to exercise routinely in my week, go on social events etc
I find been in the zone feels a lot like a less intense version of the feeling I get after a really good nights sleep or after a getting back from a hard bike ride and having a shower, it's just a general feeling of wellness.
I also find the zone happens a lot less often doing web dev than it ever did when I did desktop development, the constant scope switches combined with a massive surface means I drop out a lot more often.
Yeah instant context switching is a real nightmare for the brain, I find it far easier to get up for ~20 minutes after finshing a task and go outside, before returning and getting on with the next task with my now hopefully clear mind.
""""
The negatives are obvious; less sociable, more easily irritated, wanting to be by yourself. After you've spent a day in the zone, you're not really "party material".
"""
That hits close to home. Ive thought about this a bunch and it feels as though setting up the mental context of programming, the implicit model I have of how a programs operates and what is happening, is an expensive process. I do wonder what exactly is being depleted in this process - glucose? Neurotransmitters? And whether it'd be possible to supplement this such that I minimize the cost of such operations.
I notice that I can be in the zone while programming, but then when I need to research something (do real thinking rather than work by reflexes), I pop out of it.
I find that isolating myself from my surroundings can actually help encourage me get into the zone. I work from home, usually by myself, but if I want to get into the zone I'll chuck on a pair of headphones; something about that helps focus me, prevents distractions, and pulls me into the zone more easily. I suggested this to a friend recently whilst he was writing his dissertation, and he found that it worked well for him too and really helped him get through it.
However I can't have folk music, as I stumble across a great tune too often and get up to play it instead :)
It is much easier to stay in the zone when there's a physical barrier between you and other people. Even so much as being asked if you want a cup of tea is enough to pull you out of it. I recently asked my boss to stop other people from phoning me if they want me to be productive, and that really helped. I don't think most people understand what it's like; that amazing feeling you get when you're in the zone when programming, and it can be difficult getting them to understand why it's so frustrating being pulled out of it when a simple message would have sufficed.
I haven't been getting this much for the last few months, but I think that's due to my scattered workload. I'm about to start a new project build and am looking forward to falling back into the flow.
Its a wonderful feeling, its like the fog in my mind has been lifted.
I sometimes find myself in this situation too. I often find that I feel most productive when I reach this state. But it's quite rare, a lot of my day is interrupted by colleagues, meetings, noisy office etc
It's cool, but you can see the downsides. A few weeks ago I basically disappeared for a few days writing some code. Great fun for me, but not exactly boosting growth opportunities for the team.
This happens a lot to me. Although i always go out friday and saturday evenings. It's just hard sometimes switching it off and takes a reasonable effort...
Sometimes i'm more quiet the entire evening and sometimes it's easier. In my mind, i'm constantly thinking about code then and it's hard to be social then.
All arround, i'm a very social guy. Just when i leave the zone, i'm not.
Cook Ting was cutting up an ox for Lord Wen-hui. As every touch of his hand, every heave of his shoulder, every move of his feet, every thrust of his knee — zip! zoop! He slithered the knife along with a zing, and all was in perfect rhythm, as though he were performing the dance of the Mulberry Grove or keeping time to the Ching-shou music.
“Ah, this is marvelous!” said Lord Wen-hui. “Imagine skill reaching such heights!”
Cook Ting laid down his knife and replied, “What I care about is the Way, which goes beyond skill. When I first began cutting up oxen, all I could see was the ox itself. After three years I no longer saw the whole ox. And now — now I go at it by spirit and don’t look with my eyes. Perception and understanding have come to a stop and spirit moves where it wants. I go along with the natural makeup, strike in the big hollows, guide the knife through the big openings, and following things as they are. So I never touch the smallest ligament or tendon, much less a main joint.
“A good cook changes his knife once a year — because he cuts. A mediocre cook changes his knife once a month — because he hacks. I’ve had this knife of mine for nineteen years and I’ve cut up thousands of oxen with it, and yet the blade is as good as though it had just come from the grindstone. There are spaces between the joints, and the blade of the knife has really no thickness. If you insert what has no thickness into such spaces, then there’s plenty of room — more than enough for the blade to play about it. That’s why after nineteen years the blade of my knife is still as good as when it first came from the grindstone.
“However, whenever I come to a complicated place, I size up the difficulties, tell myself to watch out and be careful, keep my eyes on what I’m doing, work very slowly, and move the knife with the greatest subtlety, until — flop! the whole thing comes apart like a clod of earth crumbling to the ground. I stand there holding the knife and look all around me, completely satisfied and reluctant to move on, and then I wipe off the knife and put it away.”
“Excellent!” said Lord Wen-hui. “I have heard the words of Cook Ting and learned how to care for life!”
Translated by Burton Watson
(Chuang Tzu: The Basic Writings, 1964)
Prince Wang's programmer was coding software. His fingers danced upon the keyboard. The program compiled without and error message, and the program ran like a gentle wind.
"Excellent!" the Prince exclaimed. "Your technique is faultless!"
"Technique?" said the programmer, turning from his terminal, "What I follow is Tao -- beyond all techniques! When I first began to program, I would see before me the whole problem in one mass. After three years, I no longer saw this mass. Instead, I used subroutines. But now I see nothing. My whole being exists in a formless void. My senses are idle. My spirit, free to work without a plan, follows its own instinct. In short, my program writes itself. True, sometimes there are difficult problems. I see them coming, I slow down, I watch silently. Then I change a single line of code and the difficulties vanish like puffs of idle smoke. I then compile the program. I sit still and let the joy of the work fill my being. I close my eyes for a moment and then log off."
Prince Wang said, "Would that all of my programmers were as wise!"
Actually didn't realize this until you pointed it out. It is written like that in the original. I like to interpreted it as a hilarious self-referencing pun^^
I'm a Fed engineer and spent a 4 mo. assignment on an integrated team with Pivotal pairing exclusively. It was a long 4 months for me. There was no "zone." I'm not built for pairing.
Sure you do. Two mediocre programmers working as a pair might get 100k each. One elite programmer can clear 7 figures easily. The elite programmer will also have much more control over the IP they create and be able to negotiate much more stringent terms for how it is used.
If you think pair programming is a good idea you are just at the bottom of the industry.
I think pairing can be different for different people. I've often heard people saying that "the zone" comes more easily when pairing. Personally, any zone I'm feeling pairing has a different character from one achieved alone. It's easier to focus on the task at hand (because there's peer pressure).
I often see programmers on HN talk about building mental castles of their programs, but I feel like I don't really code the same way. Instead, my thinking seems more "functional". For a given problem, I can often make out the faint outline of an optimal solution, but there's a lot of cruft and misplaced bits in the way. Most of my work involves mentally simulating the consequences of different options and then bending the architecture into such a shape that the whole thing just sort of assembles on its own. I'm only "in the zone" when I have to make that final leap. There's very little castle-building along the way.
As a result, I feel like I'm somewhat incapable of working on massive, multi-part architectures, since I just can't see the running state in my head. Once I zoom in to work on a single component, the rest fade from memory and I lose the big picture. On the other hand, I have no problem working in open-office environments: I don't mentally deal with a lot of program state, so I'm able to just dive right back in. This also influences my code to be more functional, as I know I can rely on e.g. idempotent methods to keep doing what they're supposed to regardless of any finicky global state.
I wish I could get better at building those "mental castles" since it's a huge barrier to designing complex architectures (like games). I don't want to be stuck forever working on the leaves of the tree. Might be related to OCD: I've had the disorder for a long time and I've sort of conditioned myself to avoid keeping running thoughts in memory before the "OCD daemon" distorts them into something horrible. As a result, much of my thinking is necessarily spontaneous and intuitive, or at the very least wordless.
That's actually how I got into that mode too. I picked up Phaser.js and started making something and quickly realized that games give the opportunity for states to change very quickly and often in unpredictable manners especially compared to CRUD or web apps. It's not as easily defined, so you kind of are forced to hold it all in your mind to understand the ramifications of some code you're running. Especially when that code can run 60 times per second, constantly, if you put it in the update loop.
Plus testing is not just running RSpec, you have to play the game, play it a ton, play it in stupid and unpredictable ways, and when something breaks try to figure out where it broke. So you have to hold that code in your mind the entire time you're playing, too, to keep an idea of what methods are triggering at any moment.
Games are an amazing way of forcing you to "see the Matrix" and read the code in your mind as it runs in real time.
I also don't relate to programmers who write about their mental castles that evaporate with a tap on the shoulder.
Frankly it sounds to me like people are doing it wrong. When I have a castle to build, I:
* sketch out broad strokes on a whiteboard
* write stubs and placeholder in code and see how it all connects
* brutally refactor and iterate
The last part is key. I may refactor and reorganize my architecture a dozen times before I'm done, including going back to earlier discarded ideas that seemed subpar at the time (either because of new developments/additions, or because alternatives turned out to be much worse).
If I get distracted, there is few artifacts or mental state that is lost.
That's a good practice, but it's more orthogonal to the concept of flow than you think. I do basically the same thing when I design new components or systems, but I'm very much in a flow state while doing so.
It's all about the narrative in your head, the running thoughts as you say. Thinking back to my first years progressing in system design and architecture, I would lose myself for hours in these day dreams of code and relations and practical uses; being in this interconnected mental place so often creates familiarity, this mental castle product. But yes you get lost there and face a lot of your own fears too.
I don't think I've ever experienced anything like this. As I practice TDD, my usual workflow is think -> test -> code, code usually being the easiest part. Things like "problems break down instantly", "everything becomes effortless" sound strange and exciting. I wonder how that relates to the concepts of maintainability, cowboy programming and 10x engineer.
I've met a few programmers in my career who were able to write a huge amount of code doing wonderful things without testing at all. One guy I think of would spend days coding without even trying to compile his code and apparently, except for minor typos he could quickly fix, his code was working when he decided to compile and test it. He impressed bosses and colleagues with amazing features developed in a very short time but, on the other hand, nobody on the team was able to maintain his code. This was explicitly stated and accepted by team members, we knew we couldn't maintain his code but we were ready to accept it given the productivity of the guy. It was a trade-off.
This way of working is completely alien to me. I can't think things in my head out of nothing and write working code. I need to start building something and get feedback from the computer to go to the next step. That's why when I was introduced to TDD it immediately made a lot of sense to me. It matched the way I was already operating. If I didn't have this workflow I think I would be unable to write even mildly complex code.
It's interesting how people can operate differently. In a way I'm a bit jealous of those "zone" programmers who can produce amazing things very quickly. But, on the other hand, I can see that I'm also useful because companies hire me and want to keep me. I've seen many times people taking over my code, maintain it and develop it further. I've even been explicitly told a few times that my code was very easy to understand and maintain. Seeing people taking over my code and develop it further is one of the most satisfying things in my work.
Interesting point re the zone-programming and being a cowboy programmer.
I don't think that 'in the zone'-programming has to produce bad code, though (if that's what you are saying). I'd argue that it depends on what gives you a reward. If you take pride in your code then you will find it rewarding to write tests and decent comments etc., and more importantly make a habit of doing so.
A lot of people who write bad code think that they can get away with it because they are 'smart'. These same people then spend a ton of time trying to find bugs.
It sounds like your colleague is 'finishing' features by accumulating tech debt. While this may impress non-technical management, from my experience, it wouldn't make it into a high-quality production code base.
From people I've worked with, it seems like most people go through phases of extreme productivity ('being in the zone'). The code quality may suffer somewhat during those times, but they don't throw all good practice out of the window (not compiling for days, no tests?!?).
I'm one of the coders who will sit down for hours without compiling and end up with working code (doing it right now, I've got a new algorithm which I couldn't wait until Monday to dig into). But there's a process of preparation leading up to that point.
First step usually involves a whiteboard and/or pen-and-paper notes for developing the overall design, data structures and algorithms. Then I'll use hierarchical note taking to sketch out the data structures and algorithms in what amounts to pseudo-code. During that step, I'm constantly looking through any existing source code and repeatedly iterating to make sure all cases are handled.
Then the fun part of walking through those notes and coding out each individual step one by one. That will typically take anywhere from 2-8 hours without touching the compiler (though sometimes, if the changes are incremental, I'll compile occasionally to check for typos). I'll queue up a few albums and/or mixes to help focus and just sort of disappear from the rest of the world.
I do this process in code, actually, by using a somethat TDD-like methodology of "scoping" through the levels of code, where I flesh out the function signatures of all the classes, write the high level stuff like how these classes are coupled (and discover I missed some passing of objcts/values/data/control flow) and then the rest is just typing. In almost all of these cases there is a lot of thinking involved before typing ANYTHING where I take 2 or 3 days after first looking at the problem to think about different aspects of the problem and that sub-problems they might have.
I'm at the opposite extreme: I code in Lisp, so design and coding are interleaved with a cycle time measured in minutes or seconds. The compiler is my collaborator throughout, checking my work at every step.
I tend to agree. The times where I've felt "in the zone" have exclusively been in hackathons and school projects. Even when I worked at an early stage startup, I spent most of my time discussing architecture and design patterns. Plus, code reviews need to be less than 500 lines, which lends itself to getting small thought out pieces working and shipped, not long coding sessions.
I used to work like this, and the reason I was productive is I didn't write tests nor did I have to wait around for the compiler to run every few steps. Being able to visualise the result for your code is something that comes with experience, and usually on the web this is a lot easier when you're applying the same ~10 concepts over and over.
But in a team, I would much rather have someone practice TDD than be perceived as more productive. Your code will stand the test of time and be easier for others to work with, which will cost less down the line (maintainability cost + fixing bugs cost, inevitable and a huge time sink without tests). I am now trying to think in a TDD manner and it's frustratingly slower, but ultimately a lot less stressful when I have something I can point to and objectively say it fits the requirements / business rules.
Writing code within a flow is a skill you could develop if you keep practising.
ttd forces you into a pattern where your brain doesn't have to think for itself and waits for the computer to tell you if what you did was right.
ttd provides good training wheels. I think it works best when someone else has defined the requirements but is not the best choice if the requirements will continue to change or if people are not exactly sure of the outcome before the code writing starts.
> I've met a few programmers in my career who were able to write a huge amount of code doing wonderful things without testing at all. One guy I think of would spend days coding without even trying to compile his code and apparently, except for minor typos he could quickly fix, his code was working when he decided to compile and test it.
A variation of this can be interesting to do as an exercise (in my case, a single-program exercise in school). Keep your problem simple, maybe data parsing or the like. Being in a really bad mood when you start can help.
Cowboy code. Compile. Test. At any failure, delete everything and start fresh.
By the time you code a first-time-working copy you'll probably have dropped a huge amount of unnecessary junk from your code, possibly changed approaches multiple times, and maybe found some patterns in your coding that you'd like to do away with. Nuking those code files can be surprisingly cathartic as well.
Not sure how this would really go in a modern IDE or code editor though....
I do that thing, where I just start coding from scratch.
Example:
When programming in haskell, I just write the types (not always) and undefined most things and only then I start implementing. Whenever I make a new function, it gets composed by a bunch of other functions that are not yet implemented (undefined's) and eventually this converges.
Refactoring is then based on equality principles in my head. Yeah, it fails sometimes, but that's why pure functions and type safety feels so important sometimes.
For Powershell, I made a few functions to automate the process. I have:
* New-ModuleFile to create a new module file.
* Insert-TextIntoFile gives a way to specify New-Function, New-Parameter, and any other Powershell function or Cmdlet parenthetically, so adding a function to a module file is a one-liner. I use the alias "instxt".
* New-Function provides the function punctuation and my closing flags.
* New-FunctionStatement (alias NFS) helps lay out any conditional function, including placing punctuation (brackets) and closing flags.
- Instead of typing all the brackets and parenthesis and variable names, I can type "nfs if text -scriptblock '$text' -else '"No Text"'"
* New-Parameter helps you specify Parameters and their numerous variables, such as Type, Mandatory, Position in the arguments list, Validate-Set List, and From Pipeline.
- Pipeline is a Powershell way of chaining Foreach in an ad-hoc fashion.
* Get-History returns previous commands as objects; these go nicely into "instxt".
- A common workflow is to create the function in the "instxt" statement, and have New-Parameter and Get-History as arguments.
- This way, a previously-tested function can be dropped straight into a module as a new function, with parameters already set up. From there, the module can be simply reloaded, and that function used as any loaded function.
The agility this gives is almost indescribable, and I wish I had a better way to demonstrate. Suggestions?
I'm trying my hand at programming and I'm surprised at my progress so far.
But as a person who is very unfocused and poor at math programming has got to be the worst thing on earth for me. But I like it, and math.
As with anything learning to focus takes effort it's different for each person. But a clean desk, calm environment, goals, lots of sleep, eat well and I find post exercise all helps. Not just learning to program but any task.
Good luck ever getting in the zone if you do anything with modern blockchains (especially Ethereum.) All of the documentation is terrible and you waste hours trying to find a bug only to realise it was a problem with the library all along... Assuming of course: that you don't give up after seeing the "developer tools." What little tools you have for solving problems feels like you're trying to carve a delicate ice statue with a giant hammer while wearing clown gloves.
How do you deal with the related stress of having to struggle against needlessly difficult tools, libraries, documentation, and bugs caused by other people?
Most of the time I've found no one intended for the tooling to be difficult to use, it's just that they didn't know any better or haven't had time to fix it. Those are still early alpha projects so the creators are probably more focused on the core product than the tooling around it.
Follow the boy scouts rule: leave documentation and code in a better state than you found it. If enough of us do that it'll naturally get better over time.
Oh yeah, here comes the zone, here comes the zone, it's taken an hour of intense study of all this code but now I can see all the pieces at once inside my head and I can feel exactly how to thread this code right through the middle of all of it and -
COLLEAGUE LEANS OVER FROM NEARBY DESK IN OPEN OFFICE:
"Hey buddy, what's the password for the - oh no, wait I remember."
Wait, what was I doing? What's all this code on my monitors? Why was I looking at any of this?
I started using guarana tablets to help stay 'super' focused, but only when required. I find it helps me a lot with productivity, often 3+ hours of optimum output. No side effects, only other supplements I take regularly are fish oil and I dont drink coffee or energy drinks.
I get there as well, but it takes a bit. Generally, the zone hits me when I'm in crunch time and I know that I won't have any meetings for a while. My ideas all work together and if I get stuck on something, it's not long before I can figure it out. I can generally get a ton of work accomplished.
But then, someone knocks on my cube to say, "do you know where the elevators are at?"
Getting in the zone is something exhilarating for me - I experience euphoria, though I don't really notice the feeling until after it's over or if I get broken out of it.
It was actually something that as of late has started to disturb me: I notice that I live for moments like that, when I get in the zone and the whole world melts away. I feel like a junkie seeking a high, and thinking back on my youth and how destructive I was to my body and my interpersonal relationships in pursuit of "code all the time," I wonder whether that analogy is even more accurate than I'd like to believe.
I look back on my life and wonder if I've actually been a lifelong addict who is lucky enough to have a productive output of his addiction rather than a functioning member of society.
I don't know if others feel or have felt this way, or if it's just a phase that I'm going through. But these are my thoughts at the moment.
Same here.. I made a comment somewhere saying the same as you, but I feel like I'm in the middle of the thing your looking back at.
I really do feel like a junky, that has found a pile of whatever it needs and the world encourages me to get better in 'using' and keeps paying me more to get higher and higher.. it's such a strange 'unethical' feeling.. I'm programming for about 8 years now in full throttle, and it keeps feeling stranger.. I'm somehow glad others experience it also...
I'm completely opposite. I was playing chess from the childhood, and started programming only in the university. As a result, I'm addicted to chess, but not to programming. It is ridiculously hard for me to get in a zone while working, while I can play chess non-stop for hours and hours without noticing the time flying by. I'd love to reverse chess and programming....
I haven't been in the zone for months. It's mostly general dissatisfaction with my job, but it's gotten worse of late.
On an average day, there will be 4 hours of calls spread an hour or less apart for the first half of the day, with the potential for surprise calls for the rest of the day. The irony is that a lot of these calls are about why things aren't getting done.
The surprise calls are the worst. Even if I might have 2 hours of uninterupted time at the end of a day (when I am most tired and frustrated) it is impossible to get focused when there is always a looming threat of interruption. It's gotten so bad that I only get anything done late at night or over weekends, but then I am tired during weekdays and resentful that I had to throw away my freetime in order to move a project forward.
Might not help if you're stuck in an authoritarian micro managing matrix but some tactics I've found useful before.
1) Block out 3 hours in the morning and 3 in the afternoon in your calendar as busy, marked private, at slightly different times each day. If asked you can be honest, many times people will not ask and simply avoid booking.
2) Leave your least productive time of day open for 90 minutes of meetings - for me this was post lunch.
3) Always reply and ask for an agenda so you can be sure you're necessary (it's a constructive way of making the requester think twice about whether they really need a meeting).
4) Often suggest a new time that is only 30 minutes long rather than the default hour.
5) Decline politely if you are not specifically necessary (Thanks for the invite Peter, appreciate being kept informed but I don't think you need me for this and I have a conflict - no need to reschedule for me).
But mainly just look for a way to leave. That company is heading down the tubes.
I have been in a situation like that, when I worked for a company that had me managing 12 to 30 clients directly. There is a standard solution to this problem: a ticket / issue system. If clients won't use that, and you need to keep them, then hire someone to transcribe their issues into the system, and increase your prices to cover it.
The clients might find that they prefer interacting with a more business/people oriented person, rather than a stressed out INTP. That person could also help you schedule and estimate work, without needing to have programming skills themselves; another source of stress mitigated. In theory, recovering your full productivity would lead to a net increase in the value of your services, despite the expense of this new person on staff.
115 comments
[ 4.6 ms ] story [ 167 ms ] thread[0]: https://en.wikipedia.org/wiki/Flow_(psychology)
Also: "Achieving flow is often colloquially referred to as being in the zone."
So, yes, they are synonymous. :-)
The negatives are obvious; less sociable, more easily irritated, wanting to be by yourself. After you've spent a day in the zone, you're not really "party material".
The positive (apart from being very productive) is that I use it to get my negative feelings out of the way - anything that is bothering in my life is somehow gone when I am in "the zone" - it is truly a zen feeling as the author explains.
It's also important to mention that you can't force yourself to be in the zone. It comes and goes, with very little control on your behalf. People that try to force themselves in the zone by working harder, are not truly in the zone. It happens seamlessly without you even knowing or wanting it.
For instance, I'm hardly in the zone. It happens probably once every two weeks, if not less - it also depends on what I'm working on; if it's something new and exciting I'm more predisposed to get in the zone.
Being in the zone is like getting an adrenaline rush - you can force yourself to do it more often (go skydiving for instance), but if you do it too often you'll quickly drain out and not enjoy it as you used to.
As anecdata makes the data, here's mine - you have a lot of control of it.
If you can control your environment (audio, light, temperature, food, exercise, communication, interaction, ...), you can get in the zone too just by virtue of almost exclusively focusing on some type of work you get in the zone for in the first place.
Live by code, die by code.
It happens about 3-4 out of 5 times just because I real like the software I'm building or because I get thrilled about how to make something 'boring' a masterpiece to look at or even because I know there is something I don't understand.
It's almost like a drug to keep coding en digging deeper every day. To a point where I even feel somekind of a huge pressure in the middle of night to 'profit' very hard of the last minutes i' m awake.
Doesn't feel healthy anymore haha. But I just love to much somehow
I just had what I consider to be the single most productive day in the past few months, and I started it feeling like I wasn't going to get anything done. But I decided to golf a regex in our codebase and I had that feeling of motivation and jumped right into actual work.
But funnily enough I find debugging to be the most fun when I'm in the zone (assuming I know the codebase). Something about being able to get really deep into a problem and having all the tools and programs and hardware open and running and all setup correctly.
But give me something interesting - a real challenge - and I'm able to get into the zone, the hours flying by like they were minutes. My brain has to be able to fully engage with the problem to hit that zone.
Of course, I'm a technical lead in my group, so the ability to control my environment is limited. So I get up absurdly early just to get work done before I have to be available to be interrupted.
Or negociated a higher pay, so it becomes non viable financially for the employer to use me as a resource to do the routine stuff. This doesn't apply to code reviews though.
adderall
But then it's done. And then you forget all the mass information you absorbed and shat out onto a page.
I feel exactly the same way when I'm white water kayaking. As you are reading the water and choosing your line and focusing on executing it, everything else in life falls away. You almost can't be distracted. The interesting thing is that at the end of a run, I never feel mentally exhausted despite all the intense focus, only physically drained. Of course, ymmv.
For me, this is skiing. Complete focus and attention on the task at hand. Winter, come soon.
Really disagree here, I find it's the total opposite more like a serenity and calmness. I also can get into it easily enough if I sit down with a plan of action and am not just writing code blindly and getting frustrated. If I find I can't enter the 'zone', it's usually because of some distraction (meeting coming up, feeling ill, not happy with the work, noisy open office work environment etc).
> if you do it too often you'll quickly drain out and not enjoy it as you used to.
Somewhat agree, but I think you mean here that you spend too much time in front of the PC and not enough time tending to your other needs? In which case I definitely agree; I notice a marked increase in productivity if I make sure to exercise routinely in my week, go on social events etc
I also find the zone happens a lot less often doing web dev than it ever did when I did desktop development, the constant scope switches combined with a massive surface means I drop out a lot more often.
That hits close to home. Ive thought about this a bunch and it feels as though setting up the mental context of programming, the implicit model I have of how a programs operates and what is happening, is an expensive process. I do wonder what exactly is being depleted in this process - glucose? Neurotransmitters? And whether it'd be possible to supplement this such that I minimize the cost of such operations.
However I can't have folk music, as I stumble across a great tune too often and get up to play it instead :)
It is much easier to stay in the zone when there's a physical barrier between you and other people. Even so much as being asked if you want a cup of tea is enough to pull you out of it. I recently asked my boss to stop other people from phoning me if they want me to be productive, and that really helped. I don't think most people understand what it's like; that amazing feeling you get when you're in the zone when programming, and it can be difficult getting them to understand why it's so frustrating being pulled out of it when a simple message would have sufficed.
Its a wonderful feeling, its like the fog in my mind has been lifted.
It's cool, but you can see the downsides. A few weeks ago I basically disappeared for a few days writing some code. Great fun for me, but not exactly boosting growth opportunities for the team.
Sometimes i'm more quiet the entire evening and sometimes it's easier. In my mind, i'm constantly thinking about code then and it's hard to be social then.
All arround, i'm a very social guy. Just when i leave the zone, i'm not.
Cook Ting was cutting up an ox for Lord Wen-hui. As every touch of his hand, every heave of his shoulder, every move of his feet, every thrust of his knee — zip! zoop! He slithered the knife along with a zing, and all was in perfect rhythm, as though he were performing the dance of the Mulberry Grove or keeping time to the Ching-shou music.
“Ah, this is marvelous!” said Lord Wen-hui. “Imagine skill reaching such heights!”
Cook Ting laid down his knife and replied, “What I care about is the Way, which goes beyond skill. When I first began cutting up oxen, all I could see was the ox itself. After three years I no longer saw the whole ox. And now — now I go at it by spirit and don’t look with my eyes. Perception and understanding have come to a stop and spirit moves where it wants. I go along with the natural makeup, strike in the big hollows, guide the knife through the big openings, and following things as they are. So I never touch the smallest ligament or tendon, much less a main joint.
“A good cook changes his knife once a year — because he cuts. A mediocre cook changes his knife once a month — because he hacks. I’ve had this knife of mine for nineteen years and I’ve cut up thousands of oxen with it, and yet the blade is as good as though it had just come from the grindstone. There are spaces between the joints, and the blade of the knife has really no thickness. If you insert what has no thickness into such spaces, then there’s plenty of room — more than enough for the blade to play about it. That’s why after nineteen years the blade of my knife is still as good as when it first came from the grindstone.
“However, whenever I come to a complicated place, I size up the difficulties, tell myself to watch out and be careful, keep my eyes on what I’m doing, work very slowly, and move the knife with the greatest subtlety, until — flop! the whole thing comes apart like a clod of earth crumbling to the ground. I stand there holding the knife and look all around me, completely satisfied and reluctant to move on, and then I wipe off the knife and put it away.”
“Excellent!” said Lord Wen-hui. “I have heard the words of Cook Ting and learned how to care for life!”
Translated by Burton Watson (Chuang Tzu: The Basic Writings, 1964)
http://www.bopsecrets.org/gateway/passages/chuang-tzu.htm
The Tao of Programming [1] 4.4
Prince Wang's programmer was coding software. His fingers danced upon the keyboard. The program compiled without and error message, and the program ran like a gentle wind.
"Excellent!" the Prince exclaimed. "Your technique is faultless!"
"Technique?" said the programmer, turning from his terminal, "What I follow is Tao -- beyond all techniques! When I first began to program, I would see before me the whole problem in one mass. After three years, I no longer saw this mass. Instead, I used subroutines. But now I see nothing. My whole being exists in a formless void. My senses are idle. My spirit, free to work without a plan, follows its own instinct. In short, my program writes itself. True, sometimes there are difficult problems. I see them coming, I slow down, I watch silently. Then I change a single line of code and the difficulties vanish like puffs of idle smoke. I then compile the program. I sit still and let the joy of the work fill my being. I close my eyes for a moment and then log off."
Prince Wang said, "Would that all of my programmers were as wise!"
[1] The Tao of Programming http://www.mit.edu/~xela/tao.html
I did enjoy the story though.
Yeah, because everyone knows that you have to pay less wages when you have two people do the job of one.
If you think pair programming is a good idea you are just at the bottom of the industry.
Can I come live in this fantasy world you found yourself in please? You're gonna need to provide some SERIOUS proof for a claim like that...
I often see programmers on HN talk about building mental castles of their programs, but I feel like I don't really code the same way. Instead, my thinking seems more "functional". For a given problem, I can often make out the faint outline of an optimal solution, but there's a lot of cruft and misplaced bits in the way. Most of my work involves mentally simulating the consequences of different options and then bending the architecture into such a shape that the whole thing just sort of assembles on its own. I'm only "in the zone" when I have to make that final leap. There's very little castle-building along the way.
As a result, I feel like I'm somewhat incapable of working on massive, multi-part architectures, since I just can't see the running state in my head. Once I zoom in to work on a single component, the rest fade from memory and I lose the big picture. On the other hand, I have no problem working in open-office environments: I don't mentally deal with a lot of program state, so I'm able to just dive right back in. This also influences my code to be more functional, as I know I can rely on e.g. idempotent methods to keep doing what they're supposed to regardless of any finicky global state.
I wish I could get better at building those "mental castles" since it's a huge barrier to designing complex architectures (like games). I don't want to be stuck forever working on the leaves of the tree. Might be related to OCD: I've had the disorder for a long time and I've sort of conditioned myself to avoid keeping running thoughts in memory before the "OCD daemon" distorts them into something horrible. As a result, much of my thinking is necessarily spontaneous and intuitive, or at the very least wordless.
Can anyone else relate?
> I wish I could get better at building those "mental castles" since it's a huge barrier to working on complex architectures like as games.
If you truly wish to do so - go make technically challenging systems like games. From start to end. Solo.
Plus testing is not just running RSpec, you have to play the game, play it a ton, play it in stupid and unpredictable ways, and when something breaks try to figure out where it broke. So you have to hold that code in your mind the entire time you're playing, too, to keep an idea of what methods are triggering at any moment.
Games are an amazing way of forcing you to "see the Matrix" and read the code in your mind as it runs in real time.
Frankly it sounds to me like people are doing it wrong. When I have a castle to build, I:
* sketch out broad strokes on a whiteboard * write stubs and placeholder in code and see how it all connects * brutally refactor and iterate
The last part is key. I may refactor and reorganize my architecture a dozen times before I'm done, including going back to earlier discarded ideas that seemed subpar at the time (either because of new developments/additions, or because alternatives turned out to be much worse).
If I get distracted, there is few artifacts or mental state that is lost.
I've met a few programmers in my career who were able to write a huge amount of code doing wonderful things without testing at all. One guy I think of would spend days coding without even trying to compile his code and apparently, except for minor typos he could quickly fix, his code was working when he decided to compile and test it. He impressed bosses and colleagues with amazing features developed in a very short time but, on the other hand, nobody on the team was able to maintain his code. This was explicitly stated and accepted by team members, we knew we couldn't maintain his code but we were ready to accept it given the productivity of the guy. It was a trade-off.
This way of working is completely alien to me. I can't think things in my head out of nothing and write working code. I need to start building something and get feedback from the computer to go to the next step. That's why when I was introduced to TDD it immediately made a lot of sense to me. It matched the way I was already operating. If I didn't have this workflow I think I would be unable to write even mildly complex code.
It's interesting how people can operate differently. In a way I'm a bit jealous of those "zone" programmers who can produce amazing things very quickly. But, on the other hand, I can see that I'm also useful because companies hire me and want to keep me. I've seen many times people taking over my code, maintain it and develop it further. I've even been explicitly told a few times that my code was very easy to understand and maintain. Seeing people taking over my code and develop it further is one of the most satisfying things in my work.
I don't think that 'in the zone'-programming has to produce bad code, though (if that's what you are saying). I'd argue that it depends on what gives you a reward. If you take pride in your code then you will find it rewarding to write tests and decent comments etc., and more importantly make a habit of doing so. A lot of people who write bad code think that they can get away with it because they are 'smart'. These same people then spend a ton of time trying to find bugs.
It sounds like your colleague is 'finishing' features by accumulating tech debt. While this may impress non-technical management, from my experience, it wouldn't make it into a high-quality production code base.
From people I've worked with, it seems like most people go through phases of extreme productivity ('being in the zone'). The code quality may suffer somewhat during those times, but they don't throw all good practice out of the window (not compiling for days, no tests?!?).
i don't think that being high productivity prevents you from writing unit tests or doing tdd. you just do tdd with higher productivity.
First step usually involves a whiteboard and/or pen-and-paper notes for developing the overall design, data structures and algorithms. Then I'll use hierarchical note taking to sketch out the data structures and algorithms in what amounts to pseudo-code. During that step, I'm constantly looking through any existing source code and repeatedly iterating to make sure all cases are handled.
Then the fun part of walking through those notes and coding out each individual step one by one. That will typically take anywhere from 2-8 hours without touching the compiler (though sometimes, if the changes are incremental, I'll compile occasionally to check for typos). I'll queue up a few albums and/or mixes to help focus and just sort of disappear from the rest of the world.
I'm at the opposite extreme: I code in Lisp, so design and coding are interleaved with a cycle time measured in minutes or seconds. The compiler is my collaborator throughout, checking my work at every step.
[UPDATE] Downvotes? Seriously? Why?
But in a team, I would much rather have someone practice TDD than be perceived as more productive. Your code will stand the test of time and be easier for others to work with, which will cost less down the line (maintainability cost + fixing bugs cost, inevitable and a huge time sink without tests). I am now trying to think in a TDD manner and it's frustratingly slower, but ultimately a lot less stressful when I have something I can point to and objectively say it fits the requirements / business rules.
ttd forces you into a pattern where your brain doesn't have to think for itself and waits for the computer to tell you if what you did was right.
ttd provides good training wheels. I think it works best when someone else has defined the requirements but is not the best choice if the requirements will continue to change or if people are not exactly sure of the outcome before the code writing starts.
A variation of this can be interesting to do as an exercise (in my case, a single-program exercise in school). Keep your problem simple, maybe data parsing or the like. Being in a really bad mood when you start can help.
Cowboy code. Compile. Test. At any failure, delete everything and start fresh.
By the time you code a first-time-working copy you'll probably have dropped a huge amount of unnecessary junk from your code, possibly changed approaches multiple times, and maybe found some patterns in your coding that you'd like to do away with. Nuking those code files can be surprisingly cathartic as well.
Not sure how this would really go in a modern IDE or code editor though....
Example: When programming in haskell, I just write the types (not always) and undefined most things and only then I start implementing. Whenever I make a new function, it gets composed by a bunch of other functions that are not yet implemented (undefined's) and eventually this converges.
Refactoring is then based on equality principles in my head. Yeah, it fails sometimes, but that's why pure functions and type safety feels so important sometimes.
* New-ModuleFile to create a new module file.
* Insert-TextIntoFile gives a way to specify New-Function, New-Parameter, and any other Powershell function or Cmdlet parenthetically, so adding a function to a module file is a one-liner. I use the alias "instxt".
* New-Function provides the function punctuation and my closing flags.
* New-FunctionStatement (alias NFS) helps lay out any conditional function, including placing punctuation (brackets) and closing flags.
- Instead of typing all the brackets and parenthesis and variable names, I can type "nfs if text -scriptblock '$text' -else '"No Text"'"
* New-Parameter helps you specify Parameters and their numerous variables, such as Type, Mandatory, Position in the arguments list, Validate-Set List, and From Pipeline.
- Pipeline is a Powershell way of chaining Foreach in an ad-hoc fashion.
* Get-History returns previous commands as objects; these go nicely into "instxt".
- A common workflow is to create the function in the "instxt" statement, and have New-Parameter and Get-History as arguments.
- This way, a previously-tested function can be dropped straight into a module as a new function, with parameters already set up. From there, the module can be simply reloaded, and that function used as any loaded function.
The agility this gives is almost indescribable, and I wish I had a better way to demonstrate. Suggestions?
But as a person who is very unfocused and poor at math programming has got to be the worst thing on earth for me. But I like it, and math.
As with anything learning to focus takes effort it's different for each person. But a clean desk, calm environment, goals, lots of sleep, eat well and I find post exercise all helps. Not just learning to program but any task.
How do you deal with the related stress of having to struggle against needlessly difficult tools, libraries, documentation, and bugs caused by other people?
Follow the boy scouts rule: leave documentation and code in a better state than you found it. If enough of us do that it'll naturally get better over time.
"Half as long" writing lesson from "A River Runs Through It" https://www.youtube.com/watch?v=7vRhOdf-6co
COLLEAGUE LEANS OVER FROM NEARBY DESK IN OPEN OFFICE: "Hey buddy, what's the password for the - oh no, wait I remember."
Wait, what was I doing? What's all this code on my monitors? Why was I looking at any of this?
But then, someone knocks on my cube to say, "do you know where the elevators are at?"
It was actually something that as of late has started to disturb me: I notice that I live for moments like that, when I get in the zone and the whole world melts away. I feel like a junkie seeking a high, and thinking back on my youth and how destructive I was to my body and my interpersonal relationships in pursuit of "code all the time," I wonder whether that analogy is even more accurate than I'd like to believe.
I look back on my life and wonder if I've actually been a lifelong addict who is lucky enough to have a productive output of his addiction rather than a functioning member of society.
I don't know if others feel or have felt this way, or if it's just a phase that I'm going through. But these are my thoughts at the moment.
I really do feel like a junky, that has found a pile of whatever it needs and the world encourages me to get better in 'using' and keeps paying me more to get higher and higher.. it's such a strange 'unethical' feeling.. I'm programming for about 8 years now in full throttle, and it keeps feeling stranger.. I'm somehow glad others experience it also...
http://archive.oreilly.com/pub/a/oreilly/news/zenclavier_129...
On an average day, there will be 4 hours of calls spread an hour or less apart for the first half of the day, with the potential for surprise calls for the rest of the day. The irony is that a lot of these calls are about why things aren't getting done.
The surprise calls are the worst. Even if I might have 2 hours of uninterupted time at the end of a day (when I am most tired and frustrated) it is impossible to get focused when there is always a looming threat of interruption. It's gotten so bad that I only get anything done late at night or over weekends, but then I am tired during weekdays and resentful that I had to throw away my freetime in order to move a project forward.
1) Block out 3 hours in the morning and 3 in the afternoon in your calendar as busy, marked private, at slightly different times each day. If asked you can be honest, many times people will not ask and simply avoid booking.
2) Leave your least productive time of day open for 90 minutes of meetings - for me this was post lunch.
3) Always reply and ask for an agenda so you can be sure you're necessary (it's a constructive way of making the requester think twice about whether they really need a meeting).
4) Often suggest a new time that is only 30 minutes long rather than the default hour.
5) Decline politely if you are not specifically necessary (Thanks for the invite Peter, appreciate being kept informed but I don't think you need me for this and I have a conflict - no need to reschedule for me).
But mainly just look for a way to leave. That company is heading down the tubes.
The clients might find that they prefer interacting with a more business/people oriented person, rather than a stressed out INTP. That person could also help you schedule and estimate work, without needing to have programming skills themselves; another source of stress mitigated. In theory, recovering your full productivity would lead to a net increase in the value of your services, despite the expense of this new person on staff.