Skip to content

Instantly share code, notes, and snippets.

@amcgregor
Created November 16, 2010 00:02
Show Gist options
  • Save amcgregor/701213 to your computer and use it in GitHub Desktop.
Save amcgregor/701213 to your computer and use it in GitHub Desktop.
Lessons learned from #python on irc.freenode.net regarding support.

Lessons Learned from #python

Over the years myself and others have attempted to utilize the #python support channel on irc.freenode.net when solving problems. For the most part the time spent explaining the problem, the rationale behind the design, uncovering the exact question to ask to get the desired (helpful) response, and personality conflicts have resulted in more frustration than problems solved. So I’m writing up this lessons file in an effort to not repeat the past mistakes in supporting my own users.

What it really comes down to, other than wasted development hours, is not having to explain to your boss that your team should rewrite 30% of your project because some random git in a chat room said you were Doing it Wrong™.

Alternate Support Channel

In an effort to produce a place where individuals can ask questions without fear of being directly or indirectly called an idiot, I’ve opened #python-friendly, the friendly place to discuss Python, ask questions, and get helpful answers. #python-friendly will be policed and argumentative users removed to benefit the sanity, blood pressure, and project time scales of all involved.

The List

  1. For the sake of conversational efficiency it’s best not to assume that everyone is a semantic nazi or an idiot.
  2. It should be understood that not everyone solves problems in the same way, and that understanding or arguing the rationale behind a high-order design decision isn’t as important as solving the problem at hand unless you’re willing to donate the person-hours to rewrite their code.
  3. Being correct in all things makes you arrogant. Forcing your idea of correctness on others, with the same rider as the latter part of the previous point, isn’t helpful, either.
  4. “You shouldn’t use X.” should be re-phrased “I don’t use X because…” and evidence given.
  5. If opinions or The Right Solution™ is/are asked for, do not flood with your answer. Give others a chance to add to the conversation.
  6. “Don’t do that” isn’t a valid answer unless backed up with evidence or an alternative.
  7. Just because…
    1. …you do not have a use case matching a given problem does not make the problem itself invalid.
    2. …a solution is something you personally do not do (or avoid doing) does not invalidate that solution.
@emberian
Copy link

6 should be "“Don’t do that” isn’t a valid answer unless backed up with evidence and an alternative."

Reasoning: just because an alternative exists, doesn't mean it is better than the existing solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment