One of the most surprising things I’ve learnt about software engineers in Saigon is that many want to specialise in just one programming language or platform.
This is surprising to me because this attitude isn’t as common in Singapore. Software engineers in Singapore would at least say that learning new things is a good thing, even if they don’t really practice it.
But some Vietnamese engineers that I’ve spoken to have told me that they think learning new things – especially new things outside their circle of competence – is bad!
Some of them tell me that this is old Vietnamese wisdom: that if you specialise in more than one skill, you won’t be a master in any of them. Some tell me that their professors in University teach them to do this. And I am not the only one to have experienced this attitude: other software project managers have confirmed seeing this opinion in Saigon.
The net result is that I’ve met Vietnamese engineers who refuse to code in or learn platforms that are outside their selected speciality. For instance, Android engineers who refuse to touch iOS, or PHP engineers who refuse to write backends in any other language.
So which should you pick? Should you stick to one framework, or be the generalist that does all?
The answer to this isn’t that simple. It’s not true that one is good and the other bad. The real answer is this: whichever you pick, ensure your ability to learn new things does not disappear.
My main worry whenever I hear a Vietnamese engineer tell me that they don’t want to learn a new platform is that they’d forget how painful it is to learn something completely new.
This may sound strange if you’re fresh out of university, or currently an IT student. “Learning isn’t that painful!” you might say, “It’s normal!”
But give it a few years. Once you’ve spent 10 years, for example, getting good at iOS or PHP, you’ll find that learning something completely new can be very painful, especially in comparison to coding in a framework or language that you’re already an expert in.
This is especially dangerous in our industry, where things change quickly. Maybe today you’re a well-paid, valuable Android engineer. But if over the course of the next 5 years Android dies, or if Google decides to switch Android to a completely new language, you’ll be forced to learn something new or risk being unemployable.
Let’s be clear: the risk isn’t that you’ll suddenly get fired. The risk is that you’ll slowly get stuck in a company, never being promoted, and then when you’re finally let go you find that getting a job is suddenly a lot more difficult.
The flip side of this is that engineers who can learn quickly are often regarded as more valuable than engineers who can only do one thing. Companies like Google, for instance, never hire software engineers based purely on programming language skill: instead, they test programmers on algorithms and problem solving ability. Their reasoning? If you’re smart enough to pass an algorithms interview, you’re smart enough to pick up whatever language you’ll need to pick up at Google. More importantly, you’ll be smart enough to keep learning new languages as the company’s needs change.
There is, however, a flip side to this. It is true that constantly learning the shiniest new thing will come at the cost of being very good at one platform. You cannot become a master of one thing if you are dividing your time to learn many new things.
Also, I’ve met senior engineers in Vietnam who tell me that their families are more important to them. They don’t have that much time to learn new things, so why not spend it on getting good at the one thing that they already know and use? This is also true.
The truth is that both concerns are valid. This is why my argument isn’t to pick learning many things vs learning just one thing, but to ensure your ability to learn new things does not disappear. So long as you keep some base level of learning around, you’ll do fine regardless of which view you take.
This post is part of the FCS Career Guide for Software Engineers in Vietnam. Check the guide for more software engineering career advice.