Programming

17313 readers

443 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 1 year ago

MODERATORS

[email protected]

Software Engineering Documentation Best Practice? (self.programming)

submitted 1 month ago by Schal330 to c/[email protected]

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

[–] Schal330 4 points 1 month ago (1 children)

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?

[–] [email protected] 2 points 1 month ago* (last edited 1 month ago)

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.