Documentation Approach

My approach to documentation is different from the other content creation methods I use for SEO content writing or fictional writing.

I focus on awareness, clarity, structure, scope, and adequately aligning language to the target audience. The target is solving the problem for the reader rather than engaging them.

My Workflow

This entire portfolio is a live proof-of-concept of my documentation methodology. It was engineered to solve a structural problem and to maximize professional transparency.

I followed this workflow to build this portfolio:

Gap Identification → Solution Research → Strategic Roadmap → Constraints & Scope Definition → Decision Making → Execution → Meta-Documentation for the Case Study

Gap Identification: My Wix portfolio wasn't good enough for docs-as-code documentation using Markdown. It also got lost among my other content.

Solution Research: I looked for a new portfolio platform so my technical documentation could stand on its own.

Strategic Roadmap: The point at which I decided all of the things I would want from this new project and how I would approach the execution.

Constraints & Scope Definition: All of the limitations I added to make the roadmap achievable within a limited timeframe.

Decision Making: When I finally locked in what would stay and go from my roadmap based on the constraints and scope. And also picking between which platforms to focus on and why.

Execution: Putting the plan to action by creating and publishing the new portfolio.

Meta-Documentation for the Case Study: The documentation process that ran from the start of the project so I could create a case study about the entire process and thought process.

If you'd like to learn more, read Behind the Docs: A Portfolio Case Study. (Currently a work in progress)

Sneak Peek

I'll quickly summarize some decisions here about the portfolio.

Why Docusaurus?

Docusaurus is already the main choice of many for technical documentation due to its features. On top of that, it uses React, which I'm familiar with.

I compared it against Jekyll and Hugo, but since they use a language I'm unfamiliar with, it would require extra time and setup to get the project online.

Why does GitHub API doc expands by default?

This was a DX decision focused on facilitating navigation.

This documentation was built with modularity for scalability. So there are multiple global guides, then a reference folder with the endpoints folder within. Meaning that there are a lot of suborders to click before you can get where you want.

So instead of making readers click through a lot of folders, I decided to have it expanded and set it as the featured in the sidebar to highlight it.

Why did you pick these samples?

The current list of samples is short and objective. They were projects I had already written, and some even published.

So converting them to Markdown using docs-as-code was faster than creating documentation from scratch.

They serve as short, but effective examples, covering a different range of skills each with little overlap.

The samples will be expanded with both more quality and quantity. However, adding them as is was a conscious choice to keep within time constraints with a good balance of quality and quantity.