this post was submitted on 23 Sep 2024
67 points (100.0% liked)

Programming

17416 readers
86 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

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
67
Software Engineering Documentation Best Practice? (lemmy.world)
submitted 1 month 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
[–] BrianTheeBiscuiteer@lemmy.world 4 points 1 month ago (1 children)

If it's closed source then it's a losing battle to try and document code. I mean, do it when you feel it's 100% necessary (e.g. complex code that you really can't dumb down, "magic numbers" with a complicated backstory, test cases -- it feels like that's a different part of your brain so the transition is hard). Otherwise write code that almost reads like a sentence and don't add complexity until you need it.

[–] 0x0@programming.dev 2 points 1 month ago (1 children)

write code that almost reads like a sentence

You mean COBOL?

[–] BrianTheeBiscuiteer@lemmy.world 3 points 1 month ago

Hehe. COBOL doesn't look too bad. Reads a bit like a person that's never talked to another human being before.