July 17, 2026 at 12:00 am
Comments posted to this topic are about the item The Mythical Bus Accident
July 18, 2026 at 12:10 am
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
July 21, 2026 at 7:49 pm
As far as my kids having access to my on line accounts, it is covered in my will.
July 21, 2026 at 9:46 pm
Not a bad plan. I periodically send my passwords to one kid for safekeeping.
July 26, 2026 at 10:56 pm
This is a good reminder, Steve. I haven't put it in the context of my being run over by that mythical murderous bus, more like when I leave wherever I work, will my colleagues be able to carry on. However, I find it a mixed bag. And some of that is my own fault. Twelve years ago, I was one of those in a wave of layoffs. Before then I had been documenting what I worked on in Word documents. But I have to admit I don't think that was particularly good.
When I was hired in my current job, I continued that practice but began to think more of Microsoft OneNote. I've found this to be much better, as I can search all my notes faster and find what I'm looking for. My intent, when I leave this job, is to give my OneNote notebooks to my boss or some colleague. However, I don't know how well that will go. I've seen people leave, one passed away, but it seems to me that once anyone leaves for whatever reason the system administrators are in a hurry to block everything about them within a day of their leaving. So, unless someone takes my OneNote notebooks, everything I've written over the years will be lost.
Another thing which complicates the issue is where does one document things? When I first got in this job we were using TFS. No one had really used anything that TFS had for documenting projects, so we fell into using whatever the project managers wanted to use. And that happened to change a few times over the years. About 4 years ago I and another guy were designated GitHub Administrators. I had been using GitHub for 4 years before that, but strictly as a code repository. Starting 4 years ago, I began looking into Markdown, GitHub Wikis, the Docs folder, etc. To me, using these GitHub features it became evident to me that this is a superior way of documenting what I intended to do, why I approached the development as I did, when I changed my mind to a better approach, etc. And I also found that using these GitHub features had the added benefit of having all the documentation in one place, where the development team can get to it and automatically have permissions to it. But the PMs are dead set against using GitHub. They insist that we must use SharePoint, HALO, Smartsheets, Excel, etc. The problem I've seen with their approach is that very often new people to a project don't have access to the myriad of places to find all the documentation scattered all over the place. And since the approach is not consistent, then you never know if you've got access to everything or if something is missing. This for me is hugely frustrating because the PMs couldn't care less what the needs of the developers are. It is clear that the only thing that's important about documentation is where the PMs want it to be.
Three years ago, I decided to start documenting how to use GitHub's documenting features by creating a repo composed of the Markdown documents with images of Markdown, the Wiki, the Docs folder, the Discussions feature, etc. and saving it in our GitHub organization. Since then, we've added three new GitHub organizations, and I've copied that repo from the first organization into the other three. However, I've found that my fellow developers simply don't bother to look at it. So, I now wonder if I wasted my time since no one takes advantage of it.
WOW. Really, what I've written isn't encouraging.
Kindest Regards, Rod Connect with me on LinkedIn.
July 27, 2026 at 9:39 am
Well, I'm keeping the documentation in Word of markdown. A long time ago we a good wiki but that information was lost in a migration. Given the textsearch abilities of today we regularly find documentation back using keywords.
We do have a Sharepointfolder like "FirstLineSupport" where all the information of supporting various applications is kept, so they don't have to hunt across the different repositories / sharepoints
July 27, 2026 at 2:59 pm
I tried a wiki years ago, but ended up sticking with text/html in most cases. Now I'd use markdown, but I'd put this in on an admin share. I try not to put anything in my own folders that others use. I've doc'd a bunch of how SSC works on the backend, and I've put that in our department share, not in my folders, so others can get it.
August 2, 2026 at 1:57 pm
As I mentioned, I am discouraged by the fact that my colleagues don't bother to document anything, even in a repo's README. Half the time the repo doesn't have a README, or if it does it's simply the name of the repo. Like I said I believe the reason for this is the PMs refusal to work with developers and insist that developers can only document in whatever flavor of the month system the PMs want to use. And since this has changed so much over the years, I don't expect it to be the same a year from today, then it is today. Then there's another session of convert X to Y, etc.
Kindest Regards, Rod Connect with me on LinkedIn.
August 3, 2026 at 5:42 pm
Change because of new PMs or execs, is usually a waste of time, but hard to avoid.
At least with AI, migrations to new systems can be easier. Or maybe you should suggest a new PM, an ai: https://www.reddit.com/r/ProductManagement/comments/174o194/i_tried_to_replace_a_pm_with_ai_it_kinda_worked/
Viewing 9 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply