Discussion On
Be a Paranoid Pessimistic Programmer

by in Career

7 Comments

  1. Josh Strike
    Tuesday, November 2215, 2011

    I’ve been practicing this approach for about ten years now — looking first at the hardest-case scenarios for clients, then after jotting them down, giving a rough outline of difficulty without actually going into nitty-gritty detail.

    I have to tell ya, it hasn’t worked out as well as I thought. My clients like to joke that every time I say something will take a lot of thought, it seems to them like all I had to do was think about it a little and the solution magically appeared. Like, the less detail I gave them over time about the specific problems, the more they assumed the job was automatic; to the point that when there was a problem, they couldn’t understand where it was coming from.

    You’re trying to convince whining coders to stop dropping their problems into the client’s lap, and I think that’s fair. At the same time, there’s a drawback to setting your clients’ expectations unreasonably high by never mentioning what it took to do something.

    My solution, as it’s been, has been to estimate and gauge the scope of the problems and give a non-technical outline before starting the work, and then as I learned the hard way, to make sure I pound the client with all kinds of gruesome technical details about how hard it was after the work is done. That way at least they know what they spent their money on. Otherwise we really run the risk of being taken for granted.

    Reply
    • Jess Johnson
      Wednesday, November 2359, 2011

      Absolutely, there is a fine line between over-burdening clients with technical detail and not telling them enough about the work so that they don’t really understand what they are paying for. This is something that I still struggle with. And it’s one reason why I prefer working with clients who are fairly technical – they have a better understanding of the challenges involved in a project without me having to do as much explaining.

      I think there is a big difference between dropping problems in a client’s lap, and coming to them later with a list of problems plus possible solutions to them all. It is almost always better not to mention a bunch of problems unless you already have some ideas for solving them. Or if it is something that can be resolved without the client’s input, that is even better. Although as you say, it is a good idea to bring it up later so the client knows what they are paying for.

      Reply
  2. nefo
    Wednesday, November 2330, 2011

    When producing production code, I’m always thinking that the implementation is not-conservative-enough. I guess that is what you means in the article.

    Reply
  3. Dan Sutton
    Wednesday, November 2301, 2011

    Very well stated. I agree wholeheartedly… the amount of times I’ve seen systems crash because a whole load of bits of code which, by themselves, should work perfectly, don’t when they’re all stuck together is mindblowing. Just a little intelligence and a few extra checks and error handlers would’ve saved the day… but no: the programmers were too optimistic, and guess what: they were wrong.

    Reply
  4. variant-45
    Thursday, November 2437, 2011

    So true.
    Many of bug born from programmer carelesness such as lack in validation.

    Reply
  5. Bryan Lee
    Thursday, November 2433, 2011

    OMG, this is so true. thank you for posting this article :)

    Reply
  6. CodeMyBrain
    Friday, January 2024, 2012

    This has been very insightful, programming is about solving problems thus being a paranoid and a pessimist are fantastic qualities.

    Lol’d at the Swallow those words line, I guess ambition and imagination are for artists not programmers…

    Reply

Leave a Reply