How often are you in the ‘flow’?

You are coding away. A minute goes by… You check the watch, and its been two hours!

You don’t know how those two hours went by, but they were very productive. You feel good. Happy. A joy that comes of active creation.

You, my friend, were in the flow. It’s a state that is a reward in itself, a state with your highest of performance.

Given that, can we try to create conditions to get into that state as frequently as possible? What works for you? How often do you find yourself in the flow?

I find myself at my productive best when I can get at least two sessions of complete concentration in a day. These sessions don’t include checking email, or Facebook, or having design discussions or reviewing other’s work. They include working by myself, typically on a programming assignment. And often it happens when the stuff is churning in my mind for quite some time. So once I sit down, all those thoughts just spill over through the keyboard onto emacs.

What is “success” to you?

Different people, different definition.

Same person, different circumstances, different definitions.

What is success to you right now?

Work for a big label company? Create something that is highly valued/appreciated? Make a lot of money? Feel happy about what you are doing? Buy that BMW that stole your heart? Be indispensable at what you do? Be socially appreciated? Being happy?

AND, are you achieving success regularly? If you haven’t yet, is what you are doing today bringing it any closer?

It helps to revisit every once in a while.

If you do, you know what you have to do today, to reach your definition of success.

If you don’t, you keep envying others for what you don’t even want (the social perception of success).

A seed of an idea

A seed of an idea. Like many others that you thought of. But this seems different. Something interesting. Something more.

You keep thinking about it. Look at it from all the angles. It looks promising.

You discuss it. Yes, you had already thought of that angle. And you thought of it the other way too. But wait wait, you didn’t look at it in this fashion. Oh and also, how about that possibility? That is probably a better a way of approaching it. Interesting, very interesting…

Did somebody already try that? Was that a success or failure? They probably didn’t execute it right. There are many ways it could go wrong, but you, you can do right.

You build a tiny prototype. Just that core piece that is oh-so-critical. Looking good. Now that you see it work… its amazing. Didn’t think this would be an added advantage. Or is that the primary benefit? Hmm…

You know that you know a lot more about it now, than when you started. You know there is so much more.

You have a good hold of that idea now. Or probably the idea has a hold on you.

It is evolving in your sleep. It gives you sparks of brilliance at 5 in the morning. You shudder out of sleep in ecstasy. You know, you rock!

It occupies you all the time.

Breakfast, lunch, coffee or dinner.

You live the idea.

You breathe it.

The idea goes with you everywhere.

 

The idea takes you places.

Give it thought. Give it time. Give it action. Do it!

The urge to do

Programming and debugging are  activities where we should think a lot and do little. Commonly what happens is the reverse. We are driven by the urge to do something.

It's particularly true for debugging. We see a  problem, the first instinct is to print something, build and rerun. And then print some more. In the end when we discover the problem we go: Ah, that was obvious. I could have gotten there faster instead of these x iterations. And on complex systems these iterations take a long long time.

It often helps to resist the urge to do  and think what could be going off here. It saves a ton of time.

So also for programming.

A lot of programming time is spent in the edit build debug cycle. We make numerous iterations through this cycle to get to our goal. How could we optimize this? What if we are allowed only 1 iteration through this?

To ensure that I put enough thought in the process, recently I created this game for myself. After breaking the problem into subproblems I take it as a challenge that every submodule that is built will run completely in the first iteration itself. I get to decide the size of the submodule, but my code should do exactly what I intended in the first shot. Over time I have found that this leads to a lot of efficiency by forcing me to think of all the dependencies and side effects upfront.

Of course not all problems can be addressed with this method. Especially if it's a new technology or domain you learn much faster through each iteration. But for a lot of cases this approach does magic. You should try it out...