"A test is not a unit test if..." - Michael Feathers

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 question to ask is, 'How do I determine, in 30 to 60 minutes, if this person can do the work we need..'" - ACM Queue

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.

"It's harder to read code than to write it." - Joel Spolsky

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

UBS: "a suburban location has become a liability in recruiting the best and brightest..." ☛ NYT

Fifteen years ago, New York City’s reputation as an international financial center was called into question when the giant Swiss bank UBS moved its North American headquarters to the Connecticut suburbs, where it built the largest trading floor in the world.

...

Now, though, UBS is having buyer’s remorse. It turns out that a suburban location has become a liability in recruiting the best and brightest...

Another example of quick iterations to get to a solution: "You Are Solving The Wrong Problem"

You Are Solving The Wrong Problem « Aza on Design

http://www.azarask.in/blog/post/the-wrong-problem/

The problem was the problem. Paul realized that what we needed to be solved was not, in fact, human powered flight. That was a red-herring. The problem was the process itself, and along with it the blind pursuit of a goal without a deeper understanding how to tackle deeply difficult challenges. He came up with a new problem that he set out to solve: how can you build a plane that could be rebuilt in hours not months. And he did...

(via Instapaper)


Sent from my iPad 2

"The key to building a great game is rapid iteration... There is no magic formula..." ☛ Andrew Brownsword

The key to building a good game is rapid iteration... There is no magic formula that makes a great game.  What you want to be able to do is try things rapidly. By trying things rapidly, you get to experiment with what works better.  There is a rule of thumb that says... "The more times you can iterate, the better" and that means speeding up interation time.

- Andrew Brownsword

via Software Engineering Radio