I once made a “resume” video to prove I could ship a real application with Microsoft LightSwitch. I watched Silverlight projects dry up around me, and I thought a polished demo would protect me from the next round of change.

Watch the 45-second LightSwitch resume video on YouTube:

What do you think of my light switch skills?

A few months later, LightSwitch joined Silverlight on the list of things dead stacks. I spent much time and credibility learning a tool that was not solving a problem for anyone. That is one of the many times I’ve seen what the bleeding edge really costs.

It was the same lesson the CTPS had taught me thirty years earlier: a tool is only worth learning if it solves a real, painful problem for a real person.

It was not the first time I bled. I’ve had to chase enough new releases to know the pattern: a technology gets announced, people call it the future, and a year later we are rewriting what we built because the tool is gone or the problem never appeared. The lesson was to keep learning and to start with a reason.

Now, when I ask whether to deepen an existing skill or move to a new one, I look at three things:

• the problem I am trying to solve,
• the people who live with that problem, and
• the direction I want my career to go.

If those do not line up, the tool becomes inventory.

Every major bet I have made matched my values with the values of the company, the needs of the community around me, and the direction of the industry. When I joined Improving, it was because the work let me focus on problem-solving and teaching, not on defending a favorite stack.

When I stepped away from .NET to spend some years in Ruby on Rails, people asked if I was afraid I would lose my C# skills. I was not. I had already internalized design patterns, test-driven design, and the habit of naming intent in code. When I came back to .NET, the language had moved in several ways, but the thinking had not. The developers who were still writing year-one code after 15 years had not fallen behind on syntax. They had stopped moving their thinking forward. I did not want to be in that group. So I left room to be a beginner in a new language while keeping my principles sharp.

The decision is whether the next thing serves the life you are building. Years ago I helped FoxPro developers move to .NET. Some still had a decade of work ahead of them and wanted to learn deeply. Others were two or three years from retirement and told me, “Thank you for the effort, but I have what I need. Right now I just want to learn where to buy fishing gear when I retire.” Both answers were right because both matched the person’s goals. Moving on and staying put are both fine. The error is making the choice without asking What Are You Optimizing For.

If you are early in your career, you will recover from choosing wrong. The real trap is choosing nothing because everything feels urgent. Pick one framework or language, build a small project with it for three months, document what you learn, and then re-evaluate. Pick a second one, do the same, and compare. What problem does each solve that the other does not? Does that problem show up in your work? Does it show up in your company’s work? Does it matter to you? If the answer is no, you have learned enough to stop. Curiosity is a good reason to look; solving a real problem is a better reason to stay.

I have refined a note-taking process for about 25 years. The tools have changed: I used Evernote for more than a decade, and now I use Obsidian. The process evolves continuously. I rely on the system to hold the facts. I try to remember the path back to them. Every quarter or so I look at my tags and categories and ask whether they still match how I think. The label I called “user-stories” at one point was later changed to “human-stories.” If my thinking has moved, my system should move with it. The tool is just the shelf; the process is the library.

This series started with a question in the first post: Will AI take my job? The framework is the same one I use for any new tool. What problem does AI solve, for whom, and does it match what I am trying to do? If I am only reading and writing code inside one language and one framework, then AI can do much of that work. If I am trying to understand the problem, name the intent, and help a real person make a decision, then AI is a collaborator, not a replacement. Syntax knowledge is not enough. The work goes to the person who can move from the problem to the person to the purpose and back again.

Tools will keep changing. The way to keep your job is to choose work where the tool is not the point.

Further reading

• What Are You Optimizing For
• Pace Yourself
• Look for the Complete Story and Find Consistency Over Intensity
• Reflection Over Resolutions