The generalist's path involves regularly picking unfamiliar tech – such as programming languages – for study. In this article, I will discuss strategies that I believe are good – some of which I use myself and others I believe to be good for people working a different context.

Always Study Guided by Your Own Project

No matter how you study – take a course, self-study a book, or explore on your own by reading the docs and the blogs – always start with an actual project. Do not merely copy your teacher’s or mentor’s example, instead try to do something truly your own.

For example, earlier this year I decided I wanted to learn native Android programming. Having nearly zero idea of how it would be done – apart from having previously built some desktop GUIs years ago – I chose to write an app I personally wanted to use: a work time tracker with the ability to assign labels to time periods.

It did not matter that there were many existing ones available, as my primary motivation was not to build a business around it; it was something I needed for myself. Similarly, I did not even look if there were tutorials or examples for this kind of a project – I still do not know if there are any, and I do not care.

After some weeks of late evenings on the computer, I had something that works for me. I still use it every working day, but I have not published it anywhere – it serves both of its primary purposes, and it does not seem worth the effort to bring it up to publishable quality.

Go for Mastery

While Stack Overflow and blogs are useful guides, do not be satisfied with merely copying other people’s cod toward understanding why and how those snippets work.

This will be hard at first – to make progress, you have to take a lot of it on faith. However, you should not feel satisfied at that level. Work on deepening your understanding.

Follow the leaks in your abstractions

An abstraction is something that allows you to work at a high level without having to constantly think about what lies below it. Programming languages are abstractions that allow you to ignore the details of the underlying machines. Some libraries and frameworks are comprehensive enough that you do not have to think about the mess of the underlying programming language and system – one example is jQuery in the bad old days of severe browser incompatibilities.

Unfortunately, all abstractions leak. This means that sometimes, the only way to explain the behavior of some code is to figure out how it gets implemented under the hood. In many cases, the leaks are quite bad, and you really cannot work at the level of the abstraction without digging below all the time (pandas is one such example – you have to know Python to be successful with it). Some abstractions are quite solid and rarely leak.

Thus, when you find your current abstraction leaks a bit too much, go learn the stuff it was built upon. When you hit a solid abstraction, you can stop and rest. For now.

My own strategy is to try to quickly find the highest-level solid abstraction I can find, and work at that level. Any tools, frameworks, code generators, IDEs, et cetera, built on top of them I try to initially avoid. Once I get comfortable with the solid abstraction, I start discovering the pain points that led other people build those tools; at that point, I can decide whether to adopt them for my work or not – often I find them more trouble than they are worth.

Some examples

For example, web front-end programming requires HTML, CSS, and JavaScript. All three are very solid abstractions, even if they are extremely complex. There are many frameworks which are suberbly useful when building complex web apps, and many consider them essentials for a front-end developer. Yet, they are very leaky abstractions. You need to learn the solid abstractions to achieve mastery.

For another example, I have been using type hints in Python, checked with mypy, quite extensively this year, for data pipeline systems programming. The abstraction is extremely leaky, in that the static typing of mypy does not even try to hide the underlying dynamic type machinery of Python. As a static type system in the classical tradition, it would be a total failure and not worth my time, but that is not what it is trying to be.  Type hints are documentation, and mypy checks that this part of the documentation is consistent with itself and with the code base. As such, it is particularly useful to me. But it truly is a leaky abstraction, and I would advise everyone to learn classic un-hinted Python first before dabbling too much with checked hints.

To be continued

This article is a work in progress. I would appreciate your feedback via email to a.j.kaijanaho@gmail.com.