I believe everyone is familiar with the concept of being “in the zone”, I.E. that state you attain when you’re so intensely focused on something that time becomes irrelevant and all you’re focused on is achieving some certain goal. I personally find myself in this state quite often usually when I’m writing here, gaming or programming. Whilst I knew it was a common phenomenon I only learnt recently that its also recognised as a part of psychology, where they’ve termed it Flow. The concept itself is interesting an most recently I’ve started to grapple with one of the more subtle aspects, defined as point number 8 of conditions of Flow or “The activity is intrinsically rewarding, so there is an effortlessness of action”.

Now this weekend just gone past saw me back, as I almost always am, coding away on my PC. Now since I’m somewhat of a challenge junkie I’ll always seek out the novel parts of an application first rather than the rudimentary and the first day saw me implementing some new features. This always goes well and I’ll be firmly in Flow for hours at a time, effortlessly jumping through reams of documentation and masses of Google searches as I start to nail down my problem. Once the new feature is done of course then I’ll have to choose another to start work on, thereby maintaining my Flow and project progress.

However I’ve found that certain programming challenges are like kryptonite to achieving Flow. I discovered this on the second day of my weekend when I sat down to start work again, only to notice one of the tasks in my TODO list was to rework one of the earlier pages I had built to use less JavaScript and more ASP.NET Razor. The reasons behind this are simple: I’m really atrocious at JavaScript. The page in question looked good and did the job it was meant to but much of the content of the page was generated by some JavaScript code I had found on the Internet and hacked into working for me. This meant maintaining it was going to be an issue, so I set out to optimize it.

Of course the optimization process was fraught with the perils of trying to replicate into Razor what I had hacked into JavaScript with only a half understanding of what I was doing at the time. That meant untangling the mess of code that someone else had wrote and then translating that into another language that was more maintainable for someone like me. From a Flow perspective this kind of work isn’t very rewarding since I’m not going to achieve anything new and the benefits will only be realised by future me, that jerk who’s always off in some indeterminate time in the future. However the perfectionist in me knows that time saved at this point could mean multiples more saved later on, but therein lies the conundrum.

There’s a great quote by Donald Knuth (of The Art of Computer Programming fame) that says “Premature optimization is the root of all evil” which is basically a warning to avoid over optimizing your code when its still in the early stages. I’m a firm believer in the idea that you shouldn’t act like you have problems of scale until you have them but there are some fundamental differences between regular and scalable code that could prove to be incompatible with your codebase should you not make the decision early on in the piece. Of course optimization comes at the cost of progress on other pieces of work thus a balancing act between the two is required if your code is ever to see the light of day.

I guess I find it strange that optimizing my own code was so detrimental to achieving that state of coding nirvana. It’s quite possible that it was just the problem that I was working on as a previous optimization I had done, developing a cache system for a web service I was querying, seemed to have no ill effects. However that particular challenge was quite novel as I hadn’t created anything like it previously and the feedback was quite clear when I had finally achieved my goal. Unfortunately I have the feeling that most of the optimization problems will be more like the former example than this one, but so long as I write half decent code in the first place I hopefully won’t have to deal with them as much.

About the Author

David Klemke

David is an avid gamer and technology enthusiast in Australia. He got his first taste for both of those passions when his father, a radio engineer from the University of Melbourne, gave him an old DOS box to play games on.

View All Articles