At my first programming job I was at an ISP and was making the bandwidth provisioning and enforcement system. I was trying to tell the networking operations guys that it was pretty good these days and they said "Oh - OK we are putting the dev team behind it moving forward". Apparently my face was priceless. I know that sinking feeling in my gut changed my mind about a lot of things that day.
Dogfooding is good - it certainly changes how you think about things anyway.
It isn't sufficient for good software, but may be necessary -or at least when possible (sometimes you make software that has no direct application to your life...).
Or just forcing yourself to keep an open mind about pain points for others. Make notes of the "quirks" when you notice them immediately, similarly any work around should be filed as a bug. That way even if you get used to it, you know it wasn't always the case.
Comments
At my first programming job I was at an ISP and was making the bandwidth provisioning and enforcement system. I was trying to tell the networking operations guys that it was pretty good these days and they said "Oh - OK we are putting the dev team behind it moving forward". Apparently my face was priceless. I know that sinking feeling in my gut changed my mind about a lot of things that day.
Dogfooding is good - it certainly changes how you think about things anyway.
It isn't sufficient for good software, but may be necessary -or at least when possible (sometimes you make software that has no direct application to your life...).
One of the problems of dogfooding is knowing when to stop. Because you could just get used to some of the quirks or find workarounds.
Or just forcing yourself to keep an open mind about pain points for others. Make notes of the "quirks" when you notice them immediately, similarly any work around should be filed as a bug. That way even if you get used to it, you know it wasn't always the case.