Article summary
Before we dive into learning how to code, we have to learn how we learn. Only then, once we understand what type of learning coding requires, can we effectively create a stupid simple guide.
How We Learn In General
The way I see it, our brains are like giant sticky webs, capturing knowledge to snack on later.
You can fill this web in one of three ways:
1. Spaced repetition (aka school)
2. Integrating knowledge into an existing web (aka Obsidian & Roam)
3. Making a new web via “doing.”
Each of these approaches has its merits. The first approach works for knowledge unrelated to what you already know. As an added bonus, it gives you quick recall of said knowledge.
So if you are an English speaker trying to learn Spanish, spaced repetition works like a charm. It helps you learn a language unrelated to the one you already know and keeps what you learn close at hand.
Approach two is wonderful if the new knowledge relates to things you already know. With this method, you leverage what you already know to learn what you don’t yet. It’s a powerful lever, but not one that works in every situation.
Approach three covers a different kind of learning, one that is tactile and experiential. You can’t use Quizlet to become a master fencer, nor can you use Obsidian to learn to dunk a basketball. Some knowledge is tactile, only learned via doing.
Most of coding falls into this third category. You can memorize an API with spaced repetition. You can learn the basics of functional programming by leveraging your knowledge of object-oriented programming. But, building an application from scratch is a whole different animal.
There are trade-offs to consider and personalities to manage. There are security vulnerabilities and performance considerations. And always, always, there are bugs.
So how does one do this tactile learning that coding seems to demand?
How to Learn To Code
In my time at Atomic Object, where you learn on the job, I’ve found three things have worked:
1. Make It Stupid Simple (MISS).
2. Make it your own.
3. Make it communal.
1. Make it stupid simple.
Make it stupid simple. Whenever I fail a project, I see an over-complicated mess in my rear-view mirror.
My most memorable failure was before I joined Atomic Object. I was a naive high school kid fed up with the boring training of Pokemon. To skip to the fun parts of the game, I created an automated Pokemon player to do my dirty work. The first iteration was stupid simple. I used hot glue, screws, wood, and servos to button mash my way to victory.
The second iteration was anything but simple, and in the end, quite stupid. For my second iteration, I tried to build a Machine Learning powered Computer Vision Raspberry Pi. When it was all said and done, I’d fried my SD card, failed to even download the Computer Vision package, and had given up.
Reflecting back on the experience, I realize I went from 0 to 100.
I went from technology I knew for solving a problem that was challenging to technology I didn’t know solving a problem that was insane.
Don’t be the second iteration me. Be first iteration me.
Keep it stupid simple by learning to code one thing at a time. Think of your learning as an experiment. In the best science experiments, they change one variable at a time. Start simple and keep it simple by adding one new thing to learn each iteration.
2. Make it your own.
Last quarter, our accelerator cohort decided to study Amazon Web Services (AWS). AWS, if nothing else, prides itself on details and weird names, two things I’m terrible at.
I knew if I was going to learn anything about AWS, I was going to need a trick. Thanks to Joe Chrysler, I found one.
Joe created an imaginary world in which Atomic Object needed AWS to help manage our interplanetary shipping system.
Now I was no longer learning random AWS names. I was building the future of Atomic Object. Not only did the shipping system focus our learning, but it also gave us a sense of ownership.
Crafting a project to address your stupid simple learning goal gets your emotions involved.
As everyone knows, we care more about things we own (at least most of the time). To dive deep, you need to dig deep. And to dig deep, you need to get personal.
3. Make it communal.
There is a real misconception that learning to code is a lonely endeavor. I’ve talked about what people who aren’t in tech think of us before, but I failed to mention this tidbit. Even with a whole book to disprove it, the perception that you can become a coding wizard alone lives on.
Learning alone isn’t impossible, but it is harder. When we group up, we leverage the power of social ties and the pressure they create to help us get work done.
By taking inspiration from the group, we lower the amount of willpower (a limited quantity) we use to get shit done. The result? We get more shit done!
On top of getting more done, having a community around us helps shape our thoughts. This works in two ways.
First, groups force us to share our thoughts. Sharing your thinking initiates a process of refining and crafting you don’t do alone. This refinement is why rubber duck debugging works.
Second, you receive feedback and different perspectives.
This quarter, my “rock” was to connect with the Michigan Startup scene. When brainstorming ideas, all mine involved meetings with friends. Then we shared with the group and my fellow accelerator Patrick recommended finding a startup to invest in via Republic.
In one fell swoop, Patrick made my quarterly goal concrete and, better yet, testable. Within a week, I’d done research on Republic and decided the startup world and investing were not for me. Thanks to Patrick’s quick thinking, I was able to pivot and pick a quarterly rock better suited to my interests.
Learning to code is simple but not easy. What I’ve learned at Atomic Object is that good learning does three things. It makes it stupid simple. It makes it personal. And finally, it makes it communal.