Writing Good Documentation

I be­lieve that good doc­u­men­ta­tion is more im­por­tant than ever. In an age where large lan­guage mod­els have ex­cep­tional con­text win­dows, it’s easy to fall into the trap of be­liev­ing a sys­tem is sim­pler than it is. To test the lim­its of their abil­i­ties, I’ll of­ten feed Harper code in and ask for their ex­pla­na­tion of it’s in­ner work­ings. They’ve never got­ten it any­where close to cor­rect.

That’s be­cause good doc­u­men­ta­tion is more than the sum of its parts. It should con­tain all the rel­e­vant tech­ni­cal de­tails needed to work on a repos­i­tory, but it should also pro­vide a sense of qual­ity and di­rec­tion. It should dis­till an abil­ity within the reader to tell what good code and con­duct looks like.

I think this is an area Harper could do to im­prove on.

It’s Possible to Write Too Much

Too much text can be over­whelm­ing. I have met many peo­ple (myself in­cluded) who be­lieve that more de­tail is al­ways bet­ter. That as long as the in­for­ma­tion ex­ists some­where, some­one will be able to find it. In re­al­ity, that’s just not true.

That brings us to our first rule: good doc­u­men­ta­tion should be sim­ple.

The worst way to de­scribe a com­plex sys­tem is with com­plex lan­guage. It’s much bet­ter to first break it down into sim­pler parts. From there, you can build it back up again.

I’ve found it ef­fec­tive to start by erring on the side of too much”, only to pare it down later.

Needless to say, it’s also pos­si­ble to write too lit­tle.

Focus on Why

The code it­self is (or should be) the best de­scrip­tion of how the soft­ware works. Doc­u­men­ta­tion should com­ple­ment this re­al­ity by de­scrib­ing why the soft­ware works that way.

This might in­clude a lit­tle his­tory. What steps did the orig­i­nal code’s au­thor take be­fore ar­riv­ing on the fi­nal so­lu­tion? A blog is a great way to an­swer that ques­tion.

When de­scrib­ing a bug rel­e­vant to some code (like in a pull re­quest), a pic­ture is worth a thou­sand words. It’s much eas­ier to show a prob­lem than to de­scribe it. That’s why I highly sug­gest you take a screen­shot of the prob­lem. Even bet­ter: record a video recre­ation of it.

Published July 15, 2025 at 6:00 AM

Proofread by Harper.

Comments