Be a well-rounded software engineer
During a recent IM conversation I made a statement about probably being able to adopt any mainstream programming language or framework in a few days; I don’t care about the specific tech per se. I initially felt like a douche, but I quickly realized that this statement reflected what has been bothering me about my industry colleagues the last few months.
Don’t label yourself
A lot of my peers identify themselves by the technology stack they are using. Their profiles state they are “PHP programmers” or “Java developers”, or whatever programming language they are comfortable with.
Describing yourself by a technology is certainly a valid way of presenting yourself professionally. Your job probably requires you to spend a lot of time with that technology and you’re probably more familiar with that stack that 90% of the other things out there.
Describing yourself by a technology is also very limiting. You position yourself in a specific corner of the market, whether you want it or not. Specializing in itself is not a bad way of distinguishing yourself from the crowd, as long as it is a conscious decision and not because “it’s what you do.”
Tinker and learn
While our line of work allows us to tinker with new technologies in our spare time, there isn’t much use if you can’t apply the new concepts you’ve learned, outside of your weekend projects. In the end, you spend most of your time on your full-time job.
Getting outside of your comfort zone makes you more critical of your own work. It exposes you to paradigms that you might not encounter during your normal job. It allows you to accurately determine whether you are using the right tool for the right job and quickly make decisions about choosing a stack for your next project.
One thing I’ve noticed is that developers I look up to almost never associate themselves with a toolchain. The simply call themselves “software engineers”. If they do specialize, they are often an expert on the topic and are either heavily involved with the community. But they always tinker with other tech on the side.
You probably don’t want to work with a team that is resistant to change. While I’m not advocating for rewriting all your services in Go, you should definitely set aside a few hours to check out some esoteric tech over the weekend. You will be a better engineer for it.