Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Problem-solving Under Pressure: Noting the Proportion of Knowledge, Skill, and Chance

by ccarden (Monk)
on Apr 22, 2004 at 16:07 UTC ( [id://347390]=perlmeditation: print w/replies, xml ) Need Help??

In the past few weeks I've been under a very stressful series of deadlines and, as we have all probably experienced in these situations, plenty of issues crop up: bugs, personality differences, physical health challenges, sleep deprivation, prior commitments, and the usual distractions. This all can create even greater stress, which can in turn contribute to more errors and many last-minute solutions.

What I noticed first about all of this is that, no matter how well I understand a particular subject, no matter how good my trouble-shooting skills may be, often the solution comes in a flurry of tests as a sort of magical mistake, or an act of grace. Through no or little fault of my own, the answer is "stumbled" upon.

This got me to thinking about various factors, most importantly stress and one's REACTION to it. How consistently can you maintain a calm and collected demeanor while management and team-members cry for resources, solutions, and answers? How well are you able to stay focused on debugging or coding the top issue when severe back pain, the flu, or a malfunctioning air-conditioning system provide major distractions? Personally, I have found this to be one of the top lessons in my life: to remain calm in the eye of the storm ... without damaging bodily health or interpersonal relationships (read: don't ignore yourself, the boss, or the family). I have certainly not perfected this lesson, but I am constantly reminded of it.

But even if you set aside all of the distractions, all of the competing priorities, all of the stress-causing pain and noise ... even if you have a quiet, calm environment within which to work ... with the looming shadow of a deadline, it does not seem to matter how much careful thought is given, how many clever tests are run, or how much you study the perldocs, it almost always seems that the answer arrives from some last minute suspicion, or even an unconscious change (read: intuition or clumsy mistake).

This may not be the way for many of you. Perhaps I am even in the minority, or simply too junior of a Perl programmer to be above seemingly random influences. Or maybe it is simply the first sign of senility. But I wonder how many others of you have had, or continue to have, this sort of experience?

Om tat sat. This meditation is finished.

Chris Carden

"When meditation is here, where am I? When I am here, where is meditation?"
-- Shri Shibendu Lahiri, great-grandson of Lahiri Mahasaya, in a talk at Song of the Morning, ca. 1993

Replies are listed 'Best First'.
Re: Problem-solving Under Pressure: Noting the Proportion of Knowledge, Skill, and Chance
by dragonchild (Archbishop) on Apr 22, 2004 at 17:53 UTC
    After years of dealing with these kinds of clusterf*cks, I take a different tack. Deadlines that are crazy are the result of poor planning, usually 2-3 levels above me. So, I refuse to cover for their mistakes. I will work hard, and I will make a good-faith effort to make the deadlines, but I will not ruin my life or my family's life for them. Life is too short and there are too many jobs out there that pay well-enough.

    I came to this conclusion after I worked over 100 hours in a week (including 18 hours on my wife's birthday) to get a major release out for a company that laid off their entire development staff the next Friday. We were laid off because we asked for something completely unreasonable - time to design. Not only that, but we were allowed to interview for our jobs, but only half of us would get it back. After that experience, I realized that it simply didn't matter.

    When I do have to work against a deadline, I follow the "Basic Principles"TM:

    1. Always code the smallest portion that will work at any given time.
    2. Build on successes.
    3. CVS is my personal savior.
    4. Testing, even if it's just basic smoke-testing, is more important than development.
    5. Test every single change, one at a time.
    6. Have a clean development environment that no-one else can mess with.
    7. Spend the time to make the computer do as much of your work for you as possible. The investment will always pay off tenfold in the first week.
    8. Don't sweat the small stuff, and it's all small stuff.

    Yeah, a lot of those principles sound like XP, but I don't follow the XP paradigm. XP is just a codification of the "Basic Principles"TM.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Re: Problem-solving Under Pressure: Noting the Proportion of Knowledge, Skill, and Chance
by perrin (Chancellor) on Apr 22, 2004 at 16:19 UTC
    I've actually found that randomly stabbing in the dark at a bug (aka "thrashing"), although it eventually will usually lead to a solution, is not nearly as effective as taking an extremely rational and logical approach.

    Basically, you start at the visible failure condition, and you work backwards until you find the point where things went wrong. Usually, if a bug is hard to find, it's because it's in some area that the programmer assumed couldn't possibly be going wrong ("I already checked the file permissions..."). I have often helped co-workers solve bugs by getting them to test those assumptions.

    Ultimately, keeping your cool and staying rational in a stressful debugging situation will usually pay off.

Re: Problem-solving Under Pressure: Noting the Proportion of Knowledge, Skill, and Chance
by flyingmoose (Priest) on Apr 22, 2004 at 18:45 UTC
    How consistently can you maintain a calm and collected demeanor while management and team-members cry for resources, solutions, and answers?
    I have recently found that the surest path to insanity is to search for find reason in a place where there is none, for you will never find it. The same thing comes from trying to control a source of pure anarchy where a defined process does not exist. Or trying to rationalize anti-design. Sad, but true. My stress comes not from the factors I am exposed to, but failing to rationalize or control those factors. So I have finally figured that out and decided not to, except occasionally from an outside-observer perspective. That is, I only play politics when I feel like I can win, and when I will enjoy it...almost like Orson Scott Card's "Demosthenes and Locke" in Ender's Game -- detached but still manipulatory. Otherwise, I am trying to be more laid back and let the current go where it will if it doesn't affect my job security or serve my purpose. Not caring is hard... it's against my nature, but it's a cluster**** as dragon has said.

    Though Wargames was a horrible movie, it remains true that the only way to win "Global Thermonuclear War" is not to play the game. Such is the way with project managers and arbitrary deadlines -- yet I still play the game a bit. As hard as it is (heck, I score "ENTJ" on the Myers-Briggs personality profiles -- I live to command & control and NEED that feeling) to avoid straightening the solution out, try to become more layed back, begin providing rope, and let the errant parties hang themselves. If I find myself dealing with bad code, I'll let folks know, and I promise nothing but that I will follow my own process.

    Lately I have been getting marginal results by asking for requirements documents, defect numbers, and asking meta-questions like "Are we following the process?". It's not very effective, but at least it allows me to feel like at least *I* am governed by a process, even if no one follows it. Usually the things I ask for don't exist, but it gives me the illusion that I am in control, or brings me closer to it.

    My last tip is the best one -- a good audio player, decent headphones, and loud rock music, turned to 11. May I recommend Van Halen? There has even been a bit of research about how music provides isolation from external factors while providing an orienting experience that increases concentration -- sounds like psychobabble, but it works for me. Runnin' with the Devil...

      My last tip is the best one -- a good audio player, decent headphones, and loud rock music, turned to 11.
      Often I put my headphones on, continue working and then realise an hour later that I haven't turned on any music to listen to, the headphones themselves enough to create a barrier between myself and those around me in the office, allowing me to focus and concentrate on the task at hand.

       

      perl -le "print unpack'N', pack'B32', '00000000000000000000001011010011'"

        I do that occasionally, I'll play some music, tune out then realise an hour later that my mp3's have finished.. :-)

        I like it when that happens. In retrospect I realise I've focused, worked hard and usually when I'm thru' the process I have the desired result.

        I also like it that I know myself well enough that I can induce this behavior.

      . . . the only way to win "Global Thermonuclear War" is not to play the game.

      I'd forgotten that quote, but its words I try to live by. It doesn't always work, but I try :-)

Re: Problem-solving Under Pressure: Noting the Proportion of Knowledge, Skill, and Chance
by Heidegger (Hermit) on Apr 23, 2004 at 06:10 UTC
    The stressful situations arise because the managers want to save money - they get the project and ask the programmers to code. No time for analysis or design, bad chemistry in the company and stress for everybody. In the beginning programmers care about the deadlines. But when the deadlines are every week, they just don't care.
Re: Problem-solving Under Pressure: Noting the Proportion of Knowledge, Skill, and Chance
by Ryszard (Priest) on Apr 23, 2004 at 09:02 UTC

    I've worked in a few places where the stress can be very great. Looming deadlines that have the ability to cost the company money, disrupt thousands of customers etc etc.

    Of course everyone has different limits and tolerances, however what works best for me is control. I don't have to be in control of the process going on around me (although' I prefer it), however I need to have control over what I am responsible for. I like to get excited about things, and that's ok to a certain extent, however what I don't want is to get in the position where my thought process is chaotic, I'm reading every 5th line, not thinking clearly etc, kind of like an excited panic.

    I follow a very structured, analytical and systematic approach to "business", I communicate frequently, and perhaps ironically, slow things down when approaching a tight deadline. I like to keep things slow to keep control and stop the excited panic. Of course slow is a relative term, its not like I'm sitting around doing coffee and the like. I'm also not always after the gold plated solution, just the best and most efficient way to reach the target.

    So, slow things down, communicate, and take/keep control of what you can.

Re: Problem-solving Under Pressure: Noting the Proportion of Knowledge, Skill, and Chance
by Anonymous Monk on Apr 22, 2004 at 16:55 UTC
    Usually there are very few variables that you want to keep an eye on. If you can manage to know, how those variables flows, you can easily identify what's going on. If those variables are ok, find the second most important variables regarding the problem and manage to know their flow and so on.

Re: Problem-solving Under Pressure: Noting the Proportion of Knowledge, Skill, and Chance
by zentara (Archbishop) on Apr 23, 2004 at 16:09 UTC
    What I often think about is " how did the "rat-race" become institutionalized? The rat-race is not a fact-of-life, it's imposed on us by anonymous overlords. The whole world needs to slow down.

    I'm not really a human, but I play one on earth. flash japh

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://347390]
Approved by mpeppler
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (3)
As of 2024-03-29 01:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found