This article was published on April 4, 2015

Build to learn: Why you should make things no one will ever use


Build to learn: Why you should make things no one will ever use

This post originally appeared on the Crew blog.


If you’ve ever built something for other people you’ll know the buzz that comes from having real users. There’s nothing quite like knowing you made something from scratch that helped or entertained another person.

Once you’ve made something used by other people it might seem like it doesn’t make sense to go backwards and make things just for yourself. Except for one very good reason: to help you learn.

Build to learn

Building small, self-contained projects is a great way to learn and expand on your skills. When you learn by building something new instead of just through reading and theory, you learn implicitly rather than explicitly, and are more likely to retain and use the knowledge you’ve gained.

“Forget the rules, and learn from first-hand experience instead. There’s so much more to be gained from not knowing how to do things the ‘correct’ way, and learning to do them your own way.” Richard Branson

The <3 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

Let’s say you want to try out a new technology. Maybe a new tool just became available, or a new programming language caught your interest.

So you build a small project solely designed to give you a real-world lab to experiment in. You design something so small that you can easily get it started and then spend the majority of your time learning from hands-on experience.

Being at this level of expertise and being able to ‘play’ with new technologies is something beginners don’t have the luxury of. As a seasoned creative in whatever your field, you already have the skills to design and build small projects that can help you explore, answer questions, and improve your skills.

Learning by doing is often called experiential learning by educators and psychologists. In 1984, the psychologist David Kolb developed a theory of experiential learning that involves four stages:

crew-diagram

In more basic terms, the flow of this four-stage process goes something like this: you have some experience with something new (concrete experience), then you reflect on this experience (reflective observation), combine it with your existing knowledge to turn it into a concept or theory (abstract conceptualization), and finally apply that concept or theory to other projects (active experimentation).

The important part here is that the basis of your future ideas comes from the experience of working with something hands-on.

Seasoned iOS developer David Smith uses a similar “learn by doing” approach when he wants to test new technology from Apple. If Apple announces a new API that David wants to learn about, he’ll read up on it and then create a small project to test it on.

These projects don’t ever get released to users but the process helps him to conceptualize the new technology so he can later use it in the products he ships to customers.

“… you don’t learn to walk by following rules, you learn by doing and by falling over.” Richard Branson

Build to practice

I’ve known for a while now that deliberate practice is necessary if you ever want to get really good at something. Deliberate practice is a conscious effort to focus on the specific areas of your skills that need work.

For example, rather than playing songs you know well on piano, deliberate practice would be playing scales or focusing on those few bars you just can’t quite get right. It’s painful, and often boring, but it’s what separates pros from amateurs.

When I started learning iOS development I didn’t know how to deliberately practice my skills. I couldn’t understand how to practice the small things I’m terrible at in the context of building a big project. Once you’ve solved a problem within the product you’re building you don’t need to work on it again.

Of course, that means having to wait until the same problem crops up again in a different project to practice the same solution.

Without the opportunity to deliberately and regularly practice a new skill or work on a technique we quickly lose that insight into the issue and facing the problem down the road can seem like starting all over again.

The answer is to build smaller projects just for yourself—projects that force you to answer tough questions. Projects that let you focus in on one particular skill or technology at a time.

I recently started a small project that uses a list view, which gave me some extra (and much-needed) practice laying out a list and making it look the way I want.

crew-toread

I still need practice with this, so I could continue by creating several small projects, one a week even, to practice laying out list views with different data and slight layout variations.

Another thing I’m terrible at is fiction writing. If I wanted to get better at that I could work on some short stories. I don’t need to release them, but I can use each one as a playground to experiment on a particular area of my weak skills.

One could be an exercise in developing characters. Another could focus more on clarity in my writing. Another might be strictly plot-based and used for experimenting with twists and turns in the story.

Jennifer Dewalt has been doing a similar project as she learns to code from scratch by building 180 websites in 180 days. She’s gone from basic sites that include only HTML and some basic CSS to learning JavaScript and Ruby on Rails and building games and calculators.

crew-jensite2
One of the 180 websites Jennifer built in 180 days.

Though Jennifer is sharing all of her code on GitHub, she’s following a similar process to what I’m suggesting: she’s using this project an an opportunity to build for practice.

Build for yourself

Your experimental projects could very well turn into publicly released work that you’re proud of. There’s nothing wrong with that. But the freedom that comes from this type of work is partly because it’s not intended for an audience.

Jennifer mentions on her site that it’s tough to put all her learning projects on GitHub:

“It’s scary to have all of my mistakes and misunderstandings out in the open.”

I’m all for sharing your work. In fact, I think most of us could stand to share more than we do. But there’s a difference between your work and your experiments or learning. There’s an inevitable worry we all feel to some degree when we know other people will see what we’re working on. Building things just for you removes any of that concern.

Start with a plan to keep your work private. Let yourself experiment without fear of judgement, or wondering whether you’ll receive praise or make a fortune from what you’re building. Just focus on your craft and the education or improvements you’re aiming for.

This can be a surprisingly humbling experience. In a sea of likes and upvotes, when we’re so used to judging ourselves and our work based on other people’s reactions, working for yourself can really change your perspective.

It’s easy to make excuses about why you’re not improving your skills. I don’t work nearly as hard as I should on becoming a better writer because it’s hard and it takes time, and I’m just so busy.

But if we let those excuses carry us along, we’ll be doomed to let our skills become stale and outdated. We all know we need to make a conscious effort to learn new things and hone our crafts. I’ve given you a plan to do it—now it’s up to you to execute.

Read next: What I wish I’d known about running a startup

Get the TNW newsletter

Get the most important tech news in your inbox each week.