CRYPTOCHAOS

A test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can't run at the same time as any of your other unit tests
• You have to do special things to your environment (such as editing config files) to run it.

Tests that do these things aren't bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes.

The true goal of any interview is for both parties—the interviewer and interviewee—to work out whether the person can do the work and is a good fit with the rest of the group. There are many brilliant programmers out there whom I would never hire because the detrimental impact of their character defects on the rest of the team would outweigh their abilities as coders. The question to ask is, "How do I determine, in 30 to 60 minutes, if this person can do the work we need, and in a way that I can put up with him or her for 10 hours a day, five days a week, and possibly for years on end?" That's a lot to ask of such a short meeting.

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It’s harder to read code than to write it.

This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it's easier and more fun than figuring out how the old function works.

Highly recommend you read the entire article at joelonsoftware.com

A discipline like Extreme Programming requires a radical upgrade in both technical and social skills, especially for programmers. It requires become transparent, accountable, and responsible. Mostly I see people trying to get different results with basically the same techniques they always used, just rearranged slightly.

There are no super programming languages, only super programmers. And they tend to be super jerks. I should know – I used to be one. What would really make a programming language be super powered is the ability to be used by normal people.

Please click through to read the entire post... It's worth the read.

We are proposing to require the filing of a computer program (the “waterfall computer program,” as defined in the proposed rule) of the contractual cash flow provisions of the securities in the form of downloadable source code in Python, a commonly used computer programming language that is open source and interpretive. The computer program would be tagged in XML and required to be filed with the Commission as an exhibit. Under our proposal, the filed source code for the computer program, when downloaded and run (by loading it into an open “Python” session on the investor’s computer), would be required to allow the user to programmatically input information from the asset data file that we are proposing to require as described above. We believe that, with the waterfall computer program and the asset data file, investors would be better able to conduct their own evaluations of ABS and may be less likely to be dependent on the opinions of credit rating agencies.

Hmmm.... sounds like the SEC want's unit tests the users can run. I guess they don't trust the ratings agencies.

Scribd co-founder and chief technology officer Jared Friedman tells me: “We are scrapping three years of Flash development and betting the company on HTML5 because we believe HTML5 is a dramatically better reading experience than Flash. Now any document can become a Web page.