- If someone requests support in a channel and you’re around and don’t know the answer, be sure to not say anything so they can’t tell the difference between you not knowing and you not being around. That way you can complain that users don’t wait for answers, even if those answers are never going to come.
- If a user hasn’t read all of your website, all the mailing list archives, the wiki, the old wiki, all the blogs of all the developers, and the text files in CVS, refuse to answer their question. They should study harder before they’re entitled to ask questions.
- Don’t bother to write stuff down. If a user asks a question which they could have worked out by spending two years studying the code, then they should have spent that two years.
- Remember, you understand this software. If someone wants to use it to get their work done, they should be prepared to understand all aspects of it in detail as well as you do. All users should be developers.
- NEVER thank people for feedback. If they have comments on the program, they should be sending in patches.
- It’s a lot more important to finish rewriting the XML library your program uses for the third time than it is to fix a bug that makes every Fedora user crash their whole desktop. They should be using Slackware anyway.
- If you’re an influential developer at all, your opinion matters more than the users. Follow the previous rule, as it will definitely produce a positive outcome. Be sure to relate the users in question to mentally ill people and excrement.
- What you think users will do is more important than what users actually do.
- Don’t use punctuation or bother with the spell checking. This slows down the communication between you and the user.
- Insult the user. This establishes control, which is important. Support should be thought of as a battle. Popular insults include “asshole,” “mother f**ker,” “dipshit,” and “newb.” Insulting their mother is another good way of establishing control.
- If you’re confused by the “bug report” that the user is giving you, don’t feel bad, as this isn’t your fault. This is the user’s fault. Users live in a different world. They’re besuited, annoying, stupid people who aren’t able to clearly get points across. Tell them this, as they probably don’t realize it. It is sure to ease the communication.
- As a developer, you know clearly what users will want to do with the software better than they do. If they say something about the software, take it with a grain of salt. They’re only the people who actually try out your theories; you’re the one who came up with them.
- Insist that all users run CVS or svn HEAD. If they’re using your latest release stable version, they should be prepared to checkout CVS and compile it before commenting on it. A version release or downloadable binary distribution means nothing when there’s something newer available from source control.
- If someone you know tells you how they would use your software, and someone who actually uses it tells you differently, trust the person you know; after all, you know them. This is doubly important if the person you know is another developer.
- Documentation is a pointless waste of time. If someone complains that they’re finding it difficult to do anything with your program because there’s nothing written anywhere on how to use it, then tell them to read the source; that’s good enough.
- If someone files a bug which turns out to be a duplicate, be sure to let them know how stupid they were when you link the two bugs. This is particularly important if the two bugs share no words in common whatsoever and only turn out to be duplicates after a week of digging and thought by you; after all, you had to work much harder then!
- Anyone who switches away from your program to someone else’s is clearly both stupid and an enemy of free software. You’re lucky to get rid of them.
- Programming ability and usability engineering are the same thing. If you know how to write code, you know about usability already; you certainly don’t need to waste time studying it.
(with apologies to Christian “ChipX86″ Hammond, who does none of these things)
[...] as days pass by » 18 ways to be a good developer (tags: humor) [...]
Posted by Chris Dzombak » Blog Archive » links for 2006-01-23 on January 23rd, 2006.
this is one of the funniest and truest things i’ve read in a long time. my admin pulls this on me all the time. hillarious.
Posted by Anonymous on January 24th, 2006.
Aweseome. This list confirms what a great developer I am ;-).
Posted by Hermann Klinke on January 24th, 2006.
[...] d.d. 25 Jan 2006 om 11:03 in Dump en Komisch. De reacties hebben een RSS 2.0 feed. Reageer zelf of trackback ditbericht. [...]
Posted by Goede ontwikkeling ~ Low Weblog on January 25th, 2006.
I agree with that list at all :)
Posted by Patrick on January 25th, 2006.
[...] Simon has a great rant for developers. You should read this. It reminds me of Sam and his experience with smoothwall jackass Dick Morrell. It’s amazing to me how people can be such tools, especially when you are patronizing their work. [...]
Posted by SmithEllis.Com » Simon rants on January 26th, 2006.
Sorry Stuart. I really wanted you to be Simon for some reason yesterday. Go figure. I think I spend too much time at your site, and the site of Simon Willison; evenutally you have become Simon Kryogenix Programmy Langridge O’Malley in my sad little brain.
Posted by Smith on January 26th, 2006.
Go Stuart go! Beautiful rant my friend. I’ll put each one on a sticky… I’ve really been looking for some motivation to sharpen my development skills.
Posted by Dustin Diaz on January 30th, 2006.
Perfect! The thoughts that everyone who has ever worked in support goes through every day…!
Posted by Dave L on February 3rd, 2006.
There’s lots of good stuff in this list, but I somewhat disagree on the first point.
As an extremely exaggerated example, can you imagine how “helpful” a largish support channel would be, if every time when someone popped up and said “hi”, “can I ask a question?” “” (which can be hundreds of times a day), every one of the people (which can be hundreds) there actually answered “hi”, “of course”, “?
I can. It’s not a pretty picture. The channels evolved their peculiar culture for a reason, and the reason wasn’t solely that the helpers are assholes, but also because the actual helping couldn’t be done if it was drowned in ceaseless chatter of “hi”, “you can ask” or “I don’t know”
Posted by Juhaz on February 12th, 2006.
Juhaz: I sort of see your point. I’m not really talking here about busy support channels when there’s lots of people talking anyway. I’m talking about channels when there are ten or twenty people in the channel and it’s *silent*. When I ask a question and twenty minutes later there’s been no response and no further conversation in the channel at all, I’ve got no idea whether that means that (a) everyone in the channel is afk, (b) lots of people are watching the channel but none of them know the answer, or (c) no-one at all in the world knows the answer. This means that I’m no better off than when I started. If someone in the channel says “sorry, don’t know” then at least I know that it’s not a trivially obvious question that no-one can be bothered to talk about. I can’t imagine why everyone would need to say “Hi” or “Don’t know”; if *someone’s* answered then at least you’re aware that someone else has seen your question.
Posted by sil on February 14th, 2006.
you almost forget one thing ,
a good developer doent take into consideration the time of project , having fun with code is more important than what the ..cking employer wants
Posted by misagh on February 22nd, 2006.
[...] 2) We’ve integrated visualization tools that automatically layout complex traceability graphs. But Good Developers know that Project Managers don’t need dependency diagrams. Seeing the big picture without first spending hours pouring through all the excruciating detail is like having dessert before dinner. [...]
Posted by Mike Coyle’s Weblog » Blog Archive » Hawaiian Shirt Gonzo Friday Top 10 List #1: Did we solve the wrong problems? on April 21st, 2006.
Nice list. Thanks and many greetz from germany
Posted by Werbeagentur on November 17th, 2007.
Oh man… in the theory its okay. But as a developper in business practice its a hard thing to do.
Posted by werbeagentur on December 10th, 2007.
Thanks for the list, nice and very amazing!
Posted by Werbeagentur on March 6th, 2008.
Most of this are my experience too.
Posted by Kinderbuch on May 30th, 2008.
Thanks for the interesting list
Posted by Testeinkäufe on August 21st, 2008.
Interesting list. Thanks for it!
Posted by nvonatiq on November 25th, 2008.
this is so good, having been on the receiving end of dicks temper… puts it into perspective
Posted by deemed lucky on March 16th, 2009.