Programming

17659 readers

129 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

snowe

Ategon

[email protected]

110

The Grand Unified Theory of Documentation (AKA: Your project needs all 4 types or you have bad documentation) (documentation.divio.com)

submitted 2 years ago by spartanatreyu to c/programming

17 comments fedilink hide all child comments

The mistake most devs make when trying to document their project is that they only make one (maybe two) types of documentation based on a readme template and/or what their mental model of a newcomer needs.

Devs need to be actively taught that:

Good documentation isn't one thing, it's four. To have good documentation, you need all four distinct types of documentation.
What the four types of documentation are (this is discussed in the link)

If you don't have all four types of documentation, you have bad documentation.

you are viewing a single comment's thread
view the rest of the comments

[–] ericjmorey 4 points 2 years ago (2 children)

Another key point for code documentation is that the closer it is to the code it’s describing, the more likely it is to be read and maintained.

What does this mean?

[–] [email protected] 4 points 2 years ago

I assume with "close" they meant that documentation should be located right there at the code it is documenting. Think Java doc comments (heredoc) or how in Golang you put comments above a function definition which is then automatically turned into documentation.

If documentation is located in an entirely different file, it's easy to modify code and forget to update the corresponding documentation.

[–] [email protected] 3 points 2 years ago

Well, you're looking at a method, and imagine two things.

The first is a link to a confluence article. You click on it. Nothing loads. Ah, right. Activate the VPN. Click the link again. You have no access. So you send your IT a ticket to gain access. One week later you get a mail you have access know. For what? Who'd remember last week?

Alternatively, there's an inline comment, or a markdown file in the same repo so you click on it and your IDE opens it. And then you modify the piece of code and you realize you still have that markdown file still open, so you adjust a few things and also note down a weird quirk you found during debugging.

However, in the first case.. well, you finally had access to the documentation, so you want to modify it to bring it up to date. Well, guess what. You have read access. So back to another ticket with IT that you're actually working on this and you'd like to update the documentation. After a week, you're notified: Well they need approval of the documentation owner for you to get write access. They are on vacation. When they get back after 2 weeks, they approve the request, and it goes into a second round of approvai with your teamlead. And guess what? Right, he's not in for the next 2 weeks. By the time you finally have write access, you're not working in that department anymore. And no, that other department doesn't use that confluence.

Overall, documentation tends to be somewhat of a chore for many people. If it's close - it's in the same repo, you can open the file in your IDE, you can commit updated documentation with your code in the same PR - there's a slightly higher chance for folks to update documentation. If you put in the hellscape of a process some companies have for their tooling there, no one will ever touch the documentation.