on
Learning as a Software Engineer
Recently, I saw an argument in Indonesian tech Twitter where a relatively well-known tech leader in the Indonesian tech scene stated that if as a software engineer, we don’t learn one or two new technical things every week, we’re a bad engineer. Coincidentally, not too long after that, I found this video by Healthy Software Developer on YouTube, in which he argued that addiction to learning new technologies and techniques is actually counterproductive for programmers.
As someone who spends their free time learning a lot of random things, I have my own opinion on this, which I’d like to share here. But first, let’s check their arguments.
Looking at the Arguments
Argument #1: Weekly Exploration of New Technologies or Techniques is Mandatory
This argument has its merits, and I can see its point.
In our career progression as a software engineer, assuming a normal career progression, when we start as a junior software engineer, we don’t need to know a lot of things as we have more senior engineers guiding us at work. But as we become more senior, we’re expected to know more things and be able to navigate through the problems we’re facing ourselves.
The more technologies and techniques you know, the more options you have when approaching problems you encounter when developing and maintaining software at work.
Argument #2: Addiction to Learning New Technologies or Techniques is Counterproductive
This argument also has its point.
As a software engineer, hands-on technical skills aren’t everything there is for us to learn. In fact, a lot of the skills we need to perform at work aren’t even technical at all. Also, generally, if you know the fundamental concepts of computer science and systems architecture well enough, you should be able to adapt to new technologies and understand new techniques quickly even if you never touched them before.
In my own experience, there were situations where I came up with an approach myself, and a few years later I found out that someone else also did that and the technique has a name.
The “Correct” Approach
Looking at these two arguments actually reminds me of an argument I had with someone more senior than me in the Indonesian tech scene, who was training me to be a good lead engineer or engineering manager. We had some differences, mainly as follows:
- He argued that I should spend more of my time learning new technologies and techniques, while also being more hands-on at work so I won’t lose respect from those who report to me. I argued that learning the technical stuff isn’t as necessary since I can pick it up relatively quickly if needed, I should focus on high-level problem-solving skills and team management skills instead, to not lead the team in the wrong direction and make sure their needs aren’t neglected.
- He argued that I shouldn’t waste too much of my time learning about domains unrelated to software engineering and work in general, since the time could be allocated to building up my career and climbing the corporate ladder faster. I argued that I should learn as many things outside software engineering and work in general to expand my horizon so that when I end up higher on the corporate ladder I’m more mature and can think about the bigger picture from multiple perspectives.
Note that I argued against putting too much into learning new technologies and techniques because I was confident I could pick up any new technologies and techniques quickly if needed. At that point in my career, I had a history of doing the following things at work:
- Learned Ruby on Rails from zero in one morning during the first day at my first job straight out of college, and was able to build a few things with Ruby on Rails by the afternoon of the same day.
- Reverse-engineered software built by another company and reused its components to improve the system at the company where I was working.
- Learned how to do web application and network pentests on my own.
- Built a user-space device driver for a piece of custom hardware required for the company I was working at, not realizing what I built could be considered a device driver.
- Designed and built an anti-phishing system that’s able to detect whenever a new phishing site impersonating our website is up and then permanently take it down within 1 hour.
- Learned how VoIP works, dug into SIP protocol internals and Asterisk’s implementation of it, modified Elastix VoIP appliance, and developed an application on top of it all within two weeks.
So I already had a history of figuring out various new technologies and picking up various new skills by myself when it was needed on the job, and delivering relatively quickly despite that. Hence, for me personally, I don’t put learning new technologies and techniques as the highest priority as I’m quite confident I can figure out practically everything as long as I have some idea of the underlying concept on which the technologies and techniques are developed.
Given the situation with my technical capabilities, I consider my naturally low communication skills and my general lack of ability to understand people’s perspectives and feelings as the more pressing matter for me to be able to work in the role of a lead engineer or an engineering manager (I was just recently promoted to be a lead engineer). So instead, I spent a lot of time studying anthropology, culture, and psychology to help me connect better with my direct reports, while also studying mathematics and other branches of engineering such as electrical engineering and mechanical engineering in order to acquire a better sense on how things work and how they are built so I can give better technical directions to my team.
But the person who mentored me had a different situation. He has a good sense of business and product for a software engineer while being quite strong technically as he knows several technologies relatively well, enough to understand how they work at a deeper level. His technical prowess seems to mainly come from him putting the effort into understanding each technology individually. His knowledge of fundamental computer science concepts such as algorithms and data structures is decent, and he leveraged it to reason around the technologies he studied.
Despite that, from what I observed, he wasn’t able to make the connection between the core concepts and the technologies he was dealing with as quickly as I could. So it explains why the correct strategy for him was to learn new technologies and techniques as much as it makes sense to him (primarily the technologies that are commonly used in his domain of work). He’s more naturally in tune with other people and can connect with them more easily than I’m able to, and he doesn’t seem to have as much problem aligning himself to the business goals. This ability to align himself to the business goals allowed him to climb the corporate ladder faster, as when he was mentoring me I was just promoted to a lead position while he was already a director-level personnel at the company he was working at.
Conclusion
At this point, I think it should be obvious that there’s no one-size-fits-all approach to the learning strategy as a software engineer.
I wouldn’t necessarily say that an engineer who doesn’t learn one or two new technologies and techniques per week is a bad engineer since someone with relatively strong fundamentals of computer science, electrical/computer engineering, and systems architecture should be able to leverage that fundamental knowledge to pick up things very quickly when needed.
But for those who aren’t able to pick things up as fast by relying on just the fundamental knowledge they’ve previously learned, learning relevant new technologies and techniques every month might be good to keep expanding their technical knowledge. Asking someone to learn new technologies every week might be too much for me, and not everything might be relevant to what they’re aiming for.
I think in the end it really depends on what learning approach works best for you, what your goals are, and how you’re planning to achieve those goals. After all, one’s definition of a bad engineer might not be the same as another person’s. How they define a good engineer and a bad engineer reflects what they value from being a software engineer, which might give us a glimpse into what kind of engineer they’re aspiring to be and how that aspiration shapes their biases.