Trying to land your first web developer job, but feeling shaky on some of the fundamentals? Looking back on my career, I’ve come to realize that one of the most powerful tools for learning I’ve experienced is a deceptively simple idea: build your own.
There’s no substitute for hands-on experience, and the beauty of programming is that the barriers to entry are so low. A personal hobby of mine, woodworking, is the complete opposite. Want hands on experience building fine furniture? Great, go buy $10k of specialized power tools to get started.
Programming is downright miraculous by comparison. Want hands-on experience with client side JavaScript frameworks? Go build one. Right now. Seriously.
It can be daunting, to be sure:
“How do I even start? There’s no way I can do that!”
But it’s important to realize a few key details:
- If you are just starting out as a developer, your end result will be ugly. Guaranteed. It will be riddled with bugs and the code will be an ugly mess. But that’s okay. You’re goal isn’t to compete with mature solutions that entire communities of experienced devs have built – your goal is to learn. Treat it like a sketch of a drawing; sure, it looks nothing like the real thing, but you learn an incredible amount along the way.
- Once you accept that the end result will be ugly, it frees you to focus on making incremental progress. Don’t sit down at the keyboard and try to bang out a complete React clone this afternoon. Start with the smallest possible chunk you can tear off, and make that work first.
- Once you’ve built your own version, be prepared to toss it aside. Like we talked about, the goal here is to get the experience. Your solution will likely be lacking compared to the mature OSS offerings out there. But now you’ll understand those tools on a much deeper level.
But what should you build?
In short, anything you are trying to learn better.
Feeling fuzzy on exactly how JSX works? Go build your own templating language!
Unclear on how the Devise gem for Rails does it’s magic? Try creating your own user auth gem.
If you’re still not sure, here’s a few ideas to get you started:
- Promises. This is a topic that is a continual challenge for newcomers to JavaScript, and for good reason. It’s a conceptual hurdle to overcome. So go build your own Promise implementation. What does the “.then()” function actually do? How do you chain them?
- Routing engine. This is a great one to peel away some of the mystery around server side frameworks like Rails or Express. Create a library that takes an incoming URL and routes it to a given function. Now step it up a notch and add full blown controller classes. What would you do differently?
- Bundler. Modern JavaScript bundlers are enormously complex, but they tackle a fundamentally straightforward problem – take a set of JavaScript files and combine them into a single output file optimized for the web. So start small with your own – try just combining JS files into one output file. Then think of how you might make that output file more efficient for delivery over the web.
- Module loader. Another area of Node.js that often looks like black box magic: “require()” Somehow you call this function and your code is loaded! But – did you know “require()” is implemented entirely in JavaScript? Go ahead, check out the Node source! Now go and design your own “require()” function. What would you change from the default Node version? Why?
- Virtual list views. These represent a common performance optimization technique: if you’ve got a million items in a list, only render the ones onscreen. It sounds simple at first, but there’s plenty of complexity here. Check out how other libraries tackle it, and try to solve it on your own!
Now that you’re stocked with ideas, get out there and start building. And if you have any questions, don’t hesitate to hit me up at dave@discoverpraxis.com, or @davewasmer on Twitter!