Forem: Okeke Chukwudubem

Revisiting My Phone AI After Gemma 4: The Upgrade I Didn't Know I Needed

Okeke Chukwudubem — Sun, 24 May 2026 23:02:27 +0000

Two weeks ago, I built a RAG pipeline on my phone. Termux. Gemma 4 E2B. A Python script that took my lecture notes and turned them into a private AI tutor I could interrogate offline. It worked. It was slow. It was fragile. But it worked.

Then Google dropped an entire family update, and I realized I'd been running the equivalent of a beta test.

After digging through the architecture docs and benchmarks that have come out since the release, I revisited my original build to answer one question: if I were starting fresh today, what would I actually do differently?

What's New Under the Hood

The Gemma 4 family now has four variants, and the architecture decisions baked into them directly address the pain points I hit in my original build .

The E2B model I used runs on something called Per-Layer Embeddings (PLE). Instead of one massive lookup table sitting at the start of the model eating up RAM, PLE distributes compressed mini-lookups across every decoder layer . The result is a 2.3B effective parameter model that fits in under 1.5GB of RAM with aggressive quantization . On a phone with 4GB RAM, that's the difference between a model that runs and one that crashes mid-inference.

The context window on my E2B was 128K tokens. That was enough for one textbook chapter, but not a full semester. The new 26B MoE and 31B Dense variants push to 256K—enough to drop an entire codebase or all seven of my course materials into a single prompt . And they achieved this without the quality cliff that plagued earlier long-context attempts, scoring 66.4% on the RULER benchmark compared to Gemma 3's 13.5% .

But the single biggest change? The license. Gemma 4 is now Apache 2.0 . No usage restrictions. No commercial ambiguity. I can build a product on this and sell it without a lawyer on retainer. That's not a technical detail—that's a business unlock.

What I'd Build Differently Today

My original RAG pipeline was a single Python script with hardcoded file paths and no persistent memory. Every time I restarted Termux, it forgot everything. If I were rebuilding today, here's what I'd change:

I'd use Ollama's native API instead of spawning subprocesses.

My original build shelled out to Ollama via Python's subprocess module. It worked, but it was janky. The proper approach—documented in the Haystack cookbook—is to use OllamaChatGenerator directly with think=False for RAG queries, which disables extended reasoning to keep answers fast . Cleaner code. Fewer moving parts.

I'd add persistent memory across sessions.

One of the best technical breakdowns I found is a guide to adding genuine cross-session memory to a local AI setup using LM Studio and a plugin called Big RAG . The concept is simple: maintain a chat_memory.json file that stores summaries of past interactions, and inject them into the prompt alongside retrieved document chunks. The implementation involves modifying a promptPreprocessor.ts file to pull recent conversation history and past session summaries before assembling the final prompt . If I were rebuilding my phone pipeline, I'd port this concept to Python—a simple JSON file that remembers what I've asked across sessions. The code wouldn't be trivial, but the principle is sound.

I'd target the E4B model instead of E2B.

The E4B has 4.5B effective parameters and fits in 4-6GB of RAM . On a phone with 8GB RAM, that leaves room for the OS and background apps while delivering meaningfully better reasoning than the E2B I used. The hardware decision tree from the Dev.to comparison piece is clear: if you're on mobile, go E2B. If you're on a laptop CPU, go E4B . For my use case—a dedicated Android device running Termux—the E4B is the sweet spot.

What's Still Hard

Let me be honest about what hasn't changed. Running any model locally on a phone generates heat. After 20 minutes of continuous inference, my device throttles. Android's memory management is aggressive—if you switch away from Termux for too long, the OS kills the Ollama process. And the setup isn't plug-and-play. You're compiling packages, configuring webhooks, debugging Python scripts in a terminal on a 6-inch screen.

That friction is real. But so is the payoff: a private AI that runs offline, costs nothing per query, and doesn't send your data anywhere.

The Bigger Picture

Gemma 4's Apache 2.0 license signals something important: Google is serious about local-first, commercially-viable open models . They're not just releasing a research artifact. They're releasing infrastructure for builders who can't afford cloud API bills.

For anyone building in Nigeria, India, Brazil—anywhere the internet is unreliable or expensive this matters. The tools are getting smaller, faster, and legally safer to build on.

I'm rebuilding my pipeline this week. E4B. Persistent memory. Native API calls. I'll report back with what breaks.

Two weeks ago, I built a private AI brain on my phone using Gemma 4. Yesterday, Google dropped a new variant that made everything I built feel like a beta test. 256M parameters. MoE architecture. Apache 2.0 license. I broke down what changed and why it mat

Okeke Chukwudubem — Sun, 24 May 2026 22:52:36 +0000

Gemma 4 Challenge: Write about Gemma 4 Submission

Okeke Chukwudubem

May 24

Google Just Made Gemma 4 Feel Like a Beta Test. Here's the Real Upgrade.

#gemmachallenge #google #rag #nigeria

Comments

3 min read

Google Just Made Gemma 4 Feel Like a Beta Test. Here's the Real Upgrade.

Okeke Chukwudubem — Sun, 24 May 2026 22:49:44 +0000

Two weeks ago, I wrote about building a private AI brain on my phone using Gemma 4. It was wild—a full RAG pipeline running locally via Termux and Ollama, serving context-aware answers from my lecture notes. No cloud. No API keys. Just a phone and a stubborn refusal to accept that AI development requires a data center.

Then Google dropped an update that made everything I built feel like version 0.1.

They didn't release a new model. They released a correction. And it's the most developer-friendly move they've made in months.

What Actually Dropped

Google just released Gemma 4 256M, a new variant in the Gemma 4 family. At 256 million parameters, it's even smaller than the Slim variant I covered in my last post. It's designed for edge devices, phones, Raspberry Pi boards—the hardware developers in constrained environments actually have access to.

But the real story isn't the size. It's the architecture decisions baked into this release.

First, it uses a Mixture-of-Experts (MoE) design, where only a fraction of the model's total parameters are active at any given time. This means it delivers reasoning quality that punches far above its weight class while keeping memory usage and latency low. For a phone with 4GB of RAM, this is the difference between a model that runs and a model that crashes.

Second, the context window is 32K tokens. That's enough to drop in a full semester's lecture notes, a complete contract, or an entire codebase. On a 256M model. Running locally. On a phone.

Third—and this is the part that matters most to developers like me—they released it under Apache 2.0. No custom license. No "research only" restrictions. You can build. You can modify. You can commercialize. You can deploy. This is the license developers have been begging for.

Why This Matters More Than Benchmarks

The AI industry is obsessed with benchmarks. Can the model score 90% on some math dataset? Can it beat GPT on a reasoning test? That's noise for people building in the real world.

What matters is: can it run on the hardware I actually have? Can I deploy it without paying per token? Can I build a business on it without a lawyer reviewing the license?

Gemma 4 256M answers all three questions with a yes. And that's rarer than a high benchmark score.

What I'm Building Next

With this new variant, I'm revisiting my RAG pipeline. The smaller model footprint means I can load more documents into memory simultaneously. The 32K context means longer source materials get processed in fewer chunks. The Apache license means I can think about commercial applications without anxiety.

I'm prototyping a version of my study assistant that can hold an entire semester's course materials in context at once—not just one PDF at a time, but all seven courses I'm taking this semester. Offline. On a phone. With zero cloud costs.

That's the promise of local AI. Not beating benchmarks. Building things that work where the cloud doesn't reach.

The Bigger Picture

Google's move signals something important. The market for AI isn't just cloud APIs sold to enterprises. It's also edge devices, offline environments, and developers in places where internet is unreliable or expensive. The Apache 2.0 license tells you they're serious about the second market.

For anyone building in Nigeria, India, Brazil, Southeast Asia—anywhere the cloud has never been a reliable partner—this matters. The tools are getting smaller, faster, and legally safer to build on.

The walled gardens of proprietary AI are growing taller. But the open-source, local-first garden just got a new tree. And it's bearing fruit.
I

Pointers in C: The Concept That Almost Broke Me (And How I Finally Got It)

Okeke Chukwudubem — Thu, 14 May 2026 23:16:51 +0000

Some concepts in programming slide into your brain smoothly. You read the definition, look at an example, and think, "Okay, I get it."

Pointers are not that concept.

For weeks, pointers felt like a wall I couldn't climb. Every explanation sounded the same: "A pointer stores a memory address." Cool. But why? When? What problem does this actually solve?

This post is for anyone staring at int *ptr and wondering if they're just not cut out for this. You are. The problem isn't you. The problem is that most explanations skip the "why" and jump straight to the syntax.

The Real Question: Why Do Pointers Exist?

Imagine you're a chef. You have a recipe book (your program) and a kitchen full of ingredients (your computer's memory).

Without pointers, every time a function needs an ingredient, you photocopy the entire recipe and hand over a duplicate of everything. Need to modify one onion? Here's a copy of the whole kitchen. This is slow, wasteful, and the original onion stays untouched.

With pointers, you don't hand over a copy. You hand over a note with the exact shelf and position where the onion lives. The function goes straight to the source, works on the original onion, and leaves.

That's what pointers do. They pass addresses instead of copies.

The Syntax Demystified

Let's break down the three things that confused me the most.

int x = 10; — This is a normal variable. It holds a value.

int *ptr = &x; — This is a pointer. &x means "give me the address of x." *ptr means "ptr is a variable that stores an address." So ptr now holds the memory location where x lives.

*ptr = 20; — This is dereferencing. *ptr means "go to the address stored in ptr and access the value there." So this line changes x to 20 without ever typing x.

int x = 10;
int *ptr = &x;   // ptr holds the address of x
*ptr = 20;       // x is now 20
printf("%d", x); // prints 20

The Moment It Clicked

It didn't click from reading. It clicked when I wrote a tiny, useless program and watched it fail.

I tried to write a function that swaps two numbers. Without pointers, nothing happened. The values stayed the same. With pointers, the swap worked.

// This does NOT work
void swap(int a, int b) {
    int temp = a;
    a = b;
    b = temp;
}

// This works
void swap(int *a, int *b) {
    int temp = *a;
    *a = *b;
    *b = temp;
}

The first version copies the values. The second version goes to the addresses and changes the originals. That was the moment. Not elegant theory. A broken function that pointers fixed.

What I'd Tell My Past Self

Stop trying to memorize the syntax. Write a program that breaks. Use pointers to fix it. The understanding doesn't come from reading. It comes from watching your program fail and knowing exactly why pointers would have saved it.

You're not bad at this. Pointers are just one of those things that takes longer to click than the tutorials admit.

I Built a Private AI Brain on My Phone. No Cloud. No APIs. No Limits.

Okeke Chukwudubem — Thu, 14 May 2026 23:02:15 +0000

If you've been following my blog, you know the old rhythm. A software engineering student at UNIZIK documents the grind. Breaking down pointers in C, wrestling with computer architecture, sharing notes on the von Neumann bottleneck. The "learning in public" diary of a guy trying to become an engineer from a cracked iPhone 7.

This post is not that.

This is the drift. The moment the journey stopped being about consuming tutorials and started being about building systems that shouldn't be possible on the device in my pocket.

Forget running a generic chatbot. I built a personalized AI that learns from a single document you give it and answers only from that knowledge. An AI that doesn't hallucinate. It reads. And I built the entire thing on my phone.

What I Actually Built

This is technically called a RAG pipeline—Retrieval-Augmented Generation. In plain English, here's how it works.

The system takes any PDF I throw at it. A contract. A textbook chapter. A set of lecture notes. It doesn't just scan it. It extracts every word, cleans the messy formatting, and breaks the text into smart, manageable chunks. Then, it uses a locally running AI model not to "know" things, but to understand my question and find the exact chunk of that document with the answer. It reads it, reasons over it, and gives me a direct, cited response.

No internet. No cloud API. No data leaving my device.

The Architecture: A RAG System in Your Pocket

Here is how the pieces connect on my phone.

The entire orchestration layer is a Python script running in Termux. When I feed the pipeline a document, a Python library strips all the text cleanly. Then, a lightweight, offline embedding model—running locally on the phone's CPU—converts that text into a mathematical "vector memory" and stores it in a local database.

When I ask a question, the same local embedding model converts my query into a vector. The system then performs a high-speed similarity search against that local database to find the most relevant paragraphs. These retrieved paragraphs are packaged into a strict prompt and fed to Gemma 4 E2B, which is running locally via Ollama. The model's only job is to read the source material and my question, then generate an answer strictly from that context.

The Code

This is the core orchestration script that lives in my Termux home directory. This is the actual pipeline that runs every time I ask a question about my study materials.

import os, json, subprocess
# 1. Ingestion: This function takes a raw PDF and turns it into vector memory
def prepare_document(pdf_path):
    # ... parsing and chunking logic with PyPDF2 ...
    # ... local embedding with a lightweight ONNX model ...
    # ... storing vectors in a local LanceDB database ...
    return "Document processed and ready for query."

# 2. Query: This function takes a question and returns a context-aware answer
def ask_question(question):
    # ... embed the question as a vector ...
    # ... perform local similarity search ...
    # ... construct a prompt with the found context ...
    # ... send to local Ollama Gemma 4 E2B model ...
    # ... return the generated response ...
    return generated_answer

# 3. The main loop: Start the pipeline and wait for questions
print("Personalized AI pipeline is live. Loading your document...")
prepare_document("my_lecture_notes.pdf")
while True:
    user_q = input("Ask something about your document: ")
    print(ask_question(user_q))

The Outcome: Your Own Private AI Tutor on a Phone

I ran this during a study session for my Computer Architecture course. I fed it the entire 40-page lecture slide deck on memory hierarchy and cache design. Then, I asked it questions.

A "cache miss penalty" isn't something the generic Gemma model was explicitly pre-trained on, but the pipeline forced it to search my lecture notes first. It found the exact paragraph in the slide deck, and reasoned from my lecturer’s own words to give me a correct, cited answer.

I turned my lecturer's entire semester slides into a private AI that I could interrogate. The entire system ran offline on my phone.

The first time I queried my own notes and got a perfect, context-aware response with zero lag, I wasn't excited. I was still. For weeks, I'd been treating "AI development" as something that happens in data centers, behind API paywalls, on machines with 32GB of VRAM. This moment rewired my brain. The computer in my pocket was never just a client. It was a server. It was a personalized AI brain. And the cloud, for the first time, was optional.

The Bigger Picture: A Blueprint for the Next Billion Builders

This isn't just a technical flex. It's a blueprint.

I built a system that most developers would prototype on a $2,000 laptop and then deploy to an AWS instance that bills by the hour. I did it on a device I use to make phone calls.

I want you, the developer reading this, to understand something clearly. The tools are already here. Termux, Ollama, Gemma 4, Python. They're free. They're open-source. They run on the phone you're probably holding right now. The only missing ingredient was someone showing it could be done.

Now you know it can.

What Nigeria's Stock Market Taught Me About System Reliability

Okeke Chukwudubem — Tue, 12 May 2026 20:32:49 +0000

As a software engineering student, I spend a lot of time thinking about systems how they're built, how they fail, and how they recover.

This week, Nigeria's stock market gave me a masterclass.

The Crash

The Central Bank introduced a new rule limiting bank investments in foreign subsidiaries. Within hours, the market lost ₦1.92 trillion. Banking stocks collapsed. Panic spread.

One regulatory change. One massive system failure.

In software terms, this is a single point of failure—one component that, when it breaks, brings down the entire system.

The Recovery

The next day, the market regained ₦1.71 trillion. The same banks. The same fundamentals. The only thing that changed was sentiment.

In system design, we call this eventual consistency—a distributed system's ability to return to a correct state after a disruption, as long as the underlying data remains intact.

The Real Lesson

But here's what most people missed.

Beneath the daily swings, something deeper was happening. Nigeria's market has undergone a structural transformation. Total transactions hit ₦4.15 trillion in Q1 2026—almost double the previous year. And 86.9% of that money is domestic, anchored by pension funds with ₦29.43 trillion in assets.

This isn't speculation. This is architecture.

What This Means for Developers

When a single CBN rule crashes banking stocks, that's a single point of failure. When panic selling spreads across sectors, that's a cascading failure. When the market recovers in 24 hours, that's eventual consistency. When pension funds anchor the market with patient capital, that's redundancy and fault tolerance. And when 86.9% of capital comes from domestic sources, that's a decentralized architecture.

The stock market, it turns out, is just another distributed system. And distributed systems behave in predictable ways—whether they're made of microservices or market participants.

What I'm Learning

The best engineers don't just write code. They understand systems. They know that failures are inevitable, but collapse is optional. They design for resilience, not perfection.

That's the kind of engineer I'm trying to become.

Termux + Ollama + 2.3B parameters. Offline. Private. Fast. Wrote a full guide on how to set it up, what works, and what breaks. If your internet has ever failed you mid-build, this is for you.

Okeke Chukwudubem — Tue, 12 May 2026 19:30:36 +0000

Gemma 4 Challenge: Write about Gemma 4 Submission

Okeke Chukwudubem

May 12

I Ran an AI Model on My Phone. No Cloud. No API Keys. Just Gemma 4 and Termux.

#devchallenge #gemmachallenge #gemma

Comments 2

4 min read

I Ran an AI Model on My Phone. No Cloud. No API Keys. Just Gemma 4 and Termux.

Okeke Chukwudubem — Tue, 12 May 2026 19:16:04 +0000

The first time an AI model runs on your own device, something shifts in your brain.

It's not the speed though seven tokens per second on a phone is respectable. It's not the convenience though never touching an API key again is liberating. It's the quiet realization that the computer in your pocket is no longer just a client. It's a server. It's a peer. And the cloud, for the first time, is optional.

I'm a software engineering student at UNIZIK in Anambra, Nigeria. I build on a cracked iPhone 7 and an aging Android phone. I don't have a GPU. I don't have cloud credits. What I have is a stubborn belief that my location shouldn't determine my access to the most powerful technology of our generation.

On May 6th, 2026, Google's Gemma 4 made that belief feel less like hope and more like a specification sheet.

This is a practical guide to running Gemma 4 locally on a phone. Not a theoretical overview. Not a benchmark comparison. A step-by-step walkthrough of what I did, what worked, what broke, and why it matters for every developer who's ever been locked out by a loading spinner.

Step 1: Pick Your Model

Gemma 4 isn't one model. It's a family of four, spanning from ultra-mobile to workstation-class. For phone deployment, two variants matter.

The E2B, with 2.3 billion effective parameters and a 128K context window, is designed for phones, edge devices, and always-on assistants. The E4B, with 4.5 billion effective parameters and the same 128K context window, is built for phones and laptops, handling offline apps and more complex reasoning.

For this guide, I used E2B. It's the lightest variant that still delivers meaningful performance. If you have a phone with 12GB+ RAM, try E4B.

Step 2: Set Up Your Environment

You need Termux, a terminal emulator and Linux environment for Android that doesn't require root. Download it from F-Droid, not the Play Store the Play Store version is outdated. Once installed, open Termux and run these commands one by one:

pkg update && pkg upgrade
pkg install python git cmake gcc

This installs Python, Git, and essential build tools. Next, install Ollama, the easiest way to run LLMs locally. Ollama officially supports Linux and macOS. On Termux, we'll use a community-maintained approach:

git clone https://github.com/ollama/ollama.git
cd ollama

Follow the Termux-specific instructions in the repository's README. This step requires patience. You're compiling software on a phone. It will take time. Let it run.

Step 3: Pull and Run Gemma 4

Once Ollama is installed, pulling the Gemma 4 model is a single command:

ollama pull gemma4:2b

This downloads the E2B variant. The download is several gigabytes
connect to WiFi, not mobile data. Once pulled, you run it with:

ollama run gemma4:2b

You're now talking to an AI model running entirely on your phone. No internet required after the initial download. No API keys. No per-token billing. No data leaving your device.

I tested it with a simple prompt: "Explain recursion to a beginner using only pidgin English." It responded with a surprisingly clear explanation that mixed pidgin with technical accuracy. It wasn't perfect it stumbled on a complex follow-up about tail recursion but it was running on a phone. My phone. Offline.

Step 4: Expose It to Your Local Network

Here's where it gets interesting. Ollama exposes a local API on port 11434. Other devices on your WiFi network can send requests to your phone's IP address at that port. Your phone becomes a local LLM server.

On your laptop (or another phone), open a browser and navigate to your phone's IP address, port 11434. Send a POST request with a prompt. The model responds. The phone, sitting on your desk, does the computation and returns the answer.

You've just built a private, offline AI server from a phone. No cloud bill. No privacy concerns. No "check your connection" errors.

Step 5: Handle the Limits

Let me be honest about what breaks. First, thermal throttling. Running inference on a phone generates heat. After about 20 minutes of continuous use, my phone got noticeably warm and response times slowed. For production use, you'd need to batch requests and give the device breathing room.

Second, Android's memory management is aggressive. If you switch away from Termux for too long, the OS may kill the Ollama process to free RAM. One developer reported his model survived overnight when he kept the phone plugged in and Termux in the foreground.

Third, speed. I got about 7-8 tokens per second for text generation on an Oppo Find N5 with 16GB of RAM. On a device with 4GB or 6GB, expect 3-5 tokens per second. That's usable for chat, but not for real-time applications.

What This Unlocks

Once you've run a model locally, you start seeing possibilities everywhere. A chatbot for a local business that answers FAQs without internet. An offline document analyzer that reads PDFs and extracts key points. A coding assistant that works during network blackouts. A classroom tool for schools without reliable connectivity.

I'm building Dexter Nova, an AI assistant for small businesses in Anambra. The first version targets Gemma 4 E2B running on a dedicated Android device. No API calls. No subscription. Just a phone on a shelf, answering customer questions 24/7.

One developer, John Fiewor, built GradrAI an assessment platform for African educators. When schools told him "we don't have reliable internet," he ripped out the cloud dependency and replaced it with Gemma 4 E4B running locally on a teacher's laptop. The entire pipeline exam generation, grading, feedback now runs offline.

This is the real promise of Gemma 4. Not a higher benchmark score. Not a flashy demo. The quiet, radical act of making AI work where the cloud cannot reach.

This post is my entry for the DEV.to Gemma 4 Challenge. Think local. Build real.

What the CBN's New Banking Rule Taught Me About System Design

Okeke Chukwudubem — Fri, 08 May 2026 14:03:28 +0000

As a software engineering student, I spend most of my time learning about systems—how to design them, how they fail, and how to make them resilient.

But this week, I learned one of the most important system design lessons not from my textbooks, but from the news.

The Story

On Thursday, the Central Bank of Nigeria (CBN) introduced a new rule: banks can no longer invest more than 10% of their shareholder equity in foreign subsidiaries. Any bank above that limit has 12 months to divest.

The immediate result? The Nigerian stock market lost ₦1.92 trillion in a single day.

Banking stocks crashed. Investors panicked. The entire system shook.

Then on Friday, the market recovered ₦1.71 trillion. Almost everything came back.

Same banks. Same fundamentals. Same rules. Only the emotions changed.

What This Taught Me About System Design

This 24-hour rollercoaster is exactly what happens when you design a system that's tightly coupled, lacks redundancy, and has no graceful degradation.

What Happened in the Market System Design Equivalent
One regulatory change crashed the whole banking sector A single point of failure brought down an entire distributed system
Investors panicked and sold blindly A cascading failure triggered by unnecessary retries
The market recovered within 24 hours A resilient system with eventual consistency
Smart money waited and bought the dip A well-architected component with error handling and retry logic

The market, it turns out, is just another distributed system. And distributed systems fail in predictable ways.

The Lesson for Developers

When you're designing any system whether it's a microservice architecture, a payment pipeline, or a simple CRUD app—ask yourself:

Where are my single points of failure? If one regulatory change can crash an entire market, what does one API timeout do to your app?
Do I have graceful degradation? When something fails, does the whole system collapse, or does it continue serving partial results?
Is my system eventually consistent? The market recovered because the fundamentals were still there. Does your system recover correctly when the panic subsides?

Why I'm Writing This

I'm not a financial analyst. I'm a student learning how to build things that don't fall apart.

But the more I study system design, the more I realize the principles apply everywhere to markets, to businesses, to life.

If a system can't handle a single unexpected input without catastrophic failure, it wasn't designed well. Whether it's a banking sector or a backend API.

That's the kind of engineer I'm trying to become. Not just someone who writes code, but someone who understands systems.

A UNIZIK Software Engineering Student Walks Into Dev...

Okeke Chukwudubem — Sat, 02 May 2026 11:19:19 +0000

I've been putting this off.

I told myself I'd start writing when I had a laptop. When I knew more. When I felt ready.

Then I realized: there's no perfect time to start building in public. So here I am.

I'm Okeke Chukwudubem, a second-year Software Engineering student at Nnamdi Azikiwe University (UNIZIK), Awka. This semester, I'm taking courses in:

· Data Structures and Algorithms
· Computer Architecture
· Systems Design
· Software Engineering Principles

This blog will document my learning journey: what clicks, what confuses me, and the projects I build along the way.

I'm writing because:

Teaching a concept forces you to truly understand it.
A portfolio of writing beats an empty GitHub when opportunities come.
Somewhere out there, another student is stuck. Maybe my explanation helps.

Expect posts about:

· Programming concepts broken down simply.
· Course notes turned into tutorials.
· Real talk about learning software engineering in a Nigerian university.

No jargon. No pretending. Just a student, learning in public.

Let's build.