Escaping Tutorial Hell

This is some help to every beginner out there that is learning to code or manage computer systems, usually self-taught.

In the beginning we all use tutorials as instruction manuals on how to build things with specific tools in the same way we use the papers that come with Ikea furniture for their assembly.

A tutorial is a clear and well-defined series of steps in order to reach a desired state, it is akin to using Google Maps to go from A to B or finding the path in a graph between two nodes.

This is a natural and highly recommended way of achieving clear and well known objectives in a timely manner with tools we are not familiar with. This is how I began as a self-taught programmer and power-user, even after I got academically trained in computer science.

However, a true professional such as a carpenter will be able to define a vision, and find the necessary steps by herself by leveraging her knowledge of tools, techniques and aesthetic taste.

Beginners will instead get stuck into what is known over the Internet as tutorial hell.

The good news is that tutorial hell is not a property but a situation we can get out of by changing our mindset.

Yes, that is a shamelessly AI generated image using midjourney about a cybernetic hell in which the spirits of souls are tortured until they transcend the sins they committed in a previous life.

Tutorial hell is the place we end up when we let ourselves drive by the innate need for certainty and security (and sometimes pure laziness) of just seeking and following tutorials on how to work with a particular set of tools instead of achieving a deeper understanding of their principles, possibilities and the underlying problems they try to solve.

No matter how good we know the path to make a TODO list in React, we will not get to break through the underlying abstractions and assumptions we use to do the TODO list.

We will describe this mental state as the tutorial mind.

For an individual stuck in the tutorial mind, the world is reduced to a series of tutorials or lists of steps in order to reach a limited number of well known solutions.

They will only have surface level understanding of the tools they use, which in some cases are fairly complex and daunting once you pull the sheets in terms of possibilities they enable.

A master of a tool who has gone through the purgatory of true understanding will be able to unleash its creative powers over the world, which is what we really want as hackers and builders.

In order to get past the plains of the beginner into the realm of the professional, we need to make a quantum leap in the way we get to know our tools.

The first and most common way of achieving this is usually to read the handbook or documentation of the tool or library.

This is a necessary but commonly insufficient step in order to reach mastery of a technology.

Do not get me wrong, you need to read the manual, and at least eye out the documentation of the tool you are using.

But documentation is a map, it is just a description or a model of an underlying reality of a tool.

This reality will be subject to change in proportion to the maturity of the tool and the ecosystem in which it is expected to be used.

Most importantly, you need to focus on the concepts involved on the tool you are using.

An unstable ecosystem such as the web will force tools to keep evolving, this is why we have seen such a Cambrian explosion of tools and JavaScript frameworks in the last decade.

This is why in some cases, a true master must not only be aware about the features present on the documentation of the tool itself, but also have awareness about its code and architecture.

True understanding is found when we first understand the underlying problem we want to solve via the tool we want to master, and our knowledge about the experience of using the tool itself.

This is only achieved via experience, for me the best way to achieve this is through the execution of end to end projects.

True knowledge is akin to a graph, a master is able to think in terms of intermediate checkpoints in the execution of a project as well as having the knowledge about what it will cost to transition from one state to the next.

This can be true in any human pursuit, when climbing Mount Everest, building a startup or maintaining a relationship.

Bringing it back to the experience of being a software professional, let’s say you want to solve a problem.

For most problems regarding computers, the reductionist approach of breaking it up in smaller problems and solving them recursively usually work unless you get into a research grade problem on the edge of the current state of the art such as artificial intelligence or very domain specific problems.

However, if you are lucky, each of those steps can be solved using specific tools.

Let’s say you want to automate a task, and you select Python as the language to do it, Python will offer you the set of tools on the standard library to interface with the utilities offered by your operating system.

The Python ecosystem also provides you with higher abstraction tools developed by other engineers so that you can all benefit from the work of others.

Once you have the problem well-defined, you must break it up into smaller problems, some of those problems, specially the hard ones, might have already been solved by other people in the form of tools or libraries you can pull from the ecosystem.

However, in order to make a selection, you need to have a clear understanding of the problem you want to solve, then decide which of the available tools is the appropriate one for your scope.

Then you will go to read its documentation, make a diagram about the main abstractions, the operations they support, the data structures they depend upon, etc.

You might also go into the codebase for that tool, check out in what language it is written, checkout what issues are they currently dealing with. Are they testing their code? When was the last feature submitted to the main repository? Has the main interface for that library abstraction changed recently? Can you benchmark it in some way in order to check its performance against other approaches?

If you are really into it, you might also get into the code of the abstractions you think you need to solve your specific sub-problem, check out how the operations are made and what algorithms are used.

You might not become an expert, some problems really are hard, and require time to really understand, but you will stop believing in magic.

You will have a degree of understanding on how things work underneath, and you will be able to make somewhat informed decisions in the projects you will be involved.

And eventually, with persistence and dedication, you will escape tutorial hell.