I think individuals can sometimes accomplish more than teams. We know that coders vary widely; if one coder can be 10 times better than another, it seems reasonable that a very good individual can be as productive as a team, unless the team is really top-notch --- and how many such teams can exist? At the risk of sounding arrogant, I often feel that other programmers get in the way.
However, a serious reality is that an individual who wants to do something great has to work hard to stack all the cards in his or her favor. This means, I think, both financial and technical preparation, so that true full-time work is possible. I personally don't think one can produce excellent work and be distracted at the same time.
One is also better off if one can choose a hard, smooth problem to solved, rather than an easy, hairy problem. Excessive administration will defeat the Lone Coder. A problem with a thousand function points is difficult for an individual.
I think I should adjust the language of this section; I did not intend to slight any non-engineers, though some people are bound to take it that way, no matter what I say.
I think some people would interpret those same words as being flattering to non-engineers; but I don't want there to be any mistake on this point, so I'll hammer home that I am not encouraging a condescending attitude.
I actually go out of my way quite a bit to be not only trustworthy, but accessible to all the non-engineers in our company, and I think this is a very important habit that I have not spelled out in the essay but plan to soon.
I think most people understand the value of sysadmin, salespeople, marketers, managers, technical writers, receptions and janitors. They are all valuable; I don't think programming is in itself more valuable. However, I'm not ashamed to celebrate the act of mental creation of a useful artifact; and celebrating that wonderful act should not be taken as putting somebody else down.
I also think I'll add a section about serving the business interest better. To me, the model of a programmer is similar to the (perhaps mythic) Samurai---loyally putting out best effort even if disagreeing with the orders.
It's clear from some comments I've gotten that some people who do have huge egos have created enough bad feelings that we need to explicitly combat that.
Here's a question for you: How should one speak to non-engineers? I personally don't think: "Exactly as one speaks to one's teammates" is really a realistic answer.
Yes, it is probably mistitled. I'd rather expand the essay to include other aspects of programming than change the title...but in the short term I'll do that, thank you.
Yes, it is a lot of common sense. I think its at least theoretically possible to make something useful by summarizing common sense; for example, a lot of people describe XP as just a lot of common sense.
I too have been programming for 20 years, and I can't disagree with your Good/Bad and 90%/9%/1% breakdown. But I've learned a lot in 20 years, even in just the last 4, and I still have a lot more to learn. If I can improve the percentage by a thousandth for 10 people, I'll be very happy.
I don't necessarily think debugging is the most important skill for a programmer, so much as that it is the first really hard skill you have to learn. I think one can do a lot with poor design skills and good debugging skills, especially when just starting out...after all, not everyone can create the design.
Surely those who find and report bugs in open-source software are doing a very hard and valuable taks.
Good points...it is of course very broad,
and bound to fail in some ways because of that,
but I had hoped it might be useful to someone
anyway. As some others have pointed out I
have inadvertently written mostly from a corporate-team point of view; perhaps I can improve that.
I have an 87 year old gradmother who can only
walk on flat surfaces and serious osteoporosis.
I doubt riding one of these would be safe enough
for her; she, like a toddler, can fall down
just standing on a concrete slab.
However I'm sure there are a lot of people who
are movement-impaired and I think this is a great
thing for that reason. I personally hope it
succeds and competes with, and also encourages,
the use of bicycles.
Slashdot Mirror
I think individuals can sometimes accomplish more than teams. We know that coders vary widely; if one coder can be 10 times better than another, it seems reasonable that a very good individual can be as productive as a team, unless the team is really top-notch --- and how many such teams can exist? At the risk of sounding arrogant, I often feel that other programmers get in the way. However, a serious reality is that an individual who wants to do something great has to work hard to stack all the cards in his or her favor. This means, I think, both financial and technical preparation, so that true full-time work is possible. I personally don't think one can produce excellent work and be distracted at the same time. One is also better off if one can choose a hard, smooth problem to solved, rather than an easy, hairy problem. Excessive administration will defeat the Lone Coder. A problem with a thousand function points is difficult for an individual.
I think I should adjust the language of this section; I did not intend to slight any non-engineers, though some people are bound to take it that way, no matter what I say.
I think some people would interpret those same words as being flattering to non-engineers; but I don't want there to be any mistake on this point, so I'll hammer home that I am not encouraging a condescending attitude.
I actually go out of my way quite a bit to be not only trustworthy, but accessible to all the non-engineers in our company, and I think this is a very important habit that I have not spelled out in the essay but plan to soon.
I think most people understand the value of sysadmin, salespeople, marketers, managers, technical writers, receptions and janitors. They are all valuable; I don't think programming is in itself more valuable. However, I'm not ashamed to celebrate the act of mental creation of a useful artifact; and celebrating that wonderful act should not be taken as putting somebody else down.
I also think I'll add a section about serving the business interest better. To me, the model of a programmer is similar to the (perhaps mythic) Samurai---loyally putting out best effort even if disagreeing with the orders.
It's clear from some comments I've gotten that some people who do have huge egos have created enough bad feelings that we need to explicitly combat that.
Here's a question for you: How should one speak to non-engineers? I personally don't think:
"Exactly as one speaks to one's teammates" is really a realistic answer.
ProlificSage, the book is free.
One of the two reasons I used "she" is to try to make the reader's visualization of the person being talked about a little more vivid.
Thank you for this excellent comment. I will try to incorporate this into the next version.
I just really like the people I work with. I also really like Extreme Programming, and we use it at Hire.com.
I'm sorry so many people find it jarring; I may change it. I had planned on using alternation eventually.
Yes, it is probably mistitled. I'd rather expand the essay to include other aspects of programming than change the title...but in the short term I'll do that, thank you.
Yes, it is a lot of common sense. I think its at least theoretically possible to make something useful by summarizing common sense; for example, a lot of people describe XP as just a lot of common sense. I too have been programming for 20 years, and I can't disagree with your Good/Bad and 90%/9%/1% breakdown. But I've learned a lot in 20 years, even in just the last 4, and I still have a lot more to learn. If I can improve the percentage by a thousandth for 10 people, I'll be very happy.
Yes, I should have talked about that. It is very important. Unfortunately I'm not sure I'm good enough at it to write that section.
I don't necessarily think debugging is the most important skill for a programmer, so much as that it is the first really hard skill you have to learn. I think one can do a lot with poor design skills and good debugging skills, especially when just starting out...after all, not everyone can create the design. Surely those who find and report bugs in open-source software are doing a very hard and valuable taks.
Good points...it is of course very broad, and bound to fail in some ways because of that, but I had hoped it might be useful to someone anyway. As some others have pointed out I have inadvertently written mostly from a corporate-team point of view; perhaps I can improve that.
I also love _The Pragmatic Programmer_ and recommend it in the introduction. It's scope is a bit different than this essay.
I have an 87 year old gradmother who can only walk on flat surfaces and serious osteoporosis. I doubt riding one of these would be safe enough for her; she, like a toddler, can fall down just standing on a concrete slab. However I'm sure there are a lot of people who are movement-impaired and I think this is a great thing for that reason. I personally hope it succeds and competes with, and also encourages, the use of bicycles.