18 ways to be a good developer
- 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) [...]
21 hours later
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.
2 days later
Aweseome. This list confirms what a great developer I am ;-).
2 days later
[...] 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. [...]
3 days later
I agree with that list at all :)
3 days later
[...] 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. [...]
3 days later
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.
4 days later
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.
8 days later
Perfect! The thoughts that everyone who has ever worked in support goes through every day…!
12 days later
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”
3 weeks later
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.
3 weeks later
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
4 weeks later
[...] 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. [...]
12 weeks later
Nice list. Thanks and many greetz from germany
94 weeks later
Oh man… in the theory its okay. But as a developper in business practice its a hard thing to do.
98 weeks later
Thanks for the list, nice and very amazing!
110 weeks later