4 ms·

For the vast majority of us, technology is one component of the business. The rest of the business is about figuring out how to lower shipping costs so that we

by memset 15y ago

For the vast majority of us, technology is one component of the business. The rest of the business is about figuring out how to lower shipping costs so that we make more money per item shipped. Or how to deliver food more efficiently. Or accounts receivable software. And none of those problems are, well, are particularly hard or complex, at least not enough in my mind to justify ego as you've portrayed it. There are plenty of professions where people work just as hard (harder, even, including people in the knowledge-working industry) and do not complain nearly as much as developers. There is a lawyer in our office who works very hard to ensure that we are selling wine in a compliant way across multiple states with different regulations. That person's job is at least as difficult, if not more, than my job writing python. But you'll never hear them complaining because we only have apple juice, rather than orange juice, in the vending machine.

CodeMage 15y ago
And none of those problems are, well, are particularly hard or complex, at least not enough in my mind to justify ego as you've portrayed it. I wish I had a dime for every time someone underestimated the difficulty of solving or optimizing a real-world problem. I might have agreed with you if you claimed that executing a solution is not as complicated as coming up with one. There's a line between having an ego and being a jerk. I don't think that line is so thin that we have to resort to suppressing ego.
alexkearns 15y ago
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.

by memset 15y ago

CodeMage 15y ago

And none of those problems are, well, are particularly hard or complex, at least not enough in my mind to justify ego as you've portrayed it. I wish I had a dime for every time someone underestimated the difficulty of solving or optimizing a real-world problem. I might have agreed with you if you claimed that executing a solution is not as complicated as coming up with one. There's a line between having an ego and being a jerk. I don't think that line is so thin that we have to resort to suppressing ego.

alexkearns 15y ago

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.