And nuclear power gives us among other things nuclear medicine. Many times more people are diagnosed, treated and saved by such technology than have ever been killed by nuclear technology.

Many of the things listed above aren't in and of themselves bad. Assholes make those things conduits for irredeemable idiocy that simply couldn't previously achieve general recognition. There were dickheads ignoring you for their landlines prior to cells. There were perverts and dipshits long before the internet. There were people who thought themselves so damned interesting and just needed to tell the world about their trip to the grocery store before it could be tweeted or posted on FB. It isn't the tech, it's the assholes who use it with whom i have issues.

If a hiring practice is challenged in court as discriminatory, a company must show the criteria it is using are proven to predict success in the job.

Wait a second, and what? Since when is a valid defense against a discrimination complaint "yeah, we descriminate, but it's okay because it actually provides results."

How far would that kind of argument get you in a Gender, Racial, or Age-based discrimination setting? If anyone said "As a cop i assume every black person is guilty of something, but hey, my arrest rate has gone way up so it's ok." that case would be DONE.

As has been said a few times, the principle reason for a comment is to explain why the code needs to be the way it is, not what it is doing. By this definition, a few things happen.
You get fewer comments in the code, because most code doesn't need explanation. Yeah yeah there are those pesky API calls that have to get called in nonsensical order and the fact that you're rounding down and not up because your ad campaign doesn't do partial credit to save money, or whatever other nefarious, legacy, or even sometimes malicious reasons there may be. Even legitimate code can be malicious.

But lets be real. This only works if people write sensible code to begin with. Code can be self-documenting. Those nay-sayers who complain that it cannot be simply don't know how to do it, or haven't yet seen a suitable example.

You don't need to write code that has 6 equations on one line. You don't need to write 200-line methods. You don't need to use variable names that obfuscate meaning, or worse, those that have no meaning at all. (int a,b,c,d = 0). You don't need to, but many of us as professional developers do. Why in the world do we do that?

I can spout all sorts of slander about being lazy and being macho, ignorance and horribly misguided job security, but i won't because it doesn't help. I don't care why we do it, i care why we should seek to write code that we can come back to a year later and just read.

Languages are pretty high level these days. The code they support can very nearly read like sentences. Why not?

I learned how to produce useful self-documenting code by doing TDD. TDD told me to write tests that describe the behaviour i wanted to achieve (not the implementation i was trying to test). I parlayed this into my code as well. Now i might have a class called calculator, with methods such as Divide, Mulitply etc. and tests which say Divide_Prevents_An_Exception_For_A_Denominator_Of_Zero() and Divide_Reports_Divide_By_Zero_Error() and other such things.

Why would i have to comment that? Does the compiler care how long my method names are? Is anyone reading those tests or methods going to need help to understand what is going on? Not likely.

Whether you believe you can truly write self-documenting code or not isn't relevant. I can't evangelize the benefits to non-believers. But how about just trying to achieve it? Even if you don't really succeed, you'll probably find your code a lot easier to understand even if you insist on putting comments in your code.

I'll bet you'll fall in line with everyone else eventually and find that comments aren't necessary, unless something unnatural is afoot. Then and only then, will you ever find a comment in my code.

You should see the look on his face when i tell him he's getting faxed.

G.W.Bush was at first glance not a completely ignorant moron too. Maybe Mitt and his uncanneyness will not have to work as hard to rig elections either.

See, now i don't know what to put on the census form. Is my religion Apple now, or am i still a Jedi? Am i a Jedapple?

I've been working for a company which does a lot of Test Driven Development (TDD), but quite honestly, we don't develop new products all that often. We have legacy products (10 years old on average) that we work on day in and day out which in some cases are abhorrent. However, we don't try to fix the world by taking a year or two off to add comprehensive tests to the company's products, we just test anything we add or modify. Slowly but surely, you will add value to your products and the stuff you're complaining about will start to happen less often.

I would submit that you don't need to ask for permission to do this. YOU are the developer and it is YOUR mandate and responsibility to produce quality software. YOU know how best to do this, so just do it, and build it into the cost of your estimates. At first, while you get used to it, things may slow a little (not as much as you might worry about). However, once you get rolling in practice we see that things don't take any less time than they did before, and eventually some things will take less time than before. Did i just say that right? In fact I did. The difference is that the same old bugs for the same old reasons simply don't occur anymore. We just have fewer bugs coming in against our products. We KNOW that once we fix something it will stay fixed tomorrow, next release, next year, and for all of time until the spec changes (don't be deluded into thinking it won't...). We have tests that say so and will not let the build pass if at any point that feature no longer behaves as it should. In practice, whenever we add tests to legacy code that we just happen to be modifying, we aren't surprised to find out that it doesn't work the way the specifications say that it should work.

Testing isn't there to speed you up. It's there to not slow you down (among many other wonderful benefits). It's there so that you can say that you *KNOW* that your product works in certain ways. It can be hard to start writing tests, but someone above mentioned a book "Working Effectively With Legacy Code" (Michael C. Feathers), which is an excellent resource to get you started. Here are some others:

- Test Driven Development: By Example (Kent Beck)
- Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
- Refactoring: Improving the Design of Existing Code (Martin Fowler et al)

You don't *have* to adopt TDD as a daily life routine to reap the benefits. Some of these books and other reference it as an excellent tool to enable you to write better tests and better code, which i think is true. However, these books also teach you how to tackle existing code and to get it under control by writing tests for it. You're doing yourself and your products, and your employer a disservice if you don't write tests for the code you write, even if your employer cannot see the benefit. I'm sure surgeons could get stuff done a lot faster and cheaper if they took some shortcuts and didn't bother to sterilize their equipment, but they know better than to do that. You should know better as a developer than to just hack something together and run it by some visual inspection of limited "use cases" and then think that you've done your job properly. Your code may not work at all, and you won't even know it until a customer tells you so.