this post was submitted on 23 Sep 2024
66 points (100.0% liked)
Programming
17313 readers
446 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 [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This is the sort of thing you have to learn by experience, like how you can't really learn good coding taste from reading a list of rules (though some lists are helpful).
Anyway in my experience documentation is quite different in public (i.e. seen by customers) and private (inside your company). For internal stuff there's a much smaller incentive to document things because:
I think the best thing to do is to accept that people aren't going to expect documentation internally. There's zero point writing guides to tools on your company wiki or whatever, because nobody will even try to look for it - they'll assume it doesn't exist.
Instead you should try to keep your documentation as close to the user as possible. That means, don't have a separate
docs
folder in your repo - put your docs as comments in the code.Don't put deployment instructions on your wiki - add a
./deploy.sh
script. It can just echo the instructions initially.