6 ms·

Not so much lesser-known truths as absolute bullshit. The author describes developers who spend much of their time writing code as "lazy, ignorant and arrogant

Not so much lesser-known truths as absolute bullshit. The author describes developers who spend much of their time writing code as "lazy, ignorant and arrogant". I think it is the author who is being lazy, ignorant and arrogant in thinking that he knows the truth about programming. And the idea that a developer will only write a handful of lines of code each day that will end up in the final product might be true for a developer working on an established piece of software but anyone who has worked for a start-up or on their own software will just laugh at the idea of writing just 12 useful lines of code a day. A good developer can easily do hundreds, if not low thousands of lines of code in a day if pushed, and this code does often end up in the final product. Plus, he seems to think that a great programmer is someone who connects together bits of code created by others, rather than writing his own code. That's ridiculous - is someone who uses another person's code a better programmer than the person who wrote the code he is using, in which case I am a much better programmer than John Resig, say, because I simply use jQuery rather than having written it myself. I think this article is a perfect demonstration of the Dunning-Kruger effect. Sorry for being so blunt but the article bloody annoyed me.

Retric 16y ago
This is looking at the average day of the average programmer over the lifetime of the average product. Working on a 6 month old project it's vary easy to produce negative lines of code as you refractor. But, when you look at the average there is little reason to count time spent creating code that was soon replaced as useful. It's also easy to think you are vary produce when you produce 10k lines of code in the first six weeks of a project, but the reality is over time most of that is going away. And writing more than 10 lines of code a day that sticks around for more than 2 years without making people wanting to replace it is hard. PS: Google, for example, often scraps the source code of any company it acquires so the real metric of lines of code produced per day over the first six months is often zero in a successful project. Many a startup has failed and nothing of value was lost.
- alexkearns 16y ago
  I think maybe you work in a completely different field of programming to me. Most lines of code I have written in my career have ended up in the final product. The same is true of most the developers I know.
  - Retric 16y ago
    I am not saying they where never used, just the fact that much of a project is scraped at one point or another. EX: Bingo card creator started as a java app, and now it's a pure webapp. He still let's people download the app, but it's on the way out. It may be a semantic argument, but basically if the same people / team are working on the same problem then a complete rewrite does not make a new project. As far as I know zero of Windows 3.1’s codebase made it into Windows 7. However, when you look at API’s it’s hard to call the Windows 3.1 to ME family a separate project from the Windows NT to Windows 7.
    - alexkearns 16y ago
      I suppose it depends what you mean by the final product. I would define the final product as something that is installed somewhere and is used. Ultimately, all products will be scrapped or superseded but to say that means every bit of code you have written is unused seems a bit odd.
      - Retric 16y ago
        True, at the same time the is a fair amount of really old Unix code. Still, length counting a temperarry bug fix that lasts a week as having identical value as core functionality that lasts 30 years seems to miss something. A more reasonable metric might be, how much of the code you wrote today will still be in use in 15 years. And if you think more than 10 lines per day is going to make that hurdle, I think your fooling yourself.
        m_eiman 16y ago
        Few programmers ever work on something that'll still be in use 15 years later. Just have a look at http://en.wikipedia.org/wiki/Category:1995_software http://en.wikipedia.org/wiki/Category:1995_software (which isn't complete, obviously) - I don't think that even MS Office still contains much of what was in it in the '95 edition.
nocipher 16y ago
There is some truth in the article. Coding is easy. It's all the other aspects of software development that are difficult. I know that the biggest hurdle for any programming project I've ever been involved in is deciding what will be the different parts of the system and then how those parts will interact. Once I start writing code, I can program very quickly because I don't have to make hard decisions. Even so, a few thousand lines of a code a day is a bit much for anything non-trivial. To write that much code in a single day means that person must have done little else besides coding. Unless there was a period of about a week of design before that kind of coding, I'd expect the code to be rather kludgy because everything would be decided immediately. A few thousand lines of code, though, is definitely not something I'd consider average. A /small/ project that added a new feature to an existing system took about 30 hours for the initial version over a two week time period and about 800 lines of code. Granted, I don't know exactly where my programming abilities lie skill-wise, but I can't imagine someone being 30x or 40x more productive than that as you suggest. And maybe I'm just new around here, but if was going to argue for the Dunning-Kruger effect, I'd begin by arguing that I am clearly not suffering from the effect myself.
- alexkearns 16y ago
  We all suffer from the Dunning-Kruger effect, to varying degrees. I would never dream of arguing I don't suffer from it. I though do not go around claiming I know the truth about programming. I think that perhaps there are two types of programmer - those who like to spend most of the time researching, drawing diagrams and the such like, and the others who just get on with it. The suggestion of this article is that those who spend most of their time planning, rather than programming are somehow superior - my experience with developers has been the exact opposite.
- ntoshev 16y ago
  Don't worry about the lines of code you write, I'm pretty sure even Dr Norvig can't write 50 of these per day: http://norvig.com/spell-correct.html http://norvig.com/spell-correct.html
cubicle67 16y ago
to play devil's advocate: could it be that your comment is a perfect demonstration of the Dunning-Kruger effect?
- loup-vaillant 16y ago
  I think it's even simpler: he took it personally. He spends much of his time writing code (whatever that means), so he thinks the article is calling him lazy and ignorant and arrogant. (That's not even true, by the way. The article says "lazy or ignorant or arrogant".) Anyway, it triggered a classic defence mechanism: "what is calling me bad must be wrong". So he attacked the part of the article that offended him. In the process, he overshoot, and tried to discredit the whole article (by saying "complete bullshit"). (By the way, I only talk about the emotional process that likely triggered alexkearns' comment. That doesn't make it wrong. Nor right.)
  - alexkearns 16y ago
    Nice of you to write with such conviction and assuredness about my psychology and motives. It is really amazingly impressive how you have become such an expert in me from a single comment I made. I bet your friends are in awe of your ability to deconstruct people with such blithe ease. But just to clarify a few points, I did not take the article as a personal attack on me or my programming philosophy. I just happen to think that in its key points the articles was completely wrong. I know of no programmer - good or otherwise - who only produces 12 or so useful lines of code, or spends 80% of his time thinking about coding, rather than actually doing it. Now, maybe my situation is not typical (but I bet it is not that atypical) but when someone claim's something to be true that in your experience is clearly not, it is one's duty to point that out. Also, anyone who claims to know the truth about programming - I would certainly not claim I do - has to be dead certain they are right before putting these claims to publication, and one has every right to ridicule them if they get it wrong. Claiming to know the truth is not something that should be taken lightly.
    - loup-vaillant 16y ago
      I said "likely triggered the comment". I know it's speculative. But frankly, your tone was so aggressive that it was difficult not to think it was personal. To the point, I think you and the author disagree on some definitions. Most likely "writing code" and "lines of code that make it to the final product". Plus the unspoken assumptions about the project (small or large, early or late…), but that has already been pointed out. I also don't think the article suggests that "a great programmer is someone who connects together bits of code created by others, rather than writing his own code". What It does suggest is that great programmers don't write their own code when they shouldn't. That when they do anyway, it's probably out of laziness (screw the searching, I prefer coding), or arrogance (I can do better anyway), or ignorance (what? It has been done before?). You are right to ridicule those who utter bullshit while claiming it's universal truths. But be careful not to leave holes in your rebuttal. That include angry tone and amplifying the opponent's words.

Retric 16y ago

This is looking at the average day of the average programmer over the lifetime of the average product. Working on a 6 month old project it's vary easy to produce negative lines of code as you refractor. But, when you look at the average there is little reason to count time spent creating code that was soon replaced as useful. It's also easy to think you are vary produce when you produce 10k lines of code in the first six weeks of a project, but the reality is over time most of that is going away. And writing more than 10 lines of code a day that sticks around for more than 2 years without making people wanting to replace it is hard. PS: Google, for example, often scraps the source code of any company it acquires so the real metric of lines of code produced per day over the first six months is often zero in a successful project. Many a startup has failed and nothing of value was lost.

alexkearns 16y ago
I think maybe you work in a completely different field of programming to me. Most lines of code I have written in my career have ended up in the final product. The same is true of most the developers I know.
- Retric 16y ago
  I am not saying they where never used, just the fact that much of a project is scraped at one point or another. EX: Bingo card creator started as a java app, and now it's a pure webapp. He still let's people download the app, but it's on the way out. It may be a semantic argument, but basically if the same people / team are working on the same problem then a complete rewrite does not make a new project. As far as I know zero of Windows 3.1’s codebase made it into Windows 7. However, when you look at API’s it’s hard to call the Windows 3.1 to ME family a separate project from the Windows NT to Windows 7.
  - alexkearns 16y ago
    I suppose it depends what you mean by the final product. I would define the final product as something that is installed somewhere and is used. Ultimately, all products will be scrapped or superseded but to say that means every bit of code you have written is unused seems a bit odd.
    - Retric 16y ago
      True, at the same time the is a fair amount of really old Unix code. Still, length counting a temperarry bug fix that lasts a week as having identical value as core functionality that lasts 30 years seems to miss something. A more reasonable metric might be, how much of the code you wrote today will still be in use in 15 years. And if you think more than 10 lines per day is going to make that hurdle, I think your fooling yourself.
      - m_eiman 16y ago
        Few programmers ever work on something that'll still be in use 15 years later. Just have a look at http://en.wikipedia.org/wiki/Category:1995_software http://en.wikipedia.org/wiki/Category:1995_software (which isn't complete, obviously) - I don't think that even MS Office still contains much of what was in it in the '95 edition.

nocipher 16y ago

There is some truth in the article. Coding is easy. It's all the other aspects of software development that are difficult. I know that the biggest hurdle for any programming project I've ever been involved in is deciding what will be the different parts of the system and then how those parts will interact. Once I start writing code, I can program very quickly because I don't have to make hard decisions. Even so, a few thousand lines of a code a day is a bit much for anything non-trivial. To write that much code in a single day means that person must have done little else besides coding. Unless there was a period of about a week of design before that kind of coding, I'd expect the code to be rather kludgy because everything would be decided immediately. A few thousand lines of code, though, is definitely not something I'd consider average. A /small/ project that added a new feature to an existing system took about 30 hours for the initial version over a two week time period and about 800 lines of code. Granted, I don't know exactly where my programming abilities lie skill-wise, but I can't imagine someone being 30x or 40x more productive than that as you suggest. And maybe I'm just new around here, but if was going to argue for the Dunning-Kruger effect, I'd begin by arguing that I am clearly not suffering from the effect myself.

alexkearns 16y ago
We all suffer from the Dunning-Kruger effect, to varying degrees. I would never dream of arguing I don't suffer from it. I though do not go around claiming I know the truth about programming. I think that perhaps there are two types of programmer - those who like to spend most of the time researching, drawing diagrams and the such like, and the others who just get on with it. The suggestion of this article is that those who spend most of their time planning, rather than programming are somehow superior - my experience with developers has been the exact opposite.
ntoshev 16y ago
Don't worry about the lines of code you write, I'm pretty sure even Dr Norvig can't write 50 of these per day: http://norvig.com/spell-correct.html http://norvig.com/spell-correct.html

cubicle67 16y ago

to play devil's advocate: could it be that your comment is a perfect demonstration of the Dunning-Kruger effect?

loup-vaillant 16y ago
I think it's even simpler: he took it personally. He spends much of his time writing code (whatever that means), so he thinks the article is calling him lazy and ignorant and arrogant. (That's not even true, by the way. The article says "lazy or ignorant or arrogant".) Anyway, it triggered a classic defence mechanism: "what is calling me bad must be wrong". So he attacked the part of the article that offended him. In the process, he overshoot, and tried to discredit the whole article (by saying "complete bullshit"). (By the way, I only talk about the emotional process that likely triggered alexkearns' comment. That doesn't make it wrong. Nor right.)
- alexkearns 16y ago
  Nice of you to write with such conviction and assuredness about my psychology and motives. It is really amazingly impressive how you have become such an expert in me from a single comment I made. I bet your friends are in awe of your ability to deconstruct people with such blithe ease. But just to clarify a few points, I did not take the article as a personal attack on me or my programming philosophy. I just happen to think that in its key points the articles was completely wrong. I know of no programmer - good or otherwise - who only produces 12 or so useful lines of code, or spends 80% of his time thinking about coding, rather than actually doing it. Now, maybe my situation is not typical (but I bet it is not that atypical) but when someone claim's something to be true that in your experience is clearly not, it is one's duty to point that out. Also, anyone who claims to know the truth about programming - I would certainly not claim I do - has to be dead certain they are right before putting these claims to publication, and one has every right to ridicule them if they get it wrong. Claiming to know the truth is not something that should be taken lightly.
  - loup-vaillant 16y ago
    I said "likely triggered the comment". I know it's speculative. But frankly, your tone was so aggressive that it was difficult not to think it was personal. To the point, I think you and the author disagree on some definitions. Most likely "writing code" and "lines of code that make it to the final product". Plus the unspoken assumptions about the project (small or large, early or late…), but that has already been pointed out. I also don't think the article suggests that "a great programmer is someone who connects together bits of code created by others, rather than writing his own code". What It does suggest is that great programmers don't write their own code when they shouldn't. That when they do anyway, it's probably out of laziness (screw the searching, I prefer coding), or arrogance (I can do better anyway), or ignorance (what? It has been done before?). You are right to ridicule those who utter bullshit while claiming it's universal truths. But be careful not to leave holes in your rebuttal. That include angry tone and amplifying the opponent's words.