Transforming scattered notes into a structured, version-controlled knowledge base

Inspired by Anais Urlichs' Learning in Public Approach

As I continue my 90-day DevOps journey, I'm realizing that learning isn't just about consuming information—it's also about organizing and sharing it effectively. Inspired by Anais Urlichs' philosophy of learning in public, I've decided to treat my learning materials as a real project, using the "Documentation as Code" approach.

This means my personal notes, code snippets, and project documentation will live in a structured Git repository, versioned and maintained just like production code. No more scattered text files or forgotten bookmarks—everything lives in one organized, searchable place.

Why Treat Your Learning Like Code?

Version Control for Knowledge: Git allows me to track changes, revert to previous versions, and understand how my knowledge has evolved.
Structured & Searchable: A well-organized repository makes it easy to find what I need when I need it.
Showcases Your Skills: A public learning repository acts as a living portfolio, demonstrating my technical skills, organizational abilities, and commitment to learning.

My Learning Repository Structure

Here’s how I'm structuring my main learning repository on GitHub:

/
├── README.md
├── linux/
│   ├── commands.md
│   └── projects/
│       └── apache-web-server.md
├── aws/
│   ├── ec2-notes.md
│   └── s3-notes.md
├── docker/
│   ├── Dockerfile-examples/
│   └── docker-compose-notes.md
└── templates/
    └── blog-post-template.md

Documentation Standards & Templates

To maintain consistency across my learning repository, I've created several templates:

Project Documentation Template:

# Project Name

## Overview
Brief description of what this project accomplishes

## Prerequisites
- Required software/tools
- Assumed knowledge level

## Step-by-Step Guide
1. Detailed implementation steps
2. Code examples with explanations
3. Configuration files

## Troubleshooting
Common issues and solutions

## Resources
- Links to official documentation
- Helpful tutorials
- Related projects

Daily Learning Log Template:

# Week X - Day Y

## Today's Focus
What I planned to learn/accomplish

## What I Learned
- Key concepts
- New commands/tools
- Insights or "aha" moments

## Challenges
Problems encountered and how I solved them

## Tomorrow's Plan
What I want to tackle next

README Best Practices

The README.md is the front door to my repository. It needs to be clear, concise, and easy to navigate.

Clear Title & Introduction: A brief overview of the repository's purpose.
Table of Contents: Links to the different sections for easy navigation.
Learning Roadmap: A high-level overview of my learning goals.
How to Contribute: Even for a personal repository, it's good practice to include contribution guidelines.

Git Workflow for Learning

I treat my learning repository like any other development project:

Feature Branches: Each new topic or project gets its own branch
Commit Messages: Clear, descriptive commits like "Add EC2 security group notes" or "Complete Apache web server project"
Pull Requests: Even working solo, I create PRs to review my own work before merging
Tags: Mark significant milestones like "week-4-complete" or "aws-basics-finished"

Tools That Make It Work

GitHub/GitLab: Version control and collaboration
Markdown: Universal documentation format
VS Code: Great markdown preview and Git integration
GitHub Pages: Turn your repository into a searchable website
Obsidian/Notion: For mind mapping and connecting concepts before writing formal docs

Real Benefits I've Experienced

Since implementing this approach, I've noticed:

Faster Problem Solving: When I encounter similar issues, I can quickly reference my previous solutions
Better Retention: Writing things down in my own words helps cement the knowledge
Portfolio Building: Recruiters and potential collaborators can see my learning process and technical writing skills
Community Engagement: Other learners find and contribute to my repository, creating valuable discussions

Getting Started: Your First Learning Repository

Ready to build your own learning repository? Here's a quick start guide:

Create a new GitHub repository named something like "devops-learning" or "tech-knowledge-base"
Start with a simple structure - don't over-engineer it initially
Write your first README explaining what you're learning and why
Document your next project using the templates above
Commit regularly - even small updates count
Make it public - embrace learning in public

Call to Action

How do you organize your learning materials? Are you ready to try the Documentation as Code approach? Share your repository links and organizational tips in the comments below!

If you found this helpful, follow my 90-day DevOps journey where I'll be sharing more insights about learning in public and building practical skills.

This post is part of my 90-day DevOps learning journey. Follow along for more insights on Linux, AWS, Docker, and building a career in tech.

Building My Learning Repository: Documentation as Code

Table of contents