Adam Keys is Thinking

Shawn Blanc has been cataloging sweet Mac setups. Last week, he published a description of my own creative den. If you find this sort of thing as intriguing as I do, also check out The Setup.

Steve Ballmer:

Evacuate? In our moment of triumph? I think you overestimate their chances.

OK, maybe that’s Grand Moff Tarkin. Either way, I’m considering this my birthday present from John Gruber.

I have extremely mixed feelings about code re-use. I think it’s largely a red herring, never working out as well as developers would hope. After all, developers are like golfers; always optimistic about how well an approach will work or how far down the fairway their ball landed.

But here’s a real stab in the side of code re-use: in many cases, it’s tantamount to technical debt. Embrace technical debt:

For example, early on at IMVU, we incorporated in tons of open source projects. This was a huge win (and we were delighted to give credit where it was due), because it allowed our initial products to get to market much faster. The downside was that we had to combine dozens of projects whose internal architectures, coding styles, and general quality varied widely. It took us a long time to pay off all the debt that incurred – but it was worth it.

Using someone else’s code will help you keep moving now, but you stand a good chance of needing to rewrite it later.

That’s not to say it’s all bad. By the time you know you need to replace someone else’s code, you’ll have learned about the domain it covers and how you need to solve that problem in your domain.

Keep it in mind: just because you can drop someone else’s code into your app and use it, doesn’t mean it’s all roses and butterscotch.

rufus-tokyo 1.0.0 - I’ve been tinkering with Tokyo Cabinet and Tyrant lately. It’s great stuff. Grab this gem and start tinkering!

DISASTER!

Crank that funk.

maca’s arguments - keyword arguments support for Ruby, now. Wickedly clever hack that does reflection on Ruby 1.9 and uses ParseTree for Ruby 1.8. Simpler than I thought it’d be, I wish I’d thought of that.

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.

Adam Wiggins, per usual, is on to something. Values:

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.

Infinite Jest on patriotism, fanatics, love, attachments, and temples:

‘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.

If You Want to Write Useful Software, You Have to Do Tech Support:

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.

I have loved Instapaper ever since I became aware of it. It fits perfectly into my workflow. There’s tons of stuff I want to read, but not just yet. Instapaper gives you a little bookmarklet to save these jewels for later when you’ve got more time to slow down and read a longer piece.

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[1].

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.

fn1. For example, wondering why butterscotch is so awesome.

My journey through Haskell is on something of a lull, but John Wiegley’s got you covered. He’s documented his own journey learning Haskell, and it’s very accessible.

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.

I believe that writing code using testing[1] as a design activity yields long-term benefits that make my life easier.

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[2]. Once you’re happy with the structure and coverage of your code, you commit again and then push it to your peers[3].

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.

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

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

fn3. Pardon the Git-centric terminology[4].

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

The Red Bull headquarters in London has a slide going between floors.

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

Too cool - Super Mario stepper motor music:

Of course, an Arduino is involved.

Going to meaningful work:

Just like being awake is more than just having your eyes open, going to work should be more than just being at a workplace trading time for money. It should be meaningful. But where does meaning come from? Of course, it comes from ourselves. We put meaning into things, and share our meanings with others, and teach each other how to build meaning out of what is in front of us.

Buster’s on to something here. He’s articulating one of the qualities I find in the best developers: what they do has meaning and matters to their personality. They are working to make things that result in greater happiness for themselves and others. Their passion is manifest in the quality of their code.

You should also check out Buster’s personal site. He’s got a neat info-graphics, personal data-mining thing going on there.

For the like-minded aficionados of the non-traditional: A Redis implementation of Twitter, designed for learning about non-relational datastores and Clojure’s creator Rich Hickey on state (bonus track: Jonas Boner on the same). Derek Sivers on the fatal determinism of declaring a goal or as I like to say, “the reason you find so many weblogs with one post promising to post a lot”. Michael Heilemann on the lack of good fiction in contemporary games.

...thinking about an enigma. There it is before you—smiling, frowning, inviting, grand, mean, insipid, or savage, and always mute with an air of whispering, ‘Come and find out.’

— Joseph Conrad, Heart of Darkness

Brian Fitzpatrick and Ben Collins-Sussman have done a couple great talks on probing the important social aspects of software development, especially in the open source arena. Open Source Projects and Poisonous People talks about how to survive “that guy” joining the community of your favorite project, be it open source or not. Their most recent jam, The Myth of the “Genius Programmer”, tries to temper the romanticism that developers can magically put forth reams of brilliant code. By proceeding with humility, one can appear as a genius without all the hubris and potential for downfall.

See also: my OSCON 2007 talk on PeopleHacks.

We’re just wrapping up that nice time of the year in Texas. Technically, we get two nice parts of the year: the one after "winter" and the one after SUMMER. It’s nice in that you can sit outside with the dogs and just enjoy the air, the sounds and the fact you can sit idly without wishing you were in a climate-controlled environment.

This year I’m actually taking advantage of this part of the year by golfing. All the public courses are blooming: the fairways are green, the bunkers are as sandy as they’ll get and the greens are in peak condition.

My golf game is improving; a novel experience. I’m hitting some fairways, some greens and making the occasional nice putt. It’s like seeing an investment pay out. Hopefully I’ll finish the summer hitting under 100 on a regular basis.

Golf is nice, for me, because it’s as close as I get to meditation. I don’t think about code, politics, or finance. I just think about the previous shot and the next shot. In fact, the less I think, the better I do. Golf is my chance to attempt nihlism.

Golf is relaxing. It’s a little vacation. I sometimes see guys out with their wives. They’re doing it wrong. The point of golf is to spend some time away from everything. By this definition, professionals like Tiger Woods are doing it wrong too. Maybe I’m on to something here.

There’s a moment in my game, somewhere on the last three holes, where I realize I’m going to have to go back to being responsible. This moment is like hitting a bad shot; you think you can do better. On the other hand, it takes a long time to play eighteen holes, so getting back to responsibility is a good thing.

What would I do if I didn’t play golf? I don’t know. Golf, as lame as a lot of people think it is, does good things for my brain. Maybe that explains my obsession/addiction. Luckily, I’ve given up my Call of Duty 4 addition. This Old Republic game could prove troublesome though…

Guillaume Marceau has done some excellent work crafting the data from the venerable Computer Language Benchmark Game into visualizations that quickly show the trade-offs of using each language. The speed, size and dependability of programming languages puts each language in a small graph that simultaneously shows the execution speed and program size of each test for every language. From there, the characteristics of each language is manifest. He then goes on to consider whether functional languages display unique performance/size characteristics.

This is a must-read. It’s also great information design, proving that programming language esoterica needn’t bore the reader.