I often teach developers for my job, so I collect fears. Most teachers do. Your grade school teacher probably told you that you had to pay attention to boring math and/or history so that you could get a job (and not, by implication, live in a van by the river.)

So when I hear the same fear a lot, from a lot of different people, I pay attention.

I’ll bet that you don’t think you know “The Computer Science Thing” well enough. New folks like Boot Camp grads think so. So do recent college grads. And not-so-recent college grads. And veterans who “haven’t been keeping up.”

They do not, of course, all mean the same thing by it. That’s part of the problem.

The Computer Science Thing, New Grad Edition

Newer folks tend to be told by more-academic peers that if you only knew a lot of algorithms, you’d see where to use them and your work would be better. You’ll also hear this about math.

That’s not entirely wrong. I have a math degree from Carnegie Mellon and a pretty up-to-date grasp of algorithms, and I do sometimes see places to use them.

But it’s not entirely right, either.

Specifically, Wikipedia suddenly showed up, and StackOverflow, and many, many online resources that are really quite good. It turns out that if you can learn an algorithm quickly then you don’t generally need to memorise it. In fact, you can mostly pick up a good description of that algorithm and build it. And better yet, you can normally pick up somebody else’s implementation in the form of a library. Various folks may tell you that if you haven’t built it yourself, you won’t know its limitations. That’s 100% true. They won’t say that if you did build it, you also won’t know its limitations, which is also true.

As a rule, somebody else’s implementation that has been used a few times will beat out your implementation that has never been used yet.

So: when thinking about The Computer Science Thing as a new grad, you’re worried that you won’t be able to do the work when there’s something complicated that you might do better by leveraging somebody else’s knowledge, whether that’s a written algorithm or an open-source library.

That’s a valid worry, for the record. It’s not really a worry about academics or computer science. And there’s an answer to it, which I’ll get to in a bit.

Experienced Developer Edition

Once you’re an experienced developer, your fears are different. You’ve picked up algorithms and implemented them. You’ve integrated more third-party libraries than you want to think about. Those things are old hat and they don’t scare you particularly.

But you’ve seen various people be promoted quickly, maybe even yourself, and you don’t really understand why. The very experienced engineers and managers presumably choose how that happens — possibly also the executives, who you don’t talk to. But clearly there are people who judge you on your abilities, and just as clearly the process is a mystery to you.

This is a standard time for devs to flail a bit as they try to figure out what they need. Functional programming? The latest JavaScript library? An up-to-date understanding of research in their field?

And this is a time when “The Computer Science Thing” often means an academic, theoretical and mathematical grasp of their field. Clearly some folks have that. Clearly some of them are very senior. Perhaps what our experienced developer is missing is a grasp of computer science concepts — advanced algorithms, advanced research, something like that.

This stage can last quite a long time. If you work in startups or get promoted to higher rank, you’ll start to see the problem: you’re trying to find a technical answer to a social and business problem, and that doesn’t work. You’re not going to get promoted by learning React, reading whitepapers or being able to instantly derive mathematical formulas to create architecture diagrams. The people who pick your promotions actually speak business and they want to see business results. Some of that technical knowledge can help, but if you start from the technical side and ignore the business side, it will always seem mysterious.

It’s a matter of perspective and point of view. It’s also not actually a “computer science” problem. It has a similar solution to the first version, which I’ll talk about in a bit.

It also helps to get some career and business savvy. I know of no better introduction than this one for that. And it can help to learn to communicate, and to mentor others — this description of a senior engineer is a pretty good summary of that part.

Veteran Edition

Here’s an ugly reality of our field: we collectively believe that anybody who hasn’t picked up a new technology recently has become unable to ever do it again. That’s why being “out of date” is such a sin for developers who have left the workforce… Or worked at the same company too long.

When I help long-time coders update their resumes, I always recommend they put some kind of recent project with a newer technology right up-top. It doesn’t have to be important. But I suggest they mention some kind of “messing around with a new language” or “learning a new library” thing right up-top. Because otherwise, everybody assumes they can’t learn any more and they’re unhireable.

Mathematics seems like such a sane place by comparison. Once you know math, math stays the same. Euclid’s geometry still works just fine now. There’s a such thing as new math research, but mathematicians pick it up slowly. Nobody says, “you learned math 20 years ago so none of that applies any more” or “have you kept up on the latest math developments?”

Doesn’t that sound nice? I always relax a little just thinking about it. Then I think about programming jobs and I tense up again. I’m past forty — old as programmers go — so it’s always a worry.

Long-time programmers tend to think, incorrectly, that if only they understood the mathematical and algorithmic foundations of our field well enough, that jobs would stop hassling them about the latest JavaScript frameworks or whatever the kids are doing these days.

I have bad news, older developers — that’s not how it goes once you get to the job interview. In your case there’s a simple answer - stick something new up near the top of your resume and if they ask you pointed questions about whether you’ve picked up new tech lately, talk to them about that same project.

And, of course, blow them away in the interview on the general and foundational questions. You’re not wrong that knowing the fundamentals of our field is a big deal.

The Answers

We’ve talked about the fears. But fears alone aren’t an answer. We’ve talked about problems, but not what to do about them.

You know some of the answers: keep working, keep getting more experienced, keep getting more perspective. Learn the fundamentals of our discipline, and keep learning.

But since you’ve read all this way, let’s talk about another answer to all of these fears.

If you’re new and you’re worried about leveraging other people’s knowledge, your biggest weapon isn’t academic study - it’s direct experience and skill. And it turns out you can practice that.

If you’re experienced and worried, your biggest weapon isn’t a new library or a new paradigm. It’s being able to pick up a problem and get to work on it effectively. And that is the same skill - the “fingertip feel” of knowing coding problems, which comes from careful practice.

And if you’re an old hand trying to impress the youngsters, they already know: old hands come in “effective” and “ineffective” flavours, and the difference is whether they can pick up a problem and solve it. Sounds like the same thing, doesn’t it?

At every level of experience, the people evaluating you aren’t trying to answer the question, “do you know this one thing?” Not really. They’re asking whether you’re useful and effective.

And it turns out that is its own skill, and you can practice it and get better.