Some lesser-known truths about programming

My experience as a programmer  has taught me a few things about writing software. Here are some things that people might find surprising about writing code:

  • Averaging over the lifetime of the project, a programmer spends about 10-20% of his time writing code, and most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.
  • A good programmer is ten times more productive than an average programmer. A great programmer is 20-100 times more productive than the average. This is not an exaggeration – studies since the 1960’s have consistently shown this. A bad programmer is not just unproductive – he will not only not get any work done, but create a lot of work and headaches for others to fix.

    “A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates

  • Great programmers spend little of their time writing code – at least code that ends up in the final product. Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems. Great programmers are masters at recognizing and reusing common patterns. Good programmers are not afraid to refactor (rewrite) their code  to reach the ideal design. Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns, and so is very difficult to refactor. It’s easier to throw away bad code and start over than to change it.
  • Software development obeys the laws of entropy, like any other process. Continuous change leads to software rot, which erodes the conceptual integrity of the original design. Software rot is unavoidable, but programmers who fail to take conceptual integrity into consideration create software that rots so so fast that it becomes worthless before it is even completed. Entropic failure of conceptual integrity is probably the most common reason for software project failure. (The second most common reason is delivering something other than what the customer wanted.) Software rot slows down progress exponentially, so many projects face exploding timelines and budgets before they are mercifully killed.
  • A 2004 study found that most software projects (51%) will fail in a critical aspect, and 15% will fail totally. This is an improvement since 1994, when 31% failed.
  • Although most software is made by teams, it is not a democratic activity. Usually, just one person is responsible for the design, and the rest of the team fills in the details.
  • Programming is hard work. It’s an intense mental activity. Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams. Because the most important work is done away from a keyboard, software projects cannot be accelerated by spending more time in the office or adding more people to a project.

272 thoughts on “Some lesser-known truths about programming”

  1. David,
    This is so true and as you say, not well understood.
    Would you mind if we reproduced this (credited of course with a link back to your blog here) on our company blog?

  2. Pingback: Tweets that mention Some lesser-known truths about programming | Dot Mac --
  3. That’s pretty much how all workers operate.

    Gist of it is to hire people who will fit well into your plan, only hire when absolutely needed and make sure they have things to do that will challenge and reward them.

    Programmers are cool people, and can be awesome workers, but at the end of the day it’s the marketing that makes or breaks a company.

  4. Awesome list! It’s interesting to read about the 24/7 thinking addiction. Glad to hear it’s not just me. :]

  5. A great developer may be worth a lot more than an average one. Might also be 100 times as productive. Then why again is the great one getting paid the same salary as the average one?

    1. “Then why again is the great one getting paid the same salary as the average one”

      Because great programmer != great negotiator.

    2. Obviously the programmer you are thinking of is either not great or is somehow unable or unwilling to demonstrate his value above and beyond the average programmer.

    3. There are two separate skills: 1) programming skill 2) sales/negotiating skills. It is rare that one person has both. That’s why mediocre developers with great sales skills often take credit for work done by great developers and quickly get promoted. Another reason is that corporate culture assigns greater value to manager or team lead then to actual developer. Both reasons hard to fight, that’s why you need to find a place or person that appreciate actual design/programming skills.

  6. Thank you; good article. I recently worked (past tense) at a place that thought you could in fact speed software delivery by adding extra programmers and extra hours per programmer. Programming is not manual labor. Physical bodies can continue laboring long after the mind shuts off – whereas in programming, when the mind shuts off, you may code so ineffectively that you make negative progress. Bless the software managers that understand the pacing and rhythm of development.

    @Maintenance Man, that’s a good question. I think it’s partly due to a lack of understanding on the part of managers and companies. As soon as it’s easy to quantify the increased value of a good programmer vs a bad one, the salary gap will increase.

  7. maintenance man: because you cannot accurately measure “greatness”. how will you quantify how great someone really is? and when you get that magic number, will you use it as a factor to increase his pay? how will you measure improvements? what about different developers having different specialties? will you chance their pay based on their greatness level per day/per project?
    i see your point, but it is not realistic.

  8. yes… this 24/7 thinking happens with me too… I think programming job is not only for money you can only do and make your career in it if you are really interested….

  9. @MaintenanceMan
    Too many companies allow their software products to be managed by non-technical managers. They simply do not know who is good and who isn’t! They also don’t know good software from bad and evaluate performance based on speed of delivery most of all. They’re also acutely vulnerable to bafflegibber.

  10. Nice. Although I’m still a little unsure of the first two points. In the short run, I think a great programmer is not all that much more productive than an average one, but I definitely believe that if you factor in time and the amount of code that actually stays alive the difference is huge. Also, I could agree with the 10-12 lines per day, if you are talking averages. I know a lot of programmers who (without cutting and pasting) can produce thousands of lines in a very intense week, but who then slack shortly afterwards.


  11. I’m seeing that “good programmers are X-times more productive than bad programmers” meme, again, and again without a description of the shapes of the curve. This leaves people with misconceptions.

    Productivity is not a normal distribution, it’s a Rayleigh distribution. If good programmers are ten times better than bad programmers, the distribution will be such that good programmers are twice as good as average programmers, and average programmers are five times as good as bad programmers.

    The curve is skewed, and the median is above the mean. (Meaning that most programmers are better than average, as odd as that sounds.)

  12. I love reading something like this and then hear people talk about how this just proves how great they are at programming. No one ever seems to read and say, “Hmm … I wonder if I’m the guy that is a tenth as productive as good programmers?” On another note, although I agree with some generalizations, I think it is dangerous to put programmers in three categories: bad, good, and great. There is a lot of wiggle room where people don’t fit nicely in one of these categories. Some people are also good at some things and not at others. There are also people that have all the skills, but just don’t have experience yet. Everyone needs to make mistakes and learn from them, and that just takes some time.

  13. Except that average programmers are not just a multiple better than bad programmers. Somewhere just south of average, poor programmers contribute less than the increased communication overhead needed to include them on the team. A little below that, you have really poor programmers whose typical coding change makes the system worse and either requires time by alert developers to fix the problems they create or dramatically increases the risk of failure of the effort if it’s not detected in time.

    In my experience, the best programmers routinely achieve goals that average programmers don’t understand even when the result is later explained to them. In terms of pure productivity, the difference is something like 10-15x between the best and the simply good. I firmly believe that there is a transition to negative value that occurs well into “average” territory but which is only apparent to a few enlightened members of management.

  14. All great programmers start of as average programmers. Whilst almost all of what you say is accurate, it would be wise to remember the roots of many of those who went on to become great. The trick is to learn from your mistakes, and always ALWAYS refactor, until you cannot refactor anymore.

  15. Much of the content of this blog was originally posted in the classic THE MYTHICAL MAN MONTH, by Fredric Brooks. He was the guy that headed the IBM project to build the first modern operating system, OS/360, on IBM Mainframes in the 1960’s, so he clearly knew his stuff. He is convinced of the vast difference between the best and the average.

    Believe it or not, the reason why managers make more than programmers is well captured by the comic strip DILBERT. Though Dilbert is technically adept, he clearly does not understand the business world. He therefore needs the “adult supervision” of the pointy-haired boss. Admittedly, the boss is an idiot, with absolutely NO technical savvy; however, he does understand the business world, including the importance of marketing.

    1. Well, Edward, it seems that you do not read the Dilbert strip regularly nor thoroughly. Adams uses the PHB to do generally stupid things, including in several cases making decisions that show his stupidity with business matters.

      An example: the PHB cuts the marketing and advertising budget to 0 until their product sells more. (The upshot being that if you have no marketing or advertising, people will not know about the product, and hence, not buy any of it.)

  16. Pingback: Juice The Blog » Blog Archive » Some Lesser-Known Truths about Programming
  17. And one other thing. Programmers are paid for more than productivity, which is why productive programmers are not necessarily paid more than others. The technology is changing so fast that the guy who may be a mediocre user of a hot technology gets paid more than the best COBOL programmer in the world, simply because nobody cares much about COBOL any more.

  18. “Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems”

    Usually bad or lazy programmers unnecesarily start grabbing existing solutions to solve the most trivial problems, like including a logging framework just to write some text on a file or a javascript framework to make an ajax call. I have seen very simple projects turning into bloated frankenstains full of dependencies and side effects just because of this “don’t reinvent the wheel” moto.

  19. Actually, a great programmer never EVER writes code. A GREAT programmer tells other programmers how to do their job, never produces code (or anything of substance) and writes flame bait about how superior they are to all other programmers.

  20. I always feel like a slow coder. I know my output is high quality but the production rate feels low because I insist upon refactoring.

    Unlike most programmers I know, I document a lot, and do that as I program too. Always internal docs.

    It definitely works for me as a work pattern though. You get known for certain work characteristics and my employers have always allowed me to employ this method. I believe that they value the production characteristics of the results.

    If I worked for larger employers or larger teams of closely interacting programming personnel, I suspect I’d have to modify my work habits.

    One of my rules is that I’d rather write less code and have it be smarter and higher quality. Code reuse is one of the best ways of accomplishing this.

  21. You totally screwed it up by quoting Bill Gates.

    Linus Torvalds is a programmer, Richard Stallman is a programmer. They wrote and write code FOR YEARS. They disclosed their code and nobody is contesting it’s theirs. YOU are a programmer if you ever wrote something useful and shared it with others.

    Gates is an assclown. So is the tribal leader Shuttleworth. An unknown lad who writes a small code snippet and publishes it on github for free deserves more credit and respect.

    Software evolves because it is pushed by titans. Software evolves because nowadays there’s a whole community of benevolent programmers who do small contributions. Take the assclown’s name out of your article, he doesn’t deserve to be mentioned.

    1. Bill Gates was a programmer. eg. he wrote the Altair Basic (and still worked on the Microsoft Basic for MS-DOS, IIRC. Perhaps you’re confusing him with Steve Jobs who wasn’t a programmer at all.

  22. My helpful hint for the day: I have a waterproof notepad that I write my code on in the shower. It is a life (or idea) saver. Check out

  23. @Benemon – I couldn’t be more at odds with your statement. Great programmers are great the first time they write code, in comparison to others who are writing their first code. That is not to say they know all the ins and outs of an experienced programmer, but accumulated knowledge is not the differentiator of a great programmer. They “see things differently”.

    To put it another way, if experience is what makes someone “great” at something, then everyone who was taking up a new skill would perform equally in the beginning, but that’s not the case.

  24. Do not diss on COBOL. It is a great niche skill to have IMO, especially if you are somewhat young. There are millions of lines of COBOL code out there that need to be maintained because they are of such high use and importance to MANY companies. A great deal of the current COBOL ‘experts’ are getting ready to retire …

    So, if you know COBOL and you aren’t ready to retire…

  25. Sadly, many good and great programmers fail or leave because they are stuck with managers who don’t understand these truths.

  26. I couldn’t agree more with all of these, except the one about good programmers thinking about programming all day every day. I don’t think you should think about any one thing ALL the time. That’s mental tunnel vision.

  27. @Grant You’re making the same mistake though. It is some combination of talent and experience that makes one great at anything. There’s absolutely no reason to believe that great programmers were somehow better than average from the outset… they could have had breakthroughs throughout their journey. Likewise the most promising candidate could get lazy in a cush job or maybe lose interest in advancing their skills.

  28. “Continuous change leads to software rot, which erodes the conceptual integrity of the original design”

    The original design was only a dream. Good software grows into a trusted workhorse.

    The single biggest mistake you can make is to keep rewriting software over and over, because you’re sure the next design will finally be right.

  29. I would like to add a point to the article. In my personal experience, even your mood at the moment change the way you program temporarily. This means that if a programmer is in a chaotic environment, working under immense pressure or having family problems, it could affect the way he thinks and thus would be a bad programmer for a while.

  30. I agree with all of the points in this article. However, it is still hard for me to understand how one programmer can be 100x productive when compared to another programmer. I guess that I won’t be that productive as a web-designer in the same way someone with a background in databases won’t be as productive as me in writing compilers.

    1. It’s a matter of order of magnitude of difficulty, combined with re-usability and performance. Some problems you look at and you can see how to solve it and write the solution in say an hour. Other problems can not be solved or can not be solved efficiently or the vast majority of people don’t understand the math involved or even why the problem is so difficult, even if the final solution to the much more difficult problem ends up being about 100 lines of code, ie a comparable number to the length of the solution to the vastly easier problem.

      Consider the world of art, a rich patron wanted to hire the best artist to paint his portrait. Various painters show up and try to demonstrate their skill. The proverbial best painter shows up and draws a perfect circle on the floor free hand with a piece of chalk all in one go, one single perfect line. That anecdote is about Da Vinci or Michaelangelo but it is applicable to programming. One single perfect line is worth more than 100 average lines in coding and in art.

  31. I know I’m not a great programmer. I once had an interview with great programmers. They asked me to write C code on a black board while I was applying for a Python job. I was totally useless. I quickly realized I wasn’t playing in the same league. A few weeks later I joined an agile team doing pair programming. I couldn’t get any work done. While driving the session, the other guy whould quicky get fed up and take the keyboard from me. I got fired after 3 months.

    On the other hand, I’ve seen much worse than me and I often found myself teaching stuff to programmers worse than me. I use TDD and try to keep my code DRY, secure and reliable. I think my problem is that I’m not very smart. I like programming so I read a lot and I often try new techniques and languages so I have a pretty good knowledge, but I think my brain is not fast enough to compete with great programmers. I don’t think I’m the worst though because when I leave a company, people usually try to convince me to stay. I’m probably average. Do you know of any test that would help me to know where to stand? Are there any recommended techniques to improve?

    1. There’s this Programmer Competency Matrix:

      which is nice because it’s multidimentional, and gives you objectives to improve.

    2. @Alfred: try to read and share a lot. Read code, read books. Choose an open source project that you like, try understand it’s code and extend/fix it. Share your improvements with others and hear their opinions. Read books, SICP is a nice place to start.

  32. 24/7 .. ah, yes. The number of problems I have solved going home after throwing something in anger and frustration..

  33. @whattheh3ll – you may have read the same content here: – by the same author.

  34. “A programmer spends about 10-20% of his time writing code, and most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work”

    Beautiful. It seems to me programmers who are most productive spend most of their time agonizing over whether it would be worth investigating a better pattern, or use one they know will work. Knowing when to stop can be a serious challenge.

  35. Pingback: Digital Fabric » Programming Is Not What You Think It Is
  36. @Alfred: In my experience, software companies (esp larger ones) need many different kinds of programmers. The trick is to find your niche and figure out how you can best contribute.

    The software industry as a whole needs inventors, finishers, motivators, maintainers, … and also project managers and line managers who are (or at least have been) skilled enough at programming. Some people love working for years maintaining and improving a particular product; others wouldn’t be caught dead doing that, but want to innovate, prove a concept, and then move on.

    The trick for every company is to find the right mix, and dependable programmers who are Good Enough are extremely important. I have plenty of good war stories about brilliant programmers, but they are best told over beer…

  37. Very nice article. Programming isn’t similar to other jobs where amount of time spent = amount of work done. 24/7 is an absolutely right comment.

    Thanks for sharing.

  38. That was an awesome article actually. Very well written, and fully true. We have a core team of 4 dev/IT guys, and they deliver software solutions like a team of 20 average programmers. I fully agree with what you’ve written.

  39. Agreed it completely.
    Specially the last part “software projects cannot be accelerated by spending more time in the office”.
    I dont know why some software companies want to keep their employees in office 9-5 strictly!
    They should give them a nice working environment and programmers will do the rest.

  40. When I see that much enthusiastic agreement, it raises my suspicions. The majority is rarely right.

    And sure enough, when I look more closely at this, I see lots of problems covered up with sententious authority. I am glad to see that doctor doom caught one of them, but there are more.

    I will focus on only one, the point about it not being democratic. This is true, BUT: if you let only one person do all the design, you feed frustration on the rest of the team, and then what do you do if the one designer is hit by the proverbial bus? It is better to admit that the design process cannot be entirely democratic, but let the one designer bounce his ideas of other members of the team. This solves both problems by giving them a hand in the design also, and by distributing knowledge of the design among several people, so that if he is hit by a bus, he is replaceable without as much loss.

    For the same reason, it is important that that one designer know how to share with the team. Pick someone who is bright, but autocratic, and you will ruin the team and the project.

    Weinberger had an interesting correction to the article too, but he overestimates the PHB’s command of the business world. The real problem of modern day business is that the PHB who is technically ignorant is nearly as ignorant of the business world, too! That is WHY Scott Adams has the recurring line about ‘manager’ really coming from an ancient word for “mastodon dung”. That is WHY he reminds us of the managers so dumb, they didn’t even know how to use voicemail. He didn’t make that example up, either. It comes from real life.

    Nor is it really that new. The reasons such gross incompetence is tolerated in the overpaid management class of society was covered very well by Thorstein Veblen in his “The Theory of the Leisure Class”. If you really want to understand why managers are so destructive, why they will never admit that Fred Brooks was right, then read this book.

  41. The Standish Report cited in the 5th bullet point has been debunked; see

    A reason that great programmers are so productive and valuable is that they eliminate the need for large teams, dramatically reducing communication overhead and errors. Besides the attributes described above, great programmers effectively form and work in teams.

  42. “A programmer spends about 10-20% of his time writing code, and most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.”

    I agreed with this one. But most management and recruiters are clueless about this one.
    Case in point, once a recruiter asked me “How many % of your time is spent coding?”.
    It became obvious that he if I said, “20%”, I would not be considered for the position.
    Good programmers looks for elegant solution to a problem, let be using an existing library/framework or survey what others have done. The pros and cons.

  43. @Alfred – those sorts of tests/interviews are complete idiocy. When in real life are you ever going to be thrown a problem and told to “solve it in X minutes while we watch”???? That’s not what programming is about. If you need to go sit somewhere quiet, and/or alone, to think about what the problem really is before you start writing code then that says nothing negative about your ability as a programmer. In fact someone whose first reaction to being given a problem is to write code is likely to be a bad programmer from a number of perspectives. Somewhat offside, I bet the invention of cubicles reduced programmer productivity by a significant amount.

  44. @BK Lau: not sure where where those numbers come from but I know my long term productivity has been in the neighbourhood of 10-12 lines of documented and debugged code per hour, i.e. that’s the code that makes it into the product release.

  45. I learned a lot from this article. We constantly strive to hire the best programmers but sometimes fall short.

  46. Great developers visualize their solutions, the component couplings, and the “flows”. Some dynamically refactor code as they write… some refactor in their head. But all great programmers write code with a vision or goal. And all great programmers write their code anticpiating that other – less capable – programmers will use or maintain their code. Clarity, cohesion, coupling, and containment are the 4Cs.

  47. “Good programmers spend much of the other –>80%-90%80%-90%<– debugging code by randomly making changes and seeing if they work."

  48. Looks like my previous comment was not properly HTML escaped: “Good programmers spend much of the other 80%-90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 80%-90%åç debugging code by randomly making changes and seeing if they work.”

  49. A good programmer creates 20 times the amount of good code as an average one.

    The best of them spend much more time planning and designing, keeping Dijkstra’s fundamental rules clearly in front of them: programs consist only of primitive instruction sequences, loops and decision points, and every loop must have a variant that is guaranteed to signal an end state.

  50. Pingback: Lesser Known Programming Truths | Grokking Code
  51. So what happened to the concept of reuse in OOD and OOP? If the premise that productivity gains from OOD and OOP are substantially enabled by reuse, how productive are programmers who spend their time “thinking” about solving programming problems. Doesn’t the reuse tenet suggest that OOD and OOP require more system thinking about integrating components and optimizing performance as opposed to twiddling with new or available code modules? Computer systems analysis, design, programming and maintenance are primarily specialized technical skills deserving of props….however, looking at the stats provided by David, there is a huge upside potential for significantly better software and systems. Think of the wasted human and financial capital in those numbers! Should be unacceptable to any practitioners or technologists!

  52. Nice read, I especially liked the fact that doing thinks right doesn’t happen by chance, but with study, thought and experimentation to find the proper design. I’m a front-end developer, so this article helps me to understand a bit more about the discipline of programming.

  53. @Thomas “all great programmers write their code anticpiating that other – less capable – programmers will use or maintain their code”

    I think it is not necessary to worry about “lesser” programmers, it’s more like good/great programmers should be anticipating that they will have to maintain their own code. I used to startle some of the other programmers in one shop because they would come to me with a problem in a reasonably large piece of code I’d written (say 10-20K lines of C++) and after describing the symptoms I could close my eyes and recall the exact sequence of source statements responsible for the behaviour they were seeing and just write them out of the whiteboard.

    But that was from a project I was still actively working on at the time. I’ve also written programs with >100K lines of assembler and let me tell you that no matter how good you are if you don’t comment the source well then a year or two later you will be spending a lot of time thinking things like “what the heck was I doing that for?”

  54. Awesome article, Thank you so much. I always thought the same but nobody agreed with me. So, Thanks again for revealing the truth.

  55. Well this is stating each and every IT company suffering from outdated bad developers, or mainly programmers. They are writing bugs with some features instead of writing features that have some bugs. I always struggle from bad code, which make maintenance horrible, and no time to refactor and fixes are very dirty.

    Please every and each one of us developers lets think then write rather than write.

  56. If looking at the Standish reports from 1994 to 2009, you’ll discover that the Project Success Ratio went from 16% (1994) to 27% (1996) and have since then been average around ~30% with 31% in 2009. Yepp, that’s a doubling since 1994, but the doubling happened in the two years betwee -94 and -96. We really should be doing a whole lot better and hopefully new figures for 2010/2011 should improve as we’ve become better craftsmen and customers are more inclined to do agile projects.

  57. Yawn – yet another article on programmer back-patting, navel gazing and self congratulation. Folks we’re just programmers, big deal. Don’t get me wrong, I love being a programmer, but do we need to be continually congratulating and propping each other up with this kind of crap. I don’t see airline pilots, miners or train drivers posting this sort of “we’re special” drivel.

  58. Pingback: Programming Truths « ZelphyrBlog
  59. Most of the points have been made – why mention Bill Gates when you could have mentioned somebody who knew something about it all? The ideas are contained – and expanded on – in the excellent, if now quite old, ‘Mythical Man Month’.

    Ever wondered about the language used though? Why do M$ machines crash all the time? It’s not only lousy design, lousy project management, lousy conception and the rest, it’s also a bad use of language.

    Why don’t fly-by-wire aircraft crash daily, hourly, even? If they ran on M$, flying would be almost certainly suicide.

    It’s because they use Ada – allowing reliable coding.

    Also, if you say programmers produce 10-12 lines of code a day, why not use APL? That way you produce an entire usable program a day….

  60. Echoes of The Mythical Man Month by Frederick Brookes and The Cathedral and the Bazaar by Eric Raymond (so called halloween papers). I agree with most of the points above and in these works.

  61. I would honestly complete the story with a short idea (no offence intended to anyone)
    I have found in my humble 20+ yrs of programming for a few companies, that it’s always the guys with no degrees and diplomas and certifications, that produce the greatest results with the fewest lines, and the best code with the least work, while the others, the guys with the greater degrees, better diplomas, higher credentials, and more bootlicking produce the worst code, in the longest time alotted, and the most debugging-needed results…
    However, it’s always the former ones that get payed less, and the letter ones are with the highest salary.
    And until that doesn’t change… well, there will be no change in the world..

  62. I guess I’ve read too many articles like this in the last 30 years to care – I’m sure dimplomates in the ‘hard’ sciences consider us to be intellectual wannabes, so why not get over ourselves and try to do our jobs to the best of our ability. I’d also like for the language and platform ideologues to keep their nastiness to themselves, but that’s totally unrealistic.

  63. Pingback: » links for 2010-08-23 (Dhananjay Nene)
  64. Pingback: Programmers’ facts « rtCafe
  65. This is awesome. I like the part about good programmers coming up with the best in the showers and dreams. So true!

  66. Pingback: Some lesser-known truths about programming | Steven Palmer
  67. Lets continue the myth of the ninja programmer. You know the coder who sits in a black box considering the world. Then walks out writes 10 elegant lines of code that solves all problems a week under deadline. This is merely a retelling of the Eureka myth of the harder sciences (Newton ponders the world gets hit with an apple and suddenly understands the law of universal attraction).

    In both cases it virtually never happens (thou people often retrospectively decide it did). Scientific progress/coding is more often made by failures and tortured incremental progress than considered thoughts. It’s messy and non elegant and natural. But hey we all stand on the shoulders of giants. The next step is made by grasping in the dark. Yeah it’s nice to think and look around first. However often the looking just makes you try the same things as the next guy (which is why the comment about danger of qualifications is partly true at least).

    The Eureka myth has been very damaging to science and I am starting to see the concept of elegance in programming leading a similar path. Celebrate success even if ugly.

  68. Pingback: Programming
  69. All of the above views and opinions can be included in following snippet:

    printf(“My views are:);

    printf(“Above views and opinions are all true”);
    function B();

    printf(“Above views and opinions are all false”);
    function A();

  70. Interesting article. Thanks.

    I agree on the fact that programmers write most important code in the shower and dreams (and on the toilet as well, to be 100% honest ;-)), yet I don’t thing Good programmers have to think about their work 24/7. I think it’s exactly the opposite: when you are stuck on a problem, you can get lost in it if you concentrate on it continuously, without a rest. Than you have to go to the bathroom (urgently: you were so deep into the problem that you couldn’t even feel your own primary need, right? :-)) and than the solution pops up into your mind so clear and simple you feel a bit stupid to have lost all that time thinking about it. But we never learn the lesson, because when the next problem challenges us, we can’t avoid to plunge into it completely… until the toilet saves us! 🙂 Just a note: I’m not a Great programmer, but I know some who are and do exactly the same. Anyone else? 🙂

    Besides, I think the article misses some interesting points: does a programmer becomes Great, or it’s just DNA? Can a bad/average programmer be turned or turn himself into a Good/Great one? If yes, how?

  71. You do not born good or great programmer, you become one with time and study and hard work.
    At the beginning, everybody is a bad programmer. You can be bad and improve by working

  72. I think you computing environment does affect whether u become a great programmer or not. If you happen to work in a company thats been maintaining a 7 yr old code base thats been worked upon by like 5 generations of programmers with each coming with his own style. Now here productivity is measured based on workable code and how less time you use to achieve the expected product fix/feature.with little orientation on the history and workability of the product.little or incomplete documentation materials. But rather u are dumped with 104MB worth of ASP files to study in 1 week and start fixing bad codes. once code is written poorly from the on set it gets expensive to change and u the newbie programmer with the great mind, management does have the patient to understand that you are thinking conceptually in your head. they expect you the magician to churn out codes instantly that fix and do stuff in the product. Without this sorcery abilities u will get fired.
    This is what happens in my environment and my current company. So for now to feed u just got to churn out code. And lastly its easier to structure ur stuff for new products or revised products than to maintain a single non revisable code base.

  73. my best ideas, and problem solving normaly happen while on the toliet, i dont know why but it seems to happen that way, interesting article, btw

  74. Pingback: Le verità meno conosciute della programmazione | Guido Chiappucci's Blog
  75. Pingback: Alcune cose sorprendenti dello scrivere codice… « pensieri a margine
  76. Pingback: Elsewhere, on August 25th - Once a nomad, always a nomad
  77. Pingback: 사람들이 잘 모르는 프로그래밍에 관한 진실 | aronze
  78. Doubting Thomas :Lets continue the myth of the ninja programmer. You know the coder who sits in a black box considering the world. Then walks out writes 10 elegant lines of code that solves all problems a week under deadline. This is merely a retelling of the Eureka myth of the harder sciences (Newton ponders the world gets hit with an apple and suddenly understands the law of universal attraction).
    In both cases it virtually never happens (thou people often retrospectively decide it did). Scientific progress/coding is more often made by failures and tortured incremental progress than considered thoughts. It’s messy and non elegant and natural. But hey we all stand on the shoulders of giants. The next step is made by grasping in the dark. Yeah it’s nice to think and look around first. However often the looking just makes you try the same things as the next guy (which is why the comment about danger of qualifications is partly true at least).
    The Eureka myth has been very damaging to science and I am starting to see the concept of elegance in programming leading a similar path. Celebrate success even if ugly.

    It’s a mixture of both, isn’t it? 9 parts perspiration to 1 part inspiration. Yes there is a lot of tosh talked about the methods of scientific progress, software development being somewhere in that area, but in the end the people who are attracted to that sort of thinking and working are mainly there because of a love of the subject. Daft depictions by our creative colleagues in the media industries, and dumb comments by ourselves, in the end are of little importance.

  79. Pingback: Difference between a programmer, a good programmer, a great programmer « rtCafe
  80. @Jim McNeill
    To carry it a bit further, most programming isn’t scientific discovery. We’re being asked to solve, if not the same problems over and over, certainly the same problems that others have addressed at some point.

    A good programmer knows they are standing on the sholders of giants and asks what did you do to solve this problem. A bad programmer thinks they are in the valley alone. They try to brute force their way through the wall of ignorance and up the summit of knowledge. It is almost always easier to look up and ask where the path is to the mountain top.

    Also, as a general notice to all programmers everywhere, No matter how concise and elegant you think your code is (and maybe especially if you do) – Comment the code….

  81. Yeh thats great, means I am a good programmer, I code less and concentrate much on architecture, best route (login), code minimization and fine tuning the findings and then i code. Unfortunate is my previous company was not liking this attitude, left that and started my own.

  82. I must say I don’t really agree with most of what you state. Basically, we’re still work-horses. People expect us to churn out code. You might argue that programming only 20% of your day leads to the best code, but how will your project manager react when you tell him that after 3 months you’re “almost ready to start coding”? You assume here that the best code is also written quickly, which is rather debatable (and probably flat out untrue).

    By the way, but did you know you’re actually contradicting yourself?

    “Good programmers are not afraid to refactor (rewrite) their code constantly to reach the ideal design.”

    “Continuous change leads to software rot, which erodes the conceptual integrity of the original design.”

    Please, clarify this for me… Am I a good programmer because I stick to what I designed, or am I a good programmer because I keep changing my design. I’m getting confused here.

  83. wke :I must say I don’t really agree with most of what you state. Basically, we’re still work-horses. People expect us to churn out code. You might argue that programming only 20% of your day leads to the best code, but how will your project manager react when you tell him that after 3 months you’re “almost ready to start coding”? You assume here that the best code is also written quickly, which is rather debatable (and probably flat out untrue).By the way, but did you know you’re actually contradicting yourself?“Good programmers are not afraid to refactor (rewrite) their code constantly to reach the ideal design.”“Continuous change leads to software rot, which erodes the conceptual integrity of the original design.”Please, clarify this for me… Am I a good programmer because I stick to what I designed, or am I a good programmer because I keep changing my design. I’m getting confused here.

    It can seem confusing at first glance but it adressed to different points things: To REFACTOR a piece of code means to rewrite it from scratch when needed. CONTINUOUS CHANGE on the seconds means that you patch a bug with a little and innocent IF and so forth instead of checking the design. Basically it is “REWRITE” is different than “PATCH”

  84. @ fustbariclation
    If you test your environment, and your code well enough, it will be reliable enough to fly planes. This is just pointless microsoft bashing. Fair enough defense use Ada, but I’ve seen massive rail projects running on embedded windows. Windows is what it is because it supports so many people with so many tasks.

    On a general note, most of the problems cited here stem from management understanding of coding. If more bosses understood programming properly, devs wouldn’t be shoved from job to job every 5 minutes and given a third of the time they need to do a ‘proper’ job.

    Take into account also that not all software is supposed to last for centuries. Does the same apply then? (No.)

  85. Today thus far

    200 lines of code.
    4 cups of coffee.
    A meeting.
    Read this blog.
    Another meeting.

    Nothing working.

    I really suck at programming but I do love it so….

    But I can attest to being extremely tenacous. That being said, I wouldn’t hire me.

  86. As the old story about the comment written on the rejected thesis runs, “There is much here that is true and original. However, what is true is not original, and what is original is not true.”

    Software people — yes, I’m one — seldom come candidly to grips with the most important of all their characteristics: their human fallibility. Everyone makes mistakes, even the brightest of us. But we design and build software systems as if that weren’t so. Other sorts of engineers don’t do that. Other sorts of engineers have much better reputations than we have. Coincidence? I think not.

    Good software should exhibit certain user-visible characteristics: simplicity of use, strong focus on its principal functions, few or no “gingerbread” features, and stability in operation. Its design should emphasize those virtues, and should at least contemplate testability. Its implementation — here’s where programming as most understand it, and the author of the article mostly speaks of it, comes in — should:
    — cleave tightly to the design;
    — be maximally legible;
    — embed no “tricks;”
    — strive for simplicity in the Einsteinian sense (“Everything should be as simple as possible, but no simpler.”);

    Software that follows those design guidelines is easily tested; software that follows those implementation guidelines is easily debugged and maintained. Those properties minimize the importance of our mistakes, by making them easier to find and fix. And he who creates software of that sort has reason to be proud, both of it and of himself.

    The rest of us? We’re working on it.

  87. @wke

    That is not a contradiction. Refactoring is like choosing the least of all possible evils. Even though you may be fixing some flaw by refactoring you are most likely introducing another flaw.

    I agree with many of the other posts about this being another post trying to give more meaning to programming than it necessarily requires. Though my background is largely mathematical and honestly I see programming only as a tool by which to try many things I would not be able to do by hand, hence I may be biased.

  88. Good article.
    Most of these seems to make sence. It depends where you work, how you work and what do you use.
    How about improvements, I mean lots of cood short codes are derived from long bulk codes. In most cases you make working prototype first then optimize and debug an improve it. I just don’t think that I could think 90 minutes and then write a perfect code in 10 mintes, it just doesn’t sound realistic to me. (If my manager sees doing nothing I’ll be in trouble…;) )

  89. @Kev

    That’s because airline pilots and everybody else does not think to do their job and their job does not involve “pure thought stuff”…

  90. Programming is like jazz improvisation. One must attain a level of concentration, visualization, intuition and direction that can not be sustained more than a few hours at a time. Most code written after the first 3-4 hours of your work day is crap and needs to be reworked the following day. My take on programmer productivity: 4 hour days (2 X 2 hours) plus mandatory mild cardio workout and relaxation to oxygenate the brain and flush out accumulated mental fatigue. Coffee and energy drinks and multitasking should be banned. Just as drugs do not make a better sax solo, caffeine does not make better software.

  91. The article should not be taken literally. But conceptually the writer makes a very good point. Much of what occurs in code happens in your head. Programmers these days do not prototype their work. They start writing and hope it does what they want it to do. Being effective it not that important, as long as it runs is the attitude.
    Some want to add the new tricks they learned from some internet site, or a book they just read – regardless if that is the best way to implement the code or not.

    Just because you know how to write code does not make you a programmer. Sure you can learn it, but if you don’t take the time to learn how to write meaningful code that can withstand the test of time and poorly thought modifications, then what are you really doing?

    I do have one problem with the article, sometimes projects don’t meet expectations because people do not properly level set. Just because you can do something in code, does not mean you SHOULD do it. But that goes back to the thought process.

  92. A builder spends about 10-20% of his time building walls, and most builders put about 10-12 lines of blocks per day that goes into the final building.
    Good builders spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad builders spend much of that 90% checking they’re walls by randomly making changes and seeing if they do not fail if you push them.

    Bad programmers think they are software architects. Good programmers know they are not.
    Like in any other profession you can be a master in one thing and usually not so good in others, most of the building architects fail to build a straight wall.

    Good programmers make there best to learn about the tools and ideas they been given by the architects and the technology leader of the project. The uses tools like source control server, wiki, unit testing (at the minimum needed) in order to code with confidence.
    But the most important is, good programmers have REAL AQ testers and some one to overview they’re code .
    Any average team that follow this five rules will produce better software then any masters teams that will not.

    Conclusion: Good software do not depend on a programmers it depend on the customer and if he is wiling to pay for a good team with all the needed members.

    Well, they don’t as long as no one will die if the application crash.

  93. I have been known to write 1200 lines of code a day… multiple days in a row… otherwise I think the article is right on.

    Writing a ton of code doesn’t mean you’re lazy, on the contrary – if there is a need – you write.. if you’re good you can write a 1000 lines with minimal debugging issues.

  94. 10-12 lines code per day? WTF? Do you have a job left? I don’t consider myself a genius nor an complete idiot either and I write about anything between 200 to 1000 lines of code per day depending on the task in hand.

  95. Good programmers don’t spend their time writing about what they think good programmers do.

    Yes, I realize the recursive irony of this statement.

  96. Nice article.. makes tons of sense. However , I am sure professional life would have taught us that transition from bad-to-avg-to-good programmer is also a graduation which requires lot of hard work, and number of trials and errors and time ( and yes, you end up writing bad code and then painfully learn from the time spent on debugging..). Sure, there maybe programmers who are born to write code but majority I would say graduate with time – if they stil continue to be in the domain. My experience tells me that good programmers either get promoted up that they stop programming or burn out due to work load from other bad programmers..

  97. btw: It doesn’t matter 10 lines of code or 10000 lines of code you write it is always keep in mind

    Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ~Martin Fowler

  98. Bravo David!

    I have always maintained that top-down thinking is way better than bottom-up coding.

    I disagree with the previous commenter who disputed that lessor folk will be obliged to maintain the code, although if you’re truly great, maintenance will not be an issue.

    On a not totally disconnected point, I always feel that if a “User Guide” is required, I’ve failed.

    I once asked a colleague (who could lecture on SDLC in a world-class capacity) what is project management other than identifying and making happen the activities required that arise from the need to recover from fcuk-ups – he said “nothing – that’s about it”.

    “Requirements Document” – a mythical entity that, despite the title, will never fulfill the overall objective because no-one actually knows the full extent of what’s needed now, let alone that which will become apparent during the course of development. As for that which becomes apparent in the future – well … take a guess.

    “Needs Analysis” – another mythical thing that will never see the light of day in the absence of a Pratchett-esque “wrangler” who asks the awkward questions that a five year-old might, and makes the observations that only someone with mild to serious OCD would feel compelled to express – “You can’t nail a leak, Prime Minister – you just get a bigger leak”.

    Not failing to think – and executing the imperitives arising from thinking – is the key to a successful implementation. Period.

    Oh, and it helps a lot if you can quickly understand the Client’s business way better than they do … really fast, and with an eye on what they are going to work out they want/need in two years time.

    As for the metrics expressed – well, I’ve never had the luxury of knowing how many lines of code is going to be required before I knew how many hours away the completion point was required to be, so it’s never been important … trite, I know, but true nevertheless.


  99. You get a 10 out of 10!

    I have been developing software now for over 25 years and seen a lot of changes during my course. But one thing has always remained… bad programmers!

    It has been my experience that the cultivation of good or bad programmers has always rested with management.

    Good programmers come from management laying out solid development processes and holding everyone accountable.

    Bad programmers come from management laying out a policy of “get it done no matter what”.

    With that said I always believe that failure is from the top down…


  100. From Mil-Std-2167 to bringing the Customer on board. Standards and Specs don’t do it – being able to adapt to a customer’s constantly changing requirements, and stay within the budget and time line – does. You may think the latter is impossible – yes – but easier if you have the customer on board.

  101. Many good points, but I’ve seen an interesting pattern concerning this one: ” Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems.” … Especially with RoR, the developers will take “existing solutions” to different but similar problems, and call it done. It also takes a bad programmer to be incapable of producing a solution but instead to rely entirely on the community. Combining a bunch of gems or plugins, then wrestling the customer into accepting functionality that doesn’t match their spec, and trying to sell what amounts to a Frankenstein of parts, is a VERY negative extreme. Arrogance is bad, but confidence is not. Some of us know a bad solution when we see one, when to reuse, when to rewrite, and when to say: “that cannot be done.”

    You were not specific enough on that aspect. I hand n00bies code snippets daily because they are searching for “existing solutions to old problems” … they certainly aren’t “great programmers”. I was like them a LONG time ago, and have some compassion and enjoy helping. I just had to explain to one of these “great programmers” yesterday what a unix timestamp is.

    Perhaps you should have changed: “find existing solutions to old problems” to “their minds themselves are libraries full of existing solutions to old problems or the places to find them”? Modular code is awesome, re-usability is elegance, but RoR type patchwork coding can quickly turn into Frankenstein which is neither awesome, nor elegant. A Master Programmer knows the difference.

    Take this comment box, that pretends to be AJAX, but spirals forever on submit in Chrome. I know you are using Word Press, I use it too, but whichever comment plugin your using is apparently not as reliable as the default. At least not in Chrome. Gonna try to post in Firefox instead.

  102. Ah hell, now I look like a fool for posting twice, but it’s because of the bad AJAX in this page, you look like a fool writing about good programming and having bad code on the page, and we both know that it’s really because you reused something that doesn’t really work very well. :- At least Word Press has a bazzillion other plugins you can TRY you good “programmer” you. Maybe one of them will work all the time instead of just some of the time? Get my point? The ability to hunt down and reuse something is often lazy in itself and an example of a lack of skillz not evidence of them. Just sayin.

  103. Was just dying to see what this did in IE… “Error on page”, now to click Submit and see if it works… I would start firebug up and analyze the problem, but I’ve just now realized I’m the user just now. :-

  104. While the number of lines of code written per day may stay fairly constant, the amount of work done by a line of code goes up with higher level languages. 10 lines of C code does more than 10 lines of assembly. 10 lines of C# does more than 10 lines of C code. Thus productivity grows as the amount of work accomplished by a line of code increases with higher level languages. Also, one line of code today might call a library that does the work of 10,000 lines from twenty years ago. Kurtzweil estimates that the productivity of programmers doubles about every 7 years due to these and other effects. I know I get more real work done every day than I did twenty years ago. So it is not all bad news.

    I disagree with a lot of this post, but I do agree that good programmers are WAY better than bad programmers.

  105. I laid off a programmer (who was getting paid $140,000.00/year) for reasons to include he did not know how to redirect a program’s output into a file – his complaint was the stdout kept scrolling off the screen and he couldn’t read it. His code fell into the category of throw it away and rewrite. Another one would no let people look at his code because everyone who did would rewrite. After he was gone, we unlocked his directories, looked at his code, and rewrote it, in a fraction of the time he was taking.

    However, both of the aforementioned gentlemen despite being bad programmers, still used some of the “great programmer” techniques. For example, they both practiced code reuse extensively, though I cannot imagine how they would program without being able to cut-n-paste….

  106. Pingback: Linkdump 8-26-2010 | Jeremy Kahn's Dev Blog
  107. I first programmed in 1965 on a Burroughs mainframe, 9.6k memory and no operating system, in machine code and assembler. I’d certainly agree that the amount of ‘work’ done by a line of code does increase the more powerful the language (and supporting operating systems/environments) , as I have lived through their development.

    But leaving languages aside, the relative productivity of the programmers hasn’t changed over the years. Still have a top 5% you’d pick for the tough/critical jobs with a progression down the ranks. But given a large enough organisation, there are usually suitable tasks for most levels of programmers. Excepting those who would really be better of in an different career path.

    45 years on, after being side tracked into business analysis, management and design, finally back to programming, my first love.

  108. @RussTheMan
    I strongly agree ! Let “software engineering” practices (if any) be told by people writing code really… in other words, come back to real world. Practices are means, thinking and competence are the value. I only would add, as for great people, “be humble” and “listen to colleagues”, good may also be around you…

  109. I disagree. EG The best greatest most experienced ninja embedded systems programmer would, if required to write a java database web interface be classed a ‘bad and unproductive’ programmer.

  110. Great post. I especially like the points on entropics. It is a real challenge getting one of my clients to understand their software (previously written by others) is dead and unmaintainable. Now I have some better sound bites. Thanks!

  111. I have only read the first few sentences of this article and couldn’t read beyond the sentence: “…….A programmer spends about 10-20% of his time writing code…..” The word I can’t get past “HIS”. I’m sure this is a very good article and the title definitely caught my attention and I will finish reading it. But please, for anyone reading my comment, especially authors, please remember there are female programmers out here too. Maybe I’m being overly PC but I see this a lot. Thanks.

    1. The book is called the “Mythical Man Month”, it’s actually an essay, but I’m sure you wouldn’t want to read it because of the title. 😀

  112. I believe the best programmer is a lazy programmer (LP), as opposed to a lazya$$ programmer (LAP).
    A LP doesn’t want to ever come back and do the same thing again.
    A LAP doesn’t think about next week.
    A LP reuses technology that is available to perform the job at hand.
    A LAP cuts and pastes code.
    A LP comments their code cuz they know they, or some other poor schmuck will be back someday.
    A LAP could care less about how hard it is to understand a piece of code.
    A LP bothers to organize existing code into a meaningful structure with recognizable patterns.
    A LAP just adds another nested conditional expression.
    A LP writes documentation to remember why the code was designed the way it was.
    A LAP just sends an email saying ‘Done’.
    A LP has plenty of time to listen to good code singing on it’s way thru the machine.
    A LAP has plenty of time to point out why it’s somebody elses problem that the damn code don’t work.

    Two Rules: Play nice, do your freekin job.

    nuff said

  113. @RussTheMan

    One point about the user guide… in my days of gathering user requirements, I always found that if I wrote the user guide before I started my mental design, I had fewer changes to make during coding AND in the end, my programs really didn’t need a user guide.

  114. If you liked this article, you’ll appreciate “The Mythical Man-Month” by Fred Brooks. A great book with lots of software development wisdom and lore. See a synopsis on Wikipedia.

  115. I wholeheartedly agree with all of these points. Clarity of mind is the hallmark of a great programmer, in my opinion.

    For a great programmer, the act of programming is almost ancillary to the most important thing: the thought process that brings one to a clear picture. Once the process is laid out in the mind, actual programming it is rudimentary.

  116. Pingback: re: some lesser-known truths about programming — web developer & system programmer — coder . cl
  117. @ Attila
    Attila, Amen!
    Here’s one of my stories: My Bachelors degree was in Psych and Education. I taught myself programming starting with Paradox in 1990 and by 1995, had reached Delphi with SQL and the BDE.

    In 1998, I went to an interview at a phone company and the other guy with a computing degree and a better “corporate look” in his suit got the job. I took a three week vacation to Paris and other favorite places of mine. Five months later, my agent called me about the same phone company. The other guy had left after a fight with a female co-worker, and had not completed even the first project. It had an graphically elaborate first screen, though. The assistant manager had apparently liked him and she helped him design the screens. She knew Assembler.

    I began on Monday, got permission to start programming the project from scratch, and finished it in _three_weeks_ without screen design help from the assistant manager. It was a pretty straight-forward database application written in Delphi on Windows to display a lot of Unix data collected from telephone switches. The user and manager loved it. They kept me on and renewed my contract two more times, for a total of one and a half years, until in 2000, all the contracts evaporated with the new U.S. Republican Government’s blessing of deregulation. All future contracts were sent to Russia and India for 10% of the normal salary.

    It’s a wonder anything gets done at all!

  118. The most elegant solutions will always be the simplest ones. You don’t have to write 10.000 lines of code to make it “elegant”, if you can get the same job done with 25 lines of code or a good iteration/loop.
    So the amount of time spent on thinking about the program, in my opinion, is irrelevant, if it “just comes to you” how to write it, it’s like it’s in your blood. You are the damn code 🙂

  119. Pingback: “debugging hell” – running code over and over, making random changes and seeing if they worked – HAHA! |
  120. @Laura Hi Laura, I respect your femininity, wanna have lunch? Anyways, Just one thing, does anyone find that programming is taxing, on your personality? When I was a kid, I loved coding and I couldn’t figure out why nobody seemed interested in the amazing discoveries I was making in my little world on a day to day basis, I learned assembler (Intel, AT&T sucks) because that was badass in IMHO then learned C/C++/Java/blablabla Anyway somewhere through learning all this stuff I realised that I was a nerd, I didn’t look like a nerd but I was. So I sought a little ballance. Ballance is a two sided thing, the geniuses I know (I know two) don’t have balance, like the article says they sleep and dream of solutions to their problems (as I used to) and thats what makes them brillient, total dedication. I have to force my mind to not constantly run computations in the background (if I have a problem, then halfway through the day a solution will pop into my mind and I’ll know that I was thinking about it the whole time) and because of this I’ll never be truely great. I’m holding back. But I’m ok with that, thats my choice, I have a 148 IQ and that should be enough for any employer. My question is: do any of you feel like me, like maybe your coding is taking a toll on your life, your time for living?
    PS: here’s a link to using Direct3D 9 with C# and Visual Studio, it’s a beginners 3D tutorial with cool part on bump mapping and world creation. Hard to resist, you know you wanna make some 3D shit 😉

  121. Pingback: Good programmers | Franklin Andrade's Blog
  122. Pingback: Code Iteratively » Lesser-known Truths about Programming
  123. In 30+ years of programming, designing and systems architecture I’ve met exactly 2 people who were great programmers.

    They are extremely rare indeed.

  124. I love it when someone puts something this critical and essential into such simple language. It means I can point my non technical friends here and they can start to “get it”. As far as my peers go, they can keep hearing this from me in a more technical fashion.

    The only thing I do not completely agree with is the phrase, “find existing solutions to old problems”. I see my peers grab open source projects and try to get them to work for what they want; they spend days, eventually either giving up or settling for some hacky solution to make the open source “existing solution” work properly.

    I always check for an “existing solution”, but I refuse to spend more than 5% of the time it would take me to code a solution myself, looking for an “existing solution”. And I refuse to spend more than 10% of the time it would take me to code a solution myself, trying to implement some pre-existing solution.

    Happy Coding!

  125. Pingback: 一些鲜为人知的编程事实 | Let the killing begin
  126. I think that research is about changing randomly code and checking if it is working, cause Ya know, it wouldn’t be called research if we would know what are we doing.

  127. Agree 100%! That’s why I heard some star programmers gets paid $1 million salary at silicon valley. It’s very much like professional sports, one man can make or break the team. I left most of my previous jobs because I cannot stand the entropic failure of spaghetti code written by some supposedly “experienced” programmers. Or some managers who think adding programmers to a project won’t slow down it even further. For me if the code is not beautiful, then it’s not worthy.

  128. Pingback: Pro.Charm » 一些鲜为人知的编程事实
  129. Good programmers write unit tests as they code. They rely on their unit tests to guide the implementation of the design and leverage them to minimize code rot and bugs. Bad programmers see unit tests as a waste of time. They are more than just less-productive, they waste everyone else’s time by writing code full of trivial defects and is near to impossible to change/refactor (due to lack of unit tests). Bad programmers fear their own code since deep down inside, they know how brittlely/poorly it was designed and implemented.

    I need to stop thinking about this, since this has hit a bit too close to home with what I have to deal with.

    1. Technically I think you’re supposed to write the unit tests before you write the actual methods, run the unit tests on stubs and see the tests fail as expected.

  130. Pingback: 转:一些鲜为人知的编程事实 « 岁月流转,情怀依旧……
  131. Pingback: 一些鲜为人知的编程事实-转载 « MrZhang
  132. Pingback: 一些鲜为人知的编程事实 | 旅途博客
  133. Lots of truth here, although I think that

    “Most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level” and “A great programmer is 20-100 times more productive than the average.”

    are somewhat contradictory. You can hardly be 100 times more productive that an average programmer without writing significantly more lines, no matter how expressive code you write.

  134. Pingback: > 关于-程序员 | Mhycoe>>flash|flex|as3.0|ria|air|webgame
  135. “Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams. ”

    I thought it was just me, but I have solved some very complex programming in the shower. I wonder why that is?

  136. @ CJ

    We have one programmer here who does unit tests… since his first day. But, after a few weeks he stopped. Why? we’ve got deadlines to meet.

    Like, how do we do TDD/unit testing if the business rule(s) to code changes frequently?

    For our personal projects who does not have strict deadlines, yes we do. But as an employee, we are paid around 90% producing, and the remaining is what’s left for testing.

  137. Pingback: Programmering som sunn livsstil
  138. Very very True, and a programmer can know it better then anyone.

    Except 1 point “most programmers write about 10-12 lines of code per day that goes into the final product”, it all depends on what you are developing, if its a R & D or highly performance related then yes. As of me when i have something new to develop or a big change I code for almost first 3-4 hours in my day without even looking at the end result( just visualizing the end result in the mind), its only in the last 1 hour of my work that i run my code and fill in the gaps if any

    “Is anything worth thinking about 24/7?”
    90% of the time never. but sometime when we have something very complicated on hand yes we do, infact most of the solution to such problem come to mind when we are away from desk

    Lolz, I can only name by Delivery manager in that category.
    Seems like ur company must have made drinking elgal for ya 🙂

  139. @ Kelly
    The work done by the code is directly related to the design of the code. A “line” of code is not an instruction, but a complex construct, even in assembly. If you add macros, use libraries, and so on, assembly can be very powerful as well.

    The language is just one of the obstacles you have in the path to generate a program. Each language has strengths and weaknesses. C is great for some things, PASCAL for others, Lisp or small talk for still others. Choosing a language is part of the design process. Using C or PASCAL to process matrix math code is a poor choice while Fortran or APL is better in that area. Writing reports in APL is miserable (unless you have precreated some good libraries) so COBOL, SNOBOL or JAVA might be better for that. Managing large quantities of data might be better done in a database, or possibly (for somewhat smaller datasets) a spreadsheet.

    So the choice of platform will make a difference as well as understanding the requirements, the necessary interface and the context of the data.

    I’ve been programming for many years, yet every day I learn something new, from modern memory management to the different ways data can be represented to the implementation of a more lively interface with 3d or mechanical feedback.

    I don’t remember who said it, but the only constant is the rate of change. FAST!!

  140. Pingback: 一些鲜为人知的编程事实 [zz] | 程序员的信仰
  141. This is no doubt true for some cases, I currently have a couple of the bad programmers working for me, but they have there place! The code is not amazing, but it works, and it makes money. In your perfect world we all have 90% of our day to sit on our asses reading documents explaining things you should just find out for yourself, in the real world we have to make money and you do that by writing code. People who write articles, and papers and examples for you to read learn by doing. They sit there coding 90% of the time, then they take the bits that work well and use them, and bin the rest.

    Plus, you’re talking about application development, web development is a whole other ballgame. Try sitting reading w3c documents for 7 hours a day and see how fast you get fired.

  142. Pingback: 一些鲜为人知的编程真相 | Jinhai Lin
  143. Pingback: My findings (weekly) « My World
  144. Good programmers spend their time developing software and creating solutions for customers and stakeholders. Bad programmers write articles about “bad programmers” using spaghetti PHP code written by bad programmers. 😛

    foreach (qw{wordpress joomla drupal}) {
    print “${_} sucks!n”;

  145. Nice. I’ve always been aware of the content of this great book, but have been to cheap to buy it and read it in it’s entirety.

    Also, great posts, I whole heartedly agree with most of the posts. And yes, I do make some great connections after a few brews (google xkcd ballmer peak, it’s true to and a great lol) and I do make great connections in the shower, or those few moments between when the alarm clock tells me to wake up and my body actually acknowledges it. But I think that explains the complexity of what we are dealing with. If I’m just thrown a problem and need to solve it immediately (something business things I can do with enough overtime) I put in more time re-writing all the damage I have done. If given a night to sleep on the problem, completely comprehend it, let my brain stick each piece in the right spot and wait for natural processes to sort it out, I typically end up with the best, most concise and scalable code and I love it when plans come together like that (yeah, a bit of a re-work from my childhood heroes on the A-Team, please don’t hate me for that.)
    Also, I don’t think there are terrible programmers out there. There are just many that are inexperienced or come to the wrong conclusion because most college B.S. degrees are just that. I have met many programmers that were faster than me and had a higher level of quality… if I diagrammed or documented exactly what they should write, expalined what control and data structures to use, how to organize the code, etc.. The big failing is that given a set of requirements and having to start from scratch, they do not have the first idea how to proceed. I guess I’m lucky in the fact that I started writing code at 8 and was struggling with what I would later learn were the “classic” problems described by Knuth and all at a young age. Most 4 year college programs do not give enough exposure to programming to understand the basics, let alone where the problems inherant to any program design truly start. That can only be arrived at through experience and a lot of frustration.
    I think the problem has two tails, one is managements convuluted misunderstanding of what we do, and another is to tear into less experienced programmers instead of bringing them up to a higher level through interaction, good discussion, example, and sometimes hard learned lessons. It’s not that mistakes were made, the important thing is that do we understand those mistakes enough so we will not repeat them.
    I see these problems rise up daily at work, but that doesn’t mean management is too stupid to learn from these mistakes. The problem is sometimes the corporate environment is to rigid to yield for this. There was a hilarious article (or joke) on delicious that I wish I bookmarked, but it is so true. I walked into a company that was Waterfall over a year ago, and since I have been there the scope and level of detail desired quickly outpaced what was the norm there, which was simply adding to existing functionality. After a year of working as Sr Dev on projects with scope much larger than the company had dealt with since the sites first launch (which was actually written by external consultants with no impact internally) that had moving requirements (60 re-writes on my last project after “development started”, which made the project one month overdue (2 months if we didn’t pull epic overtime) in a lessons learned exercise the business didn’t fault us and agreed to try a more agile model.
    Now I am on a new, experimental team doing agile with short iterations, small teams, daily scrums, fast turn around. Almost there. This is why I wish I bookmarked that delicious link, because it made me laugh because this situation is the same. For all the agile talk going around, they still won’t give up on the basics of waterfall. So right now I feel my projects are at a higher risk than either. I go through a fast 15 day agile cycle, yet still have QA come in on day ten to start whining that something is 2px off in firefox and BAT at day 15 (the day I am supposed to go live). In the last BAT cycle, they realized they gave my team the wrong requirements, forcing a week long re-write which pushed the next development piece up by a week, and who looks like the idiot here. Me I guess, but it’s not really that bad. Any decent business wants improvement, and if you can explain it and quantify it in any measurable metric at all, you will find people willing to listen and learn. That’s another complaint I constantly hear, about how the business just doesn’t get it. But they get numbers, they get results. Coding is an experiment in a lot of ways, but the process for doing that is the same. We’ll never find a one size fits all solution, but we can find ways to recognize what kind of app we are creating, pick the best process, guide business and show them quantifiable results, and help raise the level of less experienced programmers that are involved in the process. Win-Win.

  146. Pingback: Characteristics of Great Programmers | Thought Clusters
  147. Oh man, this is so true, I thought I was one of the few (if not the only one) that spent an hour, if not longer, thinking about coding in the shower. I’ve been really temped to install some kind of waterproof whiteboard on one side of it so I can jot down notes haha.

  148. Couldn’t agree more – I’ve done so much PHP and my clients are always like? Well isn’t it easier to do this and that?! DO IT YOURSELF THEN CLOWNS!!

  149. Pingback: 一些鲜为人知的编程事实(转) at Yill
  150. Actually what you describe is the difference between a software engineer and a programmer. Programmers program. Engineers problem solve.

  151. @ Laura

    I think this stems from many languages giving words genders not only based on if the word is a human name or not. For example in my country we say “she the computer” when directly translated and “she the police”, of course those words don´t come out like that when spoken in my home language and when translated into proper English we just say/write “it” when making a reference to a computer or the police, and in the same way in my country we say “he the programmer” just because of the way the word is structured and pronounced and this is a habit that tends to arise when writing in English, of course there should be written “it” when there is a reference to the programmer in the article however you can´t get so defensive because of such a simple mistake.

    Oh and I´m sorry if my comment is too late to be valid or if I´m getting off topic, I don´t frequent these forums, just found this with stumble and wanted to add this comment.

  152. This is pretty technical stuff for me, but being an online university student and an aspiring entrepreneur, I need to learn more about this stuff. Thanks for the opportunity. Have any of you read “Programming and Meta-programming in the Human Bio-Computer” by John C. Lilly? … or “The Human Edge: Information Technology and Helping People” – edited by Gunther R. Geiss and Narayan Viswanathan?

  153. While I agree in general with this article. It is only restating things we have known for 30 odd years.

    And it has left out a couple of very important things.

    Productivity is improving for a number of reasons – even though we still code about the same number of lines each day. One important reasons is the computer languages are better, or lead us to better programming styles. Object oriented programming has dramtically altered how we think about building programs.

    Another is an accumulation of good software libraries. eg when I started programming we didn’t have DBMSs and had to code B-Trees etc just to get started.

    And the main cause for failure is, imho, a view by management that all programmers are equal combined with a corresponding inability to recognise just what was the technically hard part of the project.

    Training, commitment, experience – all essential for the good programmer. Add a touch of insanity and failed personal life for the great programmers.

  154. Lot’s of good points here. I would argue that a leading factor in setting a programmer apart from his/her peers is the quality of their unit testing. The good ones have very few bugs…most of the issues returned should come from poor or unclear documentation.

  155. Pingback: Some lesser-known truths about programming « Miles to code before I sleep
  156. Pingback: links for 2010-11-08
  157. These are really well said facts about programming. I agree 100% with what you said, and can confirm that most of my lines of code are “written” while in the shower or while sleeping. I wish everyone would understand these points because most people I know are ignorant about all this.

  158. This is a great post. Being relatively new to programming it’s always interesting to read the advice of more experience programmers. I’d like to think I’ll be able to emulate some of these truths as I continue my programming education.

  159. I just spent an entire day fixing a bad programmer’s work…

    This post should be written into programming 101

  160. the 10 lines per day thing is an over simplification.

    The first day of the project, you can easily exceed the 700 lines per programmer.

    The last day, adding more lines is a complete faliure. You should only be fixing bus.

  161. Pingback: Some lesser-known truths about programming | Dot Mac | psynchronicity
  162. Pingback: 一些鲜为人知的编程真相 « 成雷
  163. Pingback: 一些鲜为人知的编程真相 » 生活、记录 » 太牛了~
  164. Ten lines per day??? Come On Man. A good programmer will produce at least 600 lines of code (this does not include program documentation).

  165. i have to say that on larger projects, the 10 lines per day is a good average. consider a small function that does something important but relatively complex. you may fiddle around with that one function for two or three days getting it just right. you may have rewritten it countless times but in after 3 days, it’s only 30 lines. if you are writing 600 lines of code in one day, then your project was probably trivial and already implemented very well by someone else (or by you some other time).

  166. Thanks for this article full of Knowledge behind coding.
    Reading books and attaining lectures gives information about subjects but knowledge is what person have after understanding and thinking on subject.Great programmers do that.

  167. Pingback: Một vài sự thật ít được biết đến về nghề lập trình « IT Staff
  168. Hi David,
    I found your article very interesting and I would be very interested in translating it in French in order to cross post it in my blog.

    Can you tell me email if you do agree ? of course, I will quote you as the original author and give link to your post.


  169. Pingback: 一些鲜为人知的编程事实 | 忘川彼岸
  170. Pingback: Verdades não tão conhecidas sobre programação | Blog Fabio Gonzaga
  171. Pingback: Verdades não tão conhecidas sobre programação | Luís Dalmolin Blog
  172. Pingback: Verdades não tão conhecidas sobre programação « UouInfo
  173. Pingback: » Verdades não tão conhecidas sobre programação
  174. Pingback: Verdades não tão conhecidas sobre programação «
  175. @ Allan
    lol, that is funny – 600 lines a day? Prove that to me, and I will hire you at a six figure salary. I have been programming for close to 20 years and the 10-20 lines/day quote is pretty standard in the industry. However, 600 lines/day is not (seriously, 600? why didn’t you just pick 500? or did the extra 100 make it sound like you know your stuff?). Unless you are writing your code in a language that requires each letter to exist on a new line, you are /not/ writing 600 lines of code a day.
    If you are a programmer (which I have doubts), and no – dreamweaver html doesn’t count – you are either very disalusioned about your work ethic, or are an entry level programmer still working on a CS degree. I remember hearing the 10-20 lines a day statistic and thinking ‘no way that is true.’ It is very true. You can easily spend a week figuring out how to use SOAP to interface an internet gateway, configure the correct request and parse the corresponding result. In addition to that, many errors slip through the cracks in documentation and little nuances become the biggest time killers. For example, back before windows had transparent backgrounds, I was trying to make my own using the layeredwindow api. I spent easily two weeks trying to figure out how to manipulate a png image by using per pixel rendering in GDI+ and then passing that handle to the layeredwindows call without any luck. One day I literally changed a 0 to a 1 and I created a transparent form with perpixel alpha blending. Now adding controls to the form was another thing, but that easily proves that I was working on less than 10 lines of code a day for almost a month. Some days I think I was at -10 lines of code. Or 1 line of code, and as I just mentioned – 1 character of code.
    Good luck keeping up with your standard of 600 lines of code a day. Send me your info, and I will hire you through oDesk where I can track exactly how much work is being done. You keep up that 600 lines of code/day average for 1 week, and I will hire you full time

  176. Great post!

    Until a few months ago, I did not believe there was such a thing as a “bad programmer”. I have worked with “weak” programmers, but I always felt that even the weakest programmer could still contribute.

    Now, I BELIEVE! I hired into this company one year ago and most of the bugs I have to fix are the result of one programmer who got fired after being here for 5 years. Forget writing 10-12 lines of code a day, I do not consider my day to be productive unless I can delete 10-20 lines of code this guy wrote. Sometimes I can delete whole paragraphs without adding or editing any lines, that is how much useless garbage he left in.

    All of that means little. What really matters is: For 5 years this guy negatively impacted this company’s products. For 5 years the other ~100 employees (not to mention our customers) were handicapped by the poor code this guy wrote. I have to wonder how much more market share, how many more happy customers, and how much more profit we would have today had he never been here. 🙁

  177. Pingback: » Verdades não tão conhecidas sobre programação
  178. Pingback: 关于编程,鲜为人知的真相 | 程序猿
  179. Pingback: 关于编程,鲜为人知的真相 | 百锐网
  180. Pingback: 关于编程,鲜为人知的真相 | Article2Net
  181. Pingback: About programming, little-known truth
  182. I agree. Programmers perform an important function without which today’s society could not exist. It’s also true that the really good ones never stop thinking about it and how to improve it.

    I am confident of this because, as a technical writer, some of my closest friends and associates have been programmers. Of course, I wouldn’t want my sister to marry one… ROFLMAO!

  183. Pingback: 关于编程,鲜为人知的真相 | laura's site
  184. Pingback: 鲜为人知的编程真相 « 编程王网站
  185. All true. These things make it all the more important for a good or great programmer to find the right environment/employer. All too many drive developers to churn out code without thinking. Those who have been around the block a few times resist but the neophytes learn bad habits that prevent them from ever becoming good developers. The stuggle between those who know and bean counters who lack an appreciation of the process exists in all technical realms, not just software. While the rubber does have to meet the road at some point and there is a happy medium my guess is that 30-50% of companies do drive projects this way. It’s not as productive but the “dirt” is easily swept under the carpet because no one knows any better.

  186. Pingback: 一些鲜为人知的编程事实 « 简单的丰富
  187. Pingback: 鲜为人知的编程真相 | 枫林火山
  188. Pingback: 一些鲜为人知的编程事实 [zz] | 拈花微笑
  189. Pingback: UouInfo Verdades não tão conhecidas sobre programação
  190. I liked this article; it made me feel like I wasn’t such a bad programmer after all! 🙂

    @Russ: I like what you said about the sort of person who asks uncomfortably insightful and incisive questions like a five-year old or an obsessive-compulsive would. I often find myself doing that when I’m talking with clients 🙂

    @Shane: I definitely find that I have a limit as well — nowadays, I won’t do any coding past 10 o’clock, and I have to discipline myself to not think about a project if I wake up in the middle of the night. It’s just not worth it to lose a whole night of sleep over good architecture.

    However, my ‘programming muse’ often speaks most clearly to me when I was either asleep or half-asleep, and I tend to discover the most elegant solutions during those times (probably because my superego isn’t busy second-guessing me all the time). So what’s a fella to do?!?

  191. Pingback: 那些关于编程鲜为人知的真相 | Grow Up Diary-程序员成长日记
  192. This article is so true. About the 600 lines comment, I have definitely produced more than that in a single day before, but I doubt anyone has ever averaged even close to that. It really depends on whether you’re solving a problem or just doing a simple task that takes a ton of code. In my case I was overhauling all my drawing code because I discovered a more optimal way of doing it.

    1. @Parker – You are so correct about the number of lines of code. Although in past times, companies such as IBM sometimes measured programmer productivity (and salaries) in terms of “locs” – lines of code, and “klocs” – lines of code x 1,000, in modern coding environments I don’t see where this is relevant. For example, a simple task may require several hundred lines of code to achieve a given result/output for a program. Conversely, a complex problem may involve merely a dozen lines of code, yet each line of code may involve an extremely complicated mathematical calculation, which is also interconnected with the remaining lines of code which may also perform complicated scientific or logical operations in their own right. These operations must be thought-out thoroughly before the actual coding takes place, since even visualizing the effect of the code may be difficult to grasp.
      In other areas, the use of IDEs to generate code may also result in a large amount of code being “generated.” For example, when I “drag and drop” a graphical widget onto a design surface, dozens of lines of “code-behind” will be generated as part of the application that defines that given widget. As a result, after a few hours of “dragging and dropping” widgets into my web-page or other GUI-based application, the underlying code may balloon to thousands of lines-of-code, although I may have never actually typed these instructions into the application. In summary, measuring programmer productivity in terms of “lines of code” seems at best a very rough and unreliable estimate at best. A possibly better metric of productivity would be to look at what type of problems/tasks are to be solved, and try to allocate programmer resources based on the complexity and/or time required to arrive at solutions based on those tasks. For example, a labor-intensive programming task could be divided among several generic programmers, while a task requiring a short yet critical/complex calculation could be assigned to a programmer who could find a coding solution for that type of problem. In this way, coders could be optimized/matched to the tasks needing to be solved. Even if a single programmer were responsible for an entire application, at least breaking problems into smaller tasks (divide-and-conquer) would shine a light on individual tasks and their relative requirements. In contrast, strictly measuring productivity in terms of “lines of code” appears to make little sense, except in the most rudimentary situations.

  193. 10 lines or 600 lines. It entirely depends on what kind of software are you writting and the kind of problems are you resolving. There are software made of easy problems resolved and software made of really hard problems. So resolving easy problems you could easily reach 600 lines in a day, but resolving a really difficult problem 10 lines of successful code would pay the day.

  194. Writing 10 to 20 new lines is probably accurate.

    I like the comment about deleting lines. If I can make the code smaller and accomplish the same thing, then it is usually easier to read, and easier to maintain.

    By deleting, I usually mean removing 20 lines and replacing them with 4. Or removing duplicate code and merging it into one more efficient object or function and replace the duplicates with it.

    I’m always deleting my co-workers code.

  195. Pingback: Jinliang's Computer Life » Blog Archive » 转:Some lesser-known truths about programming
  196. Pingback: Chad Mendes thinks Kenny Florian could have beaten Jose Aldo | Economy Today
  197. Pingback: UFC 137′s B.J. Penn would like another title shot, but he’s not banking on it | Ultimate Fighting
  198. Pingback: Five UFC 137 prelim fights to stream on Facebook | angelas place
  199. Pingback: Injuries alter UFC 138 undercard | Marvel Staten Island
  200. Pingback: Gilbert Melendez: ?I feel like I’m ready for the title shot now.? | mmanews99
  201. Pingback: Georges St-Pierre Targets Early 2012 UFC Return, Carlos Condit Will ?Work a Little Longer? | Establishing Connection
  202. Pingback: A Backstage Interview with Kelli Hutcherson | What's Happening in my Community
  203. Pingback: 一些鲜为人知的编程真相 - 博客 - 伯乐在线
  204. The number of lines really don’t matter. What matters is the quality of code you deliver. Since I started working with Cocoa I stopped trying to measure my performance or the quality of the code i write based on the number of lines.

  205. Indeed David, really true. I’m thinking that I’m a bad programmer but thanks I should divert into a good one and I realize it through your article. Thanks..

  206. Reminds me of the quote (by Wilde, Flaubert, Chesterton, not sure):
    “I spent all morning putting in a comma, and all afternoon taking it out.”

  207. This article is spot on. It is why some outstanding programmers can justifiably be paid enormous amounts also and still be “cheap” compared to unproductive programmers on a fairly low salary.

  208. Pingback: 사람들이 잘 모르는 프로그래밍에 관한 진실
  209. Pingback: 罗青-技术博客 | [re]一些鲜为人知的编程事实
  210. Your 24/7 thing is wrong-headed[1]. Apart from that, good post.

    [1] See “Code Complete” by Steve McConnell for a criticism of this 24/7 macho nonsense.

  211. Pingback: 关于编程,鲜为人知的真相 | 北方小镇
  212. I think that the title of the article must be changed to “Some new myths about programming”.
    Programming is not only finding the “best” design but accomplishing the project. One of the
    reasons for success of companies is the re-use, so they already have the design. There is no
    objective measure for productivity – lines per day, but what about difficulty and complexity.
    In serious companies fixing a bug by random is not accepted, you have to justify and find the reason. 24/7 is nonsense – in the end it is just a job. You could either do it or not. Eight hours is
    enough. Can I ask if the author is some boss looking for slaves.

  213. I think this 24/7 thing shouldn’t be seen as a good thing. If you’re stuck thinking about your project constantly, you have most likely nerd-sniped[1] yourself and you need a change of pace before you “strip the screwhead” and stop making progress altogether.

    I very much agree with the point about a poor programmer not being worth the added communication overhead. No one’s mentioned that one so far, and I thought it was one of the best points on the article. It’s completely true.

    Also, one of my favorite quotes when people talk about adding more people:

    “Two devs won’t produce twice as fast in the same way two women won’t produce a baby in 4.5 months.”



  214. 100 times more productive is an exaggeration… or otherwise great programmers are being really underpaid… If an average programmer earns $50K a year, a great programmer that is 100x more productive shouldn’t be making $5,000,000 a year? I doubt any programmer is making this amount, a great programmer only gets 2x or 3x what the average one gets, so the increase in productivity is not that high in the long term, or they are just being totally underpaid.

    1. Just a thought: maybe great programmers (would) get tired of being underpaid and go to their own startups (hoping) to get $5,000,000 a year! 😉

  215. Pingback: 鲜为人知的编程真相 | HTML5工作室
  216. “A good programmer is ten times more productive than an average programmer. A great programmer is 20-100 times more productive than the average.”

    20 to 100 better than *average*? Come. On. The article you link cites studies comparing the best and *worst* programmers. The worst programmers have very low productivity, an average programmer produces a reasonable amount of productivity… and you’re telling me that “good” programmers do 10 X average? Gimme a break.

  217. I think one of the most important aspects of being successful as a programmer is to be able to creatively think about requirements and translate them into a design that meets them. I have met many brilliant technicians who are theoretically good at the act of programming and who create beautiful code that other developers appreciate. Such beautiful patterns and abstractions! Then, you actually check the requirements, and it doesn’t meet them because they can only think as an engineer and not as a user, a business person, or whomever the client is. So, the beautiful patterns and abstractions were a nice, fun exercise, like a big video game for someone with a high IQ, but it isn’t actually useful to the people who paid for it! Understanding and being able to translate between the various contexts and roles in an organization is a crucial part of the process that, as you said, often is lacking and often leads to failed software projects.

  218. How serendipitous I find an article that compares good programming to not so good programming. I am currently trying to wrap my head around a project that is ready to implode due to Software Rot, no in code documentation, unneeded complex deployment stack, a modular design approach that might have seemed like a great idea in the beginning but now results in a maintenance nightmare; and this is a for a relatively high profile client. So bad programmer = maintenance and debugging nightmare.

    @HarvesteR Ha! Do Kerbals make great programmers like to they do astronauts ?

  219. Thank you! As a new programmer without much support, I was finding that I was doing exactly as you describe – spending at least 80% of my timing thinking about problems, how to solve them, searching for solutions, reading articles etc. – but I thought that I was doing something wrong. Now I know it’s good practice and normal, I feel much better!

  220. Pingback: Pre-Marketing: China’s VC slowdown | News & Specials
  221. Pingback: Issue 20 – Be More Extraordinary – TLN Can Tell You How. — TLN
  222. Great programmers already have the entire application written in their mind before they sit down at the computer. If you can code an entire app without needing to see what your doing visually, just code from memory you know your close to greatness.

  223. I guess in the discussion I miss the clear definition of ‘average programmer’. I mean, is it true that in bad day the best programmer makes the wrong decision, still he’ll have to correct his failures -provided management gives him the chance. I would say again that productivity statistics used to measure people are very subjective. I’m thinking now that I’m a bad programmer, if I look at the last 6 years of my career. However, if I’m that bad, how comes that I’ve been in the business so long? Something to reflect about. Thanks for the original post.

  224. Pingback: Most interesting links of October ’12 « The Holy Java
  225. This article was of great help to me, It made me realize that I am good programmer but my boss is messing it up for me. He has the WISCA ( Why Isn’t Sam Coding Anything) syndrome. He measures progress only based on what he can understand (forms, and more forms). He is old , does not understand OOP at all which is how I do things. I can spend days working on classes come time for progress check if there is no new form then to him I have not been doing anything. This guy is turning me into a bad programmer. Bad managers can turn good programmers into bad programmers. I making steady progress towards becoming one.

  226. There are only are two categories of programmers, real and pretenders. Real programmers don’t get sucked into pissing contests, they write code that they themselves are accountable for, they write documentation most of the time, they publish useful code, they don’t have a library full of useless outdated computer books, they are respected by other real programmers, they have written/contributed to something that matters to more than 10,000 people, they are good at something other than programming. Sorry guys, everyone else is just a pretender fighting with insecurities.

  227. Pingback: “Priority Inversion” in Software Engineering Management: Misconceptions of Wasted Time | Software Development News, Events, Thoughts from Auriga

Leave a Reply