One question that can often come up in your career is the benefits of being a generalist (a jack of all trades) or to really specialize in a particular technology. I think this is a question that doesn’t just plague technologists, but people in other fields as well.
This ability has served me really well in past projects where I’ve worked with a number of smaller companies where you have multiple responsibilities requiring proficiency across multiple technologies.
There are upsides and downsides to generalization. The upside is you are always learning new ideas if you keep an eye out. As with natural languages, knowing many technologies helps you learn new technologies even faster. This can be especially helpful when your toolbox of skills doesn’t have the right tool for a particular problem. The downsides are that you can reach a limit of how deeply you delve into an ecosystem if you are in and out of that world.
There are many benefits in specialization. You get a chance to deeply understand a subject and forge new ground in that discipline, which can be truly rewarding. But there are risks as well. If you pick a technology that eventually fizzles out, you could be stuck. You also run the risk of running into a smaller variety of problems, bringing down your possible creativity when solving problems that aren’t a good fit for the technology you specialize in (like doing systems programming in Ruby).
But after some introspection lately, I’ve come to a surprising realization — to generalize or specialize is not mutually exclusive. I think a good balance for someone like me could be to specialize in a set of concepts or class of problems, yet generalize with technology implementation of solutions for those problems.
One example is web performance. Optimizing for front-end web performance can involve optimizing downloads, concatenating scripts, and also thinking what to load in optimizing the user experience. But whether you’re applying those concepts to Apache or nginx, or Ruby on Rails or ASP.NET MVC, you are still accomplishing the same goal, but with different technologies. The real value is in knowing what solutions to apply. Once you know what you’re looking for, it’s easier to find out how to do that particular task in a particular technology. Specializing in this problem set requires knowledge of upcoming solutions like the adoption roadmap for HTTP/2, and optimizations to reduce SSL overhead.
Another example is architecting for High Availability. Yes you can get highly specialized in this industry depending on the stack (knowing the difference between MongoDB Replica Sets vs SQL Server AlwaysOn), but knowing the pros and cons of each can help people make decisions.
Of course, there are some technologies that pair well with some industries. A lot of big data work uses the JVM (Hadoop, Spark), a lot of web frameworks tend to shy towards dynamic languages like Ruby and Python. Systems programming has tended to follow a C/C++ route, although lately is seeing an influx of dynamic language developers thanks to languages like Go and Rust.
But I think there can be great value in specializing in how to solve a class of problems, but knowing how to solve them in a handful of different, yet common stacks.