18 ways to be a good developer

This is as days pass by, by Stuart Langridge

You can also see older posts, code I've written, the rest of the website, or follow me on Twitter(where I most recently said 'now to put stuff in a bag ready for this weekend, which is Niamh's birthday.').

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

1.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.

2.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.

3.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.

4.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.

5.NEVER thank people for feedback. If they have comments on the program, they should be sending in patches.

6.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.

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

8.What you think users will do is more important than what users actually do.

9.Don’t use punctuation or bother with the spell checking. This slows down the communication between you and the user.

10.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.

11.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.

12.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.

13.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.

14.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.

15.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.

16.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!

17.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.

18.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) Sphere: Related Content