Clone Open Source Apps

Author’s note: This is part 3 of a series of essays I originally drafted about Opinions for your Tech Career. Part 1 is Learn in Public.

A fully expanded and revised version is available in The Coding Career Handbook!

You already know you should be making projects to learn things and potentially add to your portfolio. You’ve read your Malcolm Gladwell, you know that you need 10,000 hours of deliberate practice. Given you’re just starting out, I have a slightly contentious suggestion for you: DON’T make anything new.

Your decision-making is a scarce resource. You start every day with a full tank, and as you make decisions through the day you gradually run low. We all know how good our late-late-night decisions are. Making a new app involves a thousand micro decisions - from what the app does, to how it should look, and everything in between. Decide now: Do you want to practice making technical decisions or product decisions?

Ok so you’re coding. You know what involves making zero product decisions? Cloning things. Resist the urge to make your special snowflake (for now). Oh but then who would use yet another Hacker News clone? I’ve got news for you: No one was gonna use your thing anyway. You’re practicing coding, not making a startup. Remember?

Make the clone on your own, then check the original’s source. Now you have TWO examples of how to implement something, so you even get to practice something only senior devs get to after years of experience: understanding the tradeoffs of technical choices!

You’re lucky. You live in an age where companies and teams open source their entire apps. There’s Spectrum and Codesandbox and FreeCodeCamp and Ghost and if those seem like waaay too big of an app for you (they are huge) go look at the side projects of your mentors (see above). Ryan Florence has planner and Kent Dodds has TIL! Make a clone, then show it to them! You are guaranteed to get free feedback.

Here’s the subheading: put a time limit on it. Deadlines work wonders. Also you’re not going for a pixel perfect clone of something that teams of people, way more experienced than you, have made. You want to have a set amount of time, get as much of the interesting features as possible, and then ship it. This guarantees that you will be freed up for the next clone, and the next. Different projects let you try different libraries and stacks, and figure out what you like there. Also you get to practice one of the hardest software engineering skills of all: Project Estimation. You’ll create many, many opportunities for yourself to see what you can do in a set amount of time because you’re deliberately practicing making things on the clock. And none of that time is taken up by product decisions!

When you’ve done enough and start feeling bored, it’s time to let your freak flag fly. You’ve earned the right to make your app because you’ve made others. You know what things cost and you have used your tools well enough to get there. You’re still learning in public, though! Package up your experience into a talk. Livestream yourself coding. Blog about your game plan, then blog some more as you execute it. Developers who can communicate are in far more demand than developers who can’t.

P.S. All this will be a lot easier if you Know Your Tools well.

Backup advice from Ryan Florence:

Next: Specialize in the New!

Tagged in: #principles #advice #learn in public

Leave a reaction if you liked this post! 🧡
Loading comments...
Webmentions
Loading...

Subscribe to the newsletter

Join >10,000 subscribers getting occasional updates on new posts and projects!

I also write an AI newsletter and a DevRel/DevTools newsletter.

Latest Posts

Search and see all content