Software development is a well-paid job, and a lot of people assume it works like many other professions: you put in a few hard years of study, and after that you mostly apply what you know. It doesn’t work that way. Software development is skilled work, and in this industry skills lose their value quickly. A framework you know inside out today may be legacy in five years, and the specific tools you use every day may be gone sooner than that. So you have to keep learning, and since you can’t learn everything, you need a strategy for what to learn. I find it useful to treat learning like an investment. Some things pay off quickly and then stop being useful, others pay off slowly for decades, and part of the job is knowing which is which. This post covers what has helped me keep my skills relevant over the years: how to decide what to learn and what to skip, how to spot the skills that will last, when to jump on a new technology, how to combine skills, and some advice for developers who are getting older, because their situation is a bit different.

Learning needs a strategy

The problem isn’t a lack of learning material. It’s that there’s far too much of it. Without a plan, it’s easy to spend months on whatever looked interesting that week, such as a language you’ll never use at work or a framework that’s gone a year later. That time could have gone into something that actually moved your career forward. You don’t make visible progress, so it’s hard to stay motivated, and eventually learning starts to feel like a chore.

A strategy doesn’t have to be elaborate. You need a rough idea of where you want to be in two or three years, a short list of what you need to get there, and the discipline to put most of your learning time into that list. It also helps to know which skills complement the ones you already have. JavaScript and a front-end framework add more to a web designer’s skills than Go does, even if Go is the more interesting language.

Learn to say no to learning

What you choose not to learn matters as much as what you choose to learn. Before you commit weeks to something, ask a few questions:

• Is it part of the job you have, or the one you want? Read 20 job postings for the role you’re aiming at and count how often the skill appears, either as required or as nice to have.
• Does it build on what you already know? A skill that strengthens one you already have is usually worth more than an unrelated one, even a fashionable one.
• What do people you trust think? Colleagues and mentors who are a few years ahead of you can often tell you what has turned out to matter and what hasn’t.
• Do you need it now, or might you need it someday? Learning just in time, when a project needs something, sticks better than learning just in case, because you use it right away. Keep the “just in case” learning for fundamentals that you’re sure will pay off.

Personal interest is a valid reason too. Not everything has to pay off professionally, and curiosity keeps you engaged. Just be honest with yourself about which learning is investment and which is hobby.

Spotting the skills that will matter

Nobody can predict which technologies will win, but some signals are better than others:

• Job postings and surveys. Demand in job postings tells you what employers pay for today. The Stack Overflow Developer Survey and GitHub’s Octoverse report show what developers are adopting, year over year.
• The Thoughtworks Technology Radar. Twice a year, Thoughtworks publishes which tools and techniques it recommends to adopt, trial, assess or hold off on, based on its consultants’ experience across many client projects. It’s one of the few trend sources based on real project experience rather than marketing.
• Who is behind it, and the roadmap. A technology backed by a large, active community or a company that depends on it, with a public roadmap and regular releases, is a safer bet than one person’s side project, however clever.
• Adoption in production. Conference talks show what’s exciting. Talks about running something in production at scale show what’s lasting.
• The Lindy effect. For non-perishable things like ideas and technologies, the longer something has lasted, the longer it’s likely to last. SQL dates from the 1970s, HTTP and the Unix command line are decades old, and all of them are still everywhere. A JavaScript framework released last year might easily disappear by next year.

Combine these signals, and don’t rely on any one of them. Some technologies at the top of the hype cycle never make it, and some boring ones quietly become the industry standard.

Focus on the fundamentals

Fundamentals are the concepts every framework is built on: data structures and algorithms, how HTTP and networks work, how databases store data and handle transactions, concurrency, memory, operating systems, and the principles of software design. They last because they change far more slowly than the tools built on top of them. They also transfer. If you understand how HTTP caching works, you can pick up any web framework’s caching API in an afternoon. If you only know one framework’s API, you’re starting over when it goes away.

Fundamentals also matter for problem solving. Solving a hard problem means breaking it into smaller problems you can solve one at a time, and you can only do that if you can see what those smaller pieces are. If you don’t know how algorithms scale, you can’t explain why a feature is slow. If you don’t know how HTTP connections and DNS work, you can’t diagnose a slow network call. Knowing the fundamentals is what lets you see the pieces.

Learn some formal logic, and critical thinking

Formal logic is one of the most useful things a programmer can study, and few do. Every if statement is a proposition. SQL is built on relational algebra and predicate logic, and type systems are logic too. Even basic propositional logic pays off every day. De Morgan’s laws, for example, let you turn a confusing condition into a readable one:

// Hard to read
if (!(order.IsPaid && !order.IsCancelled))
{
    return;
}

// The same condition after applying De Morgan: !(A && B) == !A || !B
if (!order.IsPaid || order.IsCancelled)
{
    return;
}

At the more advanced end, formal methods use logic to prove properties of a design before anyone writes code. In a 2015 paper in Communications of the ACM, Amazon engineers described using the specification language TLA+ on systems including DynamoDB and S3. They found subtle bugs in distributed algorithms that testing and design reviews had missed. You don’t need to go that far to benefit. Learning to construct a valid argument and spot an invalid one makes you better at debugging, design discussions and code review.

A related skill is critical thinking in general: knowing how people fool themselves, how to judge evidence, and when a confident claim deserves doubt. One of the books that helped me most with this is The Skeptics’ Guide to the Universe by Steven Novella. It’s useful far beyond software.

When to jump on a new technology

I remember the early days of .NET Core well. What we now call ASP.NET Core was first announced as “ASP.NET vNext”, then released in preview as “ASP.NET 5”. It ran on DNX, a cross-platform .NET execution environment with its own command-line tools (dnx, dnu, dnvm), and projects were defined in project.json. Release Candidate 2 in 2016 replaced DNX with the dotnet CLI. The product was renamed ASP.NET Core before version 1.0, and a year later project.json was dropped in favor of csproj files. Everyone who learned the tooling early had to learn it again, some of it twice.

The ideas survived, though. Middleware, built-in dependency injection and cross-platform hosting are all still at the center of ASP.NET Core. That points to a reasonable strategy: learn the concepts of a promising technology early, and wait for a stable or long-term-support release before you invest deeply in its tooling or bet production systems on it.

Being early has real benefits:

• You can become the person who knows the new thing when your organization or the job market needs it.
• Your feedback and contributions can shape how the technology develops.
• Sometimes it gives you or your company a genuine head start on competitors.

It also has costs:

• APIs and tools change under you, as they did with .NET Core.
• Documentation is thin, and few people can answer your questions.
• Integration with existing systems is often rough.
• Security problems haven’t been found yet.
• The technology may not take off at all.

The Gartner Hype Cycle describes the usual pattern: a peak of inflated expectations, a trough of disillusionment, then a slow climb to real productivity. The best time to commit is usually once the technology is past the trough and starting that climb.

Combine skills

Being competent in two or three complementary areas often makes you more valuable than being excellent at one. There are plenty of very good C# developers. There are far fewer very good C# developers who also understand accounting well enough to talk to a finance team in their own language, or who can design a decent user interface, or who can run a project. Each combination is rarer than any of its parts, and that rarity is what you get paid for. It also helps if you ever start your own business, because then you need several of these skills at once.

The old phrase for someone with this kind of range is “Renaissance man”, after figures like Leonardo da Vinci. A more modern take is David Epstein’s Range (2019), which argues that people with broad experience often outperform early specialists in complex, fast-changing fields, precisely because they can borrow ideas from one area and apply them in another. You don’t have to choose between depth and breadth. Go deep in one area and build working knowledge in the ones around it.

Fields that combine well with software:

• A business domain: finance, healthcare, law, logistics, insurance. Developers who understand the domain build the right thing faster, and they become the people the business side asks first.
• Mathematics and statistics: for algorithms, data analysis, machine learning, and for reading performance numbers and A/B test results without fooling yourself.
• Writing: design documents, proposals, documentation and blog posts. Clear writing scales your influence beyond the meetings you attend.
• Design and psychology: user experience, accessibility and how people actually use software.
• Economics, product and marketing: how software makes money, what customers will pay for, and how to get a product in front of them.
• Creative fields: music, graphics, games and video. Combined with programming skills, they open up a whole category of interesting work.

Passion helps, but skill comes first

“Follow your passion” is common career advice, and there’s something to it. You learn faster when you care, and you’re more likely to stick with something hard. Cal Newport’s So Good They Can’t Ignore You (2012) makes a useful counterpoint, though: for many people, passion grows out of becoming good at something, not the other way around. If nothing excites you right now, that’s not a problem. Get good at something useful, and the interest often follows.

Learning as an investment: a rough ROI

You can borrow the return-on-investment formula from finance to compare learning options:

ROI = (gain - cost) / cost

The trap is underestimating the cost. A course might cost $500, but the 100 hours you spend on it are usually the bigger cost. Suppose you value an hour of your free time at $40. The real cost is then $4,500, not $500. The gain is uncertain too. If you think there’s about a 50% chance the skill gets you a $10,000 raise, the expected gain is about $5,000, and the ROI is about (5,000 – 4,500) / 4,500 ≈ 0.11. That’s positive, but far from the 900% you’d get by comparing the raise with the price of the course alone.

The numbers in that example are made up, and the exact result matters less than doing the exercise. It makes you think about how many hours something will really take, how likely it is to pay off, and how soon. The gain doesn’t have to be money, either. A new job, more interesting work, or simply enjoying what you do all count. If two options are close, choose the one that’s likely to keep its value longer.

Since I first wrote this post, AI has changed the calculation for some skills. I look at that separately in how developers should learn and work in the age of AI.

Advice for developers who are getting older

The industry skews young, and age bias in hiring is real, even where the law prohibits it. Experience is a genuine advantage, but only if you keep it current and make it visible. Here’s what I’d focus on:

• Stay hands-on. Keep writing and shipping code with current tools, even if your job has become mostly design or leadership. Nothing undermines years of experience faster than not knowing how a modern build pipeline works.
• Use your experience as context. “We tried that in 2012 and it failed” tends to shut a conversation down. “We tried that in 2012, it failed because of X, and here’s what’s different now” is the kind of judgment teams are glad to have.
• Shift your value toward judgment. Architecture, reliability, handling incidents, estimation, mentoring and deep domain knowledge are areas where experience counts for more than it does when writing code. Choose deliberately between the staff/principal engineer track and management. Both are legitimate, and drifting into either by default rarely ends well.
• Be selective with your time. Family and other commitments usually leave less free time for learning than you had at 25. Lean on learning just in time, try to learn through your job, and spend the “just in case” hours on fundamentals.
• Make your currency visible. Blog posts, conference or internal talks, open-source contributions and recent projects on your résumé all show that you’re still learning. Keep your résumé focused on the last 10 to 15 years.
• Invest in your network. Senior roles are often filled through referrals. The people you’ve worked with well over the years are your most valuable career asset.
• Build some financial resilience. Savings that would cover several months without income turn a layoff from a crisis into an inconvenience. They also let you turn down a bad job, or take a chance on consulting or a business of your own.
• Look after your health. A long career at a desk depends on sleep, exercise and a decent chair more than most of us like to admit.

If you think I’ve missed something important, share it in the comments. I’ll add it to the post and credit you by name.