Being versatile is something I have long prided myself on, and that has been true in more than one context. As an athlete I always felt I was more valuable in being able to play more than one position, and now in software engineering, I feel more valuable in being more than just a one-trick pony in terms of technologies I can work with or develop with. Recent discussions have brought this subject to mind again, as well as an interesting article I read the other day.
This is a subject I have touched on before, and many others have as well since it’s almost an age-old debate of sorts, but some additional thoughts came to mind that add to my prior thoughts.
Growing up, I largely played baseball and basketball. On the diamond, I prided myself in being able to play every position if needed, although I never fared well as a pitcher (in Little League, I once pitched a third of an inning and gave up four earned runs). Later on, although I would have a cameo inning at first base in my final season, I settled in to being an outfielder, and even there I was able to play all three outfield positions. In basketball, height often dictates your position, but I was able to be a floor leader or a complementary scorer if need be.
In a lot of ways, the fun came from not knowing exactly where I would play on a given night. It was also nice knowing that I was viewed as being valuable in part because I could be plugged in at more than one position. If I was really needed in a pinch, I could have played anywhere, and was more than willing.
As a software engineer, I have prided myself greatly on being versatile. I have developed software close to the hardware, as well as software where I didn’t need to care about the hardware. I am more than fluent in several programming languages, and continue to learn more to at least have in my back pocket. Within the realm of embedded systems, I can work close to the hardware, on the application level or with support tools.
All of that said, it is really hard to be exceptional at several things. The aforementioned article touches on this, but also has a fine point that goes along with my experience, which is learning adjacent technologies. It all means some level of compromise, for lack of a better term, is needed, meaning that what you attempt to become competent in for versatility likely requires that some conditions be met such as being directly relevant to what you do. There are constantly opportunities for this, and it’s an easy way to grow without going so far as to learn technologies that have nothing to do with what you’re currently engaged with.
A great way to become versatile is to understand a little more than just what your piece of the project entails. If you’re working with firmware for an embedded system, it is helpful to understand some aspects of the applications that will use it. If you’re writing an application with portability in mind, it is helpful to learn more about each operating system your application will run on than just the specific items your code has to be cognizant of. If you’re developing on a system that not only has low-level code and an application, but also a shell script or two for certain tasks, it would help to understand the shell scripts as well. You might not become nearly as knowledgeable about them as your core strength, but it’s an opportunity worth seizing.
With all of my knowledge, there are clear strengths I have. There are languages I know and am far more experienced with than others, and operating systems I am more experienced with than others. In my earlier years, there was a set of microprocessor architectures I knew from dealing with them, while I didn’t deal with others. But I know enough about many others to be more than just a support player, and also to handle them when they find their way into my work.
It’s not unlike how even a lot of utilitymen in baseball have a position or two at which they are best suited to play. Outfielders who can play all three positions are often better at one than the other two. But the game is not so simple, nor is software engineering. In a given project I may deal with hardware, low-level software, operating system items, scripts in either a Unix/Linux shell or a language like Perl, Python or Tcl, and makefiles to build the software. There might be one main piece of that for me, but all of them come into play at one time or another. It offers ready opportunities to grow by learning new things and becoming more proficient at ones I already know, and all in the course of doing what must be done.
There is no harm in learning technologies that are very different from what you mainly deal with. After all, I have taken a comprehensive web development course on Udemy and attended sessions to learn more about Ruby, Javascript and Python, though I am decidedly not a web developer. The article also mentions understanding the business and soft skills, which I cannot emphasize enough as well. But the easiest way to grow is to learn technologies related to what you deal with, because you have constant exposure to them and thus more ready-made opportunities to learn them. It’s also the easiest way to be a more versatile engineer and have a high level of competency in the areas of knowledge that comprise the versatility.