You've just spent the whole day trying to solve a problem, a design problem, a bug, etc. You know the solution is simple but you just can't see it.
A colleague walks past and notices your anguish: "What's up?".
"Oh, I'm ...". You explain the problem and what you have done so far. However you suddenly discover the solution before you have finished speaking! So far your colleague has been as useful as a cardboard cutout.
This happens often and I think it is due to you having to present your problem to someone in a way that you think will aid their understanding, often dispensing with some of the details. In doing so, you also clarify your own thoughts, untying them in your mind to eventually cite a solution.
Sometimes all it needs is a cardboard cutout of your favorite GURU!
Also sometimes known as a Programmer's Dummy - DarrenTarbard
Whenever a near-colleague snares me and won't let me escape some techno-tirade, I start ActiveListening to enhance the CP effect, hoping that's going to be good enough for them. It's either that or figure out what they're talking about. -- PCP
Does anyone have big pictures of Kent, Ron etc. that I can stick up and use as my CardboardProgrammer?
If you're going to have a cardboard cut-out of someone, you may as well get a cut-out of someone you find attractive. It would certainly make the dialog more rewarding. Unless that is why you want a cut-out of Kent or Ron...
When a real person isn't available to run your problem by, consider employing a CardboardAnalyst.
I've actually discovered that, with a little imagination, the MetaEcksDoctor works well as a CardboardAnalyst; it also helps that I use GnuEmacs as my programming editor. Its tendency to link random sentence fragments has occasionally solved my problems quite quickly. -- DanielChurch
At a computer lab at UT (University of Texas) there was a lab assistant who required all people asking for help to first tell their problem to his TeddyBear which lived on his desk. He used to say that after talking to the bear more than 75% of the people solved their problems. -- MarkInterrante
I HaveThisPattern - when working as a TA I used to make students tell me the problem while I was reading their code. Usually they worked it out before they could explain it. If not, I was in a far better position to understand them second time around (and they'd had practice explaining it :-) Some times I would even spot the problem (or some other problem) while reading the code. -- JanLarsen
For this, maybe essaying briefly your LogBook would also do. This might be heavier or even too heavy, but would give you the advantages of logging and maybe an excuse to stop and log.
I have a rubber Tux the penguin. He's a fantastic problem-solver. -- ErnestFriedmanHill?
This page is an excellent example of ThinkingOutLoud! It shows the value of converting mental problem solving models into speech descriptions. Illustrating the value of EmployingOtherAssets?. In the process of verbalizing, one employs other factors of the mental process (other parts of the brain), and searches for the words which are associated with the problem model. Often when in a problem solving mode, one is "trying stuff", not "finding stuff" to solve the problem.
Perhaps this is why in speaking to the "CardboardProgrammer" one finds the solution.
They told me my CardboardProgrammer was a better listener than me, and outsourced my job to him. He is not very productive, but the staff likes him more.
When I have a really icky programming problem to solve, I've been known to run it by one of my horses. Some of them are excellent system analysts (Norwegian Fjordhorses are a very versatile breed). -- StefanVorkoetter
I think I stepped in some of their handy work while walking to the bike trail. True GiGo?
GiGo has more to do with goats than horses, I think. Either probably do well as sounding boards. -- Matt Sach
A friend of mine (who is not a programmer) is already used to being my "inanimate object" when I need to use this sort of procedure (which I call "confessional debugging"). It's been known to work just as well with my girlfriend, other friends, my toy Yoda and even (!) real programmers! ;) -- rbp
Siamese cats (like my late and lamented 17-year old blue point Vashti) are excellent listeners. Vashti probably knew more about category theory and hierarchical graphs than any cat alive by the time I finished writing my dissertation. -- Charlie Martin
My CardboardProgrammer was outsourced to a shoebox in India.
MSN messenger! - I work from home a lot and when I get stuck coding something I contact a mate online - typing ideas into the MSN clarifies things enormously
A bit narcissistic, but I find my reflection in a mirror extremely helpful! -- bpfonte
This is one of the benefits of PairProgramming. Explaining the problem to a coworker (even a CowOrker) is beneficial in and of itself. Explaining forces you to rethink the design and implementation in simple terms (since language is always simpler than thought).
You know, folks, this is something that I've been saying for a looong time: if you can't explain it to someone else then you don't know it yer own bad sef. If you can explain it clearly to someone else then you know what you're talking about. If you can do that then you can write it down so that someone else can read it and understand it as well as you do. If that happens then you've just created a useful document, haven't you?
So, why again is there all this resistance to writing stuff down? Huh?
Speaking engages different parts of the brain then writing, and thus forces a different style of cognition that helps to clarify the thoughts. Writing it down certainly should be done, but it often takes the speaking to get to the solution first. -- PeteHardie
Hmm. That makes a great deal of sense. I'd like to find out how to engage that part of the brain that is stimulated during a spoken conversation. It would be pretty cool to get the benefit of using that part of the head-bone without actually wasting somebody else's time.