For example, if you did our Git course, you’d learn how Git internally stores file data by building an implementation of Git that can clone a GitHub repo. If you did our SQLite course, you’d end up with a SQLite implementation that can read a valid SQLite database file, and retrieve data by performing an index / full-table scan on it. The projects you’ll build are always end to end compatible with the official spec. Given the same input, your program would behave the same way the official one would.
We’re different in the developer education segment in 3 main ways:
First, we cater to people with programming experience. There are tons of introductory “learn to code” resources out there, but surprisingly little once you get past the basics. Good programmers want to get better and to develop in areas where they’re not strong yet, and that’s what we help with.
Second, the coursework involves writing actual code instead of consuming videos. You handle concurrency, develop statecharts, traverse B-trees, etc. While we test against a fixed spec, you’re welcome to try different approaches. E.g in our Redis course, you could implement handling concurrent clients either using threads, or using an event loop.
Third, instead of coding in the browser, you build these projects in your local dev environment. We create repositories for you to work out of, and you git push to run tests. The actual code can be written in your editor of choice (VSCode, JetBrains, Emacs, etc).
This last point in particular—our git-based workflow—is something customers repeatedly tell us they enjoy. We run our own git servers, and have server-side post commit hooks configured to run tests on every push. These post-commit hooks also send back logs to users, with colors to indicate pass/fail, errors, etc. Our feedback cycle for popular languages like Go, Python, JS often takes ~2.5sec (including pushing code, running tests, and streaming back results), faster than even regular GitHub pushes. We do this by executing code within firecracker VMs and caching aggressively wherever possible.
As open source contributors, we’ve always been interested in the internals of software we use day-to-day. When Paul became an Engineering Manager for a team of 12, he decided to conduct in-person “Build your own Redis” workshops as a way to engage his team and help build skills. He had a mini-curriculum, a physical leaderboard for scorekeeping, and a Slack channel for discussing solutions. Participants loved it and wanted more. With CodeCrafters, we’ve essentially built an expanded version of that workshop experience on a website—for engineers and teams that want to challenge themselves, dive deeper, and grow.
We’ve learned how much hunger there is for a skill-building path that’s structured, fun, and focused on cool, well-known projects with serious technical dimensions. Jumping straight into the deep end as an open-source contributor has always been an option, but it’s daunting, if not intimidating. It can take a long time to get oriented in a major codebase, and mentorship isn’t always available. There’s a need for an intermediate approach with lessons that build technical expertise, and that’s what we’re supplying.
So far, we’ve seen developers and teams use CodeCrafters to learn the internals of complex software, master programming languages, onboard devs in a new language, and even as a continuous team-bonding activity.
If you’re a developer, we’d love for you to try CodeCrafters. Most customers expense the subscription through their learning / professional development budgets. If you need help convincing your manager, feel free to email me — [email protected].
Paul and I are excited to continue helping software engineers become the best technical version of themselves. We'd love to hear your ideas, experiences, and suggestions. What new courses should we add? What other formats of learning have you found to be effective?
by Andrey
Azimov