About being a Generalist

Several tools on a table — Photo by Todd Quackenbush on Unsplash

Someone once told me that being a specialist is knowing a lot about fewer things while being a generalist is about knowing less about a lot of things. The first is about going as deep as possible into something. The latter is all about breadth of knowledge.

As a software engineer, I have always struggled with where to take my career. Should I go deep on some technology I like and make it my life to know everything there is to know about that? Or should I learn new technologies and expand the horizon as far as it goes?

To give it a little bit of context, I have worked with c#, visual basic, java, PL/SQL, T-SQL, Clipper, Power Builder, Kotlin, Dart, and Clojure, just to name the languages. Needless to say, I specialized in none of them. Nonetheless, I could always get the job done. It was only after 5 or 6 years that I chose to be an android developer and tried to focus on it. But then I had to deal with lots of situations where a cross-platform was the best choice. What to do then? Should I do my part on Android and leave the iOS unattended? This was not an option, so even while being a mobile engineer I was not able to focus on a specific platform. I have already created full mobile apps using native Android, Xamarin, and Flutter. Recently I even started working with Clojure, which is a functional language, different from everything I was used to.

And the doubt has always haunted me: should I be a specialist on a specific thing?

So you can see that without actually making a decision, my path has always been tilted towards being a generalist. And the doubt has always haunted me: should I be a specialist on a specific thing? Should I learn all the ugly insides of android and everything that gets released every year? Should I know by heart every Flutter widget and how to use them properly? Should I dive into the very core and mathematical theories behind functional programming? And if you got this far, chances are that you might have the same doubt. (Un)fortunately, there is no right or wrong answer. All I can say is that so far, it has worked very well for me and I can tell you why.

Perks of being a generalist

Life is not boring!

You can be challenged with all sorts of problems to solve. Something wrong with service X? Missing monitoring on feature Y? Need to build a feature that involves the full stack? It doesn’t matter! We are paid to solve problems after all.

See the big picture

When you have multiple stacks on your background, it gets easier to track and identify gaps in the system as a whole, thinking about how components interact with each other and not only about how they work while being apart.

Be part of different discussions

You will end up participating in different forums, discussing with different people about different problems. This opens up a lot of opportunities to improve your career and yourself.

Freedom to choose your tools

For someone that only knows how to use a hammer, everything looks like a nail. As simple as that. When you are confronted with a challenge, is very useful to have a large set from which to choose the right tool.

To be successful you absolutely must build things that are maintainable, scalable, and with guaranteed quality.

A few tips for fellow generalists

Avoid being too shallow

The tricky part about not specializing in a single technology is the risk of not learning enough to accomplish something. If you can get around a few languages and build something worth anyone’s time, you are good to go. But if you can just name pretty things and throw some concepts around without actually delivering anything with good quality, watch out.

Build a great foundation

If you want to pursue a career as an IC, there are a lot of things you need to hold dear, that will impact how good you are when using the tools you learn. To be successful you absolutely must build things that are maintainable, scalable, and with guaranteed quality. A lot of things help you achieve that, like good testing practices, design patterns, SOLID principles, etc. This is the part you should not skip and go as deep as it takes.

Go deep on what matters

Aside from the fundamentals, don’t be afraid of diving into anything when the need arises. What I try to avoid is going too deep while there is no need for it. Reading the source code for the sorting algorithm of your language might be important if sorting is a core feature of your program, but otherwise, you could go a lifetime without memorizing it.

Be pragmatic

Focus on what matters to you and your objectives and run as fast as you can from bikeshedding. Some people like to know the history of everything, all the whys behind every single detail and that’s ok. I just don’t find it practical. When I want to understand the reasoning behind some decisions already made, I keep going just until I can build an opinion about it. Beyond that, I feel like I am wasting my time.

The downside

You (probably) won’t be a tech rockstar

You will find it very difficult to be the tech reference on a specific field or give a relevant talk about the changes on the latest version of a framework in some glamourous convention. You will never create the framework that will take the tech community to the next level. And for me this is ok. I can dedicate time to building amazing products and solutions that customers will love, is just a matter of priority.

Specialist driven companies

Companies are often looking for specialists on the stack they have. This is the basic requirement for you to go past the front door, so it can be difficult to navigate the market when looking for a new job. This hits you hard, especially after you reach a level of experience from which you would not accept an entry-level position. For example, you might be a very experienced software engineer, know a lot about the intricacies of distributed systems, micro-services, the company love your resumé, but at the first step of the process, they send you a coding challenge and deny you the position because you did not use the latest version of some framework they expected you to know by then. On the other hand, there are great companies that hire people with different backgrounds and see the value they bring to the table, so it is a matter of searching for the right places.

Some problems will still require a specialist

Don’t forget that you don’t know a lot of things and chances are that eventually, you will need assistance from someone that knows the core of the framework. And it is and always will be ok for you to ask for help. No one knows everything.

I can only speak from my experience, and I must say that I have learned to LOVE being a generalist! It brought me where I am today, working in one of the best places there is, with some of the best talents I have ever met. It even allowed me to give it a try as an entrepreneur a few years ago. All this for not being afraid of new technologies and new challenges.

Senior Software engineer at Nubank