Learn Just Enough to Be Dangerous
Escaping Tutorial Hell
My superpower, if this counts as “super”, is learning just enough to be dangerous. I’ve never learned everything about a problem domain, all the fundamentals, every best practice: I learn just enough to get things done, gain valuable skills, and move forward.
This approach has gotten me through materials research, astrophysics, data science startups, game development, motorcycle restoration, woodworking, and pretty much everything else I've tried to do. I'm not the guy to discuss every aspect of these fields down to the bare metal, but I feel confident in all of these domains because I learned just enough to be dangerous at the time I needed the skill. This approach to learning while meeting your goals in the process is in itself a learnable skill that you can develop. I didn’t coin the phrase “just-in-time learning” ( Wikipedia has about half a page on it), but it fits.
To be transparent, to avoid the Dunning-Kruger effect this also means I have to recognize the wealth of information I don’t know. The balance is to find confidence in speaking to the things I’ve done while recognizing many people know more than me.
The Problem: Tutorial Hell
Let's say you want to make a game. Maybe you've got this vision in your head of a similar game to Pokémon that you want to build. It’ll be a super cute creature collection game and you’ve got lots of fantastic ideas that will make your game awesome. So you think, “Well, I need to learn programming first.”
You start learning C#. You download Unity. You open a tutorial on making games. You realize you need to understand object-oriented programming. You open a tutorial on OOP in C#. You discover there are tutorials on the fundamentals of game optimization. Important algorithms. Inheritance. State machines. You fall down a rabbit hole of programming fundamentals and programming patterns, spending weeks or months learning things you might never actually use.
At some point you finally feel ready to start learning game development. But now there are game development tutorials! Not for the game you want to make, but for Pong, Asteroids, Breakout… other people's games. You take courses and watch tutorials on game design, game art, animation. You're doing all these tutorials and you still haven't made the game that's in your head. You haven’t even started.
This is tutorial hell. It's the endless preparation trap where you're always learning to learn to do something instead of just doing it.
Tutorial hell happens because there's an overwhelming amount of information out there. If you want to be an expert in any language - C#, Python, Rust, whatever - you could spend years learning all the nuances. Memory allocation, string handling, data manipulation, all of it. There's a tutorial for everything.
But here's the thing: you don't need to be an expert first.
You just need to learn enough to be dangerous.
The Alternative: Just-in-Time Learning
In modern software development, we have this concept called technical debt. The idea is you get your idea to work first, then you get it to work efficiently or run cleanly or integrate optimally or whatever. This is different from most engineering projects where you need to get it right the first time; after all, you don't want a bridge builder to “sort of” get it to work and then iterate on it when it breaks. But in building prototypes, startups, game development, etc. you can get it to work and then get it to work optimally afterwards. (I know folks in enterprise applications or security are composing their rebuttals, but stick with me).
Just-in-time learning applies this same principle to, well, learning. You learn just enough to be dangerous - just enough to make progress on a real problem without getting bogged down in becoming a domain expert first.
If you want to build something like Pokémon, you don't start by learning everything you can about game development. You figure out what you want to build, break it into components, and learn just enough about one component to get started.
Pokémon has basically three parts: the overworld where you have a character walking around interacting with people and buildings in a top-down pixel art style; battles with turn-based combat and menus; and creature collection. Pick one. Start there. Learn just enough to make progress on that one piece.
You don't need to master everything. You don't need 10,000 hours of practice to get pretty good at something. 10,000 hours is five years of full-time practice (8 hr/day * 5 days/week * 50 weeks/yr * 5 years = 10,000 hrs). That's obviously a huge commitment. But what about 100 hours? That’s not a lifetime of practice; it’s a season. It’s an hour a day for 3 months. With 100 hours of focused practice, you won’t be a master, but you’ll be very capable. You can make that small game, create that piece of art, become a competent developer. (If you don’t believe 100 hours of practice is enough, try it out. Spend 100 hours and track how much time you’ve spent doing the task. Just don’t count the hours you spend watching tutorials.)
Three Skills to Practice
My thoughts about learning and in particular just-in-time learning basically break down into three skills to practice:
1. Breaking Down Problems into Components
Don't try to build the entire thing at once. This is a skill in and of itself - learning to identify the distinct pieces of what you're trying to do.
Take the Pokémon example. You've got the overworld, battles, and creature collection. Pick one first. Let's say you pick the overworld. Now break that part down further. To make an overworld you need things like character movement, collision detection, tile maps, and dialogue systems. Pick one of those. Break it down further until you’ve found the smallest piece you can make progress on.
The key is making the components small enough that you can learn what you need to know without getting overwhelmed. This can be pretty difficult. It can take a lot of practice to break things down, especially when you don’t know what you don’t know. Maybe you didn’t know starting out there are tile maps or what they are. But you know Pokémon has an overworld and it involves walking around. The key is to always ask yourself “how did they do that?” and practice picking it apart.
2. Identifying What You Don't Know
This is also a skill: recognizing your knowledge gaps in the context of what you're trying to do. You're not trying to identify everything you don't know about game development. You're trying to identify what you don't know about making a character move around a tile map. That’s the key difference. The wealth of information you don’t know about game development is vast. But the amount of information you don’t know about drawing tile maps in order to get a character to walk convincingly around a 2D top-down game that looks like Pokémon is manageable.
Again, the goal is to learn just enough to be dangerous. You don't need to know all the optimization techniques, all the edge cases, all the best practices. You need to know enough to solve the immediate problem in front of you and not break everything in the process. (Or to gain the confidence you can fix it if you do.)
3. Translating Existing Solutions
Almost anything you can think of has been done before. Your job isn't to reinvent the wheel; it's to find a wheel that's close enough, take your hammer, and adapt it to your car (okay, this metaphor doesn’t work that well, but you get the idea). This is a creative act, not just copying! You're reshaping a solution to someone else's problem to your own. Pick it apart to understand how they approached the problem and why it worked so that you can apply it to your specific need.
This is essentially what you're doing when you follow a tutorial. However, instead of following it exactly, you’ll adapt it to your needs. Finding the applicable information in a tutorial and translating it to your context is another skill you will learn through doing. Recognizing that almost nothing you’re doing is novel can be humbling in some respect, but I find it empowering to know that whatever you want to accomplish, you can use the knowledge of others to get started.
There are, of course, many examples of people not looking for existing solutions enough before (re-)inventing their own. One that comes to mind for me is the story of the nutrition scholar who published a paper on a mathematical model to approximate the area under a curve using polygons. If you’ve taken any undergraduate - heck, even some high school - calculus courses, you will recognize this as the trapezoidal rule… which has been in use since before 50 BCE. Mathematicians naturally pointed this out, and it’s since been used as a case study for why we do thorough lit reviews before publishing. I’m using it as an example for you to hopefully drive home this point: see if and how a problem was previously solved before trying to figure it out from scratch. Someone has probably done it already.
How I've Used This Approach
Let me share some examples of how this has actually worked in my life to make it a bit more concrete (and maybe help you start the thing you’ve been wanting to start).
Academic and Professional Work
When I started doing materials research as an undergrad, I had no experience with experimental research other than lab coursework. But there was an opportunity in a research lab, so when my professor asked if anyone was interested I volunteered and just started. I learned as I went: how to work with lasers, flexible electronics, clean rooms. I asked questions, figured out exactly what I needed to do for each experiment. Eventually I learned just enough LabVIEW to diagnose and fix some instrument controls.
Same thing with astrophysics in grad school. I had had a few astronomy courses as an undergrad, but really doing astrophysics research was new. I didn’t have access to telescopes or practical research as an undergrad, so during grad school I had to learn how to use telescopes, synthesize data, and do analysis for radio telescopes on the job, as I needed it. I became fairly adept at Fortran-90 and python, curve fitting, parsing large data sets and understanding signal processing.
After my PhD, I worked in startups where I applied data engineering and data science. I honestly learned most of what I know about data science on the job. Very little of what I know came from coursework or tutorials, but instead came from encountering specific problems and following the steps I described above to solve them. At that point I had a PhD in physics and masters in astrophysics, and so had a good fundamental basis of math, vector algebra, calculus, and programming. But I want to emphasize this: the majority of my practical knowledge about applied data science came from simply learning what I needed to know when I needed it.
Personal Projects
Professional work is not the only setting where I’ve found I use just-in-time learning. My hobbies follow the same pattern. I wanted to make a desktop easel for drawing and painting, so I sketched out a design and figured out what I needed to do as I went. What tools did I need? What wood? What didn't I know how to do? I learned each piece as I encountered it.
Right now I'm restoring a 1974 Bultaco Alpina: a little dirt bike that's fairly simple mechanically. But I had to learn how to take the clutch apart, how to replace seals, how a two-stroke engine works. As I encountered each problem I figured out what I needed to learn, learned it, and got it running again.
The point of this list isn't to brag. I'm not a professional mechanic, a certified woodworker, or a gallery-represented artist. In most of these fields, I'm a dedicated amateur. But that's the whole point. By learning just enough to be dangerous, I've earned something more valuable than expertise: the confidence to start, and the competence to finish.
You can get out of tutorial hell too and get started.
Why This Works (And Where It Doesn't)
Why It's Effective
When you learn something in the context of needing it immediately, it sticks better. You're not learning abstract concepts that might be useful someday. You're solving a real problem right now.
It also builds confidence in a way that tutorial hell doesn't. Once you realize you can figure out what you need to know as you encounter problems, it unlocks an approach to basically any problem. As long as you have access to information and people who've solved similar problems, you can figure it out. (The University of YouTube is a thing…)
Maybe I’m sometimes a little too confident. I know I’ve approached problems with a mindset of “how hard could it be?” and found that, in fact, it could be pretty hard. But that’s how everyone gets started. No one is born with the ability to rebuild an engine, they have to learn it.
The Hiring Paradox
Here's where this approach runs into trouble: it doesn't help you get a job.
Unfortunately, the job market for tech tests for fundamentals. Especially in the current market, for software development or data science, you're going to get coding challenges, SQL questions, probability problems, statistics questions, system design, rapid fire quiz questions about every model under the sun. The interview sequence is built around the idea that if you're really good at fundamentals, you'll be able to do anything on the job. This is a proxy. Good at fundamentals = good at job. And fundamentals certainly have their place. If you learn fundamentals you will have great exposure to a wide array of approaches, techniques, and problem types. But in my experience, the fundamentals are, generally speaking, a wide but shallow approach.
This interview process is in direct contrast to what companies often say they are looking for. Companies say they want “self-starters” and “lifelong learners” and people who are “curious.” What they're really describing is someone who's adept at just-in-time learning. What they test for, though, is someone who's spent time in tutorial hell memorizing fundamentals. The result is that job interviews are unfortunately setting this as the benchmark and using “mastery of fundamentals” as a good reason to get hired.
The irony is, most of these jobs run on just-in-time learning. Once you’re actually working no one expects you to have every answer memorized. They expect you to identify problems, break them down, and figure it out. Companies hire for encyclopedic knowledge, but they promote for just-in-time problem-solving.
When you talk about projects - the types of things you had to learn, how you approached problems, how you broke them down and solved them - that's articulating the just-in-time learning approach. That's the actual job. Interviews, in my experience, have shifted away from project discussions toward abstract problem-solving. I could probably write an entire diatribe about the gap between interview exams and in-context learning… but I’ll leave that for another time.
Getting Started
I’m not going to give you a tutorial on how to do just-in-time learning since, well, that would be pretty antithetical to what I just wrote about! It’s also against what I think is actually needed. What I believe is that no matter what you want to learn, you just need to start doing it. I’m sure there are examples where this is a bad idea (surgery comes to mind), but for most people:
Pick something specific you want to build or make or solve. Not “I want to learn programming” or “I want to be a great knitter”. Instead, try “I want to make a simple game where you catch creatures” or “I want to knit a scarf.”
Break it into 2-3 major components. For the creature-catching game: overworld movement, battle system, creature collection. Don't try to identify every single piece. Stick with the big chunks.
Choose one piece to start with. Pick whatever seems most approachable or interesting to you.
Learn just enough to be dangerous for that piece. Find examples, tutorials, documentation - whatever you need to make progress on just that component. You're not trying to become an expert, just competent enough to move forward. Don't worry about the other pieces yet.
For the tutorials: take away just what you need to apply to your problem. Don’t build their tutorial. Instead, watch/read the relevant parts of the tutorial to understand how they approached a problem and why it worked.
Adapt it to your problem. Don’t do the tutorial. Learn from the tutorial.
Get something working. It doesn't need to be elegant or optimized. It just needs to work.
Iterate. Improve what you've got, then move to the next component.
The mindset shift is the hardest part. You have to get comfortable with not knowing everything upfront. You have to trust that you'll figure it out as you go. But once you do, you too will have a superpower for approaching any problem.
The Real Superpower
What I've found is that learning just enough to be dangerous builds on itself. Every time you successfully figure out what you need to know to solve a problem, you get a little more confident that you can do it again with the next problem. You're not going to be the world's expert in anything, but you can get stuff done. Now, I’m not suggesting you partake in “hustle culture” to “get stuff done quickly” because, for me at least, learning is part of the fun. But if you’ve ever said to yourself “I wish I could make a game” or “I wish I could knit a scarf” or “I wish I knew how to change a tire on my car” I’m talking to you. You can! Just get started!
In a world with infinite information available, learning how to learn matters more than what you already know. The ability to identify what you need to know, find it, and apply it to your specific problem - that's the real skill.
So stop preparing to start. Just start. You'll figure out what you need to know along the way.
Have you experienced tutorial hell? What's something you've been wanting to build but keep putting off until you "know enough"? You probably know enough to get started right now.