The other week I was involved in a couple panel sessions for high school students interested in going into the tech industry. They got a tour of our office and the opportunity to ask myself and some of the other engineers questions about our experiences.
One of the recurring points brought up by the engineers is the importance of having some personal projects to work on. You learn so much more by doing things on your own.
Classes give you theory and disconnected techniques. You learn about various
language features and design patterns, but often don’t see how they fit
together. Homework assignments are often esoteric and contrived: designed to
complement the lectures. They guide the student to select certain techniques or
skills to solve the problem. When you’re doing homework for the chapter on
for loops, you know you should always use that tool to solve the problem.
You won’t learn how to recognize the characteristics of problems algorithms
that are better implemented with other looping constructs.
When building something yourself, you have to reach into your repertoire and select the right tool for the job. You won’t necessarily learn this from class work.
Working on your own projects also gives you an opportunity to practice related skills that are vital in industry but also usually neglected by the academy.
For example, while working on your own projects you’ll learn the value of using a source control system, especially if you are collaborating with another student. After getting lost in the weeds chasing down a solution, you’ll be so grateful to know the SCM has your back and will let you easily revert to a known good state. If you work with others, you’ll bump into merge conflicts and you’ll learn how to solve them. These are skills you’ll use daily in industry.
You’ll learn the importance of tracking bugs and feature requests1. In your own project you’ll find issues that you want to fix or features you want to add but don’t feel like diving into right away. Learn to write them down and categorize them. You’ll have to make decisions on prioritizing the list of changes. You’ll do this all the time when you get your first programming job.
Some of the students were worried about not being able to think of projects that were very interesting. I tried to show them how that really doesn’t matter. There’s plenty you can learn from a project that doesn’t really do much. When I was learning how to make DSLs in Ruby I once tried to build a directory cleaner that would sort files into folders based on their type. No one uses it, not even me! But I learned valuable skills! Objective met!
However it’s still helpful to work on a project that scratches your own itch if you can. That will keep you motivated when you inevitable get bogged down in a difficult issue. It makes what you’re working on feel more concrete and not theoretical.
While one of the other engineers encouraged the students to see a project through to completion, I sort of disagreed. I do recognize there’s a lot of value in finishing a project: you learn to support and deploy it for example. But sometimes I like to start a side project just to learn a particular skill. Once I’ve got that experience, I don’t feel guilty about abandoning the project.
For example, a couple years ago I wanted to learn the basics of compiler theory and abstract syntax trees, so I started building a SASS compiler. Once I had handled some of the basic transformations, I had learned what I wanted to learn. I figured out how to parse the input using a finite state machine, how to convert the token stream into a tree, how to walk the tree with a visitor pattern, and how to use a stack to make the transformations. These are all great skills to add to my arsenal and now that I’ve acquired them, I don’t feel the need to finish the compiler.
Along those lines, you don’t even have to share the code if you don’t want. While having a public body of work available to show potential employers probably has some value for new programmers, the primary goal of the project is to learn something from it. You don’t necessarily have to show the code in the interview, but being able to speak confidently about projects you’ve worked on or problems you’ve solved will go a long way in setting you apart of the other candidates.
So long story short, get out there and practice what you’re learning. When you’re just starting out, especially if you’re still in school, you probably have an abundance of time and energy to dedicate to learning. When you get older and have more responsibility, you’ll miss having the time to work on your own projects. I know I do!
- 1.Even if you're the one making the request ↩