The Slow Way is the Best Way

Learn to sit with a problem, rather than looking for an immediate answer.

I came across this tweet on a recent crawl through twitter:

https://twitter.com/dthompsondev/status/1261260817477120001?s=21

and while I understand this is, to a large degree, a joke, this underlies the general problem of an over-reliance of a resource.

Let me preface what follows by saying that Danny’s a great guy, and if you’re not following him on twitter, you should be. He shares lots of relevant content and insight to the struggle of learning to code, and this article is by no means a criticism of his content.

It’s a criticism of how we’re all learning to code in general, myself included.

Now, I’ve gone on ad nauseam about refraining from getting into libraries and frameworks until you know how to build the thing without this stuff, then implementing only what will be really useful. The same can be said for problem-solving resources. As developers, this is what we are first and foremost: problem solvers. I think a lot of us forget this in our excitement to build something. You start building a thing to address a problem, and you’ll come across other problems when building the thing. But what tends to happen instead of working to solve those little problems on your own is that you immediately turn to find the answer somewhere else.

While this may be efficient in the short term, this is not a beneficial long term strategy. And I’m not preaching from on high about this, I’ve fallen prey to this behavior too. But I’ve had to get away from this for one main reason: my desire to deeply understand JavaScript and refrain from using libraries and frameworks means the resources available to me to find answers for things are slim. EVERYONE fucking uses libraries in their projects and can’t seem to write a line of code without them. There are those who, in their tutorials, will claim to do a thing using “pure JS” and proceed to list six libraries. Case in point: find me a tutorial on MongoDB where they aren’t also using Mongoose.

This means I’m forced to sit with the problem myself. This means I have to deconstruct what I know and what I’ve read to figure out how to approach the problem. This means I rarely have the luxury to work through a tutorial or find a bit of code that will help me along. This means that I spend an inordinate amount of time reading and rereading documentation and playing with code until something clicks. But when that something clicks, it stays with me. I now know how to solve that problem without going hunting for a solution.

This doesn’t mean that I don’t Google shit. Google is a resource, and like any good resource, it should be utilized when necessary. However, it is not the first thing I turn to when I encounter a problem. The first thing I do is take the time to understand the problem and recognize if I already have the skills to solve it. If I don’t, then I consult the documentation for tools I’m using (i.e. Node.js or MongoDB), and if I don’t figure out how to solve the problem with the information provided there, then I turn to Google. But Google is not my immediate go-to.

Anyone can download libraries and write a few lines of code and throw up an app real quick. But if you have no idea how it works and something breaks? You’re fucked. But if you have little reliance on libraries, frameworks, and stackoverflow, you’ve got this. Minimizing your reliance on extraneous tools and working to improve your problem-solving skills will help you greatly in the long run. It’s a metric fuck ton of work to do up front. It’s slow and arduous. But as I often tell my fitness clients and yoga students, the slow way is the best way. “Give a man a fish …” and all that. It’s relevant to code too.