Skip to content
O Opemipo Jokotagba
About me

Opemipo Jokotagba —

I sit at the intersection of writing and engineering — creating documentation that developers actually want to read, and building the software that makes it possible.

The work, amplified

Writing, engineering,
and a sharp thinking partner

I'm a Docs Engineer and Technical Writer with a software development background. That combination matters — I can read the codebase, test the endpoints, and verify every code sample I publish. Good documentation isn't just well-written, it's accurate.

I'm AI-augmented — working with AI tools as a genuine thinking partner, not a shortcut. They help me pressure-test explanations, review code, and surface gaps before they reach the reader. The writing stays mine. The standard gets higher.

Docs Engineer & Technical Writer

Opemipo Jokotagba

Writing docs developers trust and building the software that makes them come alive. Based in Lagos, Nigeria — working with teams worldwide.

API Docs TypeScript Technical Writing

Working Method

AI-Augmented Workflow

Pressure-testing explanations, reviewing code samples, catching edge cases — AI tools as a second perspective at every stage of the docs process.

Clarity review Code QA Deep thinking
My Process

How I Work

These aren't aspirations — they're the principles every piece of documentation I write is held to.

Clarity First

The best documentation is the one developers actually read. I write for clarity, not completeness — stripping complexity without losing accuracy.

Developer Empathy

Good docs meet developers where they are. I write with a deep understanding of the developer experience — what they're trying to do, where they'll get stuck, and what they actually need to succeed.

Build What You Document

I'm a developer who writes docs — and a writer who builds software. That dual perspective makes everything better: every code sample runs, every integration guide is verified.

Tools & Tech

My Stack

The tools that power my docs engineering workflow — from API verification and version-controlled writing to the editor and runtime I use to test every code sample I publish.

Good to know

Frequently asked questions

Some of the questions I get asked most often.

About documentation

What does a Docs Engineer actually do?
A Docs Engineer sits at the intersection of writing and software engineering. I plan, write, and maintain technical documentation — API references, developer guides, tutorials — while also building tooling, automating doc pipelines, and treating documentation as a product in its own right, not an afterthought.
What kinds of documentation do you write?
Mostly developer-facing content: API references, integration guides, onboarding flows, SDK documentation, and architectural overviews. I also write for broader technical audiences — product documentation, knowledge bases, and internal engineering docs.
How do you approach API documentation?
I start with the developer experience — what does someone need to know to make their first successful API call? From there I build up: authentication, core concepts, endpoint references, error handling, and real-world use cases. Code examples are non-negotiable, and I test every one I publish.
Do you use AI in your documentation workflow?
Yes — I work with Claude as a thinking partner throughout every project. Not to generate docs on autopilot, but as a second perspective for reviewing clarity, catching logical gaps, and exploring alternative ways to explain complex concepts. The writing is mine. The thinking gets sharper.
Do you write code samples and live demos?
Absolutely. Being a developer first means I write code examples I'd actually want to use — working, runnable, and idiomatic. If a code sample in the docs doesn't run cleanly, it gets fixed before it ships.

About the work

Do you write code as well as documentation?
Yes — I'm a software developer who writes docs, not a writer who dabbles in code. I build the integrations, demos, and tooling that support documentation. Being able to read and write production code makes every piece of documentation significantly more accurate.
Do you work embedded in engineering teams?
Yes, and it's often the most effective model. Embedded in an engineering team, I can catch changes before they ship, understand the system deeply, and build trust with engineers early. I'm comfortable working asynchronously across time zones.
What's your process when starting a new docs project?
I start with discovery — understanding who the readers are, what they're trying to accomplish, and what already exists. Then I audit the gaps, plan the structure, and write incrementally. Feedback loops with engineers and real users shape everything.
Are you open to freelance or contract work?
Yes. I take on freelance and contract engagements for projects where documentation genuinely matters — where there's a clear audience, a product worth documenting, and a team open to treating docs as a first-class deliverable.
Where are you based and do you work remotely?
I'm based in Nigeria and work fully remote with teams worldwide. Time zone differences are rarely a problem for async documentation work, and I keep a flexible schedule to accommodate sync meetings when needed.

Sound like a good fit?

If my background and approach match what you're looking for — whether it's a full docs engagement, a specific writing project, or a conversation about developer experience — I'd love to hear from you.

Get in touch