Yesterday I found another reason on why I work in a really great place.

We have a product, our biggest product. Makes us tons of money. We moved into the "Only fix critical showstopper bugs" mode about a month ago as we near another release. We did that for many good reasons including resource availability, risk of fixes causing regressions, and a general desire to get more real-world feedback to decide what we think is broken vs. what customers think is broken.

Yesterday we found out there might be an additional build cycle to fix a problem with another team's component. We also found another bug in our stuff. The immediate response from everyone was "Well, if there is another build lets fix this bug."

And we sat and talked about what would it take to fix it, the risks involved. But then I asked a simple question.

"Why does it matter if there is another build or not to fix this?"

After a bit of discussion it turned out the answer was something like

"It's not important enough to cause a new build cycle."

So my next question was

"Doesn't that make this a non-critical non-showstopper bug?"

And the answer was "yes". A bit more discussion, and now we're not fixing the bug this time around. It's takes an amazing amount of discipline to choose not to fix a bug because you have a policy saying you won't. Especially when that policy is there for a good reason.

It's one of the reasons why we're not constantly running around in a panic like some of my friends at other software companies are.

Before we sound like a mechanical robot always following policy to the letter I'd like to point out that we do regularly deviate from policy, but it's always after a discussion and a "good reason" to do so. Most of the time I agree it's a good reason.

I didn't mean for this post to turn out this way, but I might as well mention it. We're hiring if you're in the Boston area.

We have 2 engineering positions open that are in that link above.

We also have a few "technical producer" positions open. It's a hard job to define but I guess we're really just looking for smart people that understand how software should work. Do you know when a radio button vs. a checkbox is appropriate and how to use them to create a great UI? Can you think through a set of data and decide what types of reports might be useful to users? In the job, you'd be designing software, writing specs, and have a general knowledge of what's supposed to happen. You'd work with QA to decide what's a bug worth fixing and you'd work with engineering to find cheaper ways of implementing features. It's not a programming job (but in one of the three positions it would be nice if you did know some), and it's not a design job (but being able to sketch a UI for a graphic designer to work up would be nice). And it's not really a management job either. If you're interested in that shoot me a resume and I'll try to find the official job description and forward your resume on to people who want them.

After that long job description this blog post really ended up being an ad, huh? Oh well.