Shipping Anyway: Vibe Coding vs. Imposter Syndrome
[Note: We really need a new word for ‘vibe coding’ — it’s so lame. But in lieu of easily being able to describe what I mean with another phrase… here we go.]
For a while now I’ve been using LLMs to create little side projects just for me.
I love automation and making myself more productive with little tools, utilities and scripts. But I’m a lousy programmer, so vibe coding has given me a way to quickly build these things without caring about the quality or scalability I’d normally worry about at work. As long as the outcome is what I want, great. IDGAF how I got there.
However, this holiday season, I found myself vibe coding a project primarily for myself that I then thought, “hmm, other people might like to use this.”
But before flipping that GitHub repository setting from ‘Private’ to ‘Public’ I hesitated:
- “What if ‘real’ programmers look at the commit history and notice that it’s a mess?”.
- “What if ‘real’ programmers judge me for vibe coding a project without even really looking at the code?”
- “What if someone wants to use my project for something ‘proper’ and soon realise that it doesn’t scale because it was built so poorly”.
These are obviously dumb concerns, rooted in the deep imposter syndrome I’ve felt ever since working in tech:
- Commit history and Git hygiene don’t matter in this context — it wasn’t a collaborative project and no one is going to need to understand the history past ‘now it just exists’. If anything, having a messy, vibe-code driven history declares ‘it is what it is, take it or leave it’.
- If someone is inspired by the project or finds utility in it, but realises the code is crap, they can submit PRs to refactor it (or just recreate the idea entirely themselves).
- I should be so lucky that anyone cares enough to use my project, let alone peek at the code. Most open source projects get used by nobody but the creator.
- I’m a Product person by trade — you’d think by now I’d practice what I preach and focus myself more on the outcome than the implementation!
If you’re interested in hearing about the project, the TLDR is this:
As an ex-GitHubber, I’m all in on using GitHub as a knowledge store. But my problem with viewing markdown files on GitHub repo pages is that they have too much distracting UI “chrome” — viewing a markdown README file in a repo has lovely, well-styled and readable content, but all the other stuff gets in the way.
Yes, GitHub has a Wiki feature, but I never cared for the design and UX of that.
So I created a simple Jekyll theme that basically mimics a stripped-down GitHub markdown preview experience (clean content, simple navigation via a tree view, etc.) for any repo that contains README files. Any directory that contains a README becomes a nav item. Simple.
Anyway, here it is if you’re curious: