Never give up

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.

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

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.

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!!!

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". 🙂

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.

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.