Going Beyond Surface-Level Learning

In learning to code over the past year — both on my own and through Viking Code School (VCS)— I’ve come to realize that on any topic in the programming world, the depth of any rabbit hole you go down is only limited to how willing you are to go down it.

There is almost always a quick answer. You can learn the syntax for a solution, and once you know that it works. And in Rails specifically, there is often a gem that solves a good chunk of the problem you’re trying to solve. But as my education at VCS has taught me, it’s usually worth the time to not just learn that top-level solution, but also why that top-level solution works and what the underlying functionality is. It might not be worth it to go all the way down the rabbit hole, but I think it’s worth going beyond the surface level.

An example of this is learning to use databases in Rails. I would totally understand the rationale for going straight into learning Rails’ Active Record. It is, after all, what any Rails developer would be using most of the time anyway. But instead, we spent a few days learning the ins and outs of SQL and how what we had already learning about database associations could be written in SQL queries. Two very helpful sites in this learning were sqlzoo.com and Mode, which gave you sample databases to work with and a helpful progression of the different types of queries SQL can run.

After these 20+ hours of learning, I was by no means a SQL expert (though I really enjoyed the brief taste of the language and look forward to learning more about it), but when we did jump into Active Record, it was an easy transition. It also gave me appreciation for the power of some of the Active Record methods and how when database associations are set up properly, several lines of SQL code can be reduced to a single word in Rails. But it goes beyond simple appreciation. When errors occur — and they will occur — Rails will provide you with the SQL code it’s trying to run. By knowing the SQL code that is actually being generated by certain Active Record methods, I will be much better prepared to respond to these error messages quickly.

Throughout VCS, a number of topics have been dealt with in this way. We will read a couple of sections at night on some new functionality and then spend the morning learning the bare-metal way to implement that functionality. That afternoon, or later that morning, we will then learn to use the gem or Rails-y way doing the same function — which is, without fail, much simpler and less confusing. And sometimes it does feel a bit silly when we learn something that we might never need to implement because a gem does it for us, but I love the feeling of knowing why a gem works, not just being able to call it. Plus, as I said earlier, it is a great help when debugging to have that underlying knowledge.

So for everyone else that’s with me on this lifelong journey of learning to code, take the time, when you can, to dig deeper into what you’re learning. Don’t settle for the just knowing when to use a tool — learn the why and how of its function as well.

Show your support

Clapping shows how much you appreciated Alex Lach’s story.