A Day in the Life of a McTaba Marathoner (Nairobi, 2026)

Your alarm goes off at 6:30 AM. If you live along Thika Road or out in Kitengela, make that 5:45. Nairobi traffic does not care about your learning schedule, and the matatu from Rongai to the CBD during rush hour is its own endurance test.

Most marathoners have a routine by week three. Some grab a quick mandazi and chai from a street vendor near the stage. Others stop at Java House or Artcaffe if payday was recent. A few bring packed lunches from home because KES 100,000 in tuition means budgeting everywhere else. Whatever the morning ritual, the goal is the same: get to the space, open your laptop, and settle your brain before the session starts.

The 20 to 30 minutes before class officially begins matter more than you would expect. This is when people review yesterday's notes, re-read code they wrote the night before, or quietly Google something they were too embarrassed to ask about during the previous afternoon's session. Some mornings you will feel sharp and ready. Other mornings, especially mid-week in the middle of a tough module, you will sit down wondering whether you belong here at all. Both states are normal. Both pass.

The morning block runs from 9:00 AM to roughly 12:00 PM. This is the most structured part of the day. An instructor introduces a new concept, tool, or pattern, then builds something live on screen while the cohort follows along.

Early in the marathon, morning sessions cover fundamentals: HTML structure, CSS layout, JavaScript functions, how HTTP requests actually work. The pace is measured. There is time to ask questions. By week eight or nine, the sessions move faster. You might spend a morning learning how to set up a PostgreSQL database, define schemas, and write queries, all before lunch. By the final third of the programme, morning sessions sometimes feel more like professional workshops than classroom lectures. The instructor walks through an M-Pesa STK Push integration or a WhatsApp Business API webhook, and you are expected to have enough context to follow along without pausing every two minutes.

The live coding format is deliberate. Watching an instructor hit errors, debug in real time, and talk through their reasoning teaches you something that pre-recorded tutorials cannot: how experienced developers actually think when they build. You see the false starts, the wrong guesses, the moment they open a browser tab to check documentation. That process is the skill, and it looks nothing like the polished code snippets in a textbook.

Around 10:30 AM, there is usually a short break. People stretch, refill water bottles, check their phones. Conversations during breaks tend to be about what was just taught. "Wait, did you understand the part about async/await?" or "I still do not get why we need middleware here." These five-minute hallway exchanges clear up more confusion than you would think.

Lunch runs about an hour. What you do with it depends on your budget, your energy, and where the nearest kibanda is.

Some marathoners walk to a nearby restaurant for ugali and sukuma wiki, or a plate of pilau if the week has gone well. Others order from food delivery apps and eat at their desks. A handful disappear for a quick errand, because Nairobi life does not pause for your coding education. You might need to send an M-Pesa payment to your landlord, pick something up from a shop on Moi Avenue, or make a phone call you have been putting off all morning.

The smartest thing you can do during lunch is step away from your screen. Stare at trees. Walk around the block. Let your brain process the morning's material without actively trying to learn more. Cognitive science backs this up, but you do not need a study to know that four straight hours of new information leaves you foggy. The break resets you for the afternoon, which is where the real work happens.

By the second month, lunch groups form naturally. Three or four people who sit near each other, or who are working on the same project, start eating together every day. These groups become your first professional network, even if nobody thinks of it that way at the time.

The afternoon is where the marathon earns its name.

From 1:00 PM to about 4:00 PM, you are building. The morning session introduced a concept; the afternoon forces you to use it. Sometimes that means a structured exercise: "Build a REST API with three endpoints that stores data in PostgreSQL." Other times, especially later in the programme, the afternoon is dedicated to your ongoing project, and nobody tells you exactly what to do next. You have a spec, a deadline, and a mentor you can ask for help. The rest is on you.

Pair programming is a regular part of the afternoon block. You sit with another marathoner, share a screen, and build together. One person types while the other watches, questions, and suggests. Then you switch. If you have never done this before, it will feel awkward and slow at first. By week six, most people start to see the value. Your partner catches mistakes you would have spent 30 minutes hunting. You catch theirs. And explaining your logic out loud forces you to actually understand it, not just pattern-match from memory.

The afternoon is also when frustration peaks. You will spend 45 minutes stuck on something that turns out to be a missing semicolon or an environment variable you forgot to set. You will watch your code throw the same error twelve times in a row and feel certain you are the only person in the room who does not get it. You are not. Walk over to the person next to you and ask, "Can you look at this?" Nine times out of ten, they are stuck on something similar, and the act of explaining your problem to another human reveals the answer before they even respond.

Mentors float through the room during afternoon sessions. They are not there to give you answers. They ask questions: "What have you tried so far?" and "What does the error message actually say?" and "Have you checked the documentation for that function?" This is frustrating in the moment and invaluable in the long run, because after the marathon ends, there is no mentor walking past your desk. You need to be your own debugger.

The last structured hour of the day is built around two professional rituals: code review and stand-ups.

Code review means someone else reads your code and gives feedback. In the early weeks, this is mostly the instructor or a mentor pointing out things like inconsistent naming, missing error handling, or logic that works but is harder to read than it needs to be. Later, marathoners review each other's code through pull requests on GitHub, the same way professional development teams operate. Getting your code critiqued is uncomfortable at first. It feels personal. It is not. Learning to separate your identity from your code, to hear "this function is confusing" without hearing "you are stupid," is one of the most important professional skills the marathon teaches.

Stand-ups are short. Each person answers three questions: What did you work on today? What are you working on tomorrow? What is blocking you? The whole round takes 10 to 15 minutes. The point is not status reporting. The point is that saying "I am stuck on connecting my frontend to my API" out loud, in front of the group, often results in someone saying "I just solved that, let me show you after." Problems that feel isolating when they are inside your head become solvable the moment they enter the room.

By 5:00 PM, the formal day is done. Most people do not leave at 5:00.

The marathon does not assign "homework" in the traditional sense. There are no worksheets. But there is always more to build, more to read, more to understand. Most marathoners spend two to three hours in the evening continuing their project work, reviewing material from the day, or watching supplementary tutorials on topics where they need extra repetition.

Some people stay at the space and work until 7:00 or 8:00 PM, feeding off the energy of others still grinding alongside them. Others head home to beat the worst of Nairobi's evening traffic and work from their bedroom, a corner of the living room, or a quiet cafe. The commute home can be productive if you are on a matatu: reading documentation on your phone, listening to a podcast about the topic you are learning, or just mentally replaying the code you wrote that afternoon.

There is a temptation, especially in the first few weeks, to work until midnight every night. Do not. Sleep matters. Your brain consolidates learning during sleep, and showing up exhausted to the morning session means you absorb less, fall further behind, and burn out faster. The marathoners who finish strongest are almost never the ones who pulled the most all-nighters. They are the ones who found a sustainable rhythm: intense work during the day, focused study in the evening, and enough sleep to do it again tomorrow.

The cohort's WhatsApp group stays active in the evenings. People share resources, ask questions, post memes about JavaScript, and occasionally organize weekend study sessions. This ongoing conversation is part of the learning. When someone posts a question at 9:00 PM and three cohort mates jump in with different approaches, everyone involved learns something.

Individual days matter, but the marathon is really structured around weeks. Each week has a theme or a primary skill. Monday introduces it. Tuesday and Wednesday deepen it. Thursday and Friday are about applying it in a project context. The weekend is for rest, catch-up, or getting ahead if you have the energy.

The first few weeks focus on web fundamentals: HTML, CSS, JavaScript, Git. This phase feels slow for people with some prior experience and overwhelming for complete beginners. Both reactions are expected. The foundations matter even if they feel basic, because the speed picks up significantly once you hit backend development and databases.

The middle stretch of the marathon is where things get intense. You are learning React, building APIs with Node.js, integrating databases, and starting to work with the African Stack. This is the phase where projects get real. You are not building toy apps anymore. You are building a payment flow that processes M-Pesa transactions, or a notification system that sends WhatsApp messages. When something you built actually sends money from one phone to another for the first time, the months of fundamentals suddenly make sense.

The final weeks focus on capstone projects and career preparation. You choose a substantial project, scope it yourself, and build it from scratch. This is the closest simulation of real professional work the marathon offers. Nobody tells you which library to use or how to structure your database. You make those decisions, defend them during code review, and live with the consequences when something breaks at 3:00 PM on a Thursday.

Fridays often have a slightly different energy. Some Friday afternoons include guest speakers from Nairobi's tech scene, or demo sessions where marathoners show what they built that week. Presenting your work, even something small and unfinished, builds a muscle that matters in job interviews and professional settings. The first time you demo, your voice might shake. By the fifth time, you are walking the room through your architecture decisions like you have been doing it for years.

The transformation is not gradual in the way you might expect. It happens in bursts, separated by plateaus that feel like you have stopped learning entirely.

Week 1: Everything is new. You might not know what a terminal is. You are copying code from the screen and hoping it works. The cohort is friendly but nervous. Everyone is quietly measuring themselves against everyone else.

Week 4: The initial excitement fades. This is where imposter syndrome hits hardest. You see other people who seem to "get it" faster, and you wonder if you made a mistake signing up. You did not. The people who seem confident are also struggling; they are just better at hiding it. This is the week where the most people consider quitting. Almost nobody who pushes through week 4 regrets staying.

Week 8: You start building things that work. Not elegant things. Not well-structured things. But things that run, that do what they are supposed to do, that you can show someone on your phone. The feeling of deploying your first live project is difficult to describe to someone who has not experienced it. Something you made is on the internet, and anyone with the URL can use it.

Week 14: You help someone else debug their code, and you realize you understood the problem before they finished explaining it. This is the moment most marathoners recognize their own growth. Teaching someone else forces you to organize your knowledge, and discovering that you can teach means you have genuinely learned.

Week 20: Your capstone project is underway. You are making architectural decisions, choosing between libraries, structuring databases, and writing code that you will have to maintain for weeks. The problems you face now look nothing like the problems from week 2. They are harder, yes, but you have the tools and the instincts to solve them. You Google less and reason more.

Week 26: You present your capstone to the cohort, mentors, and sometimes invited guests from Nairobi's tech community. Your code is not perfect. No professional's code is perfect either. But you built something real, you can explain every decision you made, and you have a GitHub history that proves you can ship software. The person who walks out of the marathon is measurably different from the person who walked in. Not because of any single lesson, but because of 6 months of compounding effort.