learning

Code Is Ephemeral, Concepts Are Eternal

Lots of people ask me things like "should I learn MVC or Web API first?" "HTML or Javascript?" "Angular or React?" etc. After all, there's only so many hours in the day, and what time we have to spend learning is often limited by other factors (energy, work policies, etc.) This leads to the most common question I get from junior programmers: What framework, stack, or language should I spend my precious time learning?

I always tell them the same thing: It. Does. Not. Matter.

It doesn't matter if you pick Angular, or ASP.NET, or Ruby, or Java. It does not matter if you want to build web sites, or IOS apps, or Windows programs. It does not matter if you're a fresh-out-of-school graduate or a 30-year programming veteran. All of these technologies, all of these platforms, will ultimately help you learn the same things, the same tried-and-true best practices. Just pick one!

Remember: you will be obsolescent someday. That will happen, especially in a business where you must continually stay on top of your own learning in order to do your job. You have a finite number of keystrokes left. Therefore you should spend your limited time learning whatever will stave off that obsolescence for as long as possible.

Concepts fight obsolescence. Even when ASP.NET inevitably dies, the concepts I've learned from programming in it for ten plus years will still be useful. Concepts have a longer shelf life than details, because details change. Languages are born and die, frameworks become unpopular overnight, companies go out of business, support will end. But the thoughts, the ideas, the best practices? They live forever.

Learn about SOLID. Learn KISS, DRY, and YAGNI. Learn how important naming is. Learn about proper spacing, functional vs object-oriented, composition vs. inheritance, polymorphism, etc. Learn soft skills like communication and estimation. Learn all the ideas that result in good code, rather than the details (syntax, limitations, environment, etc.) of the code itself. Mastering the ideas leads to your mind being able to warn you when you are writing bad code (as you will inevitably do).

Don't fret about the how. How you learn the concepts is irrelevant. It doesn't matter what framework you like, what stack you use, what technology you're currently in love with. Just pick one, learn that, master that, and remember some of the pain you had to deal with for the next project. Write a small project, post it to GitHub, blog about it. Get some experience with it! Experience is king, and nothing can substitute for real-world experience.

Code is ephemeral, concepts are eternal. Code is static; it will die, fall apart, degrade. It may take a long time, years or decades, but it will happen. But the concepts which programming lives off of do not die; they live on.

So again I pose the question: what should you spend your precious time learning?

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.