A few days ago, someone on Hacker News asked: How do you keep improving? For a software engineer, after working for a while, the job starts to feel routine. The experience and knowledge you have accumulated are enough for your day-to-day work, and even if you never learn the new technologies, you can still get the tasks done the old way.

But software engineering is a very unusual profession. In many other fields, the knowledge people have built up since college does not go out of date so quickly, and the work gets easier as experience grows. In software, new technologies bloom everywhere: new languages, new frameworks, new protocols, and every new thing has its own distinctive way of solving problems. If you go several years without learning, without understanding the trends and the solutions available to you, the market may soon leave you behind, and finding your next job becomes much harder.

How Do You Know You Are Learning?

If lifelong learning matters this much, how do you tell whether you are actually learning? This article, Learning without a mentor: how to become an expert programmer on your own, offers a good test: if you are troubled and confused, if you feel clumsy and everything seems harder than you imagined, then you are learning. (If you’re irritated and a little confused, if you feel clumsy and everything seems harder than it should be: now you’re learning.)

What to Learn: Skills Adjacent to Your Greatest Strength

Knowing that you are learning is a start. Then what do you need to learn? Edmond Lau, the author of The Effective Engineer, has a good suggestion: Master Adjacent Disciplines. In it, he notes that many people are torn between learning a wide range of skills like a generalist and taking one ability to extreme depth, and wonder which is better for their career. His advice is to first find a field you are passionate about. If no direction particularly excites you, he suggests learning the skills adjacent to the one you are best at. A front-end engineer, besides web technologies, might learn some product design, API design and practice, and so on. If you are an infrastructure engineer, adjacent skills might be databases, basic web development, or machine learning. The benefit of learning adjacent skills is that at work you depend less on other people, and in more situations you can be self-sufficient.

How to Learn Efficiently: Teaching and Leaving Your Comfort Zone

Once you have a direction, how do you learn efficiently? The method many people recommend is teaching. Only when you need to teach do you properly examine what you know and internalize that knowledge. If you have no good opportunity to teach, you can also write a blog, like I do.

Switching to a different department in the same company, or changing companies, is also a great way to push yourself out of your comfort zone and force yourself to learn. Many people are drawn to whatever hot new technology is trending at the moment, but in truth many technologies are old wine in new bottles, and their core concepts do not differ much. What we should focus on learning is not technologies but skills. Take the front end as an example: the technologies are the various front-end frameworks like Angular, React, and Vue.js, while the skills are testing, debugging, architecture, and best practices. That is not to say technologies are unimportant. With good skills, many technologies can be picked up by analogy.

Practice in Volume, Learn by Doing

Learning only becomes valuable when you put it into practice. After you learn a skill, besides teaching it to internalize it, you gain real command of it by practicing a lot and building new products with your newly learned knowledge. Build as much as you can argues that to raise your skill to the next level, the best method is to hone it through a large volume of practice. The article tells of a pottery teacher who split the students into two groups: one group was told they would be graded on the quality of their pottery, the other on the total quantity produced. The result was that the group graded on quantity not only made more pottery, their pottery was better in quality too. The group graded on quality spent too much time thinking about how to do it well, while the students graded on quantity learned and grew from each mistake, and made the next piece faster and better.

I once asked a Facebook Engineering Director how a software engineer grows. His answer was simple: code, code, code. Keep writing code, write code more efficiently, write better, higher-quality code. Learn by doing, learn from mistakes, and you will keep improving into a better software engineer.

Comments and emails are welcome. If I got anything wrong, please point it out. If you repost this, please credit the source. Thank you.

Sources

This post was originally published on my former blog, 「半路出家軟體工程師在矽谷」, on May 5, 2017. The blog is now offline, and the text is preserved via the Wayback Machine. It has been lightly edited for this site.