Fog Creek Software
Discussion Board




Staying focused

Unlike most of those who replied to "fire and motion," I do not find it very hard to get started after I arrive at work. Instead, I find it very easy to get distracted by my own thoughts, especially when I'm in the understanding/design phase of development (way before coding begins).

What typically happens is that my thoughts get blocked by a seemingly complex problem that I cannot even define, and for a few moments I don't know how to move forward - and instead I let "easy" thoughts distract me and I start doing unproductive things.

This can happen several times in an hour. Does anyone recognize this pattern, and if so, do you have any techniques that help you move forward and keep your thoughts focused? I have a few which sometimes work for me:

- Write down (on paper) everything you understand so far
- Make little diagrams and drawings
- Move away from the keyboard
- Reiterate. Write things down again if it wasn't clear the first time, a little tidier this time
- Discuss your thoughts with someone else (this can really help but may pull that person out of the zone)
- Go for a walk outside, look at the trees (this mainly eases the frustration when it gets really bad)

Most of these ideas seem to have to do with reinforcing what I already know and help it "sink in." What I'm missing is the link to move forward. Any ideas or comments?

Johannes Bjerregaard
Tuesday, January 08, 2002

Are you THE "Johannes Bjerregaard"

The musician on Commodore 64 which made the SID chip swing ?

FanBoy
Tuesday, January 08, 2002

Johannes

Have you ever woken up in the morning with the solution to one of the problems about which you had a block the day before ? Does the answer sometimes come to you after you've drifted off for a while ?

From my limited understanding of the brain, it is not a single processor but a very complex multi-processor machine. It does seem to have a limit to the number of threads that it can hold in the foreground, but has almost unlimited background capacity.

Unfortunately, only foreground threads have access to our I/O functions. If the old grey matter is doing it's stuff in the background, it is hard to bring it to the foreground.

Personally, I have a tendency to go with the flow and to try to temporarily forget the complex problem, concentrate on something else and wait for the Archimedes moment.

Peter WA Wood, IT Matters
Tuesday, January 08, 2002

My first step in solving complex problems is _not_ to be original. 99.9% of all problems have already been solved at least a dozen of times by somebody else. So when stuck, I search the Internet in this order:

Borland Search Engine:
http://fulltextsearch.com/search.htm

Google Web and group search:
http://www.google.com/

Most of the time, a ready to use solution shows up. Sometimes reading about related problems helps. Next options would be posting a message in the relevant Borland newsgroup.

For those few problems that persist after these searches, I often try to figure them out by drawing lots of notes and diagrams on a notepad (an dead tree version that is). Generally, the solution comes to my mind when I'm in the loo, shower or at 5am in bed, which is somewhat awkward when you want to run out to write it down.

Sometimes it also helps to discuss it with lots of beer in a pub with buddies. Be warned, other visitors might find conversations about BLOB's and sockets on the weird side.

Jan Derk
Tuesday, January 08, 2002

My first priority when working alone is to keep myself soothed (happy, comfortable, in the zone).

I like a to-do list with one or more items, and I like to know which is the top-level item (to be completed first). There are many ways to write a system (top-down, bottom-up, ...); similarly many ways to sequence a to-do list ... if every item on the list is worth doing, that gives you some choice/flexibility from moment to moment.

Sometimes, writing specs before coding is 'taking the easy route' (e.g. because early you know something about specs even if you don't yet know the code): 'do the easy part first' can be an OK way to proceed. Another way is 'do the riskiest part first', which means tackling (defining or specifying or researching) the part which is the least known or which is most likely to fail ... which is also called 'risk management'.

Sometimes the job is 'slow and simple', e.g. 'apply this refactoring', 'write down what your plan is', or 'build-install-test-release for some change' ... to avoid distraction during such a sequence, anything familiar and undemanding will suffice (e.g. a tree or window, Joel on Software, a drink).

Christopher Wells
Tuesday, January 08, 2002

Peter: "Have you ever woken up in the morning with the solution to one of the problems about which you had a block the day before ?"

- No, the situation I am trying to describe always seems to require some hard thinking on my part. Forgetting about it has never directly helped move forward.

Jan - The situation does not involve a defined technical problem. I think these problems are trivial although sometimes time consuming. Instead, it is one of concentration when understanding/designing the details of (typically) a business process that needs to be implemented. There is no code at this point. Only "stuff" inside my head that needs to get organized and get out. Although that does remind me of another technique that can be used:

- Write an email to someone describing precisely where you're stuck. (It's not necessary to send it, just write it)

Also, a TODO list, not of things that need to be implemented (which I already use them for), but of things to understand might help keep the mind focused.

Thanks for the help so far. More ideas are welcome.

Johannes Bjerregaard
Tuesday, January 08, 2002

Fanboy - yes I am the one. Those were the days weren't they.

Johannes Bjerregaard
Tuesday, January 08, 2002

Usually when this happens to me, it's because I've not broken the problem down into small enough chunks.

It may be only me, but I find that there are plenty of problems that are just too complex to hold the entire thing in my mind at once.

After I break it down into smaller chunks, then I can concentrate on just that one bit until it is done (enough) and then move on to the next piece. 

Kinda like not being able to see the trees for the forest.

Steve Barbour
Tuesday, January 08, 2002

> for a few moments I don't know how to move forward -
> and instead I let "easy" thoughts distract me and I start
> doing unproductive things

I let the easy things distract me--in fact, I keep easy things around to do just so that a mental block doesn't leave me sitting at my computer, staring at the monitor doing nothing.

When I hit that wall, I switch to some trivial task.  Once it's done, I go back and try again.  If I'm still blocked, I knock off a few more easy jobs, and return.  Repeat until the block is gone.

This almost always works for me after finishing one or two easy tasks, as if the simple task of switching and returning is enough to clear the short circuit.  At the very least, I return with a clear head, which is usually enough since I got blocked in the first place by locking my mind around a particular problem and got stuck.

When we could take cigarette breaks at our discretion, I used to go have a smoke.  Before I was halfway through the cigarette, I'd figured out an answer (not _the_ answer, but an answer), and was right back at my desk moving forward.

Justin Johnson
Tuesday, January 08, 2002

Again, from Zen and the Art of Motorcycle Maintenance. there are an infinite number of hypotheses.

Finding a new one when you are stumped though usually requires you to think at a smaller scale than you were or at a larger scale.  Painstakingly narrowing in on the line of code, the Newton-Raphson  method of debugging; or lying back and considering the ebb and flow of the interconnected processes wandering the tree, debugging from the point of view of God.

Hmmm, there's a novel in this somewhere...

Simon Lucy
Thursday, January 10, 2002

Johannes,

Loved Speical Agent and Stormlord.

I still have them on my Sidplay playlist, which I listen to help me stay in the zone.

Ged Byrne
Thursday, January 10, 2002

*  Recent Topics

*  Fog Creek Home