2009
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.
Super Mario motors
Too cool - Super Mario stepper motor music:
Of course, an Arduino is involved.
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.
The joy of enigmas
...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
Poisonous people and genius programmers
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.
Meditations on golf
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…
Visualizing language trade-offs
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.
That's the second biggest monkey head I've ever seen
A thousand times yes! The Secret of Monkey Island, revisited. My eleven-year old self is jumping with glee. Awkwardly.
See also, ScummC and The Secret of Monkey Island, The Play.
How did SQL get so popular?
Many developers, especially of the younger generation, dislike relational databases and their business-partner, SQL. It is regarded by some as the new assembly language. With all this distaste going around, how did it gain such a strong foothold in industry?
I offer you two answers: ACID and surface area.
ACID
Atomicity, consistency, isolation and durability. It’s not something most folks want to think about. To a rookie developer, it’s overwhelming. They’re not yet familiar with the semantics of the systems their programs run upon. Is fread thread-safe? “How should I know, I just learned C last semester and about fread’s parameters last week!”
The promises of a modern relational database include a compelling bullet point: your data is safe with us. Use our APIs, don’t break the rules, and we will make sure you never blow away some data and get a call at 3 AM. Rather, the DBA will, but what do you care about that guy?
So I submit to you that most programmers don’t use databases because they’re great. Rather, they have come to rely upon them because the canonical tome on transactions is heavy enough to maim small mammals and rife with formalisms. So they skip the nine-hundred page textbook and pick up the six-hundred page O’Reilly book.
Surface Area
Most programs that people will pay you to write involve side-effects. Further, many of those side-effects have to do with saving data off so you can perform further side-effects on it in the future.
The rookie developer typically leans first to files. Files are familiar and pervasive. But files leave a lot to said rookie. How should I structure my data? How do I load and save the data? How do I manipulate the data once it’s in memory? Even in scripting languages, with their simplified APIs, this means the rookie is faced with APIs like this:
fopenfreadfwriteseekfcloseencodedecodehash_sethash_get
When I was bit a wee lad o’ programming, I found this Gordian knot difficult to cut. But then, one day, I was told by a programmer of greater wisdom to use a database. That API looked like this:
connectexecutefetchnextselectinsertupdatedelete
It was a lot easier to understand, even though the last four are a completely different language.
So, I submit to you, that SQL also won because it was easier to understand how one might structure their programs, make them work and, if they’re lucky, get them to run quickly.
Inflection point
I’d wager that five years from now, the generation of developers who are now upcoming won’t take the database tier for granted. Key-value stores, distributed file systems and document databases will all play into the question of “what do we do with the important data?” Sometimes, relational databases will prove useful. But increasingly, other things will too.
In the end, there’s two ways to look at this: we will soon throw down the shackles of our relational overlords, or, prepare yourself for the database renaissance in programming fashion that will occur in a decade or so.
Everyone wins!
Design: it's important
Via Konigi, David Malouf:
Great design in the end will give us something to relate to, to feel connected with, and to reinforce our humanity. Tapping that right balance between emotion and logic, chaos and control, analog and digital, is the key to this success. We can no longer rely on “form follows function”. Form has to be parallel to function, as function is growing in commodity.
Enjoy some Wu
Ooh, baby, I like it raww… - Some Wu-Tang Clan for you. I’ve been finding Yes Yes Y’all [sic] an excellent source of music that I otherwise wouldn’t come across.
Put your objects in space
Space-based Architecture - on building and scaling your system with a tuple space, the kissing cousin of the messaging queue. I didn’t know that tuple spaces are used much in finance apps, but I’m not surprised. They’re a worthy idea.