https://arran4.github.io/blog/tags/documentation/Recent content in documentation on Arrans Technical blogHugo -- gohugo.ioentechnicalblog123@arran4.com (Arran Ubels)technicalblog123@arran4.com (Arran Ubels)Arran Ubels. This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.Wed, 28 Oct 2026 19:22:00 +1100https://arran4.github.io/blog/post/2026/058-hugo-book-github-pages-for-go-documentation/Wed, 28 Oct 2026 19:22:00 +1100technicalblog123@arran4.com (Arran Ubels)https://arran4.github.io/blog/post/2026/058-hugo-book-github-pages-for-go-documentation/Too many projects have a README, a Go package reference, and a growing pile of Markdown files named SPEC.md, DESIGN.md, or IMPLEMENTATION_PLAN.md. Some were written to coordinate an agent for one task. Months later they look like official documentation, even when they describe an abandoned approach or an implementation that has changed. What I want instead is a developer information portal: a navigable, maintained set of pages that helps a person get started, complete real tasks, understand the system, diagnose problems, and contribute.https://arran4.github.io/blog/post/2026/057-document-decisions-without-duplicating-code/Wed, 28 Oct 2026 13:57:02 +1100technicalblog123@arran4.com (Arran Ubels)https://arran4.github.io/blog/post/2026/057-document-decisions-without-duplicating-code/A coding agent can finish a feature, write its tests, open a pull request, and then add a Markdown file explaining everything it just did. At first glance that seems thorough. Across a dozen related pull requests, though, those files become another set of things to reconcile, rebase and keep current. They can outlive the context in which they made sense. I want documentation to preserve information that would otherwise be lost, not to create a second implementation that competes with the code.