Seeing problems differently
Posted by Filip Ekberg on March 14 2013 3 Comments
Posted by Filip Ekberg on March 14 2013 3 Comments
C# Smorgasbord ebook bundle including PDF, ePub and Mobi is still available for €4.99!
We always have interesting discussions at work, both philosophical and mostly programming discussions. Sometimes the things people say make you think a while longer.
The other day a co-worker of mine asked me:
If a tree falls in the forest and no-one is there, will anyone here it?
I quickly responded with this:
No, no-one will hear it but it will still make a sound.
The fact that it will make a sound is proven by science but that’s beside the point. It’s a trick question that leads you to say “No” but if you view the problem differently you’ll soon have a pretty good answer.
While my co-worker was stunned and rather mind blown by my fast and quite accurate response, I think that most of us developers think logically about most of our problems and try to see solutions to puzzles much harder than this particular one.
If we look at problems from more than one perspective and think about all different outcomes, we can and most likely will do better solutions.
I felt kind of smart for a moment there, don’t you just love that feeling?
When it comes to software engineering I try to think outside the box as much as possible. For example I reflect over the following:
- Is there anything I can do to increase the value to the customer in a timely fashion?
- If we spend X amount of time refactoring this, how much will we have saved in the long run?
- If the visitors of the website will never use a mobile device, is it a smart move doing a mobile version?
- Is the problem parallelizable?
- Can we add asynchronicity to increase the end user experience without messing up the code?
- This new feature in .NET seems very cool, but will it add value to the product? (Most times, yes!)
- What can I do to decrease the memory imprint of the algorithm?
- Can we use any patterns to make the solution more solid and less error prone?
Do you take the time to think outside the box?
Filip Ekberg is a Senior Software Engineer working in the country with all the polar bears, author of a self-published C# programming book and overall in love with programming.
Great post.
I’m a big fan of the boy scout rule, so, about refactoring I think we should always leave the code better than we found it. Of course there will be a point where it’s pretty much clean/done. The cleaner the code is, we will save more time in the long run.
You are think not quite far enough outside the box…..
The tree will cause a disturbance in the air, but it’s not actually a “sound” unless it’s heard.
Your colleague didn’t actually ask the right question. The classic question *is* whether or not it will make a sound, not if anyone will hear it.
It’s not meant to be a trick question but rather a philosophical inquiry regarding perception and reality. At face value it’s clear that it will make a sound – science and all that. However, we can never prove that it makes a sound, as proving that would require us to observe it, which then invalidates the question itself. The basis of proving something is observing and recording it, but how can we properly record something that changes when observed?
That is what this question is about. Not about witty, self-assured answers.