Be a software engineer - not a tech stack engineer
It’s a significant self-imposed limitation
In the profession of software engineering, I noticed that people often limit themselves to a particular tech stack and don’t want to move forward. Calling themselves Java Engineers, NodeJs Engineers, etc. Of course, there are people that are developing the language itself, but I’m not aiming for that. By doing so, and not wanting to expand your horizon, you quite probably limit yourself to both business opportunities, but also just learning more and advancing your skills.
In addition to forcing a bad tech stack to a particular problem. For example, forcing NodeJs to do some .pdf magic parsing whereas a Java popular library does it out of the box with minimum effort, it’s quite a strain. People are skipping job offers with the most amazing teams and companies and projects that are not their stack.
It’s in the principles — not the stack
Personally, I started with the JVM world and have a profound love for it. In the beginning, it was Java, but later on, I stumbled upon Kotlin and got amazed. So for a while, my tech stack was Java&Kotlin on the backend. I guess I was boring enough to persuade my colleagues to introduce it to our project. Thank you Alex & Victor! Of course, as a Java developer, it is my honour duty to always talk s!@#! about JavaScript, npm and the whole package. I think that every time a Java developer that works with JavaScript runs into a silly JS problem has to do the sigh and say Fu!@ing JavaScript. But as life likes to do to it, I ended up with my company on a project that is working exclusively with NodeJs and Typescript. Of course, I had previously mentioned moments.
Over time, I actually liked it. But most of all it made me realise something really important. I was doing the absolute same thing as I was doing with Java or Kotlin, just in a different language. Especially since TypeScript is so similar to Java, I needed one full working day to adapt and for people to not know that I’m actually a Java developer. It helped me realise, the principles are the same everywhere! What I didn’t know out of the box, I could easily find in the docs or google it. Because I know what to look for. (By the way, big shoutout to NestJs documentation. It’s amazing!) I needed an endpoint, ok, let’s see how to make that controller. Oh, I need to connect to my SQL database, ok, let’s see how they make repositories here. Event-driven time! Cool! Let’s see how they do that in this environment!
You are always solving similar or the same issues, the principles always apply! You are designing a REST API. You are setting up a Book entity that you want to save to your relational database. You are calculating the time to execute something. You are reaching out to some third-party API to send a notification. All those are tech stack agnostic. Clean code and readable code also follow. Yes, languages have their own conventions that could differ, but if you have a healthy approach to clean and readable code, you will do it everywhere.
So don’t limit yourself. Don’t skip that opportunity because you never typed that language. Take it as a challenge to learn more, you will advance most significantly!
So when someone asks a question that is related to the topic. I like to say that I’m a Software Engineer, not a Java Engineer. Thanks to that mindset I got one of the most wonderful opportunities to work at Decenter with an amazing team developing DefiSaver. Here, we work with Go, and that’s quite a shift compared to the previous languages. But it’s super fun, I can rely on my colleagues to help out where needed, but for the most part, I can develop without any issues.
One of my favourite approaches is the T-shape approach. You are familiar with multiple sides and stacks, but you are proficient in one area. For me, that was the JVM world. But I have grown to like Go so much that it might grow to be the proficiency I’m after. Know your architecture, know your software design, know your databases, etc. Don’t limit yourself to the language and be brave to experiment. It will be a wild and fun ride!