Other Than Think

Monday, February 23, 2009

Is this a cheeky feature, or an ironic bug?

Thursday, February 19, 2009

Line 6 BackTrack Review

I don't normally blog about the products I buy, but the Line 6 BackTrack rules. I've looked for ages for a good band recording practice tool, and this is finally it. In the past, I've used:

A digital 8 track (too cumbersome)

A portable mp3 recorder with an expensive portable mic (too clumsy and hard to balance, and I had to use some super flaky and buggy software to transfer files)

A laptop (again, too clumsy, and hard to work with on the fly)

Why does the BackTrack rule?

It just works. You turn it on, and it records your stuff in really good quality for practice purposes. Marking stuff you like on the fly is a nice little bonus to help sift through stuff later.

It automatically chops up the files for you based on pauses between sound. No more tedious manual splitting of tracks in Audacity or whatever your file splitting tool is.

It's easy to get the files onto your computer - it works as a USB storage device, so you can drag and drop.

It fits into my guitar case. No lugging some big piece of recording gear around any more, or even worse, forgetting it.

The only issue I had on the first night of practice with it was that I had configured it to a preset of Rock Band levels...meaning its recording threshold was pretty high and the mic gain was pretty low. On one of our lovely ballads, it missed the song's intro because it was below the recording threshold. (Or maybe it's a feature to discourage ballads.) It was easy enough to solve though - I just lowered the recording threshold a little.

Sunday, February 1, 2009

Why Jeff Atwood is one of my programming heroes

There are a lot of high IQ's in this world, and a proportionately high number of them are in the programming field. But IQ isn't enough. An unfortunately high proportion of the smarties don't have high EQs when it comes to what we're actually trying to accomplish in this field. Jeff Atwood is one of those people whose blog I follow that really, really gets it. Here's a snippet from a podcast between him and Joel Spolsky, where he absolutely nails this concept right on the head.

The longer I think about this, the less I care about code hygiene issues (laughs). Because the unit of measure that really matters to me is, how quickly you can respond to real business needs with your code. And by that I mean, how well are you serving the people that are using your code. To me that's what it's all about. Anything that gets in the way of you fixing your code or improving your code in a way that your customers can appreciate, is a negative. If that means using Ruby, or having lots of unit tests: whatever's working for you: do that. But if it's getting in the way, if it becomes friction, like, "I'd love to have this great new feature but I'd have to have 1000 unit tests," that's a negative.

In my opinion, this is the difference between a journeyman programmer and a master. A journeyman has all the mechanical skills that a master has; he knows all the patterns and most of the anti-patterns. But what he lacks is the wisdom to know when to use them, and most importantly, when not to use them.

Maybe someday I'll be able to give Jeff a coke, and he'll smile and throw me a smelly old jersey he used during the project :)