Release notes are a touchpoint with every user, and most are wasted. Small changes that turn a changelog into something people actually open.
GIS APIs increasingly get used by analysts, not just developers. Writing API docs that serve both audiences without patronizing either.
A documentation style guide can be three pages or three hundred. Where the useful middle sits, and how to build one people will actually follow.
Training teaches a path; reference answers a question. Trying to make one document do both jobs usually means it does neither well.
Screenshots date fast, clutter easily, and are often the wrong tool. When to use them, how to keep them maintainable, and what to use instead.
Undocumented software accrues debt exactly like uncommented code. Why the bill always comes due — usually at the worst possible moment.
Specializing deeply has costs and compounding returns. A reflection on what domain experience actually changes about how you work.
Standard proposal templates assume a standard project. GIS tenders have technical specifics that generic bid advice simply doesn’t account for.
Software ships continuously; documentation can’t be rewritten every sprint. Strategies for writing docs that survive the next release.
