Show Your WorkMy junior year of high school I took a calculus class from the local college extension. I happened to get a nice Casio calculator (circa 1994) that allowed me to write programs. Since I didn’t really have a computer, this was my first experience programming.

Each time we learned a new algorithm, I would figure out how to program that algorithm into my calculator. The problem was that once I did, I would promptly forget how to work the problem by hand.

I mostly got B’s on my tests. I would get all the answers right, but I would often get docked for not showing my work. How do you show your work when the only way you remember how to solve a problem is to plug numbers in to the program you wrote on your calculator?

I was thinking about this recently. Today I might be accused of the opposite. When I leave a comment in a bug or feature ticket, I might be accused of sharing too much information. The business person that submitted the bug in our ticket system doesn’t really need to see all the queries I ran, the results of those queries and a documented process of how I came to find my solution. They just wanted it fixed.

But here’s the deal: I don’t write all that information for them. I write it for me.

Like the algorithms I programmed into my calculator in high school, I will promptly forget what I worked on two days ago and the process I followed. If I run into a similar problem, finding the ticket where I documented my process of finding a solution in the past is often much faster than coming up with that solution (or a new solution) again. This is also why I blog.

So, if you are going to err, err on the side of sharing too much information. Even if nobody cares, you will thank yourself later. On top of that, the business person requesting the bug fix might just learn a little more about your system in the process.