Introduction
Some people learn to code in a straight line:
Bootcamp → project → job → success story.
Me? My path looked more like a Google search history:
"how to exit terminal"
"terminal fatal error"
"git undo last commit"
"refund policy template"
I started my coding journey in 2022, joined GoTo Bootcamp Batch 2, learned Ruby… and then completely left the field to work in infrastructure.
Fast forward to now — I finally have the free time (and courage) to get back into software engineering.
And yes, I’m still using the terminal, not VS Code.
Why? I don’t know… maybe I like the hacker aesthetic.
But it means I have to get used to a lot of things people with fancy code editors take for granted.
Back to Square One
When I opened my laptop to code again, I realised I had forgotten almost everything from 2022.
Ruby? Gone.
Syntax? Gone.
Muscle memory? Also gone.
This time, I decided to learn Go (Golang).
Why Go? Because it’s fast, efficient… and everyone says backend developers with Go are in demand.
Also, the mascot gopher is cute.
Somewhere along the way, I also stumbled into Big O notation.
If you don’t know it, it’s basically math meets performance — the speed and efficiency of your code.
At first, it felt like learning a new alien language.
But once you get it, you start seeing code differently, like “Ah, so that’s why this loop is slow…”.
The Coffee Shop Challenge
Then came my first real challenge:
Build a coffee shop app in one month.
Now, keep in mind:
I had no strong coding background, no team of juniors like me — but luckily, I did have two senior software engineers on my team.
And that made a huge difference.
The Seniors to the Rescue (and My GitHub Blunder)
From day one, my seniors guided me through the basics:
- Installing GitHub and setting up repos
- Understanding branches, pull requests, and merge conflicts
- Reminding me that “main” is sacred… and you don’t just push to it directly
Of course, I still made the rookie mistake:
I accidentally merged and pushed directly to main.
In GitHub collaboration, that’s like spilling coffee all over the company laptop.
What happened?
- My changes went live before review
- My seniors had to help me revert
- I learned why branches exist in the first place
Lesson learned: always create a new branch for your work.
Pull requests are like polite invitations — “Hey, can you check my code before we let it join the party?”
Skipping that step means your messy code just barges in uninvited.
Wearing Every Hat at Once
This project wasn’t just coding.
I was also:
- UI designer — Designing in Figma, revising layouts until my eyes hurt
- Legal team — Writing T&C, refund policy, and other pages (yes, I Googled “coffee shop refund policy template”)
- QA tester — Making sure the landing page was smooth, responsive, and didn’t break on mobile
- UX critic — Getting stuck for days on one screen because I didn’t like it, overcomplicating the UI until it hurt the UX
Designing in Figma was its own battlefield.
Some screens took days because I was too focused on “making it look cool” instead of “making it usable.”
Eventually, I learned the hard way: good UI isn’t always good UX.
The Frontend First
The desktop version was built with Vite + React (JavaScript).
It had:
- Login system (UI only at this point)
- Cashier dashboard
- Landing page with smooth animations and full responsiveness
- T&C and Refund Policy pages (because business needs them too)
I revised the landing page so many times that I lost count.
But it was worth it when it finally felt smooth and professional.
Mobile Version: Flutter, My Frenemy
I also wanted a mobile version, so I used Flutter with Dart in Android Studio.
And let me tell you — it was like fighting a stubborn coffee machine: sometimes it works, sometimes it spits out an error for no reason.
The first few days were chaos:
- Missing packages
- Emulator freezing
- Layout looking like it had been hit by a bus
But slowly, I learned to debug.
Every solved error felt like I had just defeated a mini-boss in a game.
The Deadline Reality
I was supposed to finish in 4 weeks.
It took me 5.
But honestly? I’m proud of that.
Because for someone without much coding foundation, I managed to design the entire UI/UX and front-end in just over a month.
And that saying is true — when you actually face a real project, you learn way faster.
Tutorials are good, but nothing teaches you like a ticking deadline.
What I’m Learning Now
Right now, I’m diving into backend development — understanding how the logic runs, how data flows, and how the app actually works behind the scenes.
It’s like I built a car’s exterior and now I’m figuring out how to make the engine run.
Lessons from My Weird Journey
If you’re starting your coding journey (or restarting like me), here’s what I learned:
- Real projects are the best teachers — You’ll hit problems you never see in tutorials.
- GitHub mistakes are part of the process — Just don’t make the same mistake twice.
- Deadlines push you forward — Without a timeline, you’ll just keep “learning” forever without finishing anything.
- Good UI isn’t always good UX — Pretty designs are useless if they confuse users.
- Ask for help — Seniors aren’t there to judge; they’ve made the same mistakes before.
- Enjoy the chaos — It’s stressful, but it’s also fun when you realise how far you’ve come.
Conclusion
From a bootcamp dropout in 2022 to building a coffee shop app in 5 weeks (with some GitHub drama, too much UI, and legal-document-writing duties), my journey has been anything but smooth.
But that’s what makes it exciting.
I’m still learning, still making mistakes, and still occasionally talking to my terminal like it’s a person.
If you’re reading this and wondering if you should start (or restart) coding — do it.
Your journey won’t be perfect, but it will be yours.
Your turn:
What’s the first real project you worked on, and how did it challenge you?