What it feels like to be in the zone as a programmer
dopeboy.github.io
dopeboy.github.io
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.
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.
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.
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
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.
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?
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 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.
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.
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.
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?
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?!?).
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....
* 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 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.
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.
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 don't think that being high productivity prevents you from writing unit tests or doing tdd. you just do tdd with higher productivity.
The game was simple: there's a silo on the screen with a hot air balloon on the left side. When I get into 'the zone', the balloon goes up and around the silo. This will loop for as long as I can hold it.
It took about two sessions with minor success, then suddenly it clicked. Now I can easily enter that state on demand.
This might sound odd, but the neurotherapy helped eliminate a lot of the negative parts of ADHD without losing the edge that a lot of medications take away. I still have a lot of energy, but I can always sit and focus on the task at hand when I need to.
[1] http://www.swingleclinic.com/about/how-does-neurotherapy-wor...
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)
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.
This got to be common enough that someone made a clock, where you could move the hands, it said "Larry will be in here" and stuck it on my door. I think it was sort of a joke but I think some people actually used it.
I couldn't come close to doing anything like that now. And at 55 years old, I can tell you that the days where you get in the zone, for me at least, are few and far between. I used to be able to just go there, now it sort of happens to me and I have to drop everything else and ride it before it fades away.
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 typically stub out a bunch of tests (just empty methods named based on what I plan to test), then go one by one and fill in the tests and write the implementations.
In the codebase I work in, we use a lot of mocks / fakes, so I typically write my tests "in reverse" - first the verification of results, then the mock / fake expectations for what methods should have been called. Then I'll write the actual implementation, and then fill in the mock inputs.
This way, if I get interrupted, it's very easy to transition back into what I was working on, as I make sure to always leave a breadcrumb trail for the next piece (when I run my test, the failure will give me a hint as to the next step to take). And since I have a bunch of stubbed out test methods, once one bit is finished, I can move onto the next one and repeat the process.
I don't know why the idea of TDD sounds so terrible to me but it does.
For example: the past 3 weeks I've been pounding out tons of code in a TDD fashion. But prior to that:
* I spent a week writing up a detailed design document and getting feedback from teammates and stakeholders.
* Another week refactoring (TRULY refactoring; no changes to functionality) the existing implementation so I can reuse the existing work in my new implementation.
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...
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?
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...
While it may not be my most economically productive part of the day (aka I'm not working on the hard, important problems) there's no doubt that for the 10-15 minutes one of those menial tasks requires, I'm in that special state.
An environmental trigger for me is to play familiar music. It doesn't have to be a special playlist; any album I've listened to >50 times will suffice.
Remaining in the zone requires incremental progress (momentum) which I think is easy to find in a boring, repetitive task that's squarely in your wheelhouse.
The real productivity sweet spot is when you're able to get that momentum going on a valuable project.
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.
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 married people or those with kids balance such bursts of creativity with personal commitments to their family ?
When they are older I plan to teach them useful complimentary skills. Graphics design. Testing. Copywriting. Marketing. Sales. :-)
That's not what most people mean when they say "growing a company."
"Half as long" writing lesson from "A River Runs Through It" https://www.youtube.com/watch?v=7vRhOdf-6co
a) You have to be interested and eager to get started. If you're not happy with the project, if anything else going on in your life is taking your attention, you will not experience it.
b) When you experience it, you feel like you're a 'real' engineer, like that is your true identity now, your imposter syndrome disappears. So ultimately, if you don't identify as a programmer, as opposed to identifying as someone who programs because it pays well or view it as just a temporary phase of your career until you do management or become a startup CEO or something, you may never experience it.
c) After you experience it, your brain goes "whoaaa" and needs to recover. You won't be able to experience it for at least another 2-3 days, in my experience.
I shared it with my significant other, in order for her to better understand the grumpy responses she sometimes gets when asking seemingly innocuous questions like "would you like some tea?"
Also: "Achieving flow is often colloquially referred to as being in the zone."
So, yes, they are synonymous. :-)
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.
But then, someone knocks on my cube to say, "do you know where the elevators are at?"
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.
http://archive.oreilly.com/pub/a/oreilly/news/zenclavier_129...
Its a wonderful feeling, its like the fog in my mind has been lifted.
Edit: but it's okay if it's a prototype