I've been a tech lead at a bank, and at the time of writing this, I'm a senior developer at a big payments network and I felt I had to always to prove myself by always following strict "enterprise" coding standards for my public personal projects. But in reality, it's more like "who cares?".
✨Who cares if it's simple?✨
You do you and have fun.
It Was Holding Me Back
Changing visibility on a GitHub repo for your side thing shouldn't be a worrying toss up of "oh no, what if they'll realise I'm actually terrible at coding?" - that's the imposter syndrome talking. It's also stifling.
Why stifling? Because for me thinking that way is akin to the old phrase "perfect is the enemy of good". Waiting for perfection stops us from learning faster. Tech loves the concept "fast fail" but I like it better described in the book Atomic Habits by James Clear. James writes about this concept on this website too, but in short:
- Jerry Uelsmann, a University of Florida professor split his photography class into two groups: One that needed to take many many photos to pass (quantity), and one that needed to create one perfect photo to pass (quality).
- The best photos came from the quantity group because they continuously ran through their learning feedback loop and built up their skills.
In 2021 I realised my hesitancy to show sub-optimal code to the world on this website and my GitHub was slowing down my learning progress. And since then I've produced sub optimal code. But had a blast at making:
- TinyWordle. A super shrunk down Wordle clone to learn about AoT in C# (blog post)
- CO2 Meter. Using an Adafruit feather to make an on-the-go CO2 meter (blog post)
- BrothermanBill. Music and meme discord bot (blog post)
- Procedural Pokémon Buildings. Rule based generation of generation 1 Pokémon buildings (blog post)
Go ahead, click on the links to the repos. Most of the time, it's simple code that gets the job done. I'm not writing code for enterprise, I'm writing it for me.
And each one of those taught me a lot and I've done many more projects. Coincidentally some even taught me skills I'd use at my job the very next month. It almost felt like I was cheating, reading the answers before I needed them, but that's just called study and it was paying off.
Another way to describe how this feels is from a niche skit from The Simpsons. Marge explains that you just need to be piano lesson ahead of the kid you're teaching, and that's always stuck with me. But hey, that's learning!
I Just Wanna Have Fun
I like Pokémon. I wanna do silly little Pokémon projects because they bring me joy. I believe this joy outweighs "what if my tech lead sees my suboptimal code?" or "will my next employer judge me?". I believe that putting yourself out there for things that matter for you is way more brave, character proving, and admirable when compared to worrying what others might think. I believe in you just doing you.
You Don't Need to Actively Learn Every Time
src of an
<img> isn't going to win an award. But the thing that pops out the other end, that final product, is absolutely satisfying - and that's part of the fun of it all.
You don't need enterprise cargo cult programming or a whole mass of open-closed principle, long class names, interfaces, guard clauses, DI, 100% unit test coverage, UI tests, YAML, Kubernetes, or anything else! (Unless you're doing it to learn).
If you just wanna get your little creation up and running (or minimum viable product) then go ahead.
If you're making it for you, you don't need to impress anyone.
Simple projects, public or private, are a wonderful boon. Whether it's for learning or your own personal enjoyment. Both are extremely valid and worth. If you're gonna make your project(s) public, there's a great amount of bravery putting yourself out there, congratulations!
For the final time because I fully believe it: you do you 💛