Why Being a Software Generalist Ensures Future Successes

Software developers should be continually watching for, learning from, and applying new technologies and techniques. This effort expands their knowledge and available toolsets to more efficiently and effectively solve future problems.

When Envy Labs started 11 years ago, we were – and still are – happy to be known as a Ruby on Rails software development agency. We promoted Ruby, we promoted Rails, published the Ruby5 podcast, created Ruby training materials, classes, products, and started the annual Ruby Heroes awards. And while Ruby and Ruby on Rails were what we were known for, they certainly weren’t all that we knew.

At that time, our developers were necessarily from differing backgrounds. There was no avoiding it: Ruby had only existed for about fifteen years and Rails for barely five. We came from organizations using Java, .NET, PHP, and more. We yearned to shed the baggage and ceremony of what many of these former ecosystems required which afforded us an ability to focus on efficiency and effectively doing what we love: Creating great software and positive experiences. At the time, we found that in Rails and there we happily stayed.

Fast forward to today and we still happily create, deliver, and support Ruby on Rails products. Additionally, we create Phoenix applications with Elixir, Nest.js projects with TypeScript, and even cross-platform Go utilities, just to highlight a few. But, this isn’t new. We didn’t just begin to expand our competencies. We’ve always created software using languages, frameworks, and techniques which we felt were best suited for the problem at hand; whether that was a Rails application or a C# desktop application.

It is this diversity of experience that provides us with irreplaceable insights and unique strengths. 

Realities of Custom Software

Software systems are complex and often involve creating and adapting a wide variety of components which must come together to form a single, cohesive solution. The technologies and approaches utilized live on to impact future development and operational decisions, product directions, and development and maintenance costs for years to come.

No single technology, platform, framework, or even development paradigm provides the magic bullet which perfectly solves every need. Developers – senior developers and technical directors especially – must have a broad base of knowledge and experience from which to draw. Bolstered by that experience, they have the best chance of identifying reasonable and appropriate approaches when solving the problems at hand.

At some point, making a decision, stepping forward, and putting in the work is taking a leap of faith. How risky it is – and how scary it feels – is directly and inversely related to the knowledge and experience which the individuals bring to bear.

The more experiences from which developers can draw from, the more likely it is that they’ve been exposed to similar problems – and therefore similar solutions – that may be readily applied to challenges at hand.

How to Become a Better Developer

Becoming better at anything requires both time and effort. You can greatly reduce the amount required of both by focusing on specific goals. The list below provides a streamlined set of targets to effectively understand, evaluate, and categorize new information, approaches, and technologies.

Understand Why a Technology Exists

People don’t tend to waste their time and energy creating a new thing for no reason. In fact, the best developers often self-identify as being so lazy that they teach their computers to do their work for them. Therefore, it is significant when an individual focuses their efforts, applies those efforts, and something new is released.

Every library, framework, language, and software paradigm was created to solve a specific, often personal problem:

• React was created by Facebook to manage user interfaces and render HTML quickly.
• Ruby on Rails was created by DHH to simplify web application development.
• Erlang was created by Ericcson to improve telephony application development.
• PHP was created by Rasmus Lerdorf to collect web form data on his personal home page.

The most effective way to grok a new technology is to understand where it fits into its world. And, to understand that, the most important question to ask is, “Why?”

Why was this created? Why wasn’t this a problem before? Why wasn’t a known approach good enough? Why would I want to use this?

Why should I care?

Answering these questions gives context and often uncovers new rabbit holes to explore. These answers grow a developer’s understanding not only of the new concept, but also the greater environment surrounding it. They highlight problematic areas of existing approaches and often go on to map trouble areas not-yet-seen across other domains.

As this understanding grows, it carves out a space and slots each new technology or approach into a developer’s mental models. While they may not need it today, they may tomorrow. The blockchain approach taken by Bitcoin may offer an approach to reducing violence in the diamond trade through greater transparency in supply chains.

Recognize Technology Trade-offs

Nothing comes free and no single solution solves every problem. After understanding the “why’s” you need to ask, “what else?”

If the new technology is blindingly fast, is it overly memory intensive? Maybe it makes use of a new browser or operating system interface that isn’t yet widely adopted or available. Is the benefit worth forcing a change to delivery environments or a complicated migration path?

In the beginning of a new technology, there’s a period of rapid – sometimes zealous – early adoption. This is an ideal time to observe and experiment. Discover how well this technology applies to real-world applications without taking on significant risks. This rapid evaluation period quickly exposes surfaces that are often less rainbows and unicorns and highlight previously unpopularized shortcomings. This was the period in which the “Rails can’t scale” stigma was established.

Perhaps it’s a new language which gains incredibly efficient concurrency at the cost of requiring a new infrastructure or architecture. So, the initial development may be simpler, but the adoption may greatly impact ongoing operations costs for new server environments.

It could be a new software framework which performs incredibly well in one area, yet it entirely ignores or underperforms in many others. To summon Alton Brown, it’s a “unitasker” – incredibly good at one job and one job, only. Knockout is a fast, simple, extendable JavaScript framework that does data binding really well. But, that’s about all. This is great if that’s all one needs, but more often than not, this narrow focus is a death knell. 

Assuming the technology still looks good, next it’s important to recognize that we’re not alone. Most projects have teams of developers. Taking on a technology without regard for the ease of comprehension, training, availability of support materials, documentation, and ultimately the impact it may have on other developers, would be short sighted and a failure. These libraries and technologies are often referred to as “having steep learning curves,” and this red flag shouldn’t be ignored.

Share Acquired Knowledge

Sharing acquired knowledge requires one to act as a teacher. We’ve found that demonstrating and teaching a subject to others requires a deeper and more thorough understanding of a topic. We’ve benefited from it through teaching internally, at meetups and conferences, on podcasts, and even productizing it with Code School. Sharing knowledge drives discussions and creativity around new solutions and applications.

One significant value to working with or being part of a team is the ability to rapidly share and apply newly gained knowledge. When one person comes across a novel idea, problem, or solution, sharing it enables the rest of the team to consume it and improve future decisions and directions.

We have active Slack channels and weekly discussions about new and interesting technologies and approaches. So, while only one developer invests the time exploring and understanding a concept, we all gain the benefits. This benefit can also be found by participating in meetups and user groups. This free propagation of knowledge pulls us out of our daily silos and exposes us to outside ideas and techniques.

Embrace the Evolution of Technology

To be a great developer isn’t just to have incredible depth in one, narrow area. A great developer takes the “soaked paintbrush” path: a shallow understanding across a wide breadth of topics, with occasional drips deep into areas as they apply to current projects or simply pique interest.

The software development world is ever evolving. The goal posts are always in motion. Each year brings new hardware, updated operating systems, new browser features, and new specifications. Where it once was flashy to animate a graphic, audiences often expect smooth transitions between pages, offline support, and concurrent document editing.

It’s impossible to say where the world will be tomorrow, but it’s certain to be different from today. We wouldn’t have found Rails if we’d just kept our heads down. Watching the world outside of our current projects and bubbles keeps us motivated to continually perform better and positions us to continue to be effective as the industry continually evolves.