Motivation: the honest version
Breaking into software without a degree can feel like walking into a room where everyone already knows the rules and you’re expected to perform anyway. Sometimes you don’t even get rejected by a person, you get filtered out by a system before your application reaches human eyes. The application process can be so discouraging, especially when you’re serious about changing your life. Still, it’s possible.
But it usually doesn’t happen through “vibes”, motivation, or random late-night tutorial marathons. It happens when you build a strategy that produces the one thing hiring managers care about most: proof. Proof that you can learn, proof that you can build, and proof that you can communicate clearly enough to be worth taking a chance on. This is the approach that worked for me.
Let's Talk About How I got here
In 2023, I hit a crossroads. I was tired of explaining ‘I’m figuring it out’ to people who meant well. I was old enough to feel the pressure of instability properly. What I was doing wasn't working out and I didn't just want a job but a career. Something with growth. Something that would stay relevant. Something that wouldn’t trap me into doing the same task forever. And yes (and maybe most importantly), something with strong earning potential. I wanted a skill that would keep challenging me and keep opening doors.
The more I looked around, the clearer it became that software engineering ticked every box I cared about. Not because I thought it would be easy, but because it rewards curiosity, consistency, and the ability to adapt.
Structured learning over random online tutorials
There are many ways to get into tech. Some people are fortunate enough to go to university, some do bootcamps, and some do it completely self-taught. Yes, self-taught developers exist everywhere in the industry.
Knowing myself and my curious nature, I knew that if I tried to do it all on my own I'd try to learn everything and never make any real progress. I’m a big believer in structured learning, especially in the beginning.
When you’re new, the hardest part isn’t necessarily the difficulty of the code. It’s the direction. There’s a lot to learn and you don’t know what you don’t know. That’s how people get stuck in loops jumping from one tutorial to another learning a bit of everything, but never building enough depth to feel confident.
Structure did a few important things for me. It forced me forward. It exposed gaps I didn’t even know were gaps. And it created momentum. It gave me deadlines, which quietly did something important: they turned 'I’ll learn someday' into 'I have to deliver.'. There was a sense of urgency, but I didn't have to wonder what I had to learn next or what would be useful in the real world and what wouldn't.
My ALX journey: the part that shaped me
In June 2023, I started the ALX Software Engineering program. I remember seeing a meme that said ALX will have you doing “Hello World” today and nested loops tomorrow, and boy was that meme accurate. Orientation came with warnings: an eighty-hour-a-week commitment, intense pacing, and a clear message that holding a full-time job or being a full-time student at a different institution while doing the program would be close to impossible. Most of us didn’t fully believe it at first. We laughed it off, believing we were smart enough not to need that much time. Then the work started, and the joke was over.
The days had a rhythm that was simple, but relentless. I would wake up to a new task, spend hours reading and researching, try things, break things, debug, read documentation again, and push until it worked well enough to pass. Then I would submit, get graded, and start again. Sometimes a project fit into a day. Sometimes it didn’t. And when it didn’t, I learned quickly that fatigue and the grading system don’t care whether you are “almost done.”
I remember our first big project, about three months into the program. We had two weeks to complete it, and we ended up spending the last week debugging. It felt like the harder we tried to make it work, the more things broke. On the last day, I started at 8 a.m. thinking we would be done by 6 p.m. Cut to 5 a.m. the next day. I was sleep-deprived, my back was aching, my eyes were barely open, and the project still did not work the way it was supposed to. That was the closest I came to quitting.
That failure made me wonder if I was even cut out for this industry. It pushed my graduation back, and it was devastating. But looking back, it taught me something I still carry. In the workplace, you will run into problems that look small and still humble you. Getting stuck is not proof you do not belong. It is part of the job. Resilience is what got me through.
What I appreciated, though, was how wide the program went. It wasn’t only about writing code. It constantly pulled you toward the bigger picture, how systems work, how teams work, how production environments differ from your laptop, and how professional developers actually operate. We were equipped with practical interview skills and often heard from former ALX alumni, which was a great reminder (and motivation) of what was on the other side of this daily chaos.
And somewhere in all that intensity, the most valuable lesson landed: the skill that keeps you alive in this industry isn’t memorising syntax. It’s learning how to learn.
You build the habit of meeting unfamiliar problems every day and still moving. You become comfortable with not knowing. You stop being scared of documentation. That’s the kind of preparation people don’t talk about, but it’s exactly what the job requires.
Getting the job: when the real game starts
After completing the program and graduating with my projects, I assumed the hardest part was behind me. Spoiler alert: It wasn’t.
Job hunting is its own skill, and it’s messy in a way that’s hard to explain until you’re inside it. You quickly realise that the tech industry is not one unified belief system. Some companies won’t consider you without a degree. Some prefer specific universities. Some label people with years of experience as “junior.” Some internships come with great support and compensation, and others pay you with “experience” and stress.
So when you don’t have the degree, you lean on the other currency: proof.
The problem is obvious. You’re newly qualified and you have zero work experience. Which means you’re trying to convince a hiring manager to trust you before you’ve had a chance to prove yourself in a workplace. That’s where your portfolio becomes more than a folder of projects. It becomes your argument. Ownership is the currency.
Early on, I noticed something that changed the way I approached things: a lot of candidates were building the same projects. A calculator, a weather app, a to-do list. While there is absolutely nothing wrong with these projects, they’re everywhere, and they often look like YouTube follow-alongs. Even if you built it yourself, the hiring manager has seen the exact same thing fifty times, and they can’t tell what you truly understand from what you copied. They don't know if you really learned or just copied the project and hoped they’d assume you knew what you were doing..
So I stopped thinking, “What project should I build?” and started thinking, “What problem can I solve?”
That shift matters. Because when a project is problem-driven, it naturally becomes more personal, more specific, and harder to fake. Even if it’s small, it carries your fingerprint. It also gives you something strong to talk about in interviews: why you built it, who it helps, what trade-offs you made, and what you learned.
At the same time, you have to keep your feet on the ground. Realistically, this isn't the stage where you're going to build the next Facebook or Uber. Not because you aren’t capable, but because experience is still loading. Better to build something you understand deeply than something huge that collapses the moment someone asks, “Why did you do it this way?”. It's very important that you 'own' the project and are able to answer questions related to it, from the idea to the code and approach.
The manager’s gamble (and the truth about AI)
Here’s something more people should say out loud: when a manager hires a junior developer, they’re gambling.
They’re not only hiring your current skill. They’re hiring your potential. They’re betting that you’ll be teachable, consistent, and honest about what you don’t know. They’re betting that if they invest time into you, you’ll grow into someone valuable.
That’s why interviews at this stage aren’t only about whether you can code. They’re about whether you can communicate clearly, whether you take ownership, and whether you can explain your work like someone who actually built it.
This is also where AI becomes a double-edged sword. AI-assisted work is normal now. Using AI isn’t the problem. The problem is when AI replaces your understanding. There’s a difference between using a tool to move faster and using a tool to avoid learning. Hiring managers can usually tell which one is happening, especially when they ask questions about your portfolio and you can’t explain basic decisions. Remember the point about ‘owning’ the project?
So yes: let AI support you. Let it help you brainstorm, unblock, and learn. But don’t let it carry you. You want to be the person driving, not the passenger claiming you know the route.
Ask yourself (and be honest): if I were the hiring manager, would I hire me? And if the answer is yes, what exactly is the reason beyond “I can code”? That’s what you should aim to communicate.
Continued learning: the job is just the beginning
When you finally land the job, it feels like you’ve reached the destination. And then the real learning starts.
Some weeks feel like you’re being chased by tickets, deadlines, and your own expectations. Deadlines can be tight. Systems can be complex. Most days you will feel like an imposter and that feeling can be sharper when you don’t have a degree, because you’ll sometimes assume everyone else knows more than you. It can feel like everyone else got a handbook you never received.
The answer isn’t to panic or overcompensate. It’s to stay teachable. Learn from your seniors, most of which expect this and are willing to help. Ask questions before small confusion becomes big mistakes. Build a habit of improving outside the pressure of deliverables, even if it’s just a little at a time. Remember, you've been hired to deliver, not to learn. So it's important to find your balance and actually deliver even though you are still learning.
Over time, you’ll also realise something encouraging: most good developers aren’t “good” because they know everything. They’re good because they know how to find answers, how to reason, how to ask the right questions and how to keep learning without falling apart. That’s the real career skill.
Closing
Tech is vast, and there are many ways to enter it. Most companies are looking for talent, not just degrees. There are roles beyond coding too: product, QA, data, DevOps, support engineering, security, design. The space is big enough for you.
But if you’re going to build a software career without a degree, be honest about the tradeoff. You will have to work harder. You definitely have to work smarter. And you must own your work from day one, not when you finally get hired. Use AI (and all the tools available to you) but don’t outsource your growth to it. Build proof. Learn how to learn. Keep going. If I could do it, you can too.