53 ms·

You are kind of making my point for me. This is a list drawn up from the perspective of a business owner who obviously would prefer all his employees to be egol

You are kind of making my point for me. This is a list drawn up from the perspective of a business owner who obviously would prefer all his employees to be egoless automatons who work smoothly together in the most cost-effective and efficient manner. Yes, from the business perspective (or the project management perspective or the agile coach perspective or the countless other professions that have infiltrated software development), this list is absolutely great. Couldn't be better. Five-star perfection. However, from the programmer's point of view - and that is the view I was arguing from - the list is pretty detestable, at least in my view. People get into programming usually because they want to make things, because they want to be creative. But - in the vast majority of cases - they end up working on legacy projects that require absolutely no creativity, where, indeed, creativity is frowned upon - see Commandment 4. You are saying they should shut-up and deal with it. I am saying, fuck that, they can complain as much as they like. Having said that, even better than complaining would be for the programmer to ditch the job and start creating their own software, under their own terms. But, of course, you would need a bit of an ego to have the guts to do that.

memset 15y ago
Haha, I am all for people squeezing out from under The Man and creating their own software. I read Commandment 4 ("Don't rewrite code without consultation") differently. My opinion is that if you are working on a team with developers, you have to be judicious about making big changes. It is possible (likely!) that some of that code was written because of some weird Python behavior or to handle an edge case from a buggy external API or some odd behavior from another internal system. I do advocate "if you want a change, write some code and make the change." But a wikipedia-style edit war between programmers' egos is also not productive. In the context of a business, "creativity" can and should mean "creative ideas that have the potential make more money." It is unfair to ask someone to pay you a salary for unbridled side-project creativity; that is what your disposable income is for! Even when you are running your own business, well, it isn't a business unless you ask the question "how can I create software that my customers will pay for?" rather than "what shall I make which sates my creativity?" I'd suggest, then, that this list is relevant for anyone trying to make money, because that always entails working with some other person (fellow programmer, business partner, customer) and that can only happen when you have a harmonious relationship with - and are willing to bend a little - for these people.
- alexkearns 15y ago
  You'd make a better employee than me! Edit: That was not meant as a dig at you but more of an indication of what a shit employee I'd be.
  - memset 15y ago
    No offense taken! Good discussion overall :)
- CodeMage 15y ago
  It is possible (likely!) that some of that code was written because of some weird Python behavior or to handle an edge case from a buggy external API or some odd behavior from another internal system. If that code is in there without at least a comment mentioning that, then you have bigger problems than handling people's egos. This kind of thing is precisely what comments are for. I do advocate "if you want a change, write some code and make the change." But a wikipedia-style edit war between programmers' egos is also not productive. False dichotomy. In the context of a business, "creativity" can and should mean "creative ideas that have the potential make more money." It is unfair to ask someone to pay you a salary for unbridled side-project creativity; that is what your disposable income is for! Tell that to people who came up with 15% "innovation time" at 3M and 20% at Google. Of course, Google's 20% got subverted as far as I've heard, but that's a completely different topic. The point is that creativity should be exercised at the right time, in the right place and in a right degree. I'd suggest, then, that this list is relevant for anyone trying to make money, because that always entails working with some other person (fellow programmer, business partner, customer) and that can only happen when you have a harmonious relationship with - and are willing to bend a little - for these people. This has nothing to do with making money. It has to do with your project being successful or not. It has to do with people on your team being reasonable most of the time and having a good manager (or something equivalent) the rest of the time. Having said all that, "Don't rewrite code without consultation" should be a no-brainer. Not necessarily for Jeff's reason, but because if it's someone else's code, chances are that there might be something you don't understand about it; on the other hand, if it's your code, there might be someone using it and your rewrite could break it for them. Checking this stuff is usually a good idea.
snikolov 15y ago
creativity is frowned upon - see Commandment 4 I don't think #4 is about creativity, but about communication and humility. It's about looking at what others did and discussing with them the possibility of changing it because 1) they built it and are probably more intimately familiar with its subtleties 2) it's a good idea to communicate your plans to your team (and especially the stakeholders in the code you're planning to change)
untog 15y ago
This is a list drawn up from the perspective of a business owner who obviously would prefer all his employees to be egoless automatons... People get into programming usually because they want to make things, because they want to be creative. Welcome to the place otherwise known as 'the real world'. Do you think the guy filming the Jersey Shore dreamed of getting to where he is today? Of course not. Even people in creative fields have to suck it up and do the dry work before they are lucky enough to do whatever they want.

memset 15y ago

Haha, I am all for people squeezing out from under The Man and creating their own software. I read Commandment 4 ("Don't rewrite code without consultation") differently. My opinion is that if you are working on a team with developers, you have to be judicious about making big changes. It is possible (likely!) that some of that code was written because of some weird Python behavior or to handle an edge case from a buggy external API or some odd behavior from another internal system. I do advocate "if you want a change, write some code and make the change." But a wikipedia-style edit war between programmers' egos is also not productive. In the context of a business, "creativity" can and should mean "creative ideas that have the potential make more money." It is unfair to ask someone to pay you a salary for unbridled side-project creativity; that is what your disposable income is for! Even when you are running your own business, well, it isn't a business unless you ask the question "how can I create software that my customers will pay for?" rather than "what shall I make which sates my creativity?" I'd suggest, then, that this list is relevant for anyone trying to make money, because that always entails working with some other person (fellow programmer, business partner, customer) and that can only happen when you have a harmonious relationship with - and are willing to bend a little - for these people.

alexkearns 15y ago
You'd make a better employee than me! Edit: That was not meant as a dig at you but more of an indication of what a shit employee I'd be.
- memset 15y ago
  No offense taken! Good discussion overall :)
CodeMage 15y ago
It is possible (likely!) that some of that code was written because of some weird Python behavior or to handle an edge case from a buggy external API or some odd behavior from another internal system. If that code is in there without at least a comment mentioning that, then you have bigger problems than handling people's egos. This kind of thing is precisely what comments are for. I do advocate "if you want a change, write some code and make the change." But a wikipedia-style edit war between programmers' egos is also not productive. False dichotomy. In the context of a business, "creativity" can and should mean "creative ideas that have the potential make more money." It is unfair to ask someone to pay you a salary for unbridled side-project creativity; that is what your disposable income is for! Tell that to people who came up with 15% "innovation time" at 3M and 20% at Google. Of course, Google's 20% got subverted as far as I've heard, but that's a completely different topic. The point is that creativity should be exercised at the right time, in the right place and in a right degree. I'd suggest, then, that this list is relevant for anyone trying to make money, because that always entails working with some other person (fellow programmer, business partner, customer) and that can only happen when you have a harmonious relationship with - and are willing to bend a little - for these people. This has nothing to do with making money. It has to do with your project being successful or not. It has to do with people on your team being reasonable most of the time and having a good manager (or something equivalent) the rest of the time. Having said all that, "Don't rewrite code without consultation" should be a no-brainer. Not necessarily for Jeff's reason, but because if it's someone else's code, chances are that there might be something you don't understand about it; on the other hand, if it's your code, there might be someone using it and your rewrite could break it for them. Checking this stuff is usually a good idea.

snikolov 15y ago

creativity is frowned upon - see Commandment 4 I don't think #4 is about creativity, but about communication and humility. It's about looking at what others did and discussing with them the possibility of changing it because 1) they built it and are probably more intimately familiar with its subtleties 2) it's a good idea to communicate your plans to your team (and especially the stakeholders in the code you're planning to change)

untog 15y ago

This is a list drawn up from the perspective of a business owner who obviously would prefer all his employees to be egoless automatons... People get into programming usually because they want to make things, because they want to be creative. Welcome to the place otherwise known as 'the real world'. Do you think the guy filming the Jersey Shore dreamed of getting to where he is today? Of course not. Even people in creative fields have to suck it up and do the dry work before they are lucky enough to do whatever they want.