Criticism and TheCafeTable

After reading the recent blog of David Heinemeier Hansson about critiquing, I started thinking of what TheCafeTable will really mean once it goes public.

So far we as developers – Rohit, Nadeem, Gleb and I – have had a reasonably productive and stable “professional relationship”. We’re all buddies, and on top of that we’re doing this project together. We all have slightly different reasons to do it, and each of us probably sees a different part of the project. Still, the criticism and disagreements that came up so far has not been from outside pressure, but from our own views of the final product, our haste to get it done, our various skill levels with the technology involved and endless frustration with certain services we’re trying to use. This means that once I get into a disagreement with one of my partners, it usually comes down to an issue of either the differences in what each of us wants, or what each of us deem as possible. The latter is normally very easy to resolve. Prove why a certain idea would take too long, be too hard or is technologically or socially unfeasible. The former takes more time and more understanding and/or communication, but so far I have found it possible to state my views, listen to the other parties involved, and find a compromise or reasonable answer.

A whole new dimension of criticism will open up the moment we allow our little pearl (to paraphrase Hansson’s blog) into the big open seas of the Web. We will all receive positive, neutral and negative criticism, and this will probably place strain on how we are involved with the project. No wonder developers often hide behind a corporate, press-pleasing shroud!

In response to this criticism, I see the following ways to cope:

  • Hide! Maybe even go so far as to have one person handle “press”.
  • Ignore! Whatever a person tells you, they’re probably a dolt, and don’t know anything about web development, so… screw the customer!
  • Ignore if its from an untrusted source! If you don’t know the person, what do they know?
  • Ignore if it is unrelated or not applicable! If the person comments on their view of our product, and this view differs from ours, ignore it! eg. “I hate spreadsheets!” as comment to an online spreadsheet application…
  • Transform any criticism into good criticism! So they hated it. Nothing personal, but what useful information can this experience give us?
  • Change everything to suit each person!

If you go through this list, you’ll probably notice that I deliberately ordered it – the easiest thing to do up to the hardest thing to do. Face it, criticism hurts like hell, and being able to take a person’s criticism, extract the useful information and then change your product (or yourself) is the ultimate double-whammy of personal strength. You’ll also notice that this corresponds well with Hansson and Dan Russell‘s arguments.

So what would do I now expect, and what do I hope to see happening?

We will definitely receive criticism (and it being our team’s first app, I expect a whole lot, with a fair share of negative comments!).

First off, I hope we can distance ourselves from the project enough that criticism on the project has no relation to ourselves – a “professional detachment” I would call it. This is quite different from not caring, which is definitely not what we should strive for, but rather an outlook that keeps TheCafeTable in perspective as a fun, hacker-ish adventure, not a life-endowing personal achievement (slash failure!)

Then, I hope to see that each of us takes as much criticism as they are comfortable with, pulls this apart to find the good ideas in the criticism (if there are any), and share as much as possible with the rest of the team.

Then, we each should be completely comfortable by stepping back and disregarding criticism when necessary. If you are not in the mindset or do not what to absorb some outside person’s opinion on our work for whatever reason, ignore it! I know I don’t enjoy criticism at all – I would go so far as to say I have a low tolerance for negative criticism, and that I usually end up taking it very personally. I will be sure to use the occasions when I’m getting fed up to disregard criticism rather than doom our creativeness because of a person’s comments on it.

Lastly, I hope to see that all of us define a strong classification between criticism we as team members give to each other and criticism from the outside, and keep these two related but separate. If we can keep up the process we’ve been using so far, and improve our mutual criticism on each other by posing ideas we gleamed from outside criticism, we might just have a winning strategy. On the other hand, becoming a proxy for outside criticism will probably serve to amplify some member of the general public’s voice into a driving force within our team. Somehow this seems very very unwise! If we put up a mutual front to process, assimilate and use criticism, we will grow through it, instead of allowing criticism to damper our creative process and cause friction inside our team.

In short…

Sometimes, your product is going to passionately piss people off. Sometimes, that’s okay. In many cases, you simply can’t design a product that will make everyone sing your praises and want to send you roses. I love my iPod, but I know there are some people who think it’s devil spawn. If Steve can’t get everyone to love his things, I’m not sure I can. -Dan Russell

Yes, it’s preferable if you can develop enough distance from your work to accept criticism like the best of them. But it’s not a skill worth pursuing at the expense of creation.

So if you have to choose, at least in the short term, I hope you pick to shield rather than to run. Mark your work a pearl, reject requests for diamonds. I desire your creation more than I care for the privilege to criticize it. -David Heinemeier Hansson

Comments are closed.