Learning on the job versus learning in the classroom — what I’ve found trying both. Part 2
In Part 1 of this series I talked about how I learnt programming and computer science on the job (essentially picking things up as I went in a rather hodge-podge manner) and my disatisfaction because of how that process left me with knowledge gaps. I ended by concluding that, despite it being in vogue now to constantly talk about reskilling ourselves, to be a truly effective self-directed learner is hard! Learning something properly needs a lot of thinking, analysing and critical engagement, all of which are hard skills to master. Moreover, for a subject like computer science, it’s not enough to only engage with ideas, as one might do with comparative literature or philosophy. One also needs to master the practical aspects — expressing an algorithm with code, working with the relevant technical tools, and applying one’s knowledge to real world problems. Making mistakes, asking questions, and relying of course mates to pick up and discuss things you may have missed are imperative. They are also almost impossible to do in a self-directed setting.
So, in part two of this series, I walk through what the opposite of learning on one’s own looks like, by describing one semester of taking a course on designing and fine tuning databases. The purpose here is to contrast the structured, week-by-week, unfolding of the semester with the more opportunistic style that I had been using before starting the course. But since structure means more than just cadence, I discuss other aspects to structure such as also having tutorials, tests, online forums, and quite importantly, time pressure and deadlines! On a more meta level, I explore how much more theoretical the course was compared to what one might find on sites like SkillShare and O’Reilly, which are more in the style of just-in-time learning, and the implications of emphasizing theory.
Week 1–6
We started off by learning about SQL queries. We tackled how to speed them up, and even slow them down, by dissecting how the Postgres optimiser works. I found this really useful because at work, slow queries are always an issue! With a mental model for how Postgres processes queries, it became a lot easier troubleshoot a troublesome query. These lectures meant weekends spent visualising the queries in postgres, going through postgres’s tables of statistics, and running lots and lots of queries of all sorts of forms.
But fine-tuning a slow-performing query is not the only way of optimizing a database. If the data itself is not laid out thoughtfully, then no amount of playing with the optimizer will help. This is where we moved on to learn about the normal forms, how they govern how data should be represented in a database, and how they prevent undesirable behaviours.
At this point, in about the third week or so, things took a sharp turn into the theoretical. Normal forms have their basis in something called functional dependencies, and functional dependencies are tied to another set of principles known as Armstrong’s axioms. Suffice to say that there were a lot of Greek symbols and logical proofs involved. While googling the meaning of the various theta, omega and phi hieroglyphs, I did wonder whether this was an example of academia being overly-focused on building intricate castles of proofs. However, I did work through all the proofs of each axiom, and practiced each of the algorithms for decomposing tables into different normal forms.
Ultimately, despite grumbling a bit as I did all this, I did appreciate being given the chance to see how an intuitive idea, such as preventing duplicates in a database, could be represented formally and rigorously through logic. The next time I have to set up a database, I don’t think I’ll have to work out all the functional dependencies by hand, but I can at least see how the various columns should relate to each other. I can even appreciate the “elegance” of the theory that went into the design of my relational database! None of this directly impacts how efficient I will be at the direct task of building tables, but reflecting on my experiences, I’ve come to think that the experience was beneficial after all.
This is because there are (usually more intangible) benefits to theoretical knowledge. To be able to theorize is to be able describe a vague problem in unambiguous terms, and then to set limits around that description. Take normal forms, for example. Normal forms are a way of mapping out the ways in which we can represent data so that we reduce duplication and prevent problems when adding, deleting and updating entries. While we could have described the problem with plain English, as we have just done, describing the problem with the language of logic, and setting out clearly the different levels of normalisation we can expect, the drawbacks of each, and when normalisation may be overkill, allows us to develop our thinking around the problem. Theorizing is a way of reasoning from first principles, of constructing a rigorous view of the issue we want to solve.
And it is reasoning from first principles that allows us to move beyond the immediate facts of a problem, and move towards tackling problems without a clear solution. For example, Netflix needs to be able to stream video content to different devices without a lag, Amazon needs to recommend relevant products to customers, banks need to develop fraud detection systems. These problems start off as, and continue to be, problems without clear answers. Working on these problems depend on being able to reason systematically and logically; going through theoretical computer science concepts is a way of developing that ablity to be a methodical thinker.
Week 8–13
Term moved on after a week’s recess. We progressed past SQL into the world of No-SQL, this time veering towards breadth over depth. While the first half of the semester was mainly focused on relational databases, the second half of the semester covered XML and JSON for semi-structured data, Cypher for graph databases, dimensional modelling for data warehouses, and also stored functions and procedures and database serialisability. I have to say I had a lot more fun in the second half of the semester. Having built a solid foundation with SQL and relational data concepts in the previous weeks, moving into the adjacent fields of XML queries, normalisation in a data warehouse and graph databases was very satisfying because we could always compare what we were learning with what we had covered before.
It was at this point that I really begun to appreciate the set pace of a structured course. Usually, we had about two weeks to complete a take-home assignment, and about a week to digest our lectures before the next week’s one. The cadence wasn’t too fast (especially compared to my undergraduate course, where we churned through 10 books and a 4000 word essay every week). In fact, the rhythm was just right. I had time to sleep (literally) on ideas, revisit them, and slowly watch as what was initially a collection of facts solidify into a working mental model of how to choose, design and tune a database for a specific purpose.
A module in a degree program is usually also more than just lectures. In addition to one lecture a week, we also had tutorials, assignments, online forums and tests. It was a big effectiveness boost not to rely on only one medium such as a Youtube video, online webinar or tutorial presented as a medium post. Being able to explore the course material multiple times, through different channels, in addition to dedicating enough time to digest the material, went a long way towards my retaining knowledge better.
I also have to make an acknowledgement to the power of time pressure and deadline pressure! When one has to balance study with a job, the struggles of self-studying even while tired is very real. In fact, Kathy Sierra, a co-author of the awesome book “Head First Java”, specifically set out to make her book quirky and suprising and fun, because she knew that the biggest barrier to learning is not access to quality information, but mustering the mental energy to study after a long day. Too often, on my own, I would skim through the hard parts of a book because it was easier than grappling with the ambiguity. I would watch a video lecture instead of doing exercises that would have consolidated my understanding better. But with a test looming, I just had to knuckle down!
Finally, after 13 weeks of hard work, the semester wound down. As enjoyable as it all was, I breathed a big sigh of relief.
Overall, my experience speaks in favour of supplementing knowledge gained on the job with knowledge from a degree program. Working gives you an idea of the problems in industry that are useful to solve, and how theory translates into practice, while studying takes you back to first principles and trains you to reason about a problem. There is a yin and yang to doing both, and personally, being able to experience the two simultaneously has been a very fulfilling growth experience.
