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.
