10 years ago, Jeff Atwood wrote an article he titled The Programmer Bill of Rights. In that article he described 6 fundamentals that companies should provide for programmers to be successful and work to their full potential, thus maximizing their productivity.

Sadly, ten years later, many companies still deny these basics to their developers, even though the business case for these six points is absolutely proved.

In this article, not only would I like to update the original 6 principles, providing further evidence of their importance; but also I would like to extend the list. Based on my experience during the last 10 years, I will propose 4 new fundamentals that I consider absolutelly necessary for the daily work of any programmer, developer or software engineer. Let’s get started:

10 Fundamental Programmer Rights (6 + 4)

It is worth mentioning that, despite the headline, this article does not refer to general Labor Rights, since those are usually well-known and its compliance is required by law. This article focuses only on aspects that are specific to software development, aspects that are usually not regulated, but have a huge impact on programmers’ daily work.

The 6 Original Rights proposed by Jeff

My 4 Proposed Additions

Every programmer shall be free to choose her preferred IDE.

In the past it was common to have the build and/or deploy process of the application being developed attached to the IDE (usually by means of a plugin). Fortunately, nowadays the use of build tools has become mainstream, making our build processes IDE-independent. For example, in the Java community, build tools like maven or gradle make it possible for developers in a team to use different IDEs such as Eclipse, Intellij IDEA or any other editors, without any problems of collaboration. They just need to use a version control system (such as Subversion or Git) to share changes and a build tool to generate artifacts. In such environment, forcing developers to use an standardized IDE seems to be only a poor resource of old-school managers used to the “command-and-control” approach to impose their rule. That imposition can only cause a low morale among team members, decrease motivation and cause brain drain in the team, since many talented developers will leave to a more open-minded company. Every programmer shall have admin rights on his computer.

Last year I was introduced to a company that had recently been created with the idea to enter in the software development market. However, I was utterly surprised when I got to know that this company didn’t allow developers to have admin rights in their computers. This is pure nonsense. As this fantastic answer in Stack Overflow states, developers in their daily work need to install software for different development purposes (editors, servers, databases, API clients…), they need to change different system configurations for different purposes and, most importantly, they need to be comfortable at work in order to give the best of themselves. Restricting admin rights to developers will only lead to a high turnover rate, inability to retain competent people, poor morale and poor quality delivery. Probably, as this other comment states, “if you walk into a job as a developer and find you have no admin rights in your machine, the best choice is to not come back the next day”. Every programmer shall have access to the big picture.

Sometimes programmers are not presented with the big picture of the system they are contributing to build, but instead they are given small tasks to do, with narrow descriptions. In those cases, they often do not have direct access to the product owner nor the end users of the software they are working on. This usually causes trouble, since many wrong decisions can be made and many misconceptions can be created. To design software that can evolve properly in the desired direction, developers should understand the big picture, the whole system that is being built, not only the small task that has been assigned to them at one point. Moreover, developers should be free to ask as many functional questions as they need, so they can make the right design decisions and write software that can evolve as expected, avoiding later problems. Every programmer shall have autonomy in his daily work.

As any other creative process, programming requires autonomy. That is why agile frameworks, like Scrum, propose planning work for periods of a week, 15 days or a month; so developers can organize themselves in between. Daily meetings can help detect and resolve problems, as well as keep the development team in sync; but freedom for each contributor to organize his workday without suffering micromanagement should be preserved. The need for autonomy also applies to the programming process, where creativity is key to problem-solving. Some developers prefer to solve a task by creating some tests first, others build a monolithic function and then refactor it, others start by understanding the existing codebase and doing some diagrams… Any of these approaches should be respected, as long as basic agreements of the team (e.g. “definition of done”) and quality standards (e.g. minimum test coverage) are met.

What do you think about these additions? Please, join the conversation!

Are these rights being respected at your company?

A real case of toxic management denying many of these rights Unfortunately, there are companies that keep denying many of these basics today. I recently saw a case in which a manager refused to replace a defective monitor with obvious flickering problems to an employee (even though flickering may cause dizziness, fatigue and headaches). This very manager was also forcing programmers to work with only one squared 19” monitor (for no reason). He firmly refused to buy second monitors and even forbade some developers to bring a second monitor from their homes… Does it make any sense? However, this guy had two wide monitors in his desk, of course. I guess he just wanted to show that there was a big difference between him and his “subordinates”, who had to be controlled and treated like clones. As with any other of these rights, a reluctance to provide programmers with two monitors not only shows that your manager or the company board do not care about your opinions or comfort; they don’t even care about productivity. It is definitely a red flag. Taking into account the ridiculously small cost of monitors nowadays, even worrying about it shows a clear case of being “penny wise, pound foolish”. But that’s not all of it. Usually, when an old-school command-and-control minded manager is violating one of these basics, is probably violating many others, since they are all tightly-linked and it is all about mindset and company culture. In this particular case, this very manager was also forcing developers to use a three-year-outdated version of Netbeans as IDE, with no front-end support (significantly diminishing their productivity). And, by the way, he had also decided to forbid admin rights to programmers in their own machines (making their daily work absurdly complicated)… So you see, three basics at once. Not to mention that micro-management was also one of the company core values. The micro-manager used to interrupt programmers every hour to closely control their tasks, taking away all the autonomy and long-term vision from the developer. If you find yourself in a case like this one, my advice cannot be clearer: there are many companies that will be glad to provide the tools you need to achieve the best results in your daily work, so don’t wait anymore, move on. No one should work for a tyrant like that.

As an ending to this article, I would like to borrow the last paragraph from Jeff’s article: “The few basic rights we’re asking for are easy. They aren’t extravagant demands. They’re fundamental to the quality of work life for a software developer. If the company you work for isn’t getting it right, making it right is neither expensive nor difficult. Demand your rights as a programmer! And remember: you can either change your company, or you can change your company”.