I am a young programmer (finished computer science university but still under a year of working in the industry) and I recently got a job working on some C code for a decent size web service. Looking at the code the only places I saw comments were when people were stashing their old code. Function and variable names are similarly informative most of the time - futex_up(&ws->g->conv_lock[conv->id%SPIN]);. Confronting a senior programmer about the situation and explaining that adding comments and meaningful names would make the code more maintainable and readable in the future, I got this reply:


  In general, I hate comments. Most of them time, like the case you
  mention with the return value, people use comments to get around
  reading the code. The comments don't say anything other than what the
  guy thought the code does at the time he put in the comment (which is
  often prior to his last edit). If you put in comments, people won't
  read the code as much. Then bugs don't get caught, and people don't
  understand the quirks, bottlenecks, etc. of the system. That's
  provided the comments are actually updated with code changes, which is
  of course totally unguaranteed.
  
  I want to force people to read the code. I hate debuggers for a
  similar reason. They are too convenient and allow you to step through
  dirty code with watches and breakpoints and find the so-called
  problem, when the real problem was that there are bugs in the code
  because the code has not been simplified enough. If we didn't have the
  debugger, we would refuse to read ugly code and say, I have to clean
  this up just so I can see what it is doing. By the time you are done
  cleaning up, half the time the bug just goes away.


While what he wrote goes against a lot I have been taught in the university, it does make some sense. However, since experience in the studies sometimes doesn't work in real life, I would like to get an opinion of people more vetted in code.

Is the approach of avoiding commenting code to make people actually read the code and understand what is going on make sense in a medium-sized coding environment (one that can be reasonably read in whole by every person working on it within a month or two), or is it a recipe for a long-term disaster? What are the advantages and disadvantages of the approach?

Well written code should be sufficiently self-documenting that you don't need any comments explaining what the code does, because it is obvious from reading the code itself.
This implies also that all functions and variables have descriptive names, although it might be needed to learn the lingo of the problem and solution domains.

This does not mean that well-written code should be completely without comments, because the important comments are those explaining why a particular, non-trivial, function/block/etc is implemented as it is and why not a different solution has been chosen.

The problem with comments describing the code itself is that they tend to get outdated, because the code gets changed to fix a bug, but the comments remain untouched. This is far less the case with comments describing the reasoning for coming to the current solution.
