ALX is the software engineering programme that half of tech Twitter in Africa either went through or is currently grinding through. It is run by ALX Africa, built on the Holberton School curriculum, sponsored through the Mastercard Foundation, and it does not cost the learner anything. Twelve months, no lectures, project after project, and a peer learning model that takes a few weeks to get used to.
This is what that year looked like for me, and what is sitting in my repos to show for it.
How the programme works
It runs in sprints. You start with foundations, then move into a specialization. You advance by finishing projects, not by passing an exam. There is a completion cutoff around 80 percent of the projects across the sprints, with a minimum average in each one. Nobody stands in front of a class. You read the material, you attempt the project, you get stuck, you ask the people around you, and you submit.
The curriculum is deliberately vague in places, and that is the point. The phrase they use is owning your own learning, and after a few months it stops sounding like a slogan.
Foundations: Git, the command line, and C
The first thing you learn is that the terminal is not scary. Git and command line basics come before any real code, then Bash, and then C, which is where the real work started.
My alx-low_level_programming repo is the record of that stretch. It starts with a Hello World and works through variables, conditions, loops, and functions. Then debugging. Then the thing that humbles everyone: pointers. Pointers, arrays, and strings get four separate project sets. After that come recursion, static and dynamic libraries, command line arguments, malloc and free, the preprocessor, structs, function pointers, variadic functions, singly and doubly linked lists, bit manipulation, file I/O, hash tables, Makefiles, and search algorithms.
Somewhere in there you also reimplement formatted output, which is the moment variadic functions stop being a curiosity, and later you build a working shell: read a line, parse it, fork, exec, wait, and loop. That shell project is where all the small pieces suddenly have to work together in one program, and it is the closest the low level work gets to feeling like an actual system.
Higher level: Python and JavaScript
Then the language changes and the ideas stay the same. My alx-higher_level_programming repo goes from Python fundamentals (loops, imports, modules) into data structures, exceptions, classes, inheritance, test driven development, and a project called almost a circle that builds a small shape hierarchy from scratch. Later it moves into object relational mapping, network requests, and then JavaScript: the warm up, then objects, scopes, and closures, then web scraping and jQuery.
The interesting part is not learning a second language. It is noticing how much of C follows you into Python. Memory, references, and what an object actually is stop being abstract once you have spent months managing all of it by hand.
System engineering and DevOps
The third thread is the one that changed how I think about software the most. My alx-system_engineering-devops repo covers shell basics, permissions, redirections, variables, loops, conditions and parsing, processes and signals, and regular expressions. From there it goes where most beginner courses never do:
- Networking, in two parts.
- Web infrastructure design, the diagrams that explain how a request actually reaches an application.
- SSH, and hardening it.
- A web server, then an application server.
- A load balancer, and later HTTPS and SSL certificates.
- MySQL, including primary and replica setups.
- APIs, and then advanced API work.
- Web stack debugging, four separate rounds of it.
- Webstack monitoring.
The web stack debugging projects are brutal, and I mean that as a compliment. You get a broken server and no description of what is wrong, and you have to find it. That is closer to the real job than any tutorial.
What ALX actually taught me
Less about any single language, and more about process. How to read documentation, how to break a big problem into pieces, how to ask a good question, and how to keep going when a project makes no sense for the first two hours. The deadlines are real and the volume is high, so you also learn to ship something that works instead of something perfect.
The other thing is people. The peer model is not decoration. A lot of what I know came from sitting with someone late at night tracing a segfault until one of us saw it. A lecture does not give you that.
If you are in ALX right now
A few things I would tell anyone in the middle of it:
- Do not skip the low level work. It is the foundation everything else sits on.
- Write down what broke and how you fixed it. It becomes your own documentation.
- Ask for help earlier. Suffering for six hours before asking is not discipline, it is wasted time.
- Push your work to GitHub as you go. Those repos are a portfolio at the end, and they are the reason people believe you when you describe what you can do.
- Do not compare your progress to the person next to you. The sprints are hard for everyone, in different places.
The repos
- alx-low_level_programming: C, from Hello World to a working shell.
- alx-higher_level_programming: Python and JavaScript.
- alx-system_engineering-devops: shell, networking, servers, and the debugging that comes with them.
If you are going through ALX, or thinking about starting, and you want to compare notes, the comments are open.
Top comments (0)