And this is 18 ways to be a good developer, written Jan 22, 2006, and concerning Rants, Software

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)

Comments

Chris Dzombak » Blog Archive » links for 2006-01-23

[...] as days pass by » 18 ways to be a good developer (tags: humor) [...]

Anonymous Coward

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.

Hermann Klinke

Aweseome. This list confirms what a great developer I am ;-).

Goede ontwikkeling ~ Low Weblog

[...] 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. [...]

Patrick

I agree with that list at all :)

SmithEllis.Com » Simon rants

[...] 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. [...]

Smith

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.

Dustin Diaz

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.

Dave L

Perfect! The thoughts that everyone who has ever worked in support goes through every day...!

Juhaz

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"

sil

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.

misagh

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

Mike Coyle’s Weblog » Blog Archive » Hawaiian Shirt Gonzo Friday Top 10 List #1: Did we solve the wrong problems?

[...] 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. [...]