Hands-on programming

Growing up I remember my favorite lessons in school were when they were hands-on. I wasn’t very good at listening to lectures or reading and summarizing, but if you told me to use my hands I was usually a lot more engaged in the lesson. Obviously for these reasons, I was particularly good at science projects and technology-based electives.

I loved that with some raw materials and a little bit of instructions that I could use my imagination to build or make something with my hands. While the intentions of the lesson would be for all of us (students) to arrive at a similar or an expected result, each of the finished products would be slightly different because each student was different.

I believe this hands-on approach has carried over in my adult life. Although I’m not taking classes anymore, I am constantly learning new things. In my craft as someone who makes things with code and pixels, I’m always expanding my knowledge in the various ways to build things.

I know this hands-on approach isn’t for everyone but for me it has definitely been beneficial. Here’s how.

I’m building a portfolio

Every new language I’ve learned, I’ve tried to think of a project to actively build while I’m learning the language. Doing this serves two purposes, I’m building something I want to see exist and it makes learning a lot more fun. As a result, I’m building something that I can actually show others — a portfolio of work. A recent example of this, I’ve been learning Ruby on Rails and what I’ve built while learning is One Thing Done Today.

This is powerful in a couple of ways. First, I’ve had random people on the Internet stumble on my site and has seen what I’ve worked on and get a sense of my skill-set and has asked me to work with their company. Second, when I’m on a job search, people will usually Internet stalk me via my website prior to an interview. When I reference something I’ve built during the interview, they usually will respond with, yeah we saw some details of it on your website; tells us more.

This allows me to solidify my skills beyond what I’ve claimed on paper.

Saves time

Because I’m building something that I want to build and not following the documentation or tutorials, I can forgo pieces of the technology that isn’t relevant to me. What this allows me to do is move quicker in my building process since documentation is more for reference instead of step-by-step lesson on how to build what I’m trying to build.

Now I admit, this doesn’t work well all the time. Because of the way I skim or sometimes skip over chunks of details, I miss smaller details that are sometimes important. In scenarios like that it would’ve been time well-spent to slowly go through the tutorial in its entirety. But in my experience, building first and then filling in the gaps as I went was a lot more beneficial in that I saved time and got to see the fruits of my labor sooner.

Helps others

The great thing with learning is that there isn’t a singular path to acquiring knowledge. Learning is very much a pick your own path adventure — there are many paths to the same destination. When I meet others who have this hands-on approach and they are trying to learn something I’ve already learned, I can usually share my knowledge in a way that resonates with them because I understand the way that they learn.

An added benefit to making things that I want to see exist, others wanting the same thing can use what I’m making. Which is ultimately what I’m trying to do with everything that I make — enrich the lives of others.

If you’re also someone who learns better through the hands-on approach and are learning to program, consider the benefits I’ve listed above. It may help you learn the technology you’re trying to learn better, with more fun and may have some added benefits you didn’t know that came along with it. Happy building friend 😁


Originally published at Michael Lee.