The Techniques (with Examples)
A work in progress.
Ask questions
Be curious. Wonder “what does that do?”
Refine your problem statement: make sure that you have an accurate understanding of the problem that is being reported to you. Work to improve the quality of the problem statement by asking good questions, reading the documentation and working to reproduce the problem that you are troubleshooting.
Increase verbosity
Error messages can be confusing, terse and vague. If it’s possible to increase the verbosity of the thing you are troubleshooting, it is highly recommended to do so. By increasing the verbosity or running the thing in debug mode, you will increase the amount of information that is displayed about the problem you are attempting to troubleshoot. Many programs have different levels of verbosity. Some tools can be extremely verbose. You will need to strike a balance between collecting enough information about the problem to proceed and collecting too much information. Becoming skilled in filtering through log files and error messages will help to increase your efficiency at troubleshooting.
Examples
RSS Feeds for Mastodon Accounts
Append .rss to Mastodon URLs. You can append .rss to the URL of someone’s Mastodon account to get an RSS feed of their posts. There is an older format that also works. Let’s say you want the RSS feed for my posts:
- My account is at
https://social.lol/@brie. - The RSS feed would be at
https://social.lol/@brie.rss. - The older format puts the RSS feed at
https://social.lol/users/brie.rss.
Note that replies they’ve written to other posts are not included in this format. To include replies:
https://social.lol/@brie/with_replies.rss
As of this writing, neither of these formats include 🚀 boosts. See 🐛 Provide a rss-feed with boosts for more information.
Reduce complexity
A common approach to reducing complexity that I am fond of is getting the client out of the way. This is a technique that can be applied when troubleshooting a problem that is somewhere on the client, the server or somewhere in between. To reduce complexity, we will remove some of the components in the chain and observe if the problem still happens.
Something I do often is try to eliminate interference by the client. For example, if I am troubleshooting a problem someone is having with sending email in Outlook, I might find out what happens if they attempt to telnet to the SMTP server. If that works, that suggests that there is a problem with the email client. (Alternately, it is possible that the problem is intermittent.) If it does not work, it suggests that the problem is not on the machine that Outlook is installed on. I would then want to know if other people are having trouble using the same SMTP server and I would attempt to reproduce the problem.