Never give up

  • Comments posted to this topic are about the item Never give up

  • All good, positive stuff, but it sounded a bit like the sermon on the mount!

  • Good Topic...well I think so anyway

    I think problem solving is a key skill and is something I rate quite highly in an individual. It shows a methodical approach and a positive attitude to work.

    My approach to problem solving is indeed that there must be a way to do something. You just have to know where to look. So use all the resources available to you. Use your peers on various forums for any pointers (you won't always find the exact answer you want). Use Google and read plenty of technical articles. Check for any errors and again investigate. Try a simple less efficient approach to get a solution then work on making it better.

    It sounds simple but I have lost count the number of times I have been told about a failed job or process followed by "What shall I do?". At this point I try to encourage the person to follow the points in the paragraph above, even if I have an idea (and depending on the urgency).

    Problem solving is a skill, some are born with it, some have to work at it.

  • I try to be open to the possibility that:

  • it MAY NOT be possible even if others say that it is
  • it MAY be possible even if others say that it is not
  • there is a better solution than the one I am considering as the best candidate
  • the best solution may take too long and that a less optimal solution may have to be implemented
  • Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • The one major thing I see missing in the article is the question of whether there needs to be a solution. Businesses evolve quicker than we realise, and quite often a rethink of a business process will allow for a lot of simplification - or at least redesign. As a result, I would suggest the first question isn't "how do I solve this?" but instead "can I remove the problem in the first place?". Even if a problem can't be removed, it's still all too forgotten that the problem can often be changed so as to make the potential solution easier to find.

    Doesn't always apply, but just remember a bit of lateral thinking is worth trying.

    Semper in excretia, sumus solum profundum variat

  • david.wright-948385 (7/8/2014)


    All good, positive stuff, but it sounded a bit like the sermon on the mount!

    Really, sermon on the mount? Have you read that lately? When Jesus was teaching it was not about never give up, it was him saying he is "the way, the truth and the life, no one comes to the Father except through me." (John 14:6)

    My motivation to write this piece had to do with my own problems at work. Sometimes you feel, or at least I feel worn down, by the issues at work. Sometimes, you don't feel like solving another difficult problem that you aren't even sure if their is a good solution to. Yet each time, I come back to the problem, believe there is a solution and end up finding one.

    Well, sorry if this piece came off too preachy.

    Ben

  • majorbloodnock (7/8/2014)


    The one major thing I see missing in the article is the question of whether there needs to be a solution. Businesses evolve quicker than we realise, and quite often a rethink of a business process will allow for a lot of simplification - or at least redesign. As a result, I would suggest the first question isn't "how do I solve this?" but instead "can I remove the problem in the first place?". Even if a problem can't be removed, it's still all too forgotten that the problem can often be changed so as to make the potential solution easier to find.

    Doesn't always apply, but just remember a bit of lateral thinking is worth trying.

    That is a good point I am glad you brought it up.

    Ben

  • It also need be said that a high-tech solution isn't always the best solution or even a better solution.

    I work at a bio-repository with literally hundreds of ultra-low temperature freezers (-80 to -180 degrees C). Staff were complaining they had to write on a paper form every time they accessed a given unit and wanted to know if we could capture that electronically using a database and a bunch of sensors or some kind of mobile technology.

    I told them that a piece of paper was really the cheapest and most efficient solution for the purpose.

    One other random thought: Good technology rarely if ever "solves" a bad process. Only changing the process does that.

    ____________
    Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.

  • I thought that it was more of a motivational style then lecturing. Some love it, some don't. Personally, I take from editorials of this style the anecdotal knowledge and like to debate the best practices for such scenarios. I am sure some people don't like my style of response.

    To quote a great comedy: "Don't panic Mr Mainwaring!!!" i.e. write what you feel and be damned 🙂

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (7/8/2014)


    I thought that it was more of a motivational style then lecturing. Some love it, some don't. Personally, I take from editorials of this style the anecdotal knowledge and like to debate the best practices for such scenarios. I am sure some people don't like my style of response.

    To quote a great comedy: "Don't panic Mr Mainwaring!!!" i.e. write what you feel and be damned 🙂

    I'd agree.

    On an international forum, style will never fit all readers, at best being a reasonable compromise. Ben's article was definitely a bit "Ra-Ra" by UK standards (for example), but the message was pertinent and we can all do with a kick up the backside from time to time.

    Semper in excretia, sumus solum profundum variat

  • majorbloodnock (7/8/2014)


    Gary Varga (7/8/2014)


    I thought that it was more of a motivational style then lecturing. Some love it, some don't. Personally, I take from editorials of this style the anecdotal knowledge and like to debate the best practices for such scenarios. I am sure some people don't like my style of response.

    To quote a great comedy: "Don't panic Mr Mainwaring!!!" i.e. write what you feel and be damned 🙂

    I'd agree.

    On an international forum, style will never fit all readers, at best being a reasonable compromise. Ben's article was definitely a bit "Ra-Ra" by UK standards (for example), but the message was pertinent and we can all do with a kick up the backside from time to time.

    I sometimes reread my own postings and dislike them. There is no pleasing everyone all the time!!!

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • New ideas are untested and spring from rational models (mind junk). Empirical solutions are simple, robust, and proven. I quickly and confidently implement these simple solutions wherever there is a squeaky wheel needing grease. I approach new designs with caution. Committing to a new paradigm generally weakens future freedom in coding.

    My wisdom is in knowing that mother nature tries tiny incremental changes here and there. If the change is evolutionary it propagates. Otherwise it dies out with little loss to the system.

    City planners favor large hi-rises, highways, and parks. They like zoning and separating commercial and residential areas. They like punctuated uniformity. All these things are contrary to the nature of an old growth forest. They are also contrary to life thriving in a city. Be careful what you envision as a utopia for your application.

    A solution must have usability, flexibility, stability, maintainability, sustainability, adaptability, and most importantly cost-justifiability.

  • I guess I always look at a problem as always having a solution. I may not have the answer but I believe it is out there. Just last week we had some major slowness in our production processing, pulling data from a data repository into our warehouse. One process ran for 8 1/2 hours, another 3 1/2 hours. I was very familiar with the 3 1/2 hour process, since I wrote it. So I focused on the 8 1/2 hour process, I made some coding changes, and it ran in just over an hour the next night. While changing that coding we discovered a process from another team was doing 98 billion reads against this repository. So after it was canceled and the code fixed I thought "well I don't need to look at the job I wrote then." But the next night it still took 3 1/2 hours. So I did some research and found I was not joining two of the tables in the most efficient way. I changed the joins and the next night... 2 minutes. WOW, I couldn't believe it. Now to clarify I had written the original code about a year ago when we first started working with this repository, and there was a lot less data. So, yes there was a solution to the problem and I learned never to assume "it can't be my code". 🙂

    -------------------------------------------------------------
    we travel not to escape life but for life not to escape us
    Don't fear failure, fear regret.

  • below86 (7/8/2014)


    ... I learned never to assume "it can't be my code". 🙂

    Always best when you can find it yourself too. Admitting the possibility of fallibility is important. To openly acknowledge it too is great for team morale as everyone can see that it is most important to resolve issues. Even if that leaves someone looking a little worse in some peoples' eyes.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Approach all problems with the belief they can be solved.

    And if you can't, it's time to find a different profession.

    We make our living solving mysteries.

  • Viewing 15 posts - 1 through 15 (of 28 total)

    You must be logged in to reply to this topic. Login to reply