Thursday, March 7, 2013

I first heard the term "Code Tax" a few years ago from a colleague. He attended a talk by Google on their software development practices and described it like this:

Taxes come when they decide the code isn't where they want it to be for some reason and they make a requirement that every checkin is "taxed". The checkin must do some sort of improvement to the code, whether it's where the code change was or somewhere else.

The idea of "always leave the code better than it was before" isn't new. I love the idea but I really hate the term "Code Tax" for it.

If your code is in a bad state the "taxes" you pay for it are in areas things like:

- bugs / worse user experience

- technical support

- delays in releases (long time to implement new features in poor code, more debugging time, etc..)

- developer job satisfaction

Taking code shortcuts is a withdrawal from your account. Taking time to improve your code is an investment (not a tax).

Sunday, March 3, 2013

The other day I ran into what I believed was an LLVM parsing bug and embarrassed myself in the process.

When I get interrupted from coding I'll often create a compiler error in the area of code I'm focussed on. This lets me quickly return to where I was before the interruption. Usually I create the compiler error by simply adding a free floating string above the line I am at. If I'm in the middle of writing a statement though I usually don't need the string since the code wont compile anyway.

In this particular case I got interrupted while writing a simple assignment statement. I got as far as the equal sign and the line looked like this:

self.dictionary =

When I came back I reflexively compiled and was unsettled when it built successfully. When I ran the code I was more confused to find that the dictionary reference actually pointed to a block object? The next few lines of code looked like this:

self.dictionary =

self.operation.completionBlock = ^{

NSLog(@"my completion block ran.");

};

It was a long day and my exhausted brain convinced itself that I discovered a really bad but really interesting parsing bug in LLVM.

I was excited at the prospect of this so (obviously) I wrote a blog entry as fast as I could and tweeted about it. For good measure I even CC'ed Mike Ash of Objective-C fame because he clearly needed to know about this. It took roughly 30 seconds for Mike to reply to me and shine a light on my dimness.

It is more obvious what is going on with a slight formatting change. Removing the new line produces this:

self.dictionary = self.operation.completionBlock = ^{

NSLog(@"my completion block ran.");

};

The result of an assignment statement is the value assigned (like x=y=10).

Lessons Learned or Re-learned:

1) Coding on little sleep is dangerous.

2) Mike Ash has better things to do than debug your crappy code.

3) Always remember: No, you did not find a compiler error. If you find yourself saying (or worse typing) those words turn the computer off and take a nap immediately.