Priorities

When using any issue tracking software, it's important to know which issues should take priority. Issues that are high priority should, obviously, be dealt with first. Issues of lower priority can wait.

Usually, this means assigning a number to a particular issue, perhaps with a descriptor of some sort. Some go from one to ten, some go from one to seven. They might go from "Must fix" to "Don't Fix". This is, however, not always intuitive. What does a six mean? What does a one mean? Are people just going to mark everything as a 10? Does the description of the issue say "Not a huge priority", but the rank says "Must fix"?

If you couldn't tell, I've had some bad experiences with priority systems.

Being Programmers

I wrote a guest post over on Recoding: Being Programmers

It's about frustration, learning, teaching, and being good at what we do. Check it out.

Solved Problems

Recently, I read an interview with Tim O'Reilly, founder and CEO of O'Reilly Media, Inc., the company that puts out the ubiquitous tech books with the animals on the front (and, oddly enough, a great cookbook). O'Reilly facilitated the open-source movement, as well as the "maker" movement, through publishing technical manuals, and through hosting conferences and summits. In short, he gave us a way to talk about community engineering, programming, and creating in general. A banner under which "makers" can unite.

I consider myself a maker. I enjoy problem solving, especially in concrete ways. When I come up with a website, a service, or even just some snippet of code that people can use (even if they don't), it's a rush. I've written about this "superhero" feeling before.