Erator's Sandbox

So a friend and I are going to start a group blog, which hopefully will allow us to both gain experience blogging and knowledge about sharing ideas with people we don't know. The blog is going to focus on software, because we share some of the same interests about best practices, user experience, design philosophies, etc. I'll post here when we get it setup and going, so that the few (if any) that read this blog, can find me --unless you already follow me on Twitter .

As a software engineer, I've had the pleasure of receiving bug reports that make no sense whatsoever, and asking for additional info leads to dead ends and frustration. I really like what Joel recommends should be on a good bug report: Steps to reproduce, What you expected to see, and What you saw instead. But I have a couple of points to add, since in my experience people skip the basics: First and foremost, test it again to make sure that it is a valid bug. Specify what is not working, and where I can find it in the program. Avoid non-standard abbreviations. Proofread the bug report before submitting it to the resolver for any ambiguous information. As I started to write this post I thought I was very clear on what I was going to write and what I wanted exactly to be in a bug report, but, as I kept typing I started to remember all those pesky bug reports that annoyed me because they take forever to research and solve (especially the ones that end up being no-bugs). If you think ...