Crank that funk.

Caveat: I haven’t tried it yet. It might punch kittens. In fact, if you think parts of Ruby are “too magical”, this definitely punches kittens.

Sharing values is the most important part of effective collaboration. If you don’t have significant overlap on values between you and your teammates, you’re going to have a tough time getting anything accomplished.

I’m starting to think that figuring what the other person puts a premium on is the most important part of a technical interview. Is the other person passionate in the same way you are? Are the things they obsess over complimentary to what you would rather gloss over? If the answer to these questions is yes, you’ll probably make awesome things together.

‘Your U.S.A. word for fanatic, “fanatic,” do they teach you it comes from the Latin for “temple”? It is meaning, literally, “worshipper at the temple.”‘

I found this passage striking as well. On the one hand, Wallace writes great dialog. Even when most of the dialog is a monologue with ignored interjections by the other character. On the other hand, some great etymology and word-play here.

And then there’s the point: choose your core philosophies carefully. Is it really worthwhile to identify yourself as a Rails person, a libertarian, or a connoisseur of fart jokes?

Side note: I’m doing this whole Infinite Summer thing because, at my core, I enjoy the challenge of reading books that are just too long. This is very borderline hipster, so I promise never to refer to David Foster Wallace by his initials, because that’s just confusing when you live in Dallas.

It seems so obvious: if you want to develop software that’s useful to people, you’ve got to talk with them. But too many developers take the anti-social approach and consider customer support to be beneath their status. Besides, talking with customers would distract them from important code-slinging.

I have to remind myself, almost every day, that one of the the most important qualities I can possess as a developer is empathy. Primarily for the user, their cognitive load, and what they’re trying to accomplish. But further, for the developer who comes to my code when I’m done, the guy who operates it, and everyone else down the line.

When the accompanying iPhone app came out, I fell in love again. Instapaper is perfect for filling your interstitial time, which is something I often find myself when I fish my iPhone out of my pocket. Also, you have to check out the tilt-scrolling feature; every reading app should implement it.

The love affair grew stronger recently. The newest version of the iPhone app came out boasting great improvements to the interaction design and new functionality that makes it an even better tool for occupying the time where you would otherwise find yourself day-dreaming¹.

Firstly: a sort of light-weight feed reading mechanism. It’s not for every site out there; there’s a curated list of sites you can consume in this way. I went with The Economist, but noticed things like Wikipedia Featured, Wired, The New Yorker, and popular stories posted to Instapaper. Great idea.

Next: folders. I’ve used it to organize my reading list into topics so that I can quickly go to whatever matches my mood or energy level. This functionality is present in the web app too, and Marco’s done a great job of making it really easy to set things up just the way you want.

Finally: shared favorites. Peek into what other people have marked as great reading. Maybe it’s a cliche “social feature”, but I’m excited to see curated reading lists from my wonderful friends.

In conclusion: Marco Ament is awesome, start using Instapaper and leave your username in the comments so I can read your stuff.

¹ For example, wondering why butterscotch is so awesome.

John starts with simple stuff like Fibonacci sequences and splitting strings, then jumps straight into modeling Schroedinger’s cat using a monad. Next he gets pretty practical, for Haskell at least: doing text manipulation ala scripting languages to drop command-line arguments and then to MacPorts packages. Finally, he reflects on thinking lazily and using infinite streams.

If you’ve been wondering what this lazy, pure, strongly typed functional thing is all about but keep falling asleep through the intense theoretical bits (there’s a lot of it!), these are a great starting point.

Though I’m a strong believer, I’ve struggled with TDD in the past. I’ve found I get bogged down in keeping the red-green-refactor cycle going. Sometimes I have to work with code that is lacking sufficient tests, but I know I can’t boil the ocean before I proceed to whatever I’m really trying to do with the code. Other times, I’m not sure if I’m testing the right things; I could be missing tests in one place and writing too many tests in another.

Three easy pieces

Last week, I read three insightful pieces and made one discovery of my own that deepened my understanding of the practice of TDD. Allow me to share.

First off, Kent Beck has been exploring the phases in the life of a startup. The earliest stage is proving the idea. He later asserted that when you’re doing stuff like this, you can drop TDD, temporarily. I thought about this and it clicked. If you’re working on a prototype, where you’re trying to explore an idea and see if it works, you don’t want to iterate on the code, as TDD would have you do. You want to iterate on the idea. TDD will just slow you down.

On the other end of the spectrum, you’ve got maintenance programming. Once a startup, company or project has proven their idea and shipped a system, you are maintaining software. Keeping it working, living, breathing. For this sort of development, where you’re making small, focused changes without adding significant functionality, Tim Bray pointed out that TDD is critical. Using it to drive the process of fixing bugs, cleaning up the system and adding minor functionality is really handy for figuring out if you’ve broken something in some dark corner. It also helps the next guy to do the same. It’s a win, and I suspect it’s the sweet-spot of TDD.

If you imagine prototyping and maintenance as opposite ends of the software life-cycle spectrum, adding significant new features to existing software probably lies somewhere in the middle. You may need to “poke around” to decide if what you’re doing is right, like when you’re prototyping. But once you’re done, you want some way for others who have to maintain the software (such as yourself) to figure out what it’s supposed to do and whether assumptions have been broken.

Then I read an anecdote by Uncle Bob about how he worked out an ambitious new feature in Fitnesse. He and his pair got a new feature working, celebrated, and called it a night. When he woke up, he realized they weren’t actually done; they still had to clean it up, by writing tests.

Oh. Duh.

This was the missing link, for me. Sometimes, you need to iterate on the idea first. If skipping the tests helps you, so it goes. Once you’ve got the idea working (and committed!), then start writing tests². Once you’re happy with the structure and coverage of your code, you commit again and then push it to your peers³.

The crux of my revelation is this: you get the benefits of TDD-as-a-design-activity by doing it. When you do it is immaterial. You just have to do it.

My own revelation is blindingly obvious in retrospect. If the going gets tough, proceed in this order: get it to work, write some tests for it, then clean up the code. Sometimes you can break this cycle if what you’re working on doesn’t take too much cognitive capacity. But if you overflow your mental buffer, you have to break it down into steps and work through the cycle. Failing to realize this was one of the causes of me bogging down in TDD.

Context is everything. Always.

Adding context to answer the question of when you start writing tests is something I haven’t found much writing on until recently. I’m increasingly finding that considering the situation is a great ninja-move in my quest towards writing beautiful, useful code.

¹ Call it a test, example, behavior, or story. Whatever.

² Jim Weirich did a great presentation on how to backfill tests on existing code.

³ Pardon the Git-centric terminology⁴.

⁴ If you are not already, please start using Git immediately.

I want to go to there. Photo credit: Alexander K.

Of course, an Arduino is involved.