Skip to main content

Command Palette

Search for a command to run...

Why African Developers Should Take Documentation Seriously (And How to Start)

The Elephant in the Room Ask any developer what they hate most about a codebase, and the answer is almost always the same: no documentation. Yet ask those same developers when they last wrote docs for their own project — and the silence is deafening. In the African tech ecosystem, this gap is especially costly. We are building fast. Startups are shipping, open-source contributors are growing, and developer communities from Lagos to Nairobi to Accra are thriving. But if the knowledge lives only in someone's head or worse, in a WhatsApp thread, we are building on sand.

This post is your nudge to change that.

Why Docs Get Skipped (And Why That's Understandable)

Let's be honest about why documentation gets deprioritized:

Deadlines are real. When a client is waiting or a sprint is closing, writing a README feels like a luxury. Nobody taught us how. Most computer science programs across Africa don't include technical writing in their curriculum. It feels boring. Writing about code is not the same dopamine hit as writing the code itself.

These are valid reasons. They are not good enough excuses but they are valid, and we should name them before we try to fix them.

What Good Documentation Actually Does

Documentation is not just a courtesy for future developers. It is a professional multiplier.

  1. It makes your project trustworthy - A GitHub repo with a clear README, setup instructions, and API reference signals that the maintainer is serious. Investors, employers, and collaborators make snap judgments based on this.
  2. It saves your future self - Six months from now, you will not remember why you wrote that function. Your docs will.
  3. It enables collaboration across time zones and languages - Africa's developer community is multilingual and spread across 54 countries. Written documentation bridges what a voice call cannot.
  4. It compounds your impact - A well-documented open-source tool from an African developer can be adopted globally. Poor docs keep great tools local.

The Docs Stack You Actually Need You do not need a full-time technical writer to start. Here is a simple, practical stack: For Any Project

README.md — What is this? How do I install it? How do I use it? That's it. CONTRIBUTING.md — How can someone help? What are your standards? CHANGELOG.md — What changed, and when?

For APIs

OpenAPI / Swagger — Describe your endpoints in a standard format. Postman Collections — Share runnable examples, not just descriptions.

For Teams and Products

Notion, Confluence, or Outline — Pick one. Use it consistently. Architecture Decision Records (ADRs) — Document why you made a technical decision, not just what it was.

A Simple Rule to Build the Habit Here is one rule that works: write docs as part of the definition of done. A feature is not finished when the code is merged. It is finished when:

The README reflects the new behavior The function or endpoint is commented A teammate could set it up without asking you a single question

Make this a team norm, and documentation stops being an afterthought.

The Bigger Picture for Africa's Tech Ecosystem

There is something deeper here worth saying. Africa's developers are building solutions for African problems — fintech for the unbanked, agri-tech for smallholder farmers, health tools for under-resourced clinics. These solutions deserve to outlast their first team. They deserve to be forked, adapted, and improved by the next generation of developers across the continent. That only happens if the knowledge is written down. Documentation is, in a very real sense, an act of community building. It says: I built this, and I want you to be able to use it, improve it, and carry it forward.

Where to Start Today If you have a project — personal, professional, or open-source — open it right now and ask:

Can a stranger understand what this does in 60 seconds? Can they get it running without messaging me? If I disappeared tomorrow, could someone maintain it?

If the answer to any of those is no, you have your starting point. Pick one project. Write one README. Ship it. That is how Docs & Devs Africa gets built — one documented project at a time.

Have thoughts on documentation practices in the African dev community? Drop a comment or connect with us on the Hashnode community.