on
Domain Expansion for Software Engineers
A few weeks ago, a friend in Japan—who’s a software engineer with experience in front-end, back-end, and mobile app development—asked me what he should learn first if he wants to pick up the infrastructure engineering domain.
Several years ago, another friend who also happened to be in Japan and worked as a software engineer—back-end with some front-end, I think—started learning cybersecurity. I observed that he was learning it by exploring the tools and learning how to operate them, as people usually do when trying out new programming languages or frameworks.
After thinking about both cases for a bit, I remembered that there had been a few cases where I observed people in the Indonesian tech industry trying to learn new domains such as data science, data engineering, and machine learning. They all made a move very similar to what my aspiring cybersecurity practitioner friend in Japan did, they started by learning the tools used for data science, data engineering, and machine learning, and tried building small hobby projects related to the topics.
Now, here’s the question: is it a good approach for learning new skills and expanding your domain?
Consider that I did this throughout the years:
- Started as a product development software engineer in 2013
- Became a security engineer briefly in 2016-2017
- Became a software engineer for VoIP system stuff, some data engineering, cloud platform, platform engineering, and cybersecurity starting in 2017
- Learned data science, machine learning, and deep learning in 2019-2021
You can bet that I did the exact same thing as the people I observed did at a few points.
While I’m not going to deny that starting from learning how to use the tools and building something out of it as hobby projects might work for some people, considering how many times I see people recommending that learning method, from my personal experience I don’t find it very effective to actually understand the domain.
The reason is that when you start by learning to operate the tools, you might be approaching it with the mindset of a software engineer trying to learn new programming languages, libraries, or frameworks. Without a significant enough goal to achieve with the tools—for example, building your first CRUD app with a new framework, in the context of learning a new programming framework—you might be losing direction when you’re learning the domain.
But the problem here is that you’re learning a new, unfamiliar domain. You probably don’t even have a good idea on what is a reasonable concrete accomplishment you can achieve with the tools yet. So you’re prone to setting an unrealistic goal which you’re incapable of achieving at that point, or setting a very low bar for the goal which feels too insignificant. Both will make you feel like you’re making no progress.
A solution to this is by enrolling in courses or getting yourself a more experienced person as a mentor to help direct your learning process and set the milestones for you to achieve. But in my case, I never really had a mentor to teach me stuff. So how do I do it?
I’m actually taking a very slow route to learn a domain: by building a network of related topics across domains in my head. A few people criticized me for taking such a slow route back in 2014-2016, and I did feel like I wasn’t progressing at all since all I learned feels like just another fun fact/trivia that I remember whenever I encounter something related to the topic. But once you reach a certain inflection point after you explored enough topics and made enough connections, it should enable you to adapt to new domains relatively quickly—especially STEM domains since they share quite a lot of similar fundamental concepts, but with different constraints unique to each field and different implementation mediums.
When you haven’t built enough connections between concepts to intuitively pick up a new domain that’s quite different from the domains you’re already familiar with, what you will need to do first and foremost is to make a mental model of the most important concepts within that domain.
For example, in the case of the person who asked me how to start learning the infrastructure engineering domain, I first explained to him the subdomains of infrastructure engineering, what is the purpose of each subdomain, and how the purpose is usually served. For the case of the person who was learning cybersecurity, I’d probably suggest he start by understanding the concept of the AAA framework (Authentication, Authorization, and Accounting), the CIA (Confidentiality, Integrity, Availability) triad, and modeling offensive and defensive security as a game with win and lose conditions for both sides. I didn’t really give the cybersecurity guy the explanation at the time because I saw that he preferred to explore by himself and the few hints I gave him were unsolicited already.
Last year, I wrote a different post about learning as a software engineer. It was about two opposing arguments I saw made by two different senior people in software engineering, so it’s entirely unrelated to what’s discussed in this post. But if you’re interested in topics related to personal development as a software engineer, you might find that interesting.