If anything at all is not right I write a up a ticket which goes into detail about what's wrong and what I think is right.

It wouldn't be a good place to put documentation for, say, how the data team is supposed to do a process, but I sure will write detailed documents for procedure I do to set systems up for my work and how my tester can set up situations. If it has anything to do with the ticket I think it is fair game and personally I find stuff like that easy to find because I have JIRA open all day and use it as my "second brain" to keep up with the work I do. (e.g. I think I had something done Dec 24 but didn't have time to make the PR because I wanted to do a round of checking out, but because I have detailed notes I'll be quick to get started at the end of the year.)

Similarly, I am not one to write a lot of little comments in the code apologizing for why it is hard to understand, I think is better to use longAndDescriptiveClassFieldAndMethodNames and clean up anything that you want to apologize for. On the other hand I write long comments in certain places of the code that explain the organization of the system, details of how it works, conventions used, etc. It is good for me but I can also tell Junie, "I want you do add some tests for the work we just did, take a look at ... to see how we write tests for this sort of thing"

---

So far as Confluence goes I find it slow, awkward, hard to find things (in the sense of the search tools being bad but also easy to put things in the wrong place), and not necessary for my daily workflow. If I got in the habit of using it I'd be used to it, but I can go a year and not have to look at it, even though I think there is IT documentation in there.

We have a data team that uses it every day and they are disciplined with it and I never hear complaining about it. If I need to know something about the way they do things I usually go knock on their door and ask.