Since I started to work in the IT field, there were two stories/analogies that marked me in the way I see software as a process, mainly because there were real-life situations.

The main takeaways from these stories are about the mindset and how our way of thinking can affect the way we build our software.

I am not sure who owns these two stories but I do know from whom I heard them.

The first one is from a teacher, and he shared this story with us back at the university when we were studying Design Systems from a software architectural point of view.

The story was about an industrial team working on a new car.

Once they got the car finished and ready to be presented they were impressed by their work and prepared a whole presentation and went through all the things they have achieved.

At the end of the presentation, there was a video of the car running where the engine was making actually no sound so that the only thing you can hear is the tick-tack of the clock in the car.

The whole audience/team started clapping except for one person that was quietly thinking and raising a hand up.

At the moment everybody got quiet again, this person exposed: “I know how to stop the sound of the tick-tack”.

As silly as it sounds, this taught me to always be ambitious and have a sense of continuous improvement because there are no limits. Recognitions are always good, but the software is an ongoing thing, and this is where the phrase that I normally use comes from " always beta version".

The second story that I would like to share, is from a former work colleague, who told me a story about a problem that a factory was facing with its conveyor belt taking up empty boxes.

So in order to fix this problem, they had to figure out how to extract and remove those empty boxes from the mainline.

After analyzing complex solutions with x-rays, scales, and even robotics a curious person walked by and said: - Why don't you put a fan next to the conveyor belt and that will blow away the empty boxes?.

As simple as that, the main takeaway from this story for me is to always take simplicity and creativity over over-engineering solutions that may look smart but also unnecessarily complex or inefficient.

The reason why I like these two stories, and the reason why I always like to highlight them is that they reflect how curiosity, creativity, and continuous improvement can make you think outside of the box.

But wait a minute! How do we think outside of the box, what does it mean?

I really like this paragraph from the Grammarly Blog, https://www.grammarly.com/blog/think-outside-the-box/

The problem is that we’re creatures of habit and most of us prefer the comfort of familiar routines. Thinking outside the box can mean challenging long-held beliefs. It’s about answering “These are our best practices” not with a nod but with a raised eyebrow.

Other things that I normally hear from friends and also helped to encourage myself to think outside of the box are:

• Change the domain of the problem, ask kids or elders about how they will assess the problem you are dealing with
• Explain the problem to someone from the outside
• Don't always look for solutions in the same portals
• If it's a known problem, check how people used to solve this issue in the past without any technology
• Think about how to overcomplicate something and then try to take shortcuts
• Put the solutions into a drawing
• Think about the worst-case scenario
• Try not to get immersed in the routine and change small habits
• Think about what would you do with infinite resources
• Think about the ideal solution and try to reverse it

There is no handbook for this, but these few points always helped me to tackle things differently. Try to create your own list, without making it a routine!

We, as engineers, tend to overcomplicate things, because our mindset is built and shaped in a way that we always have to go to the optimal solution, and sometimes solutions are right in front of us and simpler than we think.

I hope you enjoyed reading this and that it has helped you come to any personal conclusion, but in the end what I wanted to share is how by listening to these types of analogies between life and coding you can change the way you think and build your software, because at some point what we do is try to solve human life problems.