11 ms·

No matter how much "karate" you know, someone else will always know more.

169 points by macco 15y ago

Akram 15y ago
* Be kind to the coder, not to the code. ^ * Treat people who know less than you with respect, deference, and patience. - My friend/cofounder has been inspired by the codeyear thing and have been bringing to me a lot of silly code issues... guess i was being a bit rude with him lately.
- defrost 15y ago
  I'm frequently in a room with people that know less about mathematics and programming than I do (and let's be clear, I don't regard myself as exceptionally talented in either field). It's not surprising, that's usually the reason I've been asked in to consult. The great joy is discovering what these people know more about than I do: electronics, cartography, avionics, wet film processing, fire fighting, violin making, linguistics, ... it's always a surprise finding out just how much some people know about their particular interest and how well they can make you appreciate it. I'm get a little tired of hearing "the IT Crowd" cackle on about how stupid their users are, maybe that is true for them but it is possible to go out and find end users that stretch and challenge you as a programmer to meet their needs.
  - Akram 15y ago
    being the only tech guy in the room sometime sucks. But you are right.. there is more to just math and programing.. You are right^
    - hessenwolf 15y ago
      Meh. I've done the rounds as a statistician, and it would be pretty unusual to meet somebody who knew as much as me about what I do - in fact, even if I meet another statistician, there is almost surely no chance they know everything I know. I am always the expert, at what I do. And then I have to try really hard to get any idea of what everybody else is doing.
      - davidw 15y ago
        > it would be pretty unusual to meet somebody who knew as much as me about what I do What do you think the odds are?
marcusf 15y ago
> Don't rewrite code without consultation. This is linked to a pet peeve of mine, especially with restless, young developers. There's a significant difference between the two statements "I don't get this code, it's crap, let's rewrite it." and "I understand this code, it's crap, let's rewrite it". I don't know how many times I've seen someone go down the path of seing battle-tested code, not understanding it, thinking they can rewrite it better only to spend a month falling in to all the same pitfalls that lead to the original code. The middle road is of course refactoring. Cleaning up the code in small, discrete steps to something you can understand and work with is many times better than just tearing stuff out and restarting.
- adrianhoward 15y ago
  If anybody on the team can spend a month going down a rabbit hole rewriting code then there's something seriously wrong regardless :-) The "Don't rewrite code without consultation" was the only one of Jeff's points I would niggle with. I love environments where there is collective code ownership - everybody being free to edit any code without asking first. It encourages everybody to keep the code in a state where that's possible, lowers the barriers to getting code improved, and helps lower the bus number by getting more people familiar with more of the code base. But for it to work you need an environment where you have rapid feedback, regular integration of changes, etc. If those times are measured in days, weeks or - deity forbid - months then you're heading for trouble.
  - bmj 15y ago
    But for it to work you need an environment where you have rapid feedback, regular integration of changes, etc. If those times are measured in days, weeks or - deity forbid - months then you're heading for trouble. This is a big caveat for lots of developers. Not everyone works in such an "agile" environment. Another poster has already linked to Joel's essay on rewrites, and that's written with his experience at Microsoft in mind. There's also a matter of testing. If you have a group of testers slated for a release, suddenly dropping a bunch of regressions on them will seriously skew their time lines. That's not say that the environment you describe isn't a good thing--it's just not reality for many of us.
barefoot 15y ago
> The only true authority stems from knowledge, not from position. That's certainly not the full story. In many organizations, having a lot of knowledge about something that someone else is supposed to know more about is a good way to make them feel uncomfortable or in extreme cases dislike you. From a practical vantage, knowing how to apply what knowledge you do have (and having the will to follow through) is a lot more valuable. It doesn't help to have a broad and deep understanding of software development and business but be socially awkward and suffer from severe akrasia.
- bdunbar 15y ago
  In many organizations, having a lot of knowledge about something that someone else is supposed to know more about is a good way to make them feel uncomfortable or in extreme cases dislike you. This. I worked for one org (USMC) where I was a young(er) worker, with more knowledge about our job (micro-computers, LANs) than most of my superiors. And this was okay. Encouraged, even. My lieutenant's job was to lead a team, not be a know-it-all. Then I stepped into the civilian world and found a majority of managers were freaked out when their juniors knew more than they did.
  - iron_ball 15y ago
    On the other hand, in the armed forces, rank commands respect (or at least all outward forms). In the civilian world, those with rank may be more insecure.
    - bdunbar 15y ago
      I think it's more about culture, not respect for rank. A guy is supposed to learn at least the basics of the next higher-up job, sometimes two. Team leaders are supposed to reach down two levels, ensure juniors are properly schooled to step up. Obviously this is so if one's leader is zapped, juniors can step up and carry out the mission. But this works out well in nominal peace-time and non-combat jobs, too. And the better trained and schooled one's juniors are, the better the unit can carry out the mission. Example: one week into a three-week field exercise I was given 20 minutes to pack and report to a new, temporary, job, far away from my parent unit. We could do this because everyone under me (all of three guys, but still) knew what I did and could do the job. The only problem it caused was that they suddenly had one fewer person to stand watch in the server CONEX.
memset 15y ago
It is interesting that all of us are getting a different takeaway from this list; something different resonates with different people. It also surprises me that these lessons originated in 1971 (though I had not heard of this text until just now.) Back then, IBM was hiring English majors and training them in assembly to work on OS/360 etc. It would not have occurred to me that developers back then would have cultivated a stereotype of a "prima donna." Because to me, and perhaps this is a reflection of my age, it has only been recently that the popularity of joelonsoftware-esque "pamper your developers!" has led to a culture in small companies where we demand free beer and 36" Macs as a condition for employment. Or has it always been that way for developers (of young tech companies; none of this really applies if you work at Fidelity Investments) modulo the greatest tech of the day?
- robfig 15y ago
  I think this is just supply-demand of the current labor market. There are enough lawyers to go around, but not even close to enough good developers. I think it will continue to be that way for a long time
  - memset 15y ago
    Interestingly, you have compared apples and oranges: "lawyers" and "good developers" (as opposed to "good lawyers".) What I mean to say is - and, of course, this is all unsubstantiated - there are plenty of coders and lawyers to go around, but fewer good lawyers (with relevant experience in a field of business, for me it is the wine biz) and good developers (can you follow the instructions on our code test?) Possibly good lawyers simply get paid more than good developers, and so that - combined with a different culture between the two professions - engenders a different sense of professionalism. What is the essential quality about dev which causes our culture to be different than other professionals (lawyers?)
    - arethuza 15y ago
      Well, as someone married to a lawyer I one thing that is completely different is that they have to worry about their professional license - if they screw up badly enough then it can be taken away and then they can't work as a lawyer anymore. There is no sanction that can be applied to a developer that will mean that they can never get employed as a developer again.
alexkearns 15y ago
I hate this list. It should really be called the Ten Commandments of Good Little Worker Programmers. The 'commandments' are all about creating nice friendly programmer cogs that work smoothly together, minimising hassle for their employers. There's nothing there about programming as an art. There is nothing there about pushing the boundaries of what is possible through determination, vision and, yes, ego. There is nothing about solving complex technical problems through sheer force of will. To hell with 'egolessness'. Why shouldn't programmers have an ego. And, indeed, doesn't it take an ego to do anything great, to think that preposterous thought that you can do something no-one has done before.
- 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.
  - 15y ago
leon_ 15y ago
Sad times when Atwood is giving coding advice ...
seclorum 15y ago
The corollary: All human knowledge can be known.

169 points by macco 15y ago

Akram 15y ago

* Be kind to the coder, not to the code. ^ * Treat people who know less than you with respect, deference, and patience. - My friend/cofounder has been inspired by the codeyear thing and have been bringing to me a lot of silly code issues... guess i was being a bit rude with him lately.

defrost 15y ago
I'm frequently in a room with people that know less about mathematics and programming than I do (and let's be clear, I don't regard myself as exceptionally talented in either field). It's not surprising, that's usually the reason I've been asked in to consult. The great joy is discovering what these people know more about than I do: electronics, cartography, avionics, wet film processing, fire fighting, violin making, linguistics, ... it's always a surprise finding out just how much some people know about their particular interest and how well they can make you appreciate it. I'm get a little tired of hearing "the IT Crowd" cackle on about how stupid their users are, maybe that is true for them but it is possible to go out and find end users that stretch and challenge you as a programmer to meet their needs.
- Akram 15y ago
  being the only tech guy in the room sometime sucks. But you are right.. there is more to just math and programing.. You are right^
  - hessenwolf 15y ago
    Meh. I've done the rounds as a statistician, and it would be pretty unusual to meet somebody who knew as much as me about what I do - in fact, even if I meet another statistician, there is almost surely no chance they know everything I know. I am always the expert, at what I do. And then I have to try really hard to get any idea of what everybody else is doing.
    - davidw 15y ago
      > it would be pretty unusual to meet somebody who knew as much as me about what I do What do you think the odds are?

marcusf 15y ago

> Don't rewrite code without consultation. This is linked to a pet peeve of mine, especially with restless, young developers. There's a significant difference between the two statements "I don't get this code, it's crap, let's rewrite it." and "I understand this code, it's crap, let's rewrite it". I don't know how many times I've seen someone go down the path of seing battle-tested code, not understanding it, thinking they can rewrite it better only to spend a month falling in to all the same pitfalls that lead to the original code. The middle road is of course refactoring. Cleaning up the code in small, discrete steps to something you can understand and work with is many times better than just tearing stuff out and restarting.

adrianhoward 15y ago
If anybody on the team can spend a month going down a rabbit hole rewriting code then there's something seriously wrong regardless :-) The "Don't rewrite code without consultation" was the only one of Jeff's points I would niggle with. I love environments where there is collective code ownership - everybody being free to edit any code without asking first. It encourages everybody to keep the code in a state where that's possible, lowers the barriers to getting code improved, and helps lower the bus number by getting more people familiar with more of the code base. But for it to work you need an environment where you have rapid feedback, regular integration of changes, etc. If those times are measured in days, weeks or - deity forbid - months then you're heading for trouble.
- bmj 15y ago
  But for it to work you need an environment where you have rapid feedback, regular integration of changes, etc. If those times are measured in days, weeks or - deity forbid - months then you're heading for trouble. This is a big caveat for lots of developers. Not everyone works in such an "agile" environment. Another poster has already linked to Joel's essay on rewrites, and that's written with his experience at Microsoft in mind. There's also a matter of testing. If you have a group of testers slated for a release, suddenly dropping a bunch of regressions on them will seriously skew their time lines. That's not say that the environment you describe isn't a good thing--it's just not reality for many of us.

barefoot 15y ago

> The only true authority stems from knowledge, not from position. That's certainly not the full story. In many organizations, having a lot of knowledge about something that someone else is supposed to know more about is a good way to make them feel uncomfortable or in extreme cases dislike you. From a practical vantage, knowing how to apply what knowledge you do have (and having the will to follow through) is a lot more valuable. It doesn't help to have a broad and deep understanding of software development and business but be socially awkward and suffer from severe akrasia.

bdunbar 15y ago
In many organizations, having a lot of knowledge about something that someone else is supposed to know more about is a good way to make them feel uncomfortable or in extreme cases dislike you. This. I worked for one org (USMC) where I was a young(er) worker, with more knowledge about our job (micro-computers, LANs) than most of my superiors. And this was okay. Encouraged, even. My lieutenant's job was to lead a team, not be a know-it-all. Then I stepped into the civilian world and found a majority of managers were freaked out when their juniors knew more than they did.
- iron_ball 15y ago
  On the other hand, in the armed forces, rank commands respect (or at least all outward forms). In the civilian world, those with rank may be more insecure.
  - bdunbar 15y ago
    I think it's more about culture, not respect for rank. A guy is supposed to learn at least the basics of the next higher-up job, sometimes two. Team leaders are supposed to reach down two levels, ensure juniors are properly schooled to step up. Obviously this is so if one's leader is zapped, juniors can step up and carry out the mission. But this works out well in nominal peace-time and non-combat jobs, too. And the better trained and schooled one's juniors are, the better the unit can carry out the mission. Example: one week into a three-week field exercise I was given 20 minutes to pack and report to a new, temporary, job, far away from my parent unit. We could do this because everyone under me (all of three guys, but still) knew what I did and could do the job. The only problem it caused was that they suddenly had one fewer person to stand watch in the server CONEX.

memset 15y ago

It is interesting that all of us are getting a different takeaway from this list; something different resonates with different people. It also surprises me that these lessons originated in 1971 (though I had not heard of this text until just now.) Back then, IBM was hiring English majors and training them in assembly to work on OS/360 etc. It would not have occurred to me that developers back then would have cultivated a stereotype of a "prima donna." Because to me, and perhaps this is a reflection of my age, it has only been recently that the popularity of joelonsoftware-esque "pamper your developers!" has led to a culture in small companies where we demand free beer and 36" Macs as a condition for employment. Or has it always been that way for developers (of young tech companies; none of this really applies if you work at Fidelity Investments) modulo the greatest tech of the day?

robfig 15y ago
I think this is just supply-demand of the current labor market. There are enough lawyers to go around, but not even close to enough good developers. I think it will continue to be that way for a long time
- memset 15y ago
  Interestingly, you have compared apples and oranges: "lawyers" and "good developers" (as opposed to "good lawyers".) What I mean to say is - and, of course, this is all unsubstantiated - there are plenty of coders and lawyers to go around, but fewer good lawyers (with relevant experience in a field of business, for me it is the wine biz) and good developers (can you follow the instructions on our code test?) Possibly good lawyers simply get paid more than good developers, and so that - combined with a different culture between the two professions - engenders a different sense of professionalism. What is the essential quality about dev which causes our culture to be different than other professionals (lawyers?)
  - arethuza 15y ago
    Well, as someone married to a lawyer I one thing that is completely different is that they have to worry about their professional license - if they screw up badly enough then it can be taken away and then they can't work as a lawyer anymore. There is no sanction that can be applied to a developer that will mean that they can never get employed as a developer again.

alexkearns 15y ago

I hate this list. It should really be called the Ten Commandments of Good Little Worker Programmers. The 'commandments' are all about creating nice friendly programmer cogs that work smoothly together, minimising hassle for their employers. There's nothing there about programming as an art. There is nothing there about pushing the boundaries of what is possible through determination, vision and, yes, ego. There is nothing about solving complex technical problems through sheer force of will. To hell with 'egolessness'. Why shouldn't programmers have an ego. And, indeed, doesn't it take an ego to do anything great, to think that preposterous thought that you can do something no-one has done before.

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.
- 15y ago

leon_ 15y ago

Sad times when Atwood is giving coding advice ...

seclorum 15y ago

The corollary: All human knowledge can be known.