The mystery of good art
The trick about good art is that it has some mystery, an unknown. The problem is that if you get too close to the art, you risk unraveling the mystery. If you deconstruct it, engage it, or study it, the unknown becomes known. Thus, if I really enjoy a song (in particular), movie, etc. I stay away from taking it apart to see how it works. I’d rather enjoy it for a long time.
I have this problem where I over-listen to an album. It started in my teenage years. I learned all the bass-lines for Pearl Jam’s Ten. After that, I couldn’t listen to the album for ten years; I knew all the secrets, all the interesting bits. Rewind a year ago, and The Who’s Live At Leeds was my jam. Now, I can’t listen to it.
But I’ve been very rigorous about listening to Bruce Springteen’s Born To Run. It is such a perfect piece that I only allow myself to listen to it once a month[1]. No more. Similarly, I won’t let myself learn to play any of the songs on the guitar. I want to maintain that mystery.
I wonder if there is other art like this. Could you get overexposed to a Mondrian painting or a Hemingway book? Even with works that are more popular in their sensibilities, is it possible? Is there such a thing as too much Starry Night or Ghostbusters?[2]
The bottom line: enjoy good art, but take care not to over-enjoy it.
fn1. I even feel like I’m cheating if I listen to Born To Run in anything but album-form. To hear “Thunder Road” or “Jungleland” by itself feels incomplete, like I’m missing something.
fn2. Yes, I just put these on the same level, even though I’m not much of a van Gogh aficionado.
Testify
Two unrelated and great songs, one title.
“Testify” by Parliament
“Testify” by Stevie Ray Vaughn
Enjoy!
Gird your greyscales
Logan Hicks has some really great subterranean photography going on. (Via Infrastructurist)
And if you like that, you’d probably also like some Russian submarines, their interiors, and their underground bases.
While we’re dwelling on intriguing/depressing concrete structures: one dude’s home built into a former missile silo and the Oak Ridge plant where the materials for the Manhattan Project were refined.
Getting to know your bookshelf
The Book Stalker - Rands figures you out by your bookshelf:
Where’s your bookshelf? It’s this awkward moment whenever I first walk into your home. Where is it? Everyone has one. It might not be huge. It might be hidden in a closet, but in decades of meeting new people, I’ve never failed in finding one and when I do I consume it.
Here’s mine from almost two years ago (plus more):
I’ve since expanded to two shelves and look forward to the day when I can devote a whole wall to just reading. As I often tell myself as I sit down to start, “reading is the best”.
Free Parking Is Not Free
Free Parking Isn’t Free. Turns out those parking lots, while sometimes handy, are actually pretty gnarly, if your goal is to build a nice place to live:
Throughout the 1940s and 50s, as automobile use became prolific in the United States, parking became a problem, congesting streets and overflowing into neighbors' lots. In response, most municipalities instituted off-street parking minimums requiring developers to provide all the parking that the residences or shops would need on-site. This seemingly sensible notion has created a cascade of problems. It encourages sprawl by spreading buildings apart to make room for more parking (requirements usually demand more area for parking than the building it supports). It also weakens urban design, as urban buildings are torn down to make room for desolate surface lots, and hulking parking garages sprouted in downtown areas. It discourages revitalization of existing historic buildings, since developers have trouble meeting modern parking requirements in neighborhoods that were built before auto dominance. And the requirements drive up the cost of development: parking spaces can cost between $10,000 and $50,000 – typically more than the cost of the car that occupies it. High parking requirements can raise the price of homes and apartments by $50,000 to $100,000, a serious challenge to affordability.
When I have more money that I know what to do with, I’m going to start buying up parking lots and turning them into parks. It’ll be my little way of sticking it to people who drive over-large cars.
Kill your menubar darlings
The Menubar Challenge - everybody, clear out your menubars! It’s one of my secret productivity weapons, I highly recommend it. Also, read everything on Minimal Mac; it’s the best.
Here’s my current attempt to use as little as possible in my menubar:
LittleSnapper normally isn’t running, so that doesn’t count. If I could, I would run DropBox and FastScripts without menubar icons. I’m still not sure I like having a clock visible at all times, but at least analog clocks are classy-lookin'. I’d love to remove the battery icon, but it appears doing so disables the “your battery is tapped” warnings, leading to spontaneous laptop sleeping.
My setup
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.
Balmer =~ Tarkin
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.
Code re-use as technical debt
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 goes 1.0.0
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!
Differently hackish keyword arguments for Ruby
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.
Interviewing to seek values
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 and fanatics
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.
Software development requires empathy
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.
Instapaper is wonderful
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.
Haskell modulo excess theory
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.
When to do test-driven development
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.
A slide in the workplace
The Red Bull headquarters in London has a slide going between floors.
I want to go to there. Photo credit: Alexander K.