A man and woman were in their kitchen getting ready to cook a ham for dinner. The man takes the ham out of the fridge, puts it on the counter, and cuts both ends off.

Confused, the woman asks “why do you always cut the ends off the ham?”

To which the man responds “I don’t know, my mom always did it this way, so there must be a good reason.”

The next day the man calls his mom to ask why she cut the ends off a ham. She said “I don’t know, your grandma always did it, so I always did it that way too.”

The man proceeds to call his grandmother and asks the same question. Again she said, “My mother always did it, that’s just what we did.”

The following day, the man makes a trip to see his great-grandmother. He asks “why do you cut the ends off the ham before you cook it?”

She looks at him and says in a matter-of-fact voice, “back then, our ovens were so small a whole ham was too big to put in the oven. I had to cut the ends off to make it fit!”

For years, this family mindlessly cooked this way because nobody stopped to ask “why.”

I can’t tell you how many times I’ve seen this with software. Patterns, components, and processes get reused every day because it works and nobody wants to bother to come up with the right way to do it. Building software “because it’s the way we always do it” is the antithesis of innovation.

So let’s figure out how we can start changing our mindsets to naturally think out of the box.

Image by Sasin Tipchai from Pixabay

Learn From Your Experiences - Don’t Relive Them

You learn new things every day. Important things, unimportant things, gossip, current events, things related to computer science, the list goes on and on. You draw ideas and experiences from everywhere. Experiences that might not seem relevant to your day job could turn a design into a one of a kind system. You just have to connect the dots.

You will never know less than you do right now.

What you don’t want to do is replay what you did in the past. Even if it was successful. No two pieces of software are alike. Neither are the teams that are going to build it. What worked in one situation is not guaranteed to work in another. Even if it was for the same company. Or the same development team.

Entropy and the second law of thermodynamics tell us that if you do nothing to change a process/pattern/design over time, it will only get worse. The level of disorder will continuously increase more and more until it is practically unusable.

If you learn from your past successes and apply lessons to your new project, you will grow not only your understanding, but also the process. So think about that gossip you heard or that recent current event. What can you learn from those stories to help come up with a new way to do something?

Image by Robin Higgins from Pixabay

Become a Professional Skeptic

As an engineer, you’re probably pretty good at this already. But I’m going to say it anyway.

Always Ask Why

Sure, taking things at face value is easy, but is it right? Being told to do something is the easiest way for this is the way we always do it to slip into your project.

Without thinking about it, you could have a pattern that was put in place 20 years ago added into your app. If you had asked why and pushed back on doing something this way versus that way, maybe you could have saved yourself.

Software engineers almost never have an issue explaining why they chose to do something. The ones that hesitate are trying to hide something. The nature of a developer is to be curious and to explain the cool solution they came up with. If someone doesn’t want to go into detail about a solution, that’s a red flag.

I recently heard a story of a team of engineers who were developing a third party integration into their system. They couldn’t access the the third party system until their credentials were cleared, but had to start building right away to hit a deadline.

So they decided to put up a mock server to act as the system until they got their credentials. Easy enough.

Except this team of engineers were following the this is how we’ve always done it principle. They started coding a mock web service with dummy endpoints, writing deployment scripts to push it to a server, and describing patterns on to add new mocks to it. Why? Because that’s what they have done before.

Luckily, an engineer on that team had recently heard about Postman mock servers and was able to build exactly what they needed in minutes, not days. No custom code, no deployment scripts, just simply using a better way to solve a known problem.

If the engineer hadn’t been skeptical about the decision to build a throwaway dummy service, the team would have been out days of work.

Photo by Nathan Dumlao on Unsplash

Embrace Diversity

You know what’s easy? Thinking you’re right.

You know what’s easier? Having people you’ve worked with for years and years telling you you’re right.

If you have worked with the same people for years, chances are you’ve developed a similar mindset as each other. You’ve made the same decisions, learned the same lessons, and picked up on the same gotchas. What you haven’t done, is built a diverse set of ideas.

You and your team have validated each other into thinking your ways are the best. Why? Because you always agree on the path to go down.

This is one of the easiest and scariest that’s the way we always do it traps. You don’t get challenged when replaying an idea, so you reinforce its validity in your mind.

Please don’t do that.

Ask around. Get ideas from other people. Use Google. Go to Twitter. You literally have some of the world’s best software developers at your fingertips through social media.

Take the time to ask a question, read up on a new technique, or fire off a tweet. There are people out there that genuinely want to help, and you should take advantage of it.

A diverse group of thinkers will take your project and skyrocket its potential.

The best thing you can do for yourself and your software is to get a diverse look at the problem. Not only will you learn new ways to approach a problem, but you also get the opportunity to teach others. Plus, you will tackle a problem in a new, innovative way.

Photo by Owen Vachell on Unsplash

Be Willing To Change Direction

Guess what. You aren’t going to be right 100% of the time.

You’ll make a decision on how to build your project and once you get in there, realize it was the wrong call. You’ve made a mistake.

But it’s ok. You recognized it early and are willing to course correct. Right?

When exploring uncharted territory, you need to be hyper aware of your surroundings. Keep a watchful eye on everything. If something starts looking like you went down the wrong direction, identify it as quickly as possible and come up with a solution.

You can’t realistically expect new patterns, processes, and designs to be right first try. You build software with full intentions to iterate. And we all know it’s not iteration if you only do it once.

Catch problems early and adapt.

Maybe you need to change something small. Maybe you need to abandon this path completely and go down another route. As long as you have caught it in a responsible time frame, do it.

Be flexible. Give yourself a chance to fail. Give yourself a chance to learn.

Start Now

The best time to start something new was yesterday. The second best time is right now. You don’t have to wait until you’re on a brand new project or doing greenfield development to start thinking for yourself.

Start surrounding yourself with people from different backgrounds. Ask people on social media their ideas. Get a diverse group of people to constantly challenge you.

The world needs people to innovate. We won’t innovate if we are herding a bunch of sacred cows.

Be smart, think unique, build something great.