I prefer to place the comments above, if a statement, or below if part of an if condition. 1k of comments to explain those 50 characters will either help your successor, or clarify to them why they should not touch what they do not understand.

We exist. It's really pretty simple, achieve enlightenment, then the regular expressions will get you. It's much harder the other way around.

I once wrote a program that read tables from a database to generate regular expressions to parse really messed up addresses (third world, not easy US style). The regex generated the Perl variables that would populate the database table. I think the largest of the expressions was ~43k, hence why the regex was generated, being a concept that was used in the code, but never appeared, for the intense fear it would incite. 10 pages of code and a few tables to replace an expensive program we bought that didn't work.

As with any type of programming, you have to look at it from the computer's perspective and understand how the computer will feel about the code you're feeding it.

The difference is that those are federally protected groups. You may not discriminate on those criteria without running afoul of the law. You can discriminate against someone because they have been convicted of a crime(even if not relevant to the job), are incompetent, publicly express strong political opinions that contradict the employer's purpose, etc. You can't expect a military contracting company to hire a well known anti-war provocateur, can you? A prosecutor's office would not hire a pro-marijuana crusader, would they?

There's definitely a lot of grey area where you could make a reasonable sounding argument to fire someone in a protected group based on some non-protected activity, but that's where consistency matters. If the company fires a black person for the same activity that a white person receives no attention for, they're going to have problems.

I agree with the ruling, but I think it's important for both companies and employees to be sensible about their expectations. I don't name my employer when making statements about the industry, even though my statements may not be related to my current or past employers. I also do not use my work email address for anything non-work related. Many companies have policies about these types of behavior, but they're often vague and not enforced. There are far more employers looking the other way than ones who have the spare time and money to play big brother.

Are you suggesting that tech support isn't already done by tarot? Each person you talk to has a completely different, but random answer, and none of them have any familiarity with the products they support. How else could you explain that without tarot?

Why does the blame matter? That's all political BS. I don't care if I get blamed for my manager's incompetence. I've had my manager replace my name with his on stuff and take all the credit for it. That kind of stuff really doesn't matter, because I'm paid hourly for all of the time I work. Every time my advice is ignored, we create some total mess that results in more billable hours. As long as I keep getting paid, I don't care if only a small group of people know why they keep paying me. As long as my boss's boss's boss signs off on paying me more than they're supposed to pay us little IT people, I'm going to keep doing what I can to help solve problems, and if that means taking the blame for someone else's poor decision, oh well.

Why is this moderated funny? People in India are pressured to move to management after they get 2-3 years of on the job experience. The ones who stay technical go to a country that pays more. Fixing what offshore can't do or comprehend is a valid talent that still commands good salaries.

It's entirely possible that a dramatic magnetic shift could cause disruption to electronic services, and I'm sure that if Facebook were down for days, there are millions of people who would just die.

I'm pretty sure that business schools teach people that you can borrow against the future forever. After all, if go out of business, the interest you owe to the future becomes irrelevant. If you've moved onto another job by the time you have to pay the piper, you can claim success while your successors are the failures for not moving faster.

From a business standpoint, russian roulette is the best possible business model. What other gamble offers you an 80% chance of winning? Business schools weed out the analytical types who ask about the other 20%.

Unfortunately, testing is one of those things that you're never going to convince anyone will save any money. If you've always been doing it, you can't prove otherwise. If you never did it, how could you have made it so far if testing was so important? I'm all in favor of good development practices, but there's no way to make a business case for trying to achieve the stability and durability of a pyramid when you have the budget and manpower for a shanty town.

If there's an anti-photon, would that mean that black holes are just anti-matter stars?

Or in the case of fields like marketing and insurance, causation is irrelevant if the correlation is strong enough.

If teenagers have a 1% chance of getting into an accident in their first year being insured with the company, but ones with red cars have a 3% rate, you don't have to prove any causal relationship between car color and ability to drive, you just play the numbers and raise rates accordingly. Business decisions don't have to be rational, they just need to be right 51% of the time to stay in business.

Bad coding is never deliberate. It is an art that can only be attained by the truly uninformed.

Having worked for a marketing group, I would bet this is working exactly as intended as far as browser based rates go.

The old addage of quality, cost, time - choose two holds here. You're absolutely right that when quality is negotiable, cost and time are much more flexible. For us, we could throw away 5% of the data and it met spec.

Many years ago I set up mechanical engineering systems that performed simulations of stress when operating at 8 kelvin. The calculations in a system like that must be done right and have to adhere to strict requirements. However, I suspect the same group of programmers who wrote those parts of the code also wrote the daylight savings time conversion that caused the job scheduler to always think it was 2 hours in the future. The sign was wrong and the vendor was on the east coast, we were on the west coast. They couldn't reproduce the problem. Some aspects of projects may have a higher quality threshold than others, but overall the approach can work if applied in a thoughtful manner. From the customer's standpoint, a fair amount of effort to debug a problem with the scheduler is annoying, bugs in the simulation code would be unacceptable and extremely expensive.

If the core goal keeps changing, you're doomed. However, it's possible to make major changes to key requirements in order to keep the project on track.

I implemented a data warehouse where we had purchased some address parsing software. The addresses in places like Brazil and Mexico are incredibly inconsistent compared to US addresses, so the software simply did not work. We could have spent an infinite amount of time trying to customize the software we bought to do what we needed and it simply could not have worked. Instead, I wrote my own process from scratch that ran circles around anything we could get out of the software we bought, so we abandoned that investment and used my code. That was one of 3 major components in the process that had to be completely rewritten. Sometimes the right solution is to recognize that starting over is the fasted and most productive path, regardless of previous investment of time and money.

The goal, even if somewhat vague, should be solid and understood by everyone. The agile approach is about starting small and making it better. Nothing ever gets to perfection with the agile approach, but if you get things to be good enough on the key features, it counts as a success. If only Microsoft could raise their standards to "good enough". =)

The reason it looks like magic is because it requires at least one person who Truly Gets It. It's easy to get business people to buy flash, because they cannot measure substance, nor can they differentiate between skill and luck with past experience.

For Agile methods to work, you need at least one person who sees the whole big picture, and given enough time and/or other good people to work with, could implement everything from scratch. Once you have that person and a commitment to make the project work, you'll succeed. If you don't have that person, your odds are just as good as any other poorly managed software project.

I worked on a project where we had 6 months to do more than others had done in 18-24 months in the past. The requirements were subject to change on the fly, but the big picture was understood well enough by everyone to make sure that we kept going down the right path. We bought three off the shelf software components that were supposed to be the building blocks of the project. In the end, we used one, abandoned one, and had to do a lot of work to make the third one usable for our purposes. From a functionality perspective, buying the software covered 10-20% of the work that needed to be done to create a viable solution.

There were several times where the management direction would have badly crippled us further into development. However, our management trusted our recommendations and later in the process learned that what we were advocating had been right all along, but wasn't obvious until core requirements changed later.

Without someone who has a deep understanding of software development and all of the things that go into it, the whole process looks like magic.

So the patent lawyers go up against the wall first, problem solved.