The Programmer's Bill of Rights

Jeff Atwood over at Coding Horror wrote The Programmer’s Bill of Rights I like the idea, but some points aren’t how I’d like to have them.

If we think of what’s really essential for doing our job, the list would be very short. A table, a chair, and a computer, that’s it. Unfortunately this won’t work for very long. We’d get back-aches from the cheap chair, headaches from the cheap monitor, and we’d be pretty frustrated working with the loud, slow and unfitting computer.

Please note that this is just a quick overview of things I think are important! So my Programmer’s Bill of Rights, or Wishlist looks like that:

  1. Every programmer shall have a decent chair.
    Jeff is absolutely right, we’re sitting most of the time. A bad back is a serious defect and hard or impossible to repair. The Aeron chair is a very fine choice and for this kind of chair well priced.
    The table is usually not very interesting, it shouldn’t be too high or too low and leave some space for the legs, duh.
  2. Every programmer shall have a monitor setting best suited for his or her task.
    Jeff was on the right path here, but for me two monitors would not help very much. I’m currently using Eclipse, and in case you don’t know it, the window for the actual code is about a quarter of the whole available monitor space (subtract 1/4 on top, bottom, left, and right). So for me (and any other Eclipse user) a big monitor is much better than two monitors. On the other hand if I work with an text editor I’ll probably need the help system open all the time, in this case a second monitor is priceless.
  3. Every programmer shall choose his or her own toolset.
    Again I agree with Jeff. Whenever something is ours, we’ll handle it differently. If we chose your tools we’ll do anything to show our peers that we’ve chosen the right thing. We’ll find new and creative ways to use our tools and master them. No two persons are equal, so everyone has his or her own preferences. We need to be able to choose a keyboard6, a mouse7,and most important software we like to work with. Hell, the biggest flame-wars on the Internet are about Vim or Emacs, Windows or Unix. Let us choose!
    It seems pretty weird to let the programmer choose his keyboard and mouse, but I think there are some very good arguments about it. First, a keyboard and a mouse are a host for many bacteria, I’d rather dwell in my own bacteria than anyone else’s. Second we get used to our equipment, I’d like to have the same equipment at work as I have at home.
    Of course not everything is a variable1, and we’ll have to have standard equipment. But the tools we use to get our things done should be chosen by us!
  4. Every team or programmer shall have access to the information it, he or she needs to get the work done.
    Most of the time we’ll hear something like “you’ve got Internet access, use it”, but that’s a poor argument. The quality of the information on the Internet is very variable, and finding something very specific is hard. We need to get access to online books (ACM offers access to several hundred books, O’Reilly’s Safari Bookshelf is also searchable).
    Make customer conversations available to the programmer. Let your people get the raw material! Every post-processing loses some information.
  5. Every team or programmer shall have an environment best suited for it, him or her.
    The environment we’re working is is crucial to our work. It’s important to have a quiet place to work2. Every team shall have a room for it’s own. Every team shall be allowed to change the room for their own needs. Every programmer shall have space for his stuff (paperwork, pens, utilities etc.), or the room will quickly look like a chimp-cage.
  6. Every team or programmer shall have the freedom to choose the best process and methodology for it, him or her.
    There are many, many processes and methodologies out there promising “to be the best”. Not every process suits every project or team, we need to choose which one is best for us. It’s important to get that straight: We’re building software for a customer, either internal or external, how this is done should be our responsibility because we’re responsible for the product!
  7. Every team or programmer shall have the right to be involved in all stages of the software development.
    To get a good understanding of the project, the requirements, and the constraints we need information. So we should have the right to be at meetings with customers, managers, testers, designers etc. It’s not necessary to dive in, talk with them or something, just listen, get the information needed and ask questions if something is unclear3!
  8. Every team or programmer shall have time to reflect.
    History favors those who take the time to learn from it. If a project went well, sit down and discuss why and what went well. If a project went down the line, sit down and discuss what could have caused it. The important thing is to reflect what went well and maybe more important what didn’t. Try to extract the essence of the success or failure. Learn from the past!
  9. Every team or programmer shall have time to learn something new.
    Our business is a very fast one. Whenever you stop to keep up to date we’ll quickly lose tracks. We have to constantly learn new things, stay on top and try to educate ourselves as well as our peers. It’s like the Race with the Red Queen, we have to run as fast as we can to stay where we are4.
  10. Every team of programmer shall have the freedom to criticize.
    We should take criticism seriously, we have to listen and react. It’s of no use to try to change the people, usually people don’t complain out of nothing. We have to take it as an opportunity. We should educate them if they got something wrong, or change our point of view and think about the criticism, maybe there is something about it5.

Jeff Atwood isn’t the only one to write a Bill of Rights, the C2 Wiki has one too as well as a Bill of Responsibilites.

1 One man’s constant is another man’s variable. — Alan Perlis

2 I once worked in a room with seven people and at least five different projects, imagine the noise level in there.

3 We often discussed issues which were dictated from above, but we didn’t know it, so we lost hours or days discussing alternatives which simply were out of question.

4 I know of a company which is very into communicating new ideas. They preserve time to educate their people, but they forgot to consider the learning time in the first place.

5 I once was asked to stop criticizing some product we were building. I was so perplex I couldn’t say anything about it. Isn’t criticism a way to improve things, or at least a pointer what is wrong with a particular product?

6 I used to like the Microsoft Natural Keyboard Pro while using a PC.

7 I once was asked to share a mouse with a colleague sitting in another room :-).

Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis.
— Alan PerlisFools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.
— Alan Perlis