Only the best developers learn useless things (carefully)
July 13, 2019
I used to think that Computer Science was for chumps. That it was all just a bunch of academic bullshit that's 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. More importantly though, was it true? Well, maybe not entirely true, it turns out.
See, I actually ended up needing something from Computer Science the other day. I know - shocker, right? Thing is, I've always prided myself on being ruthlessly pragmatic. 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 shit done here in the real world. I've got plans and 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?)
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 somehow managed to use as a kickass school assignment. What an amazing feeling. I made everyone I knew play that thing, nail-biting on the edge of my seat as I watched them play, waiting for any indication of enjoyment like I was jonesing hard. The thrill, the rush of building a world we could step into and ride our imaginations to the ends of the world. With that kind of excitement shining in my eyes, surely that was the start of my journey with programming, right? After that it was passionate coding into the wee hours of the night by CRT-nightlight that led to my career today - 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 than that, though, 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 there was no need that I could see for putting colored lines and simple geometric shapes on the screen.
But there's a problem with that: "there was no need that I could see" - but 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. Much as I love web development, can you imagine if I'd continued pursuing those skills back when I was 10 and ended up with the skills I need 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 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 is the counterpart to push-based learning. It's all those times you learned something just in case it might come in handy, or just 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, truth be told, 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.
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? Both styles of learning have their weaknesses - is there no hope? The answer, like with most things in life, is balance, or using 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 drive for anything that isn't pushed on you.
- Remember that you have unknown unknowns - you can't say that something is more important just because it's more needed when you don't know how useful something unknown might be!
- When we're too grounded we lose creativity, flexibility, and openness to new. Take a step back every so often to survey other options and approaches to deliberately remove your blinders.
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'?"
- Remember that as a developer your professional knowledge and skillset exists for a purpose - creating real-world value. Don't get sucked into valuing knowledge for its own sake. Its value is in the impact it creates - use that as your evaluating rubric.
- Exploration (as with pull-based learning) can lead to greater creativity, flexibility, and openness to new things, but at the cost of focus and drive. Be willing to put your pull-based learning on the back-burner when life throws curveballs at you that need to be dealt with here and now.
And above all - try not to judge others who more naturally fall onto 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!