Skip to content

Keeping your skillset fresh as a developer

Whether you’re committing 30 minutes or 3 hours a day to learning, consistency is key. Klint Finley asks 3 tech professionals at different stages in their career for more advice.

Keeping your skillset fresh as a developer

If there’s one thing that everyone agrees on in the fast-changing world of software, it’s that developers and other tech professionals need to be constantly learning in order to keep their skills fresh and relevant. On the one hand, that’s easier than ever with the wealth of resources available, from books to online classes to YouTube tutorials. There are more programming languages, database systems, cloud platforms, and other technologies than anyone could ever learn. So how do you decide what to spend your precious time learning? And how much time should you commit to learning new technologies?

To answer your questions about keeping your skillset fresh, The ReadME Project’s senior editor Klint Finley gathered a panel of three tech professionals at different stages of their careers. Let’s meet our panelists:

Headshot photograph of Karhik Iyer Karthik Iyer is a software engineer at JPMorgan Chase. He graduated from IIT Roorkee in June of 2021. He’s been a Google Summer of Code candidate twice and loves anything related to software used in films and likes to read about computer graphics.

Headshot photograph of Monica PowellMonica Powell is a senior software engineer at Newsela, a GitHub Star, and founder of React Robins. She’s passionate about making open source more approachable, elevating people through technology, and cultivating communities.

Headshot photograph of Dan Kuebrich Dan Kuebrich is VP of platform engineering at FullStory. He previously spent a decade working on distributed tracing and observability as co-founder of Tracelytics. He likes games, making things, and biking around town with his family.

Klint: How do you decide what to invest your time into learning?

Monica: I’m guided by what I’m working on at the moment and what I’m trying to accomplish. In my first job, I was doing a lot of work with React, but I didn’t have much experience in it. I had to get familiar quickly, and I spent a lot of my own time rebuilding my personal website in React, going beyond what was required for me at work, and deepening my understanding of the library and its ecosystem. If there’s a job I’m interested in, I’ll research what types of technologies I need for that role.

When I’m not heads-down learning things for work, I have the bandwidth to be more exploratory and enjoy using my side projects to investigate cool new technologies that I want to examine that might not be immediately useful at work. Right now, for example, I’m looking into different 3D libraries. The concepts between different frameworks or cloud platforms are usually pretty transferable, so I focus on learning particular areas rather than get bogged down worrying about which specific tool to learn.

Karthik: I’m early in my career, so I feel like I still have quite a bit to learn. I tend to think big picture about areas of expertise, like networking or machine learning, rather than specific technologies. The networking concepts from Amazon Web Services will be broadly applicable to Microsoft Azure, as Monica said, so I try not to overthink which specific tools to learn and think more about the direction I’d like to take my career. Besides that, I follow a good set of more experienced people on Twitter and pay attention to what they’re learning and what tools they’re using. When I hear about something interesting, I Google it and maybe watch a few YouTube videos and then decide whether it’s something I want to dive into. You never know what skills are going to be useful in the future, and focusing on what interests me keeps me engaged.

Dan: As Karthik said, there are a set of broadly-applicable principles and skills. I’d also argue that the way to really learn a technology is to build something with it that someone can actually use and then maintain it over time. I try to focus on technologies I actually need to use today, to solve a real problem. When you’re learning something new for the sake of learning, make sure it’s actually something new: One MVC framework will likely be similar to the next one, just as relational databases tend to be similar to each other, and so on. But a functional programming language might be fairly different from an object-oriented one, and a statically typed language will be different from a dynamically typed one. You’ll learn more deeply by picking something truly different than what you’re used to.

Klint: Conversely, how do you decide NOT to learn something? What makes you scratch something off the list or move it to the “not right now” category?

Dan: I usually only reach for a new tool if there’s an overwhelmingly compelling reason to use it instead of what we’re already using. So if there’s no clear reason that the new thing is preferable, I say skip it and make your existing tools do the job. I’m a big advocate for having a small set of tools that you know well.

Monica: I agree. If something doesn’t solve the sorts of problems I’m working on, I’m not going to spend time learning it. It’s fun to learn for the sake of learning, but if I try to learn too many things at once I don’t get the depth I want. To narrow things down, I think about how the things I want to learn complement what I’m working on and my goals. For example, I recently decided not to spend much time on emerging serverless databases. I’ve done some exploration of different options, but they don’t really fit into the work I’m doing. For my personal projects, I’m able to leverage serverless functions instead of a database. It’s not that I don’t want to learn more about serverless databases eventually, but it’s just not something I need immediately.

Karthik: I try not to write things off without learning a little about them first. I know that machine learning is a field that is advancing rapidly. Still, when I started with the beginner resources in ML, I felt that, because of the mathematics involved, it wasn’t for me, so I ended up focusing on the data visualization side. But I gave ML a fair try first, and it’s something I might come back to. Just because others are doing it doesn’t mean that you have to do it if it doesn’t grab your interest. Although I try not to be dismissive, it doesn’t necessarily make a lot of sense to spend time on legacy technologies if you’re not actively using them at work. It’s worth paying attention to what sorts of platforms are being phased out.

Klint: What skills have you learned that ended up being the most transferable? What skills make learning other skills or technologies easier?

Karthik: The basics of computer science, like data structures and algorithms. I worked with C++ throughout university and now primarily work with Java, but the underlying principles were transferable. The design patterns and architectural principles of a Python application can be applied in Java. The principles of functional programming are applicable in Rust, even if you learned them through Haskell.

Dan: That’s exactly right. I suppose I can go a layer deeper, below computer science. When I was a kid, if we had a question at the dinner table, my dad would get the dictionary or an encyclopedia and answer the question. Of course, now you can just Google the answer to just about any question, but what that showed me was that with a little initiative, you can find the answers to your questions yourself. That principle helped me in college when I was studying operating systems. I had to read code and documentation to find the answers to my questions. And it serves me well to this day. If I have a question about some software, I start grepping. I find many of the questions I might have are answered in git logs or Slack logs somewhere. Sometimes it’s best just to ask someone who knows, but getting good at finding answers for yourself pays dividends: You’ll get faster at it and gain more intuition about when to search for an answer and when to ask for help.

Monica: For me, it would be accessibility. It’s applicable to any website. Learning to audit a website or product for accessibility issues is valuable regardless of the language or framework used. Relatedly, understanding web performance, which can be viewed as a subset of accessibility, is extremely useful. I want sites to load quickly, even on slow connections, so that users can access a site’s core functionality regardless of their internet speed. Both accessibility and performance are beneficial from job to job. The most important transferable skill, however, is learning how you learn most effectively. Once you better understand your learning style, you’ll learn more quickly and have more fun doing it. And as far as specific tools are concerned, learning Git has been extremely valuable and portable across roles.

Klint: How much time do you commit to learning? Where do you fit it into your schedule? Do you commit work hours “on the clock” to training or do you mostly learn during your free time?

Karthik: I don’t really have a set formula, but I definitely try to spend some time at work, say half an hour to read books or watch tutorials. But every day is different. If I’m doing something for myself, say for an open source project I’m working on, I’ll do that in my personal time after work. Apart from when my work schedule is very heavy, sparing half an hour a day to upskill is pretty doable.

Dan: My company has a program in engineering called “sharpen the saw time,” where folks are able to take advantage of up to four hours per week for learning, whether that’s reading a book or taking a course or something else. But the best way to learn is to have a job that pushes your boundaries. Then there’s little difference between time spent “on the job” and time spent doing the job because you’re almost always learning. In part, that’s down to finding the right job. The other part is about applying yourself. Sometimes that means thinking beyond your immediate responsibilities, as Monica did with React, and trying to understand additional layers of your organization’s tech stack. Maybe it’s looking at the little nuisances in your workflow to find ways to make it better. There are so many things we interact with in our day-to-day work that we could better understand. Applying a little curiosity to your current role will help you grow constantly, not just when you’re sitting down with a book or a tutorial.

Monica: Yes, I’ve done a lot of on-the-job learning, especially when starting out in a new role. How much time I commit to learning each day really varies. Sometimes I go into learning overdrive, like I did during my first software development job. Every day I learned something new at work. Outside of work, I build projects with the same sorts of tools I use during the work day so that I can understand how different parts of a web application fit together, even the parts I don’t contribute to at work. I build better mental models and better understand where my work fits into the bigger picture.

I like to have small, achievable goals. It’s easy to feel like you’re not making any progress when you’re only spending around 30 minutes at a time. I recommend the book Atomic Habits by James Clear. Last year I learned more about art by drawing something every day. It was hard to see the progress at first, but spending half an hour per day really adds up over time. It’s the same way with technical skills. The important thing is consistency.

The ReadME Project is a GitHub platform dedicated to highlighting the best from the open source software community—the people and tech behind projects you use every day. Sign up for a monthly newsletter to receive new stories, best practices and opinions developed for The ReadME Project, as well as great listens and reads from around the community.

Explore more from GitHub



See what’s happening in the open source community.
GitHub Universe 2024

GitHub Universe 2024

Get tickets to the 10th anniversary of our global developer event on AI, DevEx, and security.
GitHub Copilot

GitHub Copilot

Don't fly solo. Try 30 days for free.
Work at GitHub!

Work at GitHub!

Check out our current job openings.