Learning to Avoid the Golden Hammer

Learning how to code can be quite challenging at first. Not only are you expected to build a solid foundation of programming concepts, but sooner or later you are presented with a myriad of different possibilities.

There are many different languages to choose from, each with it’s own merits and drawbacks. Each language further comes with its own ecosystem (or potentially ecosystems) filled with different frameworks, build tools, package managers, coding conventions, deployment tools and so on.

And of course, there is a lot of variety when it comes to how you actually choose to build your applications too. For web applications, for example, you may want to consider the kind of architecture to be used — one that is monolithic or one based simple detached web-services. Or the kind of database that makes the most sense for your needs, SQL or NoSQL.

When designing complex applications there are several of these decisions that need to be made at various stages of the development process — some dictated by technical requirements, some by by business constraints, and others by personal taste.

After building a few such applications, you naturally tend to feel more comfortable with these choices, often using input from previous problems while solving new ones. If you found a particular piece of technology or paradigm easy to use in the past, chances are you would lean towards more using it again in the future.

This is not all bad. Obviously, if you are proficient in a particular language for example, the time you save by continuing to work with it might very well outweigh any downsides that may arise. For small-ish projects, it would definitely make sense to emphasize your own comfort. However, over-reliance on it makes you susceptible to potential blind-spots down the line.

This is precisely what the Golden Hammer is, assuming the solution to a problem before even knowing what the problem is. It’s a common anti-pattern.

If the only tool you have is a hammer, every problem you encounter is going to look like a nail

Why Does This Happen?

Well, let’s start with the obvious. Nobody likes change. Learning a brand new tool set for every project you work on is highly undesirable. It is much, much easier in the short run to simply use something you are familiar with. The lines of code keep coming with very little resistance, giving developers the euphoria they so crave.

XKCD — Golden Hammer

But the bigger issue lies in what happens when this attitude seeps into teams and organizations. If you are a large team that has been working together to solve problems for a long period of time, you likely develop preferences towards specific technologies. Moreover, infrastructure is built to support and encourage development in those technologies. As a team, you slowly develop conventions that everyone follows.

After a few iterations, you tend to get caught in this situation where this piece of technology is your de facto solution.

How To Avoid This?

On the one hand, it is fantastic that there are a set of people who are extremely proficient in what they do, making development much faster. They have learnt to navigate most problems quickly and efficiently that arise out of using their chosen product.

But it is also problematic for a couple of reasons. You want to avoid the situation where you are so tied to a technology that you fail to take advantage of the latest and greatest the software community has to offer. Moreover you want to be in a position where you can adopt emerging trends and standards with little overhead.

1. Conscious Effort Toward Exploration of New Trends and Technologies

This is not to say that you should be jumping on every new framework that comes out. A lot software ecosystems are so vast and sprawling that it can be impossible to keep up with every new update in the community, let alone venture outside it. *Cough* Insert angry JavaScript rant here

But at the same time, there should be a conscious effort toward exploration of new tools, ideas and practices to avoid complacency. This can be in the form of one-off projects written in something completely different from what you are used to. Infrastructure should be built with the mindset of adaptability to future changes, whenever possible.

2. Encouraging Exchange of Ideas

In addition to exploration, it is important for developers to be part of larger communities dedicated to conversations around technical ideas. This is a great way to stay up to date within your community and learn about emerging trends.

Conversing with other people in your community allows you to learn from their experiences and understand their rationale for following certain practices. Being a part of certain conferences can also be helpful.

3. Cashing in on Technical Diversity

It’s beneficial to have teams made up of people with varying levels and areas of expertise. If everyone on the team has identical experience, there are hardly any chances of having a meaningful discussion about possible solutions when building a product. Constructive arguments can be a really good thing and the best way to encourage them naturally is by drawing on a diverse talent pool.

As a final point, I want to stress the broad applicability of the Golden Hammer, which can wield itself in a lot of different ways. Although this post focusses entirely on the technical aspects, overreliance can also occur when it comes development processes instead of tools. It’s important to not do things simply because “thats how they’ve always been done”.

Individuals and teams should periodically reflect on their development practices to see if something can be changed to make them more productive and/or efficient.

If you liked this post, make sure to hit the ❤ button below. Feel free to let me know what you think about this piece in the comments, or through LinkedIn.