Only the best developers learn useless things (carefully)

Finding a balance in how we learn

Luke Mayhew
Jul 14 · 8 min read

I used to think that Computer Science was for chumps. That it was all just a bunch of academic BS of no use to anyone in the real world (unless you’re one of those neckbeards working on compilers or something). CompSci seemed like a black hole for money; sucking poor, naive developers into a degree in missing the point. Was that a bit harsh? Sure — I was a young, puffed-up web developer whose self-taught success made him think he was on top of the world. But, was it true? Well, maybe not entirely as it turns out.

See, I actually ended up needing something from Computer Science the other day. I know — shocking, right? Thing is, I’ve always prided myself on being ruthlessly pragmatic. As much as I love learning, I’m not interested in knowledge for its own sake. I’m here to make a difference — to get real stuff done here in the real world. I’ve got plans, goals, and a drive to make things happen, and anything that’s not moving me toward that would be well advised to stay the hell out of my way. If you want to chase some academic, theoretical whatever your whole life then hey, that’s fine too, but that’s not my shtick. So quite frankly I’ve never had time or patience for CompSci. I always figured if it was actually useful in the real world I would come across a need for it and then reach out and learn it, just like everything else I’ve taught myself.

And sure, there’s definitely something valid to that. I mean, I owe my success as a highly effective senior developer to it, after all. But that’s only one kind of learning — let’s call it push-based learning since you have to be pushed into it. And like just about everything in life, it has its strengths — but also its weaknesses (I got called on those weaknesses in a job interview recently, actually. Who knew interviews could teach you how to avoid ruining lives and how to not suck at growing in your own life as well?)


Push-Based Learning

As a kid, I always had an affinity for computers. Maybe it was due to the countless hours spent playing games on monochromatic screens with pixels the size of your fist. Maybe it was the fact that my father had been a software developer for decades. Maybe neither, maybe both. In the end, I don’t know what made computers click for me, but I do know what got me to learn how to program for the first time at the tender young age of 10. Games. Hot dang did I ever love games — maybe even more than I loved novels — and I’d been playing some old-school (even back then) text-based adventure games. A combination of gaming and storytelling? I was all over that. So when my father told me I could actually make these wondrous marvels? Yep, sign me straight up.

So he taught me how to build a basic text-based adventure game which I managed to use as a kickass school assignment. What an amazing feeling. I made everyone I knew play that thing, biting my nails as I watched them play and searching for any indication of enjoyment. The thrill, the rush of building a world we could step into and ride our imaginations to the ends of the world. With that excitement shining in my eyes, surely that was the start of my journey with programming and from that point, I started passionately coding into the wee hours of the night by CRT-nightlight — right?

Nope. See, no one else I knew really liked text-based adventure games, and what’s the point in building a game no one will play? Knowing that the wide world of programming had so much more to offer, my father tried teaching me more — drawing 2D graphics on the screen — but that fell through and I dropped out of the programming scene.

Did you spot where things went wrong? I was chock-full of obsessive passion but never learned to tap into harmonious passion. And that, in part, was because I was following push-based learning. With push-based learning, we only learn when there’s a clear and current demand for the outcome of that learning. In other words, I couldn’t be bothered to learn those 2D graphics because I didn’t see a need for putting colored lines and simple geometric shapes on the screen.

But there’s a problem with that: I don’t have perfect insight. I couldn’t see it at the time, but those shapes I was putting on the screen were the foundation for more advanced programming that would have gotten me somewhere. As much as I love web development, imagine if I continued pursuing those skills back when I was ten and ended up with the skills needed to get hired as a game developer. Holy crap. Building those godawful text-based adventure games as a kid got me so fired up, I can’t even imagine what my life could’ve been like if I hadn’t said “I don’t see the point” and dropped out.

Push-based learning is great for keeping us on track and well-grounded in our current reality, but its gaping flaw is that it’s completely vulnerable to the unknown unknowns. Sometimes, you don’t know how useful something will be until you’ve actually learned it and can now see its use cases. If you’re lucky, you’ll stumble across these things and find out enough to at least have an idea of the gaps in your knowledge. But how often are we not even stumbling onto these things and having them slip through our grasp entirely? I have no idea — and that’s the whole point (and the danger).


Pull-Based Learning

Photo by Rob Walsh on Unsplash

Pull-based learning is the counterpart to push-based learning. It’s all those times you learned something just in case it might come in handy or because you enjoyed the learning itself (you’ve done that at least once or twice, right?). It’s no silver bullet though — as always, there are both strengths and weaknesses here.

The first weakness — and probably the one that has been behind most of my scorn for it in the past — is that folks who primarily follow pull-based learning often end up just being so damn useless. With pull-based learning there’s a very real danger of getting lost down a rabbit hole — or worse, a rabbit warren — with nothing tangible to show for it. You know what I mean — we’ve all seen those folks who know so much about things like blockchain, or the internal workings of some compiler, but when you ask them if they’ve ever come across a case where that knowledge provided better cost-to-benefit ratio than any other option, the answer ends up being “no” in the vast majority of cases.

The second big weakness I’ve seen when folks chase pull-based learning too hard is that they start to think that it’s the learning itself that’s the goal, or where the value is. Take Haskell for example — it’s hard to learn, and that’s not a good thing. But a lot of Haskellers — once they’ve got the hang of it — seem to see that pain as a badge of honor, rather than something to be improved on. As if the challenge of the learning gives the learning itself some kind of extra worth somehow.

Or there are all of the developers who love functional programming (as I do), use JavaScript as their weapon of choice (as I do) and end up jumping through crazy, convoluted hoops to force functional programming into their JavaScript (as I sometimes do), even when the language design really doesn’t want to cooperate with that. And when asked why, I’ll get answers about all sorts of features of functional programming — “it’s point-free” or “it separates ‘data this’ from ‘functionality that’”.

But the truth is, something like point-free style is a technique, not a benefit. How does point-free help us here? What’s the impact? Getting too caught up in pull-based learning seems to often blind us to the difference between the value of knowledge (which is the result of the application of that knowledge, and is dependent on the context of that application), and the knowledge itself.


Yin and Yang

So where does this leave us? If both styles of learning have their weaknesses — is there no hope? The answer, like with most things in life, is a balance in finding the right tool for the job. We can’t truly thrive without pull-based learning taking us to places we’d otherwise never go, and we can’t be effective without push-based learning keeping us on track.

When using push-based learning, keep the following in mind:

  • Don’t be so results-focused that you lose the drive for anything that isn’t pushed on you.

When using pull-based learning, keep the following in mind:

  • Don’t get lost down the rabbit holes! Take a step back every so often to ask yourself “Are there things I know/can do already that could be good/close enough?”

And above all — try not to judge others who more naturally fall into a different part of the spectrum (yes, I know, my bad, I’m working on it). Take a lesson from the Yin and Yang — nothing is solely good, nothing is solely bad. We need all types of folks to make the world go round, and we all need a well-rounded personality. Just try to use the right tool for the job!


Originally published on my blog (https://www.webuildlegends.com)

Better Programming

Advice for programmers.

Luke Mayhew

Written by

Front-end/full-stack developer. Mentor to struggling developers. Pursuer of growth, wisdom, and a life well-lived. He writes at webuildlegends.com

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade