How to Restart Learning to Code After Giving Up Twice

If you have quit learning to code, you probably feel some combination of guilt, frustration, and doubt. "Maybe I am just not cut out for this." "Maybe I wasted my money." "Maybe I should pick a different career path."

Here is something that might surprise you: a large number of working, employed, successful developers quit at least once before they made it. They started a course and stopped. They bought a book and never finished it. They enrolled in a bootcamp and dropped out after three weeks. Then, eventually, something clicked. They tried again under different conditions and it worked.

Quitting does not mean you cannot code. It means the specific combination of format, timing, and circumstances did not work. Maybe you were using the wrong learning resource. Maybe you were trying to learn alone when you needed a community. Maybe life got in the way: a job change, a family situation, a financial crunch. Maybe you were just exhausted from your day job and could not muster the energy to study at night.

None of these make you a failure. They make you a normal person who tried something hard and hit real obstacles. The question is not "should I try again?" but "what should I do differently this time?"

Before you restart, spend some time honestly analyzing why you stopped the previous times. Not the surface-level reason ("I got busy"), but the real reason underneath. "I got busy" usually means "coding was not a high enough priority to protect against competing demands." Why not? Were you not seeing progress? Was it too frustrating? Was it lonely?

Common reasons people quit, and what they really mean:

"I got stuck and could not figure it out." This usually means you were learning alone without access to help. The material jumped from something you understood to something you did not, and there was no one to bridge the gap. Solution: next time, do not learn alone. Find a mentor, join a cohort, or at minimum, find a study partner who is learning the same material.

"I ran out of motivation." Motivation is not a fixed resource. It comes from progress. If you were not seeing visible progress (building something, solving a problem, deploying a project), motivation evaporates. Solution: restructure your learning around frequent, visible wins. Build something small every week, not one big project at the end.

"Life got in the way." Sometimes this is genuinely true: a health crisis, a family emergency, a sudden job loss. But sometimes "life got in the way" means you did not protect your learning time. You let other things take priority because learning to code did not have external consequences for being skipped. Solution: create consequences. Tell people what you are doing. Set deadlines. Join a program with a schedule.

"The material was too hard." This often means you started at the wrong level. You jumped into React before understanding JavaScript. You tried to build a full-stack app before learning how HTTP works. The material felt overwhelming because you were missing prerequisite knowledge. Solution: be honest about your starting point. Go back to fundamentals without ego. Filling gaps is faster than you think.

"I did not know what to learn next." This is a curriculum problem. When you are self-teaching, the sheer number of technologies, frameworks, and learning paths is paralyzing. You spend more time researching what to learn than actually learning. Solution: follow a structured path. Pick one curriculum (freeCodeCamp, a bootcamp, The Odin Project) and follow it start to finish. Stop browsing alternatives.

The most common mistake people make when restarting is relying on renewed motivation. "This time I am really going to commit." Motivation is high on day one. It will not be high on day thirty when you are stuck on a confusing error at 10pm after a long workday.

Instead of betting on motivation, change the structural conditions around your learning. Here is what that looks like in practice.

If you failed alone, add people. This is the single most impactful change you can make. Learning to code in isolation is brutally hard. Find a study partner, join a cohort, sign up for a bootcamp with live sessions. The presence of other people, even just one other person, changes the dynamic. You have someone to ask for help, someone who notices if you disappear, someone to celebrate small wins with.

If you failed with self-paced, try structured. Self-paced courses have very low completion rates. If you have tried self-paced twice and stalled both times, that format does not work for you. That is not a flaw. It is information. Try a live cohort with deadlines, a bootcamp with weekly sessions, or a structured program where someone else sets the pace. At McTaba Labs, our 26-week marathon is designed specifically for people who need structure and accountability. The schedule is the product.

If you failed at night, try mornings. Many people try to learn after work and discover that their brain is depleted by 8pm. If evenings consistently do not work, try waking up an hour early and coding before your day starts. Your mind is fresher, there are fewer distractions, and you get the satisfaction of having done something productive before the day even begins. This is not for everyone, but if evening study has failed twice, it is worth testing.

If you failed with a big goal, shrink it. "I am going to become a full-stack developer" is a goal that takes 6 to 12 months to achieve. That timeline is too long for your brain to maintain urgency. Shrink the goal to something you can accomplish this week. "I am going to build a webpage that displays my name and a photo." "I am going to make a button that changes color when I click it." These micro-goals give you wins that fuel continued effort.

Big goals are inspiring but terrible for momentum. "Become a developer" is where you want to end up. It is not useful as a weekly target. You need goals small enough that you can achieve them frequently, creating a pattern of success that keeps you moving.

Week 1: Write an HTML page with your name, a paragraph about yourself, and a photo. Deploy it to the internet using Vercel or Netlify. Share the link with someone. That is it. You shipped something to the internet in your first week. Celebrate that.

Week 2: Style that page with CSS. Change the colors, add a background, make it look decent on a phone. You now have a personal website. It is simple, but it is real and it is yours.

Week 3: Add a button that does something with JavaScript. Anything. Shows a hidden paragraph. Changes the background color. Displays the current date and time. You just made your first interactive web element.

See the pattern? Each goal is achievable in a few hours. Each one produces a visible result. Each one builds on the last. After a month, you have a personal website with styling and interactivity, and you have a streak of four weekly wins. That streak creates momentum. Momentum creates habit. Habit carries you through the weeks when motivation is low.

Compare this with the common approach: spend two weeks watching tutorial videos, build nothing, feel like you "should know more by now," get discouraged, stop. The difference is not the content. It is the feedback loop. Building something, seeing it work, and showing it to someone generates the dopamine hit that keeps you coming back. Watching videos does not.

As the weeks go on, the goals get bigger. But they should always be achievable within the week. "Build a project" is too vague. "Build a form that saves data to a database and displays it on a page" is specific enough to execute and small enough to finish.

Accountability is not about punishment. It is about creating a social environment where quitting has a cost. Here are concrete systems that work for people restarting their coding journey.

The study partner. Find one person who is also learning to code. Agree to check in with each other twice a week. Share what you worked on, what you are stuck on, and what you plan to do next. This is the simplest form of accountability and one of the most effective. When someone is expecting your update, you do the work. Find partners on Twitter, LinkedIn, or local tech communities. The person does not have to be at your level. They just have to show up consistently.

The public commitment. Post on Twitter, LinkedIn, or a WhatsApp group: "I am learning to code. I will post what I built every week for the next 12 weeks." Now quitting is public. It is not invisible anymore. You might feel silly posting your beginner projects, but the support you get will surprise you. People love cheering for someone who is learning. And the fear of going silent after three weeks is a powerful motivator.

The cohort. Join a program with other learners. A bootcamp, a coding community, a study group that meets weekly. The social bonds formed in a cohort create a kind of accountability that individual commitments cannot match. When your classmate asks "are you coming to the session tonight?" you show up. When you see your cohort mates making progress, you do not want to fall behind. This peer pressure is healthy. It is the same force that makes people show up to a gym class they would never do alone.

The financial stake. This is uncomfortable but effective. When you have paid money for something, you are more likely to use it. A free course is easy to abandon because you lose nothing. A course you paid KES 50,000 for? You are going to try harder to finish it because the money represents a real sacrifice. This is not about spending more than you can afford. It is about recognizing that some level of financial investment changes your psychological relationship with the commitment.

The calendar block. Put your coding time on your calendar as a recurring event. Treat it like a meeting that cannot be moved. When someone asks you to do something during that time, say "I have a commitment." You do not need to explain that the commitment is to yourself. The act of protecting the time on your calendar gives it weight and structure it would not otherwise have.

You have decided to restart. Here is exactly what to do on day one. Do not overthink this. Do not spend three hours researching the "best" way to restart. Just do the following.

Step 1: Assess where you are (30 minutes). Open your old projects, if you have any. Can you still read the code? Do you remember what it does? If yes, you retained more than you think. If no, that is fine. You learned it once, and relearning is always faster than learning the first time. Write down what you remember and what feels foggy.

Step 2: Pick one learning resource (15 minutes). Not three. Not five. One. If you are starting from scratch, use freeCodeCamp or The Odin Project. If you want structure and mentorship, look at McTaba Tech Foundations (KES 2,999) as an affordable starting point. Pick one and commit to it for at least four weeks before evaluating.

Step 3: Build something tiny (1 to 2 hours). On your first day back, write code that does something visible. An HTML page. A styled component. A JavaScript function that runs in the browser console. Do not watch a tutorial first. Just try. If you get stuck, then look something up. The act of writing code, even bad code, on day one resets your identity. You are a person who codes now. Not a person who watches videos about coding.

Step 4: Tell someone (5 minutes). Text a friend, post on social media, or message a coding community. "I am restarting my coding journey today. Here is what I built." This tiny act of going public creates a thread of accountability. Next week, you will want to have something new to share.

Step 5: Schedule your next session (2 minutes). Before you close your laptop, put your next coding session on your calendar. Two days from now, same time, same place. Do not leave the "when" open. Decide it now. The first week back is about building a routine, not learning a ton of material.

That is it. No grand plan. No elaborate system. Just assess, pick, build, share, schedule. Repeat next session.

The first two weeks of a restart feel great. You are motivated, excited, and making visible progress. The danger zone is weeks three through eight. That is when the novelty wears off, the material gets harder, and old patterns try to reassert themselves. Here is how to survive that stretch.

Expect the dip. Somewhere around week three or four, you will hit a session where nothing makes sense, nothing works, and you wonder why you are doing this again. This is normal. It happens to everyone. Knowing it is coming does not prevent it, but it does prevent you from interpreting it as a sign that you should quit. It is not a sign. It is a phase. Push through it. The next session will usually be better.

Celebrate weekly wins. Every Friday (or whatever day your week ends), write down one thing you built or learned. Just one. "I figured out how to connect my app to a database." "I deployed my first project." "I finally understand what a callback function is." This practice keeps you aware of your progress, which is easy to lose track of when you are focused on how much you still do not know.

Compare yourself to last month, not to experts. Scrolling through Twitter and seeing developers build incredible things is demoralizing when you are struggling with basic concepts. Stop comparing yourself to people who have been coding for years. Compare yourself to where you were four weeks ago. If you know more now than you did then, you are on track. That is the only comparison that matters.

Build for someone else. One of the most powerful motivators is building something that another person actually uses. Build a simple tool for a friend's business. Create a website for a family member. Make something a classmate needs. When someone else is depending on what you are building, the motivation shifts from internal ("I should really code today") to external ("Wanjiku needs this by Thursday"). External motivation is more reliable than internal motivation, especially during the hard weeks.

Accept imperfection. Your code will be ugly. Your projects will have bugs. Your understanding will have gaps. That is fine. You are learning. Perfection is not the goal. Progress is. Ship things that are not perfect. You will improve them later, or you will build better things next time. But you have to ship something to get to the next level. Do not let perfectionism become another reason to stall.