http://www.perlmonks.org?node_id=253984

Eureka!! eureka!! Archimedes shouts in streets of Syracuse ....

May be that was a big discovery for archimedes. Sometime you stuble upon piece of code or design or any other task. You don't have any idea how to get it working. Yet it works finally.
May be It doesn't work because you are tired or overloaded. Sometime you even forget to consult your immedidate resources and dont' know where to go... and something clicks.

How do you do it / What does it?

May be you have defined regular methods as what to do when it doesn't work. May be you trust some place/instinct/event/time/people that will make this thing working. When your most moments of 'Aha!' comes?

Do you make active use of these 'events'? What are they and how do you make use of it ?. The approach you take depends on lots of things. Your surrounding, status, power, problem understanding, knoledge, instinct etc.. These tips can play a good part to reduce occcasional stumbling

Few things that comes to my mind. Not in any particular order.

artist

Replies are listed 'Best First'.
Re: Eureka!
by cacharbe (Curate) on Apr 29, 2003 at 16:57 UTC

    "The most exciting phrase to hear in science, the one that heralds the most discoveries, is not 'Eureka!' (I found it!) but 'That's funny....'"
    --Isaac Asimov

    I usually step away from it for the rest of the day, head to the gym or run, and then set my mind clearly and focused on the problem before I go to sleep that night. I usually wake up with a solution, and if not, at least with a clearer understanding and a path to head down.

    Many times it just takes talking about it with someone else and forcing other parts of my brain into the mix, taking the pressure off of the cognitive problem solving portion for just a moment. The act of articulation solved a gnarly bug for me yesterday, after I had already practiced the steps mentioned above. I was still stumped when I got to work. I started talking about it to someone else, had an idea, wrote a line of code, saw something I didn't expect ("Now that's funny") which lead me to the true problem and to the solution.

    The brain works in mysterious ways.

    C-.

    ---
    Flex the Geek

Re: Eureka!
by BrowserUk (Patriarch) on Apr 29, 2003 at 23:37 UTC

    As many others have said, getting away from the keyboard, white board, design/requirement documents and doing something completly different is usually the surest way of acheiving breakthroughs when I get stuck when analysing a problem or coding the solution.

    However, I noticed a long time ago that when the Eureka moments occur, that whatever else I am involved at the time usually has a non-obvious bearing upon the problem. The inspiration often comes from seeing or using a manual or natural mechanism that is in some way analogous to the problem I am trying to solve. Good examples are hard to describe, but a trivial one I remember was the first time I really understood the the bi-directional version of the bubble sort was when I de-shuffled a pack of playing cards in a pub to check they were all there. The pack was made up from bits of several different packs, so a simple count wasn't enough.

    Since then, I have actively sought out non-computerised analogies to intractable problems. Sometimes I find something directly analogous and it helps by allowing me to observe the individual steps involved, but this is rare. More often, the link or analogy is considerably more tenuous. I once took inspiration for a date parsing routine designed to handle multiple input formats from a pin-ball machine. You know those sections where you have to knock down all of a set of pop ups in any order to get the bonus points. Originally, I tried to code (in C) a routine to look for each of the possible formats in each of the possible orders. The inspiration was to scan the string linearly, compare what I found against each of the bits I was looking for: Does it look like a year, if so, knock down the flag; does it look like a month, knock down the flag. If the flag is already down, I've got a problem. Are all the flags down, Im finished. This meant that in most cases, I made a single pass to find the date, rather than the multiple passes required by the "Is it in this format? Or this? Or this?".

    In reality, I don't actually have to find an anology, the process of looking for the anology is often enough. The very act of looking at an unrelated process and trying to map it to the problem often has two beneficial side effects.

    • It stops you thinking about the problem directly, whilst still keeping the problem in background.
    • It has a tendancy to re-order your priorities and assumptions.

    Traffic lights make a good analogy for bi-directional semaphores in multi-threaded and multi-process control.

    The take-a-number queueing and priority system in post offices and deli-counters makes a good analogy for the 'pool' model of using threads and processes.

    Take a look at the way the trunks, branches, twigs and stems of a tree grow to get a good insight into the working of the Mandlebrot sets.

    Many of my flashes of inspiration come from looking for a good analogy, regardless of whether I find one or not. It helps if you have a good familiarity with an industry or field outside of computing I think. In my case, having worked in the auto industry, I find many anologies there that inspire solutions in my code, but I worked with guy a few years ago that found all sorts of inspired solutions in music, both the notations used and the order therein.

    Try it next time you get stuck with your code, it might work for you too:)


    Examine what is said, not who speaks.
    1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
    2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
    3) Any sufficiently advanced technology is indistinguishable from magic.
    Arthur C. Clarke.
Re: Eureka!
by AssFace (Pilgrim) on Apr 29, 2003 at 16:04 UTC
    Without a doubt, pretty much every single one of my "Eureka" moments has come from one of the following:
    1) The shower
    2) The toilet
    3) A long run
    4) Sleeping
    5) Heavy drinking (alcohol)

    Every single one of those is a result of relaxing and letting my conscious mind drop the problem and let the rest of my brain toss it around.
    (number 5 happens a lot less in programming for me - esp since I rarely drink now - but it was big in college when I was working on architecture projects and had been up for some time. the two downsides to #5 are that if you aren't near your project, you aren't likely to remember the Eureka, and also that it might seem like a great idea, but is actually alcohol induced junk - and I suppose the same could be said of other mind altering substances)

    -------------------------------------------------------------------
    There are some odd things afoot now, in the Villa Straylight.

      There's a charming children's book series called "the Great Brain," where a boy in the early 1900s recounts the amazing mental feats of his unusual older brother.

      The older brother had a strategy for the tough problems: he'd think about the question just before going to sleep, to engage his subconscious. It always worked for him. It's often worked for me, too.

      Step away from the problem. Walk to the vending machine, to the parking lot, to the corner market, or just sit on the couch at home for a little while. No paper, no pen, no books. Just let your brain cruise.

      --
      [ e d @ h a l l e y . c c ]

        Several times I've awakened in the morning with a solution after going to bed thinking about a particular problem. I'm starting to think I might do my best work while sleeping.

        90% of every Perl application is already written.
        dragonchild
        Off topic, I really loved those books as a kid :> Probably cos of all the schemes the "Great Brain" came up with...
        If this was a series and some of the stories were similar to some of Mark Twain's work, then I think I may have read those.

        The things I remember from it (or if not it... something) are brothers, a small town, a cave, a swimming hole, candy (I think licorice specifically), and one brother trying (successfully) to get the mumps from the other brother.



        -------------------------------------------------------------------
        There are some odd things afoot now, in the Villa Straylight.
Re: Eureka!
by neilwatson (Priest) on Apr 29, 2003 at 16:04 UTC
    Just walk away. Go do something complete different and forget that problem. Come back later (usually the next day for me) and look at it again.

    Neil Watson
    watson-wilson.ca

      Heh. I'd love to be able to tell my boss -- "I'm a little stumped. See you tomorrow."

      (But I do see what you mean, and I agree)

        Less so now that it is post "dot com" era - but this is actually not entirely out of place in the tech world.

        Especially if your workplace has the mindset that things need to get done by a certain date, and how they get there doesn't entirely matter (depending on what you are producing, and perhaps team dynamics or lack thereof) - then frequently they will tell you to do whatever it takes to free your brain to wrap around the problem.

        Effectively managing a problem includes knowing when there is inefficient cycles, and remedying the solution.

        That said - there are many more managers that would never ever do that.
        (and of course if you have a schedule that involves certain hours due to customer interaction, this is totally infeasible)

        -------------------------------------------------------------------
        There are some odd things afoot now, in the Villa Straylight.

      I second that. When I started to work for the company I now work for, I used to have the best idea during the five-minute walk to the next train station! Which is a good indicator that I haven't really been able to detach myself from the problem during the day.

      I like to ask my coworkers as well. It often helps that most of them are not programmers; I have to explain the problem in a different way to them, which helps me to find the solution.

      And I also like to go and have a cup of coffee. Not because of the coffee, but because it makes me get up and walk around. Then, I can just stay in the kitchen for a few minutes and think about my problem in a different environement.

Re: Eureka!
by Juerd (Abbot) on Apr 29, 2003 at 22:18 UTC

    For me, sleep. Definitely. I sometimes wake up in the middle of the night, having fixed a problem in the time I thought I was sleeping :) I even fix bugs that I was completely unaware of.

    The other day, I woke up, fixed an obscure bug and went back to bed. The customer sent me an e-mail asking why I worked so late, and how I knew about that bug since he hadn't reported it yet. I don't know! Maybe in my dreams, I'm a much better coder :)

    But when I want to solve a problem, this never works. No eureka when it's needed most :(

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      Ditto. I started keeping a notebook (pen and paper, not laptop - although I have wireless capability now..hmmmm) next to the bed because my girlfriend was getting upset with me wandering in to the computer at 3 in the morning and waking her up.

      C-.

      ---
      Flex the Geek

Re: Eureka!
by sschneid (Deacon) on Apr 29, 2003 at 16:01 UTC
    When I come across something that I'm not entirely sure how to implement, I usually talk to someone (co-workers) about it. Not necessarily always from a technical standpoint, but usually in the vein of "step back and look at what you're doing, and see if there's a different and/or better way to do it".

    -s.
      I've found that I can solve many things this way - but it isn't even from any feedback from them (although that too can obviously help) - but it is frequently just as effective to get a room to yourself and a whiteboard and write it out - and more importantly TALK it out as if you were explaining it to someone that was new to it.
      Doing that removes you from your normal train of thought and allows you a different perspective and frequently one finds themselves verbally saying something that makes no sense - and that is the reason it doesn't work... b/c it doesn't make sense.

      It is much like writing a paper - when you go to proofread your own work, you are familiar with it, so you tend to skip over sections without even realizing it b/c you head is thinking "this part, and then this, and yeah, this next part, and this..."
      But if you go over the work backwards, your brain has to think differently, making it almost a new subject, and it allows a nonsubjective view at the same material - which will frequently expose things you hadn't noticed before.

      -------------------------------------------------------------------
      There are some odd things afoot now, in the Villa Straylight.
Re: Eureka!
by TStanley (Canon) on Apr 29, 2003 at 17:57 UTC
    For myself, I find that stepping away from the problem helps, or I will actually talk myself through the problem out loud, while driving home.

    I would strongly advise against the second option, unless you're really good at multi-tasking :-)

    TStanley
    --------
    It is God's job to forgive Osama Bin Laden. It is our job to arrange the meeting -- General Norman Schwartzkopf
      I like to talk it out loud in the shower the next morning. Having already had dreams about the damn thing all night.

      Neil Watson
      watson-wilson.ca

Re: Eureka!
by Anonymous Monk on Apr 29, 2003 at 22:35 UTC

    I just keep thinking about it...

    Really, you run into a problem, why walk away? Sit there and think about different solutions until you come up with a satisfactory one. You'll be far better off than if you just get someone to hand you an answer.

    Oh, and where can I get some of this "Caffaine?" ;-)

      Yes I'm in this camp also.

      Alternative solutions are nearly always available - even though I know at the time that they are a substitute for the 'unrevealed' one.

      The Eureka moment often comes, for me, sometime after the implementation of 'one of the others'.

      I can't decide whether that's funny or not %>

Re: Eureka!
by zby (Vicar) on Apr 30, 2003 at 11:30 UTC
    Like for the others here it mostly happens to me when my attention is detachet from the problem. Usually it happens at lunch.

    There is a guy analysing more 'active' ways to 'creative thinking': Edward De Bono. I have read just one book by him - but it was really thought provoking, and I am determined to read some more. What he proposes are some techniques for random playing with problems.

Re: Eureka! sixth side
by Discipulus (Canon) on Apr 30, 2003 at 12:01 UTC
    if you can't enter in a pentagon through no one of his five sides try through the sixth.. cheers from sunny roma
Re: Eureka!
by michaeld (Monk) on Apr 30, 2003 at 14:22 UTC

    The toilet is definitely number 1! *grin*
    There's not many places a man can hide and find enough tranquillity to think about a problem...

    As for the "Eureka-Erlebnis", this often happens to me when debugging.

    I seem to be doing a lot of debugging (don't we all...) and for some reason, I seem to be quite good at it.
    Some days ago, I was able to figure out why :
    - before working on a problem, I always seem to make some sort of mental map of the system: programs, environment, data, anything involved in the issue really...
    - experience in problem solving
    - an open mind - meaning that EVERY single 'environment variable' should be taken into account and seen as a possible source of errors. Don't rule anything out!
    - loads of patience...

    Some of my colleagues seem to be able to pinpoint THE source of a problem in a matter of minutes. You know the sort: "It must be the data. My program just can't be wrong...".
    Usually, the problem turns out to be caused by several things at the same time... and they are proven wrong.

    Cheers,
    MichaelD

      You know the sort: "It must be the data. My program just can't be wrong..."

      <merlyn>I've written a node on that...</merlyn> :)

Re: Eureka!
by markjugg (Curate) on May 04, 2003 at 16:01 UTC

    I work to keep my energy level up and my mind focused. For me this means getting plenty of sleep, eating well, regular excercise, and time for relaxation. (And often, classical music at work).

    I try to increase my focus by creating large chunks of time dedicated to programming. This means turning off my e-mail, setting the phone to "do not disturb". I also like to turn off the lights in my work area and rely on the sunlight coming in through the large display window next to my desk. It's a nicer quality of light, more relaxing.

    My break through ideas often come as I stand up and walk around or a take a juggling break. My walks to work are also a good source of ideas.

    -mark

Re: Eureka!
by benn (Vicar) on Apr 29, 2003 at 16:14 UTC
    All my older wiser cleaner friends tell me that kicking the caffeine actually makes ones thinking clearer. When I manage to give up my particular $x cups of "What do you call that? I said *coffee* not *dishwater* - give me that grinder!" per day, I'll report back. :)

    Ben.

      In studies that I have read based on that, they have shown that caffeine can have the effect of narrowing ones focus on the task at hand, which is great if you are healthy and relatively awake.
      One major problem with that is that caffeine's mechanism of action is to block the pathway that makes us feel fatigue - but the results of fatigue are still there in the background.

      So if your sleepy, non-alert self injests some caffeine, then you will quickly feel refreshed and as if you are focused and getting much done - but for the most part, you just feel that way and your productivity is declining at the same rate as if you hadn't had the caffeine (in many cases it is actually worse because you will think you are doing okay and continue to work, your quantity of work increase, but not the quality - whereas were you to actually feel how tired you really were, you might have stopped and gone to bed - as a result, when you come back to all of your work later - it is very likely that you have a lot of junk that you have to wade through).

      Now if you really want something chemical in nature to narrow your focus - then you are going to want some derivative of the methamphetamine family.
      The largest downside of this (aside from the whole "addiction" part) is that it will make you focus on something very intently. You won't eat, you won't be tired, and you will have to finish what you are working on with great determination... but that thing which grabs this undying attention may very well be something entirely different than what you should be working on. So instead of solving some computer programming issue - you might instead vaccum the entire upstairs of your house with amazing diligence.
      and as it has already been noted - frequently instead of narrowing your focus on the task at hand, you instead should be lessoning the grasp of your conscious mind and allowing the rest to have a hand.

      -------------------------------------------------------------------
      There are some odd things afoot now, in the Villa Straylight.
Re: Eureka!
by zentara (Archbishop) on Apr 30, 2003 at 13:58 UTC
    The sub-concious mind is far more powerful than the concious. Just keep the idea in your head, and all of a sudden, the best solution will pop out( it might take some time depending on how intuitive your brain is).

    The universe will sometimes give you clues...like seeing something on a billboard, which triggers a train of thought. Or you wake up from a dream and say "Of course, it has to be that way". The answer is always what method utilizes the least energy to accomplish the task.

    It's almost an universal rule, the lowest energy method is preferred, and in computer realms that means fewer cpu cycles, fewer disk writes, and simpler methods. I usually visualize a problem like this: There is a bunch of information on the left of a barrier, there is a blackbox in the barrier that the information can pass thru to get to the other side, and be in the desired form. The perl program is the "black box". All the studying I do is just to learn the various expert techniques, which reduce cpu cycles and disk writes, yet still let me process the information. At first my methods are crude and brute force, but the more you learn, the more efficient your processing becomes.

    So I visualize the problem, get a picture of the "black box" in my sub-concious, then go about meditating on it, picking up the clues which the "event sequences of the world" provide. Eventually an answer appears, which is the best.