Solidity Bootcamp

Our topic selection process

A lot of courses like to cram as many impressive-looking topics into a syllabus to create an impression that the student will learn a lot of material. Obviously, it is not possible to “master” (in any sense of the word) 10 topics over the course of 10 weeks. In fact, if you spend so little time on a subject, you will probably just forget it the week after - and you don't waste time! Our heuristic for what to include is simple: build the underlying skills that enable developers to easily understand large production-level DeFi codebases.

DeFi will feel easy after this

Fundamentally, all DeFi protocols have:

If you master these three components, then you will be able to make sense of any DeFi protocol.

Let’s examine what the Tokens to DeFi course covers and see how they fit into this learning goal:

Topics we do not cover

Let’s consider some topics we did not include and our rationale for not including them:

How we design our assignments

We learned through experience that “project-based learning” is an inefficient use of time. We replaced it with “exercise-driven training”.

Many educators mistakenly confuse “learning by doing” with “project based learning”. It’s better to work on exercises that are designed to give rapid feedback rather than leave students to explore on their own and get delayed feedback as to whether they understood a concept correctly or not.

Here is why project-based learning is suboptimal

To get a project to function, there is a strong temptation is to copy working code from Stack Overflow or an LLM without understanding how it works. This is fine for a job or hackathon where you are evaluated on shipping features rather than knowing what you are doing. But it is counterproductive for efficient learning as your time is spent expertly crafting your Google search or LLM prompt instead of internalizing a design pattern.

People learn faster when they get direct feedback on their mistakes. A “functional” project doesn’t give as much feedback as targeted exercises do. We design our course to maximize feedback. Our exercises are designed to “bite-back” quickly even if a small mistake is made.

Instead, we ask engineers to write code we have already prepared aggressive unit tests for. When the engineer forgets to include a safety feature or deviates from best-practices, the unit tests will give rapid feedback for the engineer to course correct. On top of that, we have 1-1 code reviews with the instructor, but a pre-existing unit test will always provide faster feedback than an instructor can. In our course, you get the best of both worlds.

Even professional code reviewers (aka auditors) miss issues in large codebases; it’s very hard to reliably catch every mistake a coder makes. If an engineer learns by creating several projects, but makes more than a few uncaught mistakes, this can lead to engineers creating several projects while also unconsciously enforcing bad habits. That’s why we scope our exercises down to where the number of mistakes that could be made are limited and easy to catch.