Processing feedback (a retrospective)

Wow - never thought that my recent post (Software In Pictures) would become so popular.
Almost 700 views during 2 weeks, and still counting !

I have also received a lot of comments, and the post contents were even discussed in a couple of Linkedin groups. As a junior blogger, I find this very encouraging.

However, naturally, not all feedback is good:
- Some people did not like my "good code" metaphor.
- Some of the other examples were put in other contexts, where they are actually welcome and functional, with good cost-efficiency (such as the door in the wall, that can be used to load goods to an upper floor).
- Some of my examples were seen as possibly offending to the less fortunate populations, that come to these solutions out of necessity, and without a better option.

What I learn from all that:
- The more people read your blog, the more feedback you will receive. And a certain portion of it will be criticism.
- People seem to be more encouraged commenting on topic upon which they disagree, than on topics they do agree upon.
- All feedback is good and welcome. The more feedback I will get for my posts, the more I will learn and the better my next posts will become.
- The more often I write, the shorter will these improvement cycles be.

When thinking of it, it's not so different from building a new product.
As you start, and produce your first prototypes, or even the 1.0 release, most of the feedback will be negative - as chances are that your initial product will suck in some areas.
By collecting the feedback, processing it, and learning from it, you will gradually improve and so will the product.
The negative feedback is indeed the preferred one, since it can help you understand where to focus your next efforts.

So, my bottom line for all the bloggers out there is: write, get feedback, process it, rinse and repeat.
And the same - for the all the product developers out these.
And the more frequently you write/release, the faster the improvement process will happen.