Never Stop Learning

We can’t really become too complacent with our skills

You’re a software engineer. You consider yourself very skilled with this language or that library, etc. This comes with the territory. Even though many of us didn’t really have strong preferences about the technologies we use daily at work at first, we all tend to end up preferring the tech we’re most comfortable and productive with.

Alright, well, it can also be said that you don’t know the tech you consider yourself an expert in as well as you think you do. Let’s say you’ve worked with React for a few years now and have used Context, Redux, custom hooks, React Router, etc., more times than you can count. Can you still write the boilerplate for each of these things without looking at the docs? Probably not! Some, certainly; but not all.

This was a recent realization of mine. I did another tech interview for a position that seems like a great fit. When the interview was scheduled, the recruiter told me to at least familiarize myself with React Query as it would be part of the interview. Considering that I learn by diving in and experimenting, it seemed natural to spin up a small project this weekend using React Query just to get a feel for its basics.

While choosing my tech stack, I started thinking about all the things that could come up in the interview that might need a little refresher. I realized Formik and React Context were two technologies I should probably use as well — not because they made sense for my project but for the sake of practice. I used both almost daily during my 5.5 years at Indeed, but it occurred to me that most of the time, I was editing existing files rather than creating new ones from scratch.

While our familiarity with the tech we use daily persists, we tend to forget some of its facets. New libraries, frameworks, and languages are constantly emerging, often solving problems better than what we’ve been using up to this point. Additionally, there are likely certain aspects and features of the tech we use that we never learned in the first place. As engineers, we can’t become complacent with our knowledge and skills since things change so quickly. We also have to circle back from time to time to refresh our knowledge since we don’t use every part of every technology every day.

Whether you want to level up or not, you’ll have to learn new things

Learning is part of the job. I’d wager that it’s likely a part of most jobs, but especially so in any engineering field. Even if you decide you’ve finally landed that lead or staff engineer role and you’re done trying to level up at this point, you’ll still have to constantly learn since the tech we use is always changing. In this field, being an “expert” with some tech is a short-lived thing unless you keep up with incoming changes — and there will almost always be changes.

I experienced this phenomenon firsthand this weekend while setting up my weird little project to get some basic familiarity with React Query. I’ve used many patterns for setting up React Context over the years, but when I searched for boilerplate code to stub out my file, I realized there was yet another “preferred” way to do it—at least for now. It’ll change again and again too. While this can be annoying, I get it. The thing that makes it okay for me is that the general idea of how to use something rarely changes; only the patterns and implementation evolve. Maybe there will be more API changes in the future, but unless the dev team realizes a completely different approach with substantial gains, even these changes will be relatively minor and quick to understand.

As new tech grows in popularity, there’s also the hype and peer pressure that can lead you, your team lead, or your company eventually adopting it. Remember writing unit tests with Mocha and Jasmine? I bet you don’t use either anymore! I also can’t tell you when I last used Rails, Bootstrap, Foundation, jQuery, etc. I managed to survive in the web development world for years after React’s release before finally learning it. Before working at Indeed, I’d had a ton of experience with Angular — it was what I always used. But since Indeed used React, between accepting my offer and starting there, I learned React. Even after beginning at Indeed, I had to learn function components with hooks because that change happened during my tenure there. Then I moved from using TestCafe to Playwright for E2E testing.

You really don’t get the option to stop learning unless you’re an old-school expert Cobol programmer writing your own paycheck because you’re one of the only people left who’s an expert in a language that might be older than you and is still used in banking software!

How I choose what to teach myself next

Decision paralysis can set in if you sit down with the intention of diving into something new. What do you learn? If you’re like me, you view the time you spend learning new technologies as an investment in your future and want to make that investment wisely.

I approach this by splitting things up into a few different categories. First and most importantly: is there something new I should learn that I’ll use at my job? I prioritize this above all because our jobs are what allow us to afford to live, so this category always gets top priority in my book. If there isn’t anything new being discussed at work, consider getting familiar with the next major version of a library or framework you already use. For web developers: are you aware of the latest ES features and proposals? There’s plenty to think about when it comes to keeping your skills sharp for your job — especially if you want to level up.

After that, I look at what new technologies would suit my needs for any side projects I’m interested in. This site is a great example — I went all-in with Astro and Tailwind for the first time after previously using Gatsby or Next with styled-components. The last version of my portfolio used Vue and Nuxt just because I knew that combo could generate static sites and I wanted to try Vue (I actually really liked it). React is now the common library for which I reach, but there are still things I can change even if I stick with React. Hell, I played around with Deno, Fresh, and Preact just because I was curious.

Finally, there’s the “I’ve always wanted to learn this tech” category that I prioritize last. I was very interested in learning Rust after reading about it, so I spent some time playing with it. I wouldn’t apply for a Senior Engineer in Rust role because I’m not an expert — but I do have a basic understanding of how it works and could see myself picking it back up someday. I’ve also been interested in the Godot engine for game development and even bought some courses on it. While I haven’t spent much time with Godot yet, I at least know I’d enjoy using it if I ever decide to dive into game dev.

One of the great things about experimenting with new technologies — even those that don’t apply directly to your current career — is that you expand your understanding of programming in general. A staff engineer once told me that a good software engineer can be productive in any language, even one they’ve never used before. Sure, we get comfortable with certain languages and frameworks over time because we memorize patterns and syntax. But at its core, programming is about understanding data structures and algorithms — and occasionally dabbling in very different languages can expand your understanding of these fundamentals.

I realized I’d reached this point when I was able to some backend code in Kotlin even though I’d never touched the language before. I just looked up the available data structures and methods and chose what best solved my problem. While you shouldn’t expect to do this all the time, there’s definitely value in creating things with technologies outside your usual toolkit — especially if they’re drastically different from what you normally work with.

Part software engineer, part student

I won’t touch the “engineer vs developer” debate with a ten-foot pole! Regardless of what title you have, if you write code, you’re also a student! If you have a comp-sci degree, you really just learned theroretical foundations of programming. If you have many years of experience, you’ve likely learned a lot that is useful along with a lot that will soon be outdated. You’ve probably forgotten more obselete info than you currently know. We don’t have the option to stop learning in this field. Honestly, that’s part of the appeal to me. Until my brain loses enough plasticity that this need to be constantly learning because problematic, I’m happy to do it and I don’t see that day arriving for probably another couple of decades.