In the 80s, Japan had an issue. Their new high-speed trains brought with them an explosive level of noise pollution. The highest noise levels were reached when the trains exited tunnels — compressed soundwaves created loud pops, akin to bombs going off.

Then came along an engineer named Nakatsu. Nakatsu was not your usual, single mastery type of guy — he was a generalist, with knowledge in multiple disciplines outside his main mastery domains.

The next thing you know, Nakatsu had redesigned the Shinkansen bullet trains to not only be quieter but also faster. He did all this based on the knowledge and connections he made from his side hobby and an obsession with birds.

Nakatsu made an impossible connection possible.

The Edge of Mediocrity

When everyone is an expert and is good at what they do, the industry sinks into a level of homogenized mediocrity. It is a state known as The Red Queen Effect.

The name stems from Lewis Carroll’s book — Alice Through the Looking Glass — and refers to a statement made by the Red Queen:

Now, here, you see, it takes all the running you can do, to keep in the same place.

As developers, we search for trends and the latest languages to pick up. We keep running and learning to try and remain relevant within our industry and niche fields. However, when your skills, knowledge, and experiences are closely aligned with everyone else’s, it becomes more difficult to create innovative solutions.

We become part of the mediocre crowd, limited by our knowledge domains. We may be skilled at what we do, but we don’t have that extra knowledge required to make the connections needed for innovation and differentiation.

Why We Need More Generalism in Tech

Recruiters call it being t-shaped. The letter T represents the breadth and depth of a potential candidate. The ideal recruit balances depth in their chosen work domain with breadth — varied knowledge and experiences in different organizational structures and external pursuits.

The issue that many developers face is that we often pigeonhole ourselves into just learning code. But our job is more than just tapping out if else statements. Our job is to translate ideas and realities into acceptable digital formats.

A generalist developer — one who isn’t just skilled in their chosen primary tech stacks — is able to produce unexpected, and potentially much more effective, results due to their faceted knowledge in multiple areas. This is because there is more surface area available than the confines of code.

Code is More Than Just Code

There’s a focus in the industry on finding “unicorn developers”. They’re the ones who can do it all — the ones who can cross between frontend, backend, infrastructure, security protocols, and everything between.

The issue with this label is that it focuses on technical knowledge and experiences. It doesn’t look at the other ancillary skills required to be the elusively borderline mythical creature of the tech world.

When it comes to translating solutions into a digital format, the developer behind the keyboard also needs to understand what it is they are tapping into existence.

You can’t effectively implement an eCommerce solution if you don’t understand how retail transactions work and where it could potentially go. It limits your ability to proficiently architecture and plan for growth in data, or sets you back as you try and unravel the mysteries of translating shopping experiences.

While this example may seem overdramatized, it is one of the reasons why many developer job descriptions require eCommerce implementation experience.

Learning to Make More Connections for Innovative Solutions

As developers, we’re much closer to the end-user and their experiences than many people realize. This is because we’re often at the frontline — as represented by the frontend — and there is more than just speed and response times involved.

While a project or feature may have already gone through marketing, commercial managers, test groups and everyone else, developers are much more attuned to what a system can potentially do. When the person or team behind the code has knowledge beyond their job descriptions, they are able to make more constructive design feedback.

The effectiveness of a developer is not only measured by how cleanly they can create code — but also by their ability to recognize, extract, pitch, connect, architecture and implement knowledge from external areas that are not within the frequent visited spaces of the job and general operations.

Sometimes, a product feature or project is conceptually developed in isolation, leading to a missing link that only a truly effective developer can identify and connect.

Final Thoughts

People tend to focus too much on the concept of innovation, often calling for it to come into existence. Sometimes, this happens out of nothingness. No one really focuses on the ingredients needed for such a thing to occur.

The true effectiveness of a developer should not be based just on how well they can code. While the depth of knowledge is still a valid metric, having good breadth beyond the code is also a great asset to the business.

Breaking out and pursuing interests beyond code can also help market yourself differently from your peers, creating an additional layer of value that is unique to you as a developer.

You never quite know where and when your ancillary knowledge will come in handy — but trust that it will. One day in the future the opportunity will come for the dots to finally connect into a beautifully unique picture.