Programming

17511 readers

342 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 !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

Software Engineering Documentation Best Practice? (lemmy.world)

submitted 2 months ago by Schal330@lemmy.world to c/programming@programming.dev

34 comments fedilink hide all child comments

Hey all, I'm still a junior dev with years of experience in IT. One of the things I've noticed since making the switch is that (at least where I work) documentation is inconsistent.

Things I encounter include incomplete documentation, outdated documentation and written process details that have assumed knowledge which makes it difficult for junior Devs to pick up.

I've had a search and a lot of what is out there talks more about product and how to document that SDLC rather than best practice in writing and organising documents against the actual software engineering and its processes.

Does anyone have any good sources or suggestions on how I could look to try and begin to improve documentation within my team?

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

[–] Kissaki@programming.dev 26 points 2 months ago (3 children)

Be bold and make changes. Document what you find out, what is outdated, what is missing.

Take ownership. If there's nobody that oversees overall structure, be the one to do so - at least where you're touching it or are being bothered by it.

Diatraxis gives some great insight and considerations input into writing and structuring documentation. Namely how different target audiences and doc use cases require different forms and detail levels of guidance.

My company's internal doc/guidance also links to https://www.writethedocs.org/guide/ which seems like a good source.

[–] aurelian@lemmy.ml 4 points 2 months ago

+1 for Diatraxis, my team has started using it to align all documentation.

[–] Badland9085@lemm.ee 2 points 2 months ago (1 children)

Sort of interesting that this documentation system appeared in two different places that don’t seem to reference each other.

https://docs.divio.com/documentation-system/

[–] Kissaki@programming.dev 1 points 2 months ago* (last edited 2 months ago) (1 children)

Looking at the Web Archive; Diatraxis has been around since 2021. That divio docs since May of this year.

I doubt they didn't "get inspiration" from Diatraxis.

[–] Badland9085@lemm.ee 1 points 2 months ago (1 children)

I’ve been referencing that Divio doc since 2021, possibly earlier in 2020. I even linked to the document in early 2022. It’s quite likely that it simply wasn’t crawled by the Web Archive before May this year.

[–] Kissaki@programming.dev 1 points 2 months ago

Now that you say so, I feel like I've read about this before. In comments about Diatraxis/one of them years ago. :)

[–] Schal330@lemmy.world 2 points 2 months ago

Thank you for those links, it has given me a great place to get stuck into!