Picking what to learn
Before getting into coding, everybody always asks what programming language to start with. There is no single answer that is right for everybody. It’s always “it depends”, and it depends on what we want to do with our new knowledge.
The problem of not knowing what skills to pick up never really goes away. After a while, the question of what to learn first turns into the question of what to learn next.
We rarely learn new things for the pursuit of knowledge alone. Instead of randomly acquiring new skills, we want those skills for something. We learn languages to travel more. We learn how to drive to get places. We learn programming to build things. Without a use for a new skill in mind, we might as well not learn it at all.
The end always has to come first. If we know what goal we want to achieve, we can figure out what we need to get there. That approach shows us what we need to learn, but also what we can skip. We can filter the list of potential topics down so we can focus on what matters most.
My understanding of how the human heart works is superficial at best. Everybody at work talks about pulmonary valves and ECGs, while I nod along like an idiot. My limited knowledge of those terms makes it difficult for me to contribute to the team. Wanting to do a better job, I am unexpectedly learning how the human circulatory system works. The choice was easy, because I could see where I wanted to go.
Guess I am not learning how to juggle anytime soon. That would have been a huge distraction that contributes nothing to my current goal.
Tutorials often default to todo-apps. These twists on that idea help you dig into how the framework you’re learning really works.
Treat existing codebases as a blackbox. Take small pieces and write tests for them to understand a project’s inner workings step by step.
Streaks limit us to short-term thinking, yet we can only see long-term effects in retrospect. It’s okay to break a streak along that way.