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!

Need To Know: Why I Think Self-Driven Learners Make The Best Programmers

What makes a quality programmer? In a previous post I listed out five "personas" that I believe make an effective programmer: coder, investigator, theorist, logician, communicator. I still believe that each of these traits are essential to being an effective developer, but there's one trait that I left out that might be the single most important factor in determining whether a person will be an successful programmer: the drive to learn.

"Successful" programmers (for whatever that means to you) seem to have that in common; they are self-driven learners. They want to understand everything, want to break apart the black box to study it's insides. They need to know. It's why memes like this are so effective:

Two shots of a programmers, the first captioned

The joke, of course, being that sometimes we have no idea what we did wrong, or what we did right. But it's only funny because of this kernel of truth: we need to know why things work.

The Way Things Work

I distinctly remember a particular book that my dad got when I was little (about 9 or so) and being fascinated by the pictures and drawings that explained how things worked. The book was The Way Things Work by David Macaulay, and you can get the new edition from Amazon right now.

A screenshot of the book's cover

As a technically-minded young child, the book was fascinating to me in that it took at the things that I thought were simply magic and explained them, even if I didn't completely understand what the explanations meant (the book is written for teenagers). It told me that there was a reason for how things worked, that I could figure out what those reasons were and use them. Machines didn't seem like magic anymore; they seemed like something I could work on some day.

Whaddaya know, I guess today is "some day".

Point is, I wanted to learn about the world. To be fair, this is true of any small child; they have an innate desire to learn and understand the work around them. But my drive, my focus, was on these newfangled (at the time) machines people kept calling "computers". These magic boxes were portals to another world, in the same way that books are. I was spellbound by them, and I couldn't wait to learn more. That, it turned out, was the key to finding out that I enjoyed programming: realizing that I loved the act of learning as much (or more) than the act of coding.

As another anecdotal example, I regularly annoy my wife due to this desire to understand how and why things work. We went to Disneyland before we were married, and after every ride I'd be staring up into the darkened rafters or ahead to the lit tunnels and pathways, wondering what kinds of magic and machinery were up there controlling our ride, thinking about how I could sneak in there and find out just what made them tick. She just wanted the experience; for her, that was the end, but for me, it was only the beginning (sorry, babe).

Need to Know

I need to know. Doesn't matter what it is, I just need to know it. That can be dangerous (or even just time-wasting), but I think it's why I enjoy programming so much; technology changes so fast that there's always something for me to learn, to try, to fiddle with. I have an infinite sandbox where the only limits are time and imagination (and my own personal demons).

Does that make me, personally, a good programmer? Hell if I know. I got fired from my last job after all.

But it does make me enjoy it more. The rush of learning new things, the joy of actually putting what I've learned into practice, the elation of seeing it work for the first time. It's all part and parcel of the programmer's daily grind, and I love it.

I don't think you have to love writing code to be an effective developer. I don't even think the drive to learn is unique to our profession. But I do think that, without the drive to learn, without need to know, eventually you're going to get to a point where what you know isn't enough, and what you can learn won't catch you up. The torrent of new technology makes it easy to get lost in the wake, so we need to be constantly paddling, constantly learning, to keep abreast of the tide.

Question is, will you get swept away, or swept up? I'm aiming for the latter.

I Don't Care If I Suck, As Long As I'm Learning

I am an enormously self-critical person. If I'm going out to a party, or having dinner, or even just giving a presentation, I'm constantly playing back my speech and my actions in my head to see where I went wrong. It sounds like two awful television sports announcers who follow me around only to trash whatever I think or do or say.

DICK: And here comes Matthew, shuffling into the presentation arena, sporting a wrinkled button-down and black slacks with ugly shoes. He clearly wants to make an impression, Bob.

BOB: Right you are, Dick, though I'm not sure what kind of impression that will be.

DICK: The meeting has now started, and look at this! Matt is waving his arms around, trying to provide emphasis to his explanations! Has he lost control of his limbs?!.

BOB: He'd better rein in his enthusiasm here or he'll be mistaken for someone who is suffering a seizure.

DICK: Let's listen in.

MATTHEW: ...So here's why we might want to consider using SOLID principles in our everyday coding...

DICK: Did you hear that, Bob? All of those conditional words! "Might want to consider," wow! Could he be any less decisive?

BOB: I don't know, Dick, but obviously he doesn't know either.

I'm really hard on myself. I know this, and I accept it. I'm not sure if this is because I expect better or worse of me, but I do know that it leads to some really interesting conversations, during at least one of which I actually yelled at my own brain and startled the hell out of my dog.

Still, this state of mind is useful to me in my professional life. In an industry that expects us to keep with ever-changing technologies, being self-critical is important to our careers. After all, how can you know you need to improve on something without first being able to recognize that you're not good at it? In that vein, recognizing your shortcomings is a boon, a helpful reminder that you might need to work on some things.

After a while though, constantly reminding yourself that you suck gets rather disheartening.

I suck at jQuery, I should practice more, you think. But the next day it's I suck at mongoDB, I should practice more, then I suck at Technology X, I should practice more and eventually you're surrounded by demands from all sides to practice more, write more, DO MORE. It's never enough, and it'll never be enough, but you're not aware of that fact because you're too busy trying to keep up.

It didn't help that I was seemingly surrounded by more competent people than me, even though that was only my insecurity talking.

I'd see "rock star" programmers pass through my organization and think Wow, if I could have a tenth of his knowledge, I'd kick ass at Javascript. That other programmer might have been terrible at SQL, but he was a God of Javascript, and so I'd aspire to be like him. Anybody who was clearly better than I was at a particular aspect of development caused me immense envy. I was comparing the grand total of my technical knowledge with the best parts of theirs, and coming up short.

Hit your head against enough walls and eventually you realize that you have a headache. I'd gotten sick and tired of caring about what other people knew or didn't know, and so I found myself actively trying to stop being concerned about it. I had to reorient my mind, to focus on how I can improve my technical knowledge without comparing it to others. I had to stop making comparisons altogether.

The unexpected outcome of this was that, because I wasn't making comparisons anymore, I no longer cared whether I sucked at a particular technology. It just didn't matter.

The day all of this clicked into place, the day that I realized I didn't need to compare myself to anyone, was a glorious day. I was free, more free than I'd been in a long while, free to improve my development skills without the shackles of other people's perceived stardom binding me. I was free to learn what I wanted, when I wanted.

A sunrise over the ocean Sun rise at CuaLo by Handyhuy, used under license

With that freedom came a price, though; how could I know I was getting better if I couldn't compare my skills against anybody else's?

That's the paradox; if you no longer care whether or not you suck, how can you be assured that you are improving? I have a simple question that can give you the answer: are you learning? If the answer is yes, you're getting better. Otherwise, you may want to reconsider your position.

It took a while, but I finally discovered that the best way to offset my highly self-critical brain is to stop caring whether or not you suck, because it doesn't matter as long as you are learning.

Now if I could only get Dick and Bob to just shut up for a while. Does anybody see the remote? I'd like to change the channel.

We Don't Have Enough Teachers of Technology

Scott Hanselman has an post up called Bad UX and User Self-Blame - "I'm sorry, I'm not a computer person." It's an excellent read, and in it he discusses the phenomenon of users blaming themselves when something goes wrong when using a computer. Specifically he notes that older people and people who are new to technology feel this way often, saying that it's their fault something went wrong.

Hanselman wonders if the problem is abstractions (emphasis mine):

I think one of the main issues is that of abstractions. For us, as techies, there's abstractions but they are transparent. For our non-technical friends, the whole technical world is a big black box. While they may have a conceptual model in their mind on how something works, if that doesn't line up with the technical reality, well, they'll be googling for a while and will never find what they need.

I posted this article to Reddit, and the first comment on it was very interesting:

But at a certain point you have to understand how computers work in order to use them. I mean I wouldn't expect to be able to drive a car without understanding gears or roundabouts. I wouldn't expect to know how to read without understanding the alphabet.

Some things you have to learn. I guess the real problem is that computers are introduced to some people when they are long past the point of them being able to learn. Few people learn to read or drive at 50. And I imagine if you tried to teach someone how to read at 50 you'd quickly say MOVE!

In a way, this is also true. It's reasonable to expect people to understand just a little bit about the technology in use so that they can use it properly. But this comment is also kinda missing the point. The problem is not that users should have to learn something in order to use technology proficiently; the problem is that there aren't enough skilled, approachable teachers of technology.

Teaching is Hard

Ever tried to teach your grandparents how to use the internet? Often it's like you and they are speaking two different languages; they simply don't have any frame of reference for concepts like "browser" or "malware". On the other hand, those of us who grew up with the internet know these things like they're second nature, and that paradoxically makes it very difficult to explain to people. The things we take for granted are the things we have the hardest time explaining to others.

I'm a huge proponent of being able to explain yourself. In my eyes this "divide" between tech and non-tech people can be bridged via technical people becoming better teachers. There is a learning barrier in place between non-technical people and technology, and the people who can best assist those persons are the people who already live and breathe technology. We're the ones with the knowledge after all; we can't expect people who have no knowledge of how technology works to suddenly acquire that knowledge with no outside help. And who are the non-tech people going to get it from, if not us?

OK, great, so we should try to become teachers to the less-technically-inclined people in our lives. Sounds easy enough, right? But even if you have this lofty goal, though, teaching someone else can be difficult and frustrating.

One of the primary obstacles to learning is that the student has to actually want to learn, and not just acquire an answer for their current problem. There are some people who simply don't want to think, and there isn't a whole lot you can do for those people. My experience, however, says that this group is much smaller than we think.

Putting those people aside, if we are to help those who really want to learn, then we have to be able to determine what their level of proficiency is. Are they a total beginner, or do they have some relevant experience or knowledge that we can use as a launching point for learning about a technical topic? It's important to keep in mind that what they tell us they know and what they actually know are two different things, and part of the learning barrier is unreliable communication about what the student actually knows.

Once we've established a baseline about the student's knowledge, we can start to help them learn how to ask questions, both to people and search engines. Finding answers to your questions is really easy when you already know how to Google, but for people who have little understanding of how technology works, blindly Googling around probably isn't going to help them. It's often easier for non-tech people (hell, for the majority of people) to communicate with real persons rather than machines.

If all of this sounds, well, difficult, that's because it is. Why do you think there are so few good teachers? Because teaching is all about communication, and communication is hard.

The Solution Is Us

The ultimate goal of all this is simple: teaching someone else how to use technology should enable them to solve their own problems, and not have to rely on others to do it for them. This takes both confidence and skills, and a person who lacks one will eventually lack the other; a person with no confidence in his ability to learn may allow his skills to atrophy, while a person with no skills may lack the confidence needed to try, fail, and try again. It's a Catch-22.

The primary problem facing non-technical people today isn't that the technology doesn't work for them, it's that they face an uphill climb when trying to learn how to use it. There simply aren't enough technologically-savvy persons out there that have the patience and skills to help a novice learn how to use technology.

But there is a solution, and the solution is us.

Programmers, developers, web designers, technical managers, QA personnel, all IT people can be the solution. We can be the sherpas for the climb, the people who can actually make technology more accessible for those who are less savvy. If you are a developer, or designer, or other technical guy or girl who can help a non-tech person use technology better, consider this your wake-up call. Many of these people want help, and you are the one with the power to assist them in learning how to make technology work for them.

You can heed the call to be a teacher of technology, and consequently make life surrounded by it just a little bit easier for those who want to learn.