Indeed, if they breach his cannon, it will likely backfire the next time he tries to use it. He could be seriously injured.

Wait, seriously? Sitting next to fat people is more inconveniencing than having your airways close off and going into shock because the airline decided it was clever to serve the food item with the most potentially deadly allergic reaction in a small cabin with recycled air?

Oh, wait. You mean inconvenient to you. Right. I suppose other people potentially dying isn't a problem then. Carry on.

The difficulty with including oncall pay in the base salary of the position is that oncall time and difficulty can vary greatly depending on circumstances, and there's no way to reflect that in one's salary in a timely manner. If one member of the team gets ill and another has to cover two 24/7 shifts, he is not going to be happy if he's not getting compensated. Extra comp time would help, but that's more or less identical to paying a bonus, except that you're getting less productivity out of the department.

There are also longer term issues. If an employee is promoted, quits, or dies (it's happened =(), the oncall rotation can change a lot, and in addition to the extra work required of the team to make up for the missing position, it can brew discontent fairly quickly. People can talk about salaries and agreements and sucking it up and such, but if you have a good team they probably realize it as much as you do, and screwing them over with extra work that they were not expecting when they were hired and without appropriate compensation is not a good way to keep people around.

See, I read it as "Bugger," which is a great name for the channel.

Self-documenting code is ideal, as long as it also includes comments.

Don't underestimate the power of the re-org. Someone moves into a position above you, decides everyone needs a fresher approach, and suddenly there's a contractor in, documenting the code for you, and you're replaced by a cheaper or more friendly face.

Watching it happen from the outside, the transition can be painful, but nobody is as irreplaceable as they think.

Embedded programming is an entirely different beast, I'm sure. The way you talk about it, I think all programmers should be forced to write and maintain embedded code for a year or two before they're allowed to work on anything else.

I agree that sometimes it's required, especially where performance is the main factor and the compiler isn't able to optimize well enough on its own. Hopefully, it's either part of the original design, or at least discussed by the team beforehand. In those cases it needs to be commented very well.

I was talking about cases where clever node is written for the sake of being clever, or because it was the most expedient solution to a non-performance issue. Those kind of things can really build up, and can ruin a codebase. I worked for a company where the only person that really understood the code was a developer they kept on as a consultant. There were years of cruft built up to the point where they attempted a re-write, which causes its own problems.

Pleasant programmers are, on the whole, more valuable to corporations than good programmers, for certain values of good. A total genius that writes awesome code nobody else can read is a terrible asset to the company. If the software product is their main product, it could bring the entire company down. Assuming it's their own fault because nobody else is as "smart" is just hubris, and probably delusion.

An actual good developer, while needing actual ability and experience, also needs to be able to work with the rest of the team to write code that potentially any of them can maintain. The developer might quit or die, leaving everyone stuck, or he might just be on vacation when a P1 bug occurs. I know it's more personally validating for your manager to have to call you up because you're the only one that can possibly fix something, but it's really not valuable to the company.

It's called commenting. Proper commenting is just as good and often better than documentation. -Especially- when you're being rushed through a deadline, because that code is probably going to be badly planned and may bite you or someone else in the ass later.

Whenever I hear the word "clever" relating to code, I cringe. I generally use it as an insult. In any professional project, clever code generally means "unmaintainable."

Custom kickstart with all the required configurations, and some basic configuration management software, makes it -extremely- easy to manage. The requirement is having an admin that knows how to set it up correctly in the first place.

Lock out root accounts, mount user home directories from a separate partition/disk/network share and you can even reinstall the base OS without touching their files. Any decent configuration management software (there are a lot of choices) would also allow IT to add rpms or make individual config changes on each user's machine by adding a line to a script or a file to a host-specific directory. Even easier to track who's running what, or who has a weird setup. And if the box explodes or they break something, it can be rebuilt to the same configuration in like 15 minutes.

Again, this is all with an admin that knows how to manage this. That's where you hit the problems, and that's why Linux is probably not appropriate for corp IT currently. There aren't enough people that can manage it well, and those that can will probably have better jobs than planning out desktop migrations.

The difficulty, in my limited but frustrating experience as a patient, is which numbers to use for each patient. I have a certain combination of chronic health issues that seems to be unusual, so I get a lot of different opinions on what the actual problem is.

The end result is that I will visit my general practitioner, who will think that I should see a specialist in problem A, but thinks I might also have problem B. The specialist in problem A says that I can't have problem B because they often have similar general symptoms and are not comorbid. Then specialist in problem B will say that it actually looks like I may have this problem, and I should try this medication, which helps for problem B. Though the medication may exacerbate problem C, which wasn't much of an issue until then. Later on I will find that problem A and problem B are actually comorbid in a significant subset of people, but may have been excluded from studies due to misdiagnosis or existing conditions, and the treatments I've been given are actually incorrect in my case and have caused more problems overall.

So I go back to my general practitioner, who is very good, and he gives me an OTC medication and some vitamins, and the occasional short course of prednisone if I'm having a lot of trouble, and I'm feeling better.