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?
The Code is my Bible.
Yeah seems about right… off the top of my head:
the output of tools like sphinx, javadoc and so forth is a good starting point, especially if you feed them properly commented code.
the rule “garbage in, garbage out” definitely applirs here.
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.
Writings self documenting code is so important.
Comments get stale and over time transition from: accurate to outdated, to eventually flat-out lies.
Go hard in the paint when choosing method or variable names. If it’s hard to give them coherent names, that’s a code smell.