obsolescence

Learn or Die: Warding Off My Coding Career's Eventual Obsolescence

I often give technical demos at my work about various topics, and the most recent one was an introduction to ASP.NET Core 1.0 that spawned a lot of blog posts. Overall, this class was well-received (at least I believe so, given that people keep showing up) so hopefully I'll get to continue doing these kinds of presentations.

At the end of these sessions, I generally "open the floor" for comments, questions, concerns, extended discussion and the like. During one of these recent classes, a coworker of mine asked about MVC 6's View Components, which are similar to Partial Views except they include functionality with them by being bound to a server-side class. Honestly they look pretty darn awesome, and I'll need to be writing a post about them.

Anyway, this attendee (we'll call him Liam) pointed out something that was frustrating him:

Liam: I just wanted to ask about those View Component things you just showed us.

Matthew: Sure, man.

Liam: They look a lot like User Controls from WebForms, don't they?

Matthew: What, the .ascx file things? I suppose so, but these are more in line with how MVC, and by extension the Web in general, operate.

Liam: It just seems to me that we keep going in circles. I feel like we did this 15 years ago, and now it's being presented back to us as "oh, here's this new thing we came up with, hope you enjoy it" but we already had it. It's not new.

Matthew: I suppose it can feel that way sometimes. Like we're not really doing anything new, just improvements on existing ideas.

Liam: Exactly! I feel like I have to constantly keep learning new ways to accomplish the same things, solve the same problems. After a while, it's kinda like, "what's the point?" I already know how to do this, why should I have to learn it again?

Five years by Michael Ruiz, used under license

I know the feeling. I have this saying that I trot out every so often, though I forget who said it first: "Half of everything you know will be obsolete in five years or sooner." It's a good reminder to me to stay sharp, keep working at it, don't get caught up in thinking I know everything, don't care whether you suck or not. But it's not easy, having an expiration date for your skills.

"Can't I Just Do What I Know?"

Liam was annoyed that things keep changing, and he has to keep up. This is understandable, considering that technology changes at lightning speed and we're still reacting to it at a human pace. Yeah, it's frustrating (and, given enough time, demoralizing) to have everything you know and understand change every X years. Why can't things just stay the way they are so I will continue to understand them? That would be easier for me.

To make matters worse, in Liam's mind, the new technology that I was demoing (ASP.NET MVC 6 View Components) was something that we already had in the form of User Controls for WebForms. Now, my opinion on the matter of WebForms is that they suck, but I can kind of see where Liam is coming from. Dammit, I already know how to do this, why I can't I just do what I know?

The short answer to that being, "go ahead."

Seriously. If that's what you want, and your customer understands and is OK with the benefits and drawbacks of your preferred technology, then go ahead and do what you know. Strictly speaking, we don't need to be constantly learning new things to continue solving problems. In fact, most of the problems we'll be faced with on a day-to-day basis are issues that someone else has probably already encountered and fixed. Only the technology being used to solve them changes. There are no new problems under the sun.

Inevitable Obsolescence

But, and this is a big but here, there will come a time where what we know, what we can do, is simply... outdated. It's going to happen to you, to me, to everyone. At that point, we'll have less competition for our skills (since most of our coworkers will have moved on), but also less potential customers for our work (unless you're a COBOL programmer, since apparently we'll need those people forever). There will come a point where what we know and what we can build doesn't cut it anymore. It will happen.

When it does, when your acquired skills and knowledge become obsolete, what will you do?

Two obsolete televisions, sitting in a trash pile.

Will you double down on your knowledge, becoming a big fish in the shrinking pond of a dying tech stack? Or will you try to bring your skills up to date? Every piece of software ever written has an expiration date, and by extension, the skills necessary to create that exact piece of software again will also expire. When your skills expire, how will you react?

If we do nothing, if we learn nothing, there will come a day when our skills, our intimate knowledge of any given tech stack or pattern or language, will no longer be useful to us or anyone else. Will we cling to that knowledge, trying to restore the safe harbor it once held for us? Or will we set sail into the infinite abyss of the unknown, attempting to catch something, anything that will allow us to keep on keeping on for another five years?

C'mon. You already know what the answer is.

Go DO Stuff!

Go learn. Read books, read blog posts, try things. Teach others. Give a talk at a conference, or even just present something small to your coworkers. Go be an investigator. And while you are learning, fail at something. Might as well get used to that, as every single person you know will fail at one time or another.

Go do something. Even if it's just writing "Hello World!" in a new language. Anything we learn can help us stave off our career's eventual obsolescence. Future you will thank you for the effort you put in now.

What about you, readers? How do you prevent your career's obsolescence? Do you read, teach, write? Which of these has worked the best for you? Do you need some assistance getting started with learning a new stack, or pattern, or language? Share in the comments!

Happy Learning!

The Ultimate Fate of All Software

Some realizations come slowly, but some hit you like a freight train. I had one of those this week while working on the latest change to the PAE system we've worked so hard on. It was a good change, one I was happy to implement and am sure the customers will want and use.

So why was I so down?

I couldn't place the source of my worry. I love my job; I get to teach and learn every day. So what was this black cloud of trepidation that was now haunting me?

There was no warning, and suddenly that freight train collided with me. I realized that I was writing yet another codebase that would slowly, surely, inevitably, fall into obsolescence. It wouldn't happen tomorrow, but it would happen.

There's no avoiding it, I realized, everything I write is doomed to fade away.

This thought had me reeling. What good was my code doing if its only fate was to be used and discarded like some child's toy? How can I make a difference to my field, my company, my career if nothing I write will ever last long enough to show to my children when they are old enough to understand what it means? Is everything I do destined to decay and be replaced (or, in management speak, "rewritten")?

Of course, nothing lasts forever. I know this. But software isn't even on the same time scale. Bridges, buildings, other "typical" engineering produces results that can last for tens, even hundreds of years. Software is lucky to last for five years before becoming obsolete, and often the time frame is much shorter than that. Everything I write, everything I design, will become useless within my lifetime. I get to watch all of my projects, the totality of my development career, fall into oblivion.

This can't be all I'm good for, I thought. There must be something more to this field than writing disposable methods and replaceable applications. I matter, dammit! So my code should matter too! It should last, be useful, be important forever! After all, I made it, so it will be perfect. Right?

Right?!

All software is destined to become obsolete and be replaced by something bigger, better, more powerful. This is its ultimate fate.

The ideas behind the code we write may survive the test of time, but the code itself will not. Our work, the applications and websites we pour our sweat and tears and time into, none of them will matter in the grand scheme of things. Nothing we program will have any lasting, usable impact on future generations of developers (unless you get lucky or are really, really good).

That sucks. A lot. I mean, if everything I write is going to die (in a manner of speaking) why bother writing it in the first place? What difference could it possibly make? It's pointless.

I found myself needing to get away from my desk and take a walk. I hurried through the office, down the stairs, and out onto the roof of the adjacent parking garage. The desert sun beat down on me, hot but refreshing, as I gathered my thoughts.

A short time later, I'd thought it through. All software has a time limit, an inexorable march to obsolescence that not even the greatest programmer alive could halt. The countdown starts the moment you declare the application starts being used.

But you know what? I was overthinking the entire damn thing. It all boiled down to one simple statement: It's just code.

If you were expecting some earth-shattering conclusion, I apologise for disappointing you. I was let down as well. But, really, programming is only what I do, it's not who I am. I am not my code.

I returned to my desk, ready to keep chugging along. Sure, the code I write will eventually become old, creaky, just plain bad, and will be replaced. And that's OK, because ultimately it's just code. Nothing more.

Now the only trick left is to remember that when I'm rewriting my own projects in five years. And five years after that, and five years after that...