> Of course it causes all these things. If you're refusing to modify existing code, then you can't refactor it to handle extra cases

This is already covered by the rules. What you're describing is part of the "intersection" of old code and new code. Avoiding those changes as far as possible is the correct route (but the new code still needs to be integrated to the system so that it's executed as part of the program's execution). But writing independent module first, and then integrating it carefully to the system is the correct route. Just need to be more careful with the intersection, since all those modifications are dangerous.

1. naah, it causes no such things.
2. It's not about bug fixes. That is handled by not writing broken code in the first place. If you need to write same thing twice, you're wasting time the first time you wrote it. You should review your code policies if you have large number of bugs to fix.
3. information lost = noone bothers to rewind the version control history to find the exact version of the software that actually works. It needs to work every day and every week for years. It's not enough that half the versions are working and the rest need to be reconstructed from version control histories. Everything in version control must work. Deleting code is dangerous because you cannot track all dependencies from the deleted code to the whole system.

It's more like breaking already tested code is wasting too much time...

1) Adding new code is always ok. Just need to keep it independent of the old code. Avoid modifying intersection of old code and new code.
2) Modifying code is dangerous. It can break features anywhere in the system.
3) Deleting code is extreamly dangerous. It can both break code, and lose information what was original code version.

No amount of version control hacks is changing these rules.

Here's reasons why I don't like this topic:
  1) There is no bad code. Every programmer has written the best code they can write. If you have trouble reading it, buy some better glasses.
  2) Complex code is not bad code. The programmer you're trying complain about is smarter than you think. He saw some complex problem in your software architecture and his complex code fixed it. You still can't even see the problem, much less the solution. It works, and any complaining about the details is useless.
  3) Reading someone elses code is always difficult. about 90% of programmers think they write better code than others simply because reading ideas from other programmers is difficult. This accounts large portion of "bad code" out there. You need to find better criteria for labeling someone elses code bad. How about check test cases that fail... Oh wait, where's our test cases?

> Of course! This would surely not have occurred to the particle physicists who built and operate
> the machine and published these results.

Well, it always sounds like if they make the same mistake twice, then it's already better to publish it...

I'm pretty sure their huge device is just not accurate enough. Two separate measurements can give different results based on how they configured the device. And if one of them gives photons and the other some Z's, then it's clear the difference is based on different devices measuring it. I'm surpriced their measurement result fits to same page in the graph... few GeV/c difference is so small we can confidently say higgs exists...

I bet they get 99.9999% reliability for their electricity... Sounds just like what the data center needs.

Since I didn't see their data, I can only guess what could be the problem. They're detecting both neutrinos and light some way. My bet is that their detector for light have some additional delay making the light detection wrong. They probably didn't spend millions on the light detection system since they were planning to detect neutrinos only. Probably cheap parts are causing this problem.

If you only consider that they can get it from only the few individuals who did lose in the lottery, it sounds much more reasonable.

" it's killing pretty much everything it makes and just repackaging stuff made by another company."

If it's so easy that just repackaging someone elses work, why wouldn't microsoft do it themselves? There would be no reason for microsoft to play this game, if your theory is correct.

While your answer was mostly ok, the last paragraph ruined it. There are no people who are not confident programmers, because everyone is trying their best. Everyone is different. For some people or teams code reviews are useful. But sometimes it just doesnt work. This is not because the developer was inexperienced or not very good, but instead because code reviews just are not suitable for everyone. Big mistake is trying to forcefeed your own conventions and practises to other people. Not everyone needs code reviews. Or there are other problems. Assign the problems to the responsibility of the process. Never blame other people. People are not idiots, Programmers especially. Everyone is still trying their best.

good companies will have 15 different positions open and their interview just jumps from one position to another every time the person makes a mistake. If they have only one position open, then they are very tight on money, and the position will not last too long.

Stump the candidate obviously tests how fast they are. If the company have tight deadlines, they obviously need people who are very quick solving these problems. If you failed on of these tests, they were looking for more experienced people for the position and you were not a good match for it. It's better to find something else. Slow and inexperienced people in these positions can cause large amount of damage.

Of course I bet the company will have lots of difficulty finding anyone suitable for the position, but at least they're trying to fill it.

This just means your company is not very desirable for the more experienced folks. And everyone who has experience is already busy.