Two years ago, my job was making sure the produce section didn't run out of avocados and that sixteen people showed up for their shifts on time. Today, I maintain two open-source Linux projects, one of which ships with real packaging, real users, and real GitHub issues from strangers I've never met.
Nobody handed me this. I built it, in public, starting from zero.
Here's how a retail manager with a TikTok LIVE community became a developer — no bootcamp, no CS degree, no permission slip required.
The part nobody puts on a LinkedIn banner
For about eight years I ran the floor at Trader Joe's: scheduling, payroll, vendor relationships, training new hires, defusing the customer who is very upset about the samples. Before that, front desk work — phones, filing, the unglamorous infrastructure of an office nobody thinks about until it breaks.
On the side, I was building something else entirely: a TikTok LIVE community that grew past 50,000 followers, with a 300+ member Discord I ran with a 16-person moderator team. Analytics dashboards. Retention strategy. OBS and audio troubleshooting at 11pm because a stream can't just pause while you fix a driver issue. Conflict resolution, but for the internet.
None of that reads as "engineering experience" on paper. All of it was.
Picking the least glamorous problem I had
I didn't start with a bootcamp project or a todo-list clone. I started with something that actually annoyed me: my laptop's built-in keyboard kept interfering when I had an external one plugged in. So I built KeyFlip — a Linux utility that detects internal vs. external keyboards and disables the built-in one safely, with a GUI, tray controls, and fallback behavior so you never get locked out of your own machine.
That "safely" part mattered more than I expected. The first version worked until it didn't — an edge case where a bad detection could leave someone typing-blind on their own laptop. Fixing that taught me more about defensive coding than any tutorial would have. I tested it on real hardware, packaged it for Fedora, and I still ship updates based on feedback from Linux developers actually using it.
That's the difference between a portfolio project and a toy project: someone else's workflow depends on it not breaking.
Then I let myself build something a little weirder
My second project is Mochi — an open-source desktop companion: a small pixel-art creature that lives on your screen and reacts to you. Built with Python, GTK4/PyGObject, and Cairo, it's taught me event-driven architecture, animation state machines, Wayland/X11 quirks that don't show up in any documentation until you hit them yourself, and the discipline of writing a real test suite instead of "it worked on my machine."
The engineering lesson here was scope control. It would be easy to let a desktop pet grow feature-creep forever — health bars, mini-games, notifications. I made a deliberate call: no punishment mechanics, no pressure, quiet by default, the user's input always outranks the pet's autonomous behavior. Constraints like that are a product decision as much as a technical one, and having to make them is exactly the kind of judgment retail management already trained into me — just pointed at code instead of a schedule.
What actually transferred
- Debugging a livestream at 11pm → debugging a segfault at 11pm. Same nervous system, different stack trace.
- Managing 16 volunteer moderators → managing scope, priorities, and a GitHub issue queue.
- Training new hires on a process → writing documentation someone else can actually follow.
- A customer escalation → a bug report from a stranger who is, understandably, a little annoyed.
The tools were new. The underlying job — stay calm, find the actual problem, fix it, explain it clearly — was not.
If you're standing where I was standing
You don't need a CS degree to start. You need one real, specific, slightly annoying problem in your own life, and the willingness to make it work on real hardware for real people — not just in a tutorial's happy path.
Pick the boring problem. Ship it badly first. Fix the edge case that embarrasses you. Then pick a second project and let it be a little more you.
I'm still job-hunting. I'm still learning. But I stopped waiting for someone to tell me I was allowed to call myself a developer, and started proving it with commits instead.
I write about the nontraditional path into tech, Linux desktop development, and building in public. Follow along if you're doing the same thing from a different starting line.
Top comments (3)
What a great story and such a smart way to learn something new while actually building along the way. I really admire it!
It's so easy to get stuck in tutorial hell. I've been there too. But once you build something real yourself, you realize it's the only approach that truly works for both learning and creating.
Your story should also be hugely inspiring for anyone stuck in a job that isn't very interesting or well-paid. Yes, it's hard to work on something else after a tough day, but it's possible, and you're living proof. Chasing that goal is always a worthwhile investment.
Thank you, I really appreciate that! 💚
Tutorial hell is so real 😭 I think the biggest change for me was finally accepting that I don’t need to understand everything before I start building. Half the learning happens because I break something and have to figure out why.
Still have a long way to go, but I’m having way more fun learning this way. Thanks for reading!
I really relate to this. When I was starting out as a software engineer, I spent weeks, sometimes months, stuck in tutorials because I thought I had to know everything before I was allowed to build anything. It stressed me out so much. If only I could go back and tell myself to go easy on himself and just start making things.
Having a long road ahead is the exciting part, especially when you acknowledge that and once you've figured out what works for you.
Enjoy every step of it! 🙌