This is a blog about broken things. After all, most of the software systems I work with are broken.
To be fair, I’m usually the one breaking them so I’m not complaining. When I work as a system or performance tester, that’s part of the job description. You’ve got to push the limits of the software before the users do, and that means things are going to break.
It’s not that different when I’m developing software, either. I’m just pushing limits in a different way – working with new technologies or solving problems that haven’t been solved before. It’s normal for systems to be broken while I’m figuring things out.
Since working with broken things is normal, I’ve had plenty of experience in un-breaking them. I’ve come to understand that troubleshooting is as much about how you think as what you know technically. So, in this blog, I want to explore the theory and practice of troubleshooting.
Or, if you want a more modern perspective – how do you go about hacking trouble?