[skrebbel]

I like the product, but I think this blog post would've been much more interesting if it wasn't written in a "omg we're so aweome we're using our own product and we wrote a script that makes it difficult not to! disruptive!"-way.

Instead, maybe, what trouble did you have when dogfooding? Did you ever run in the situation that you couldn't proceed because of a bug in the then-being-dogfooded software? How did you get by it? Did engineers like it? How about non-engineer team members? Did the dogfooding influence the way you prioritized?

Sure, I like that the second part of the blog post says "we found some new requirements because of this", but for me, as a programmer of another piece of software, it would've been much more interesting to find out how you got to those requirements and how you dealt with them, rather than what the new requirements were. I mean, every software team finds new requirements all the time.

I mean to be constructive here: I strongly doubt blog posts about how awesome your own tool is and how using it yourself made it awesomer is the best approach. By turning it less into promo and more into general experience-sharing, the post may be more generally useful and thus spread further.

[fredsters_s]

Great feedback dude! Thanks. We will try and take this approach in the future.