66
Software Engineering Documentation Best Practice?
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 23 Sep 2024
66 points (100.0% liked)
Programming
17416 readers
38 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
I would say as a new junior dev you are uniquely placed to help with this. Documentation tends to be written by people who know a lot about a thing and they try to imagine what might be useful for someone. Someone new coming in with a fresh perspective can help uncover assumed knowledge or missing leaps to make the documentation better. One of the common onboarding steps I've seen is to go back and update/improve the onboarding docs after you've just been onboarded for example.
I would say pick your battles though because documentation can be a never ending task and documents are almost always out of date shortly after they are written. Think about what would have saved you time or mental overhead if it was just written down and fix those first.
As far as organising and writing, every place is different and it can depend on the tools your org is using. In general I'd at least have links to relevant docs as close to where they might be needed as possible. Like how to set up and get up and running with a code base should probably be documented directly in the readme, or at least linked to if it's overly complicated.
Hopefully that's at least somewhat helpful. It's definitely a problem basically everywhere I have worked though, you have to do what you can and not stress too much about it.
Thanks for this. As part of onboarding I have been trying to update where I can. There are times I wonder if I am adding to docs what others may perceive as fluff as it may be something obvious to them. I like to work with a "If we're all on a bus that goes over a cliff, does someone new have everything they need?" mentality.
At present the team is using GitHub Pages, which almost feels like a hurdle itself in updating the documentation quickly and keeping it organised and consistent. Being a junior I personally prefer a WYSIWYG. From your experience is there any pros/cons in using a WYSIWYG vs Markdown?
No worries, sounds like you're definitely on the right track with your approach.
In terms of the style of editor I don't have a strong preference, I think the most important thing is discoverability which generally means putting docs where they are expected to be found and using whatever your team or org is using. Personally I have a slight preference for markdown mainly because it's easy to version control, see who wrote what (so I can ask them questions) and use all the tools I'm used to that work well with plain text. Tools that use more WYSIWYG style can be good too though and many of them like Notion have the advantage of making it relatively easy to search across your entire companies documentation assuming everyone uses the one tool.
For my personal notes I use Logseq which I highly recommend. It's a bit of both, markdown under the hood but with a simple editor that lets you focus on writing notes, tasks and links.