If anybody is looking at the source code: the main way in which it’s not representative of how I normally program is the fact that most classes don’t have unit tests. This sometimes happens to me when I’m gluing stuff together: there’s not much in the way of logic, and the ultimate test of a fair bit of that code is how it looks in the web browser, so I’m not sure where unit tests would be useful. In situations like that, though, I do like to throw in some kind of overall acceptance test that at least detects whether or not I’m inadvertently changing the HTML output. And, of course, it’s much smaller than software that I work on at work! Other than that, though, it’s reasonably representative: functions and classes are pretty small but there’s room for further shrinking, I’ve taken a bit of care to remove duplication, but I wouldn’t present it as anything like a shining, polished gem.

I’ve also added a front page for the site, so you can see the fragments (at least the most recent 20 ones—no pagination yet) without having to go to the feed. (Incidentally, Safari isn’t correctly doing feed autodetection right; I’ll look into that eventually, but if somebody happens to why that isn’t working, please tell me.)

It’s turned out differently from how I expected it to be. In particular, I labeled it as a “microblogging platform” above, but you’ll see if you look at the front page that that isn’t accurate, that “miniblogging” is more the size posts are turning out. Also, in the original post, I talked about “mosaics”; support for them is still there, but I’ve only written one, and that one was a proof of concept instead of something that I really felt compelled to do. So, instead of figuring out how to represent mosaics on the front page, I just left them off the front page entirely, and am not advertising the mosaics RSS feed, either; I’d be surprised if I ever write another one, though who knows.

What does seem to be the case is that the fragments blog is turning into my ‘morose blog’. Something about the fact that it feels hidden—very few readers (almost all of whom are people I know and feel quite comfortable talking to in person), combined with a complete lack of comments and an almost complete lack of analytics—makes it feel more private than it actually is. (Because I don’t want to kid myself: it’s on the web, it’s accessible by search engines, so any mistakes I make there will be available to be uncovered!) The result of which is that I spend some amount of time digging into in-person interactions, and the in-person interactions that I think about the most are ones where I feel out of place. That gives entries a morose tone, to the extent that I end up backtracking on that within the blog itself, because I certainly don’t feel like a morose person the vast majority of the time! Still, I think I’ll stop backtracking/apologizing for that within the blog: this paragraph is the context you’re going to get for the tone, the fragments themselves should be minimal and unapologetic.

And, unless something changes, this post and its predecessor is all the talking I’m planning to do about the fragments blog: it’s been a successful enough experiment that I’ve added a link to it to the right-hand column on this blog, and I imagine the fragments will spur ideas that play out here in a larger scale, but in general I’m going to leave it tucked away. No more discussion of it here, no automatic forwarding of posts there to Facebook or Google+ or whatever. I doubt that the vast majority of you reading this would find anything at all interesting there: it’s primarily targeted at myself (which, admittedly, is the case for this blog, too!), and I don’t think people who haven’t interacted quite a bit with me would find anything of interest there.

It took me quite some time to get around to writing the post, however; and, when I started typing, I realized why. To dig into Apple’s place in my psyche, I had to explain my history with Apple products, and indeed with computers in general. And, as it turns out, that takes a while. The result is a post where the tail is rather wagging the dog; interesting to me, at least, but one that could most charitably be described as ungainly. (Feel free to skip ahead to the Apple bits.)

At any rate: the computers I have owned, and why I am fascinated with Apple.

Prehistory

My parents bought us an Apple ][+ in May 1982; I was in fifth grade at the time. That was the only computer we had at home through at least 1989, when I went off to college (my brother got a computer when he went to college a few years earlier); hard to imagine these days. I'm not sure when my parents got a second computer, and I know they continued using the Apple ][+ for several years after I left home, at the very least to run a program they wrote to help manage their finances.

I programmed some on that Apple ][+ (the high point being a text adventure that I wrote), but my memory is that I didn't program particularly seriously on it. I used it to write papers (and for some other writing projects, I went through a phase when I wrote short stories and a novella). And I played quite a few games on it, high points being various Infocom games and the first four Ultima games, but I also think fondly of Robot Odyssey, Le Prisonnier, Lode Runner, and Wizardry.

In 1987 (my junior year of high school) I started hanging out more at Oberlin College, and I spent quite a bit of time in the various computer clusters in the school library. I got to be a rather fluent VAX/VMS user, and (presumably through some of the math courses I was taking?) started hanging out with some computer science majors. They got me interested in learning to program in C and Scheme, and in the 1988–1989 school year I started using Unix more. I also remember helping one of them install GNU Emacs on that VMS cluster. (At the time, the computer science’s Unix cluster actually had Gosmacs installed instead of (or at least in preference to?) GNU Emacs.)

Oberlin College could send e-mail to other institutions via Bitnet, and had a DECnet connection with a half-dozen or so other colleges. (DECnet was pretty cool.) It also had Usenet feeds. It was not yet on any of the TCP/IP-based networks that became the internet.

College

When I went off to college in the fall of 1989, my parents brought me a Macintosh SE/30; I used it to write papers in non-technical subjects, play games, and do some amount of programming. (I wrote my papers on technical subjects in LaTeX; I’m honestly not sure whether I mostly typed those on my Mac or on one of the clusters mentioned below.) Continuing my habits from the last two years of high school, however, I spent much much more time on the various computer clusters around the college. I begged an account on the math department’s Sun workstation cluster, though the sysadmin and I had an iffy enough relationship that I didn’t spend very much time there. I begged an account on the computer science department’s Sun workstation cluster as well, where I spent more time. (There were probably Ultrix machines in that cluster, too?) And I got a part time sysadmin helper job on the general school cluster. (Mostly Ultrix machines, initially with dumb terminals but X terminals showed up fairly soon.)

I probably spent most of my time on the general school cluster: programming, playing around, and doing system administration work. Coming out of that, I was much more comfortable on Unix than in any other computing environment, and had installed various bits of free software (mostly GNU tools of various sorts) over and over again. I also had a friend from Oberlin who was then working at the Free Software Foundation, so I was getting a strong free software philosophical dose from him as well.

I took a couple of computer science courses (an intro theory course, a compilers course), but not many: mostly because I could learn how to program computers just fine on my own, partly because I had enough other interests competing for my course time. Also, at that time Harvard’s computer science department didn’t have the buzz that I’d gotten from Oberlin. (Though there were students and faculty members that I learned a lot from, don’t get me wrong.) I was into programming languages and compilers at the time: I did some sort of undergrad research project on compilers, I was a course assistant for a few courses on programming languages and compilers, and I spent three out of my four summers during that period doing programming-related work. (One summer at MITRE, one at DEC, one being a course assistant at Boston College; the fourth summer was spent at a math research program whose main benefit was that I became a not-hopelessly-incompetent cook.)

During this period, I had access to TCP/IP-based networks: ARPAnet had evolved into NSFnet, with the internet coming. The web poked its head out right at the end of this period, but it certainly wasn’t clear to me that it was anything more than a peer to the various other network protocol that were floating around at the time.

Life as a Mathematician

Then, after a year’s interlude, I went to math grad school in 1994. I still had my old Mac, Jordan bought a new Mac (that I played Marathon on), Liesl bought a 486 machine running Windows 3.1 (I played Myst, System Shock, and Dark Forces on that), and at some point I was given an X terminal that I could use at home. Most of my computer time was spent on the math department machines, though; and I essentially wasn’t programming at all during this time period. Also, a friend of mine gave me an NES, which started me on a spiral of depravity that I still haven’t emerged from. (One of the first things I did after getting my postdoc acceptance letter was to get a Nintendo 64; good thing my thesis was almost completely written by then…) Actually, though, my dominant leisure activity during that time period was reading books, I averaged more than a book a day over the course of grad school.

I can’t remember if I moved my old (9 years old at the time!) Mac with me when we went to Stanford in 1998; we moved Liesl’s computer, but I’m not sure if we ever turned it on. In general, I did my computing on the machine in my office at the math department; I can’t remember its specs (though I believe it had 4 GB of hard drive space?), but it was running an early Red Hat Linux version. I still wasn’t programming significant amounts: I was busy being a mathematician and a parent (Miranda was born in 1999), trying to figure out how to teach well, and playing video games, doing the latter almost exclusively on consoles instead of computers.

Returning to the Apple theme that triggered this post: during this period, my interest in Apple was quite low. I had a Mac, but barely used it; I certainly wasn’t going to use Windows machines, but really my focus was on Unix. (So, in terms of recent computing deaths, Dennis Ritchie’s is a lot more relevant.) I was at least partly anti-Apple at the time: the Free Software Foundation and the League for Programming Freedom had boycotted Apple because of their use of user interface patents, and that had an effect on me.

Transitioning

In 2002, academia and I came to a mutual decision that we weren’t as good a fit as I had thought. Fortunately, the Stanford math department was willing to let me hang around for another year; so I spent half my time that year teaching calculus and half my time brushing up my programming skills. I learned C++ and Java (object-oriented programming was far from dominant when I was an undergraduate), and contributed a fair number of patches to GDB.

It also became clear that I wouldn’t be able to depend on my employer to provide my computing resources; so I bought domains to use for my various internet presences, and, for the first time since 1989 (13 years!), acquired a new computer. It was a Dell Inspiron 8200 laptop, a behemoth that was barely portable (and that, fortunately, I rarely needed to carry anywhere); we set it up to dual-boot Windows and Linux, and I spent the vast majority of the time on the Linux side.

Also, befitting my academic nature, I started reading books and going to talks. A lot of the books that I read were C++-specific (and I learned a lot from them, C++ is an extremely interesting language); in terms of non-language-specific books, the refactoring book had a big impact. The talk that had the most impact on me was one that a couple of researchers in a local corporate think-tank (?) gave about their experiences with something called “eXtreme Programming”; that was my first exposure to Agile software development.

The GDB work led to consulting work at a startup called Kealia, and I started working there full-time when I left academia in the summer of 2003. We got acquired by Sun a year later; soon after the acquisition, I became a manager, albeit a manager who spent a lot of time programming.

Agile

I spent a lot of time trying to understand Agile software development over the next five or seven years. At first, I was just trying to do this on a personal level, practicing refactoring and trying out test-driven development. Kealia’s legacy code provided some interesting challenges on the former front; the company also already had a bit of a testing culture when I showed up, and we experimented with going farther in that direction. And becoming a manager got me interested in other aspects of Agile: the more explicitly people-focused aspects, the planning aspects. And, as part of planning, the idea that programmers don’t make all of the design decisions (which was quite a change from working on GDB!): other people have a better idea of what the end users really value, what will work well in their context.

As an academic, I’d been quite ivory tower (at least aside from my interest in teaching); that changed. I was working at a startup which got acquired by a larger company that had suffered a lot over the last few years; part of startup life is trying to figure out how to make your business work, and Sun was trying to figure that out at a larger scale. Sun also put enough resources behind StreamStar (Kealia’s video server project) that we had quite a lot of room to experiment with different business strategies, trying to find one that would stick. (Far too much room: the fact that Sun didn’t cancel StreamStar years before I eventually left was a sign of Sun’s own management problems.)

My boss was a big fan of Clayton Christensen’s disruption theories, and I got to see both sides of the difficulties of disruption first-hand. Sun was a large company that was already far along the path of being disrupted by commodity hardware running Linux, and was trying to figure out how to deal with that; StreamStar was trying to disrupt the existing broadcast television infrastructure, replacing it with IP-based solutions. In neither case did we navigate the difficulties well, but I have quite a bit of sympathy for both sets of difficulties: surviving being disrupted is extremely difficult, and when it comes to broadcast television, you have to deal not only with the existing technological infrastructure but with the existing broadcasters and existing content providers. So it’s not surprising that we failed to disrupt broadcast television delivery, whereas Youtube was much more successful with its end run around the last two issues.

During this time, I won an iPod (one of the hard-drive based models), and a couple of years later, an iPod Nano at company raffles. I wouldn’t have bought the first iPod on my own, but its presence made my jogging a lot more presence; I probably wouldn’t have bought the iPod Nano on my own, but I was quite surprised how much more I liked its small size, the lack of skipping, and the general elegance of its design.

Our Dell laptop died in 2006, and had been showing its age enough by then that I was already planning to replace it. For my own Linux use, we got a Sun Ultra 20; to have a computer that Liesl could use and that I could run iTunes on, I got a MacBook Pro. This was the first model after the Intel transition; I felt more comfortable going back to the Mac instead of having a Windows machine around, and the fact that there was now Unix underneath MacOS was a real bonus. (Incidentally, back in 2003 I’d turned down a job offer working on GDB for Apple: I like Unix and the GNU toolchain, but I wasn’t really interested in specializing in the latter.)

At some point while I was at Sun (probably in 2008), I got an iPod Touch. That was really a revelation to me: it was wonderful having a little computer in my pocket, one that was already fairly versatile and was becoming more so every year; I had Wi-Fi access most of the places I spent time (there was even spotty Wi-Fi available from Google when wandering around Mountain View), but I could tell that having a phone network provide almost constant network access would be so much better.

But more than that: Tweetie made me sit up and take notice. That was the Twitter client that eventually became the first-party Twitter client; and despite running on this quite small device, I far preferred using it to any Twitter interface I had available on computers that didn’t fit in my pocket. That didn’t make much sense to me; clearly there was something going on with design that I didn’t understand and that could make a real difference.

At this time, I was also getting more and more tired with having Unix on my desktop. I love Emacs, but it’s stuck in the stone age in so many ways: what really drove that home was once when I fired it up on a machine where I didn’t have my standard .emacs file and realized that, by default, Emacs put the scroll bars on the left. That may have been a perfectly reasonable decision when it was first made, but it wasn’t any more and hadn’t been for at least a decade; did I really want to be working with tools that were so willfully ignorant about design conventions? GNOME had helped civilize X Windows, but it had only brought the experience up to a minimally acceptable level, and even so there were too many non-GNOME applications around.

Reaching the Present

So, when I started work at Playdom, I asked for a Mac for my work machine: that way I could have a Unix command line and tools combined with a GUI that accepted the idea that design was a virtue. Which the IT department was oddly hostile to: you’d think that a company with a large contingent of graphics artists that deploys software to Unix servers would be a natural fit for Macs, but Playdom had its quirks, and its IT department was definitely one of those quirks.

At around this time we got a second Mac laptop at home, and I got an iPhone. (My first cell phone; I am a luddite at times.) The Ultra 20 died; I decided that I wanted to continue to run a Linux server (e.g. to host this blog), but that I would prefer to interact with it through an ssh connection, so I got a virtual machine at Rackspace. Also, I was getting older, and carrying around a laptop during GDC 2010 put a surprising strain on my back; the iPad had been announced, so I decided I’d get one the next time I went to a conference. Which happened sooner than I expected, since I decided to go to GLS later that spring.

My back thanked me for the iPad purchase; but my psyche thanked me as well, to a surprising extent. I found that I preferred reading e-mail on the iPad to reading e-mail in a web browser, and that I far far preferred reading blogs in Reeder than through Google Reader’s web interface, whether I used the latter to go to the blogs’ web pages or stuck with the RSS feed. In both cases, the iPad acted like a wonderfully adaptable piece of paper: the words I wanted were right there, with enough style to be pleasant (unlike the Google Reader web interface) but without any surrounding crap (unlike blogs’ web pages). Having a screen that was much smaller than computer monitors that I was used to, and that was in portrait mode instead of landscape mode, turned out to be excellent for letting me focus on what I was reading. (As it turned out, I even slightly prefer reading blogs through Reeder on my iPhone over reading them through a web interface on a standard computer, despite the rather-too-small size of the former’s screen.)

In early 2011, one of our laptops died; rather than replace it with another laptop, we got an iMac and a second iPad. Our current technology roster is an iMac and a MacBook (one of the white plastic ones); two iPads (one from each generation); three iPhones (one from each of the last three generations, though the oldest one is being used by Miranda as an iPod Touch instead of as a phone); a virtual machine located elsewhere running Linux; and half a dozen game consoles. (My rate of technology purchases has increased enormously since 1998.) Also in 2011, I started working at Sumo Logic; as is typical in startups around here (at least judging from the ones I’ve interviewed at), it’s largely a Mac shop for development (with deployment happening on Linux virtual machines), and my coworkers generally prefer various Apple products for personal use, though there’s more variation on the personal side.

So: that’s the computers and other technology that I’ve used over the course of my life. Apple played a large role when I was young and more recently, but in the middle there was a long phase where my norm was Unix + GNU toolchain, with a strong free software ethos. Why did I shift out of that, what’s behind my recent fascination with Apple’s products and, increasingly, Apple as a company?

Habitable Software

The first is the concept of “habitable software”. I talked about this last year: the idea is that there is software that my brain shies away from using, and there’s software that I actively look forward to using, where the thought of using it relaxes me or brings a smile to my face.

I actually think that console gaming gave me my first nudge in this direction. You stick the cartridge into the machine, you pick up a controller with a relatively constrained set of inputs, you turn on the machine, and it just works. Note too that a console controller, unlike a mouse and a keyboard, is explicitly designed for the task at hand: yes, gamepads may have a few too many or too few buttons and sticks for a given game, but at least it’s focused on the domain of playing games. (Hmm, maybe the controller/game match is why I think back on text adventures with so much fondness?) I keep on installing Windows on machines with the thought that I’ll finally play the many important PC games that are missing from my background; and I keep on deciding that no, I really don’t want to put up with the crap that PC gaming makes you deal with.

But shifting from X Windows back to the Mac also gave me a huge shove towards being sensitive to habitable software; and going from the Mac to iPhone/iPad software like Tweetie and Reeder was, in its own way, just as large a leap. Every time I use X, I find something that feels wrong; a Mac feels neutral, but I don’t generally look forward to turning it on; Tweetie and Reeder make me actively happy. It’s not just software that I’m learning from, either: I was surprised how much happier I was with the iPod Nano because of its small size, light weight, pleasant screen, and lack of skipping.

The Unix command line also makes me actively happy. It’s wonderfully coherent; for certain tasks related to writing and, especially, deploying software, it’s just what I want, I love the interface that it presents to me. So it’s no coincidence that I do my programming on machines where a Unix terminal window is one key combination away, and that I use virtual machines running Linux to deploy software on: I feel completely at home in those contexts when working on those tasks.

Designing Software

Habitability is how I like to express the importance of design in software to me as a user. But I’m a programmer as well, so I see design from that side as well.

When I was younger, I spent much of my programming time concerned with tools for programmers: thinking about programming languages and compilers, working on GDB. In those contexts, I didn’t have to think too hard about design: I was an acceptable proxy for the end user for the software, so if something felt good for me, then that was good enough.

That’s a relatively unusual subset of software, however; as I started to work about other kinds of products, I realized that my design instincts wouldn’t do a very good job. And, at the same time, I got interested in Agile: and one of Agile’s main tenets is that design concerns (personified as the “Customer”) are paramount when deciding what to work on. Not that the technical details aren’t important as well—you get great benefits from keeping your code flexible and well-architected—but ultimately it’s not programmers’ jobs to decide what’s important to present to the users.

Even though it carves out a space where design can happen, Agile isn’t actually very good at giving you advice at how to design well: specific recommendations are much more focused on the programming side of things (e.g. refactoring, test-driven development) or the programming/design interface (estimating, iterating) than on the design side of things. Also, my talents and instincts are much stronger on programming than on design: I still have a lot of room for improvement, but I’ve got some understanding of what’s involved in writing code that’s clean and functional from a technical point of view, whereas I have much less understanding of what’s involved in developing a product that people are actively happy to use.

And, to produce really great products, I’m not convinced by Agile’s engineering/customer representative split. The Lean concept of a Chief Engineer who’s immersed in both worlds seems much more powerful to me, and I see around me wonderful pieces of software written by single individuals, or startups (including Sumo Logic!) run by people with both a vision for what they want to produce and the technical chops to help bring that into existence.

Apple can probably be argued as providing evidence on either side of the argument about that split, but there are clearly individuals who made a huge difference in its products. Apple also points out how ludicrous it is to label the designer as the “Customer” if you really want to produce something new and great, and at the limits of the analytics-focused mindset that I saw so much of at Playdom; in general, Apple’s approach to iteration seems interestingly different from yet related to Agile norms. And their systems approach gives Apple many more design knobs to turn than they would if they were exclusively a software company. (Or exclusively a hardware company, of course.)

Business Success

Back in my academic days, I didn’t care about practical applications of my research. When I started working for startups, though, that changed: if you don’t have your eyes on how you’re going to make money out of your startup, you’re doing the wrong thing. (Not that startups don’t have a heavy dose of ego satisfaction in them, of scratching your own itch.)

Once I started paying more attention to making money, it turns out to be totally fascinating: if you like complex systems, capitalism is full of them. Just figuring out cash flow: where money is coming in, where money is going out, the difference between those two in quantity and in in time. So many possibilities there!

Apple’s business success over the last decade is staggering, of course. But they are fascinating far beyond their simple profit figures: the consequences of their systems approach to design, their use of their savings to buy vast quantities of parts from their component vendors (and even to allow those vendors to purchase tooling!), the role of their physical stores, the list goes on and on. There’s still a stereotype of Apple as making overpriced products, but their competitors are finding it very difficult to build products with the hardware quality of the iPad or MacBook Air while maintaining any sort of profit margin at all.

Of course, lots of startups aren’t focused on being profitable: Silicon Valley is full of company that are trying to get eyeballs, hoping that profitability will come somehow, and perfectly happy to sell the company to somebody else who can worry about that problem. We see echoes of this in the Android / iPhone fight, and these days I’m generally more interested in making money than having users without a good business model; but the iPod shows that you don’t always have to compromise, that you can win on both fronts.

Disruption

I mentioned Clayton Christensen’s disruption theory above: living in Silicon Valley, there’s no end of startups trying to remake an industry, no end of once dominant companies that stumbled, got bought, died.

Apple looked like it was following that latter trajectory; it pulled out of its decline like no other company. And did so in a very interesting way: not only did it disrupt other industries, it also disrupted itself, with the iPhone cannibalizing iPod sales and with the iPad cannibalizing laptop sales. This is extremely difficult to do: existing successes almost always lead to institutional antibodies that attack new products, leaving that success to newcomers.

Over the last decade, we’ve all become aware of disruption; the companies that can figure out how to repeatedly harness the powers of disruption will be the ones that flourish (the ones that survive at all!) over the next few decades. They will have to learn from Apple. And if I’m going to continue to build a career working at exciting companies, I’m going to want to learn from Apple, too, to help me figure out what sorts of qualities to look for the next time I’m on the job market, to pick employers that will disrupt successfully!

Repeatable Creativity

Disruption aside, though, there’s something amazing about Apple’s run of products over the last decade: one interestingly new product after another. I wish I knew how they did that.

It’s easy to ascribe this to a solo genius theory; but, while I don’t want to minimize Steve Jobs’s contributions, I don’t think that’s all that’s going on here. Pixar is another relevant datum: they’ve also managed to be consistently creative, and they continued to do that after Jobs sold the company to Disney. Perhaps because of the domain, people don’t credit Jobs with the same influence on Pixar’s repeated creative success as they do with Jobs; but, to me, the two companies suggest that Jobs has learned something about helping groups to innovate repeatably in a way that goes well beyond his personal contributions.

Over the last couple of years, stories have come out about some sort of Apple University, which seems to be trying to systematize those ideas. This reminds me of Toyota’s conscious efforts to improve themselves as a learning company; Apple is, sadly, much more secretive than Toyota, but I hope more of Apple’s methods will become public over the next decade. And, of course, I hope that Apple will be able to continue to innovate over the next decade, that their innovation really is due in part to a systematizable process.

Bad Apple

During the mid-90′s, I was down on Apple. I hoped that had gone away with the new decade, however: their user interface patents had gone away, and they were active open source contributors, though that clearly wasn’t the company’s main focus.

Unfortunately, those problems have come back in spades. By far the one that I find most distasteful is their aggressive use of patents: I think software patents are bad for the industry, bad for the world, and while I’m more and more bored by other companies that seem to largely be trying to produce knockoffs of Apple’s products, I very much support allowing those companies to do so.

Apple’s recent systems are also much more closed than computing platforms I’d used before then. I would expect that to bother me; for whatever reason, though, it actually doesn’t particularly. Certainly it would if I didn’t have ample access to other computing platforms, or if the tools to develop for iOS platforms weren’t so readily available; and while Apple teeters on the edge of behaving in a manner I find unacceptable in their application approval process, for whatever reason I generally think they’re okay. (I’m actually more worried about Amazon’s behavior in that regard.)

I’m being ungenerous in saying this, but: these days, when I read Richard Stallman complaining about Apple’s closed systems, part of my brain interprets that as RMS wanting it not to be his fault if other people don’t have software they want to use: RMS has made an open system, it’s other people’s fault if they don’t take advantage of that. These open systems are, in all serious, a great good: but actually having good software on your computer is also worthy, and having software that’s a joy to use is a great good. It’s fine if having well-crafted software for the non-programming public isn’t RMS’s concern, there’s no reason why it should be; but I see him as a single-issue voter whose issue is no longer dominant to me, and who is willfully blind to other issues that are important to me.

To those of you who have read this far: I salute you. And to those of you who don’t like Apple’s products, who don’t care about what Apple has done as a company: that’s great, there’s no reason why others’ interests should be my own. And there’s no question that company has flaws, does things I really don’t like. But I’m fascinated for many reasons by what Apple has done over the last decade, and I fully expect to be trying to sort out the implications for much of the next decade.

Some Jobs-related posts that I particularly enjoyed:

• John Shook asking Was Steve Lean?
• Another lean-focused post, this time from Evolving Excellence
• Horace Dediu on what Steve Jobs didn’t do.
• A podcast reminiscence from John Siracusa.

The contents would probably fit in fine on Tumblr, but I decided not to go that route, for better or for worse. For one thing, all things being equal I’d rather have my writings show up on platforms that I control; for another thing, it lets me experiment with form more than I could otherwise. The posts on the fragments blog are extremely bare, completely devoid of bloggy apparatus such as links (not even links to the next/previous posts) and comments; I’m curious to see what effect those formal concerns will have on the content. It lends itself to a feeling of isolation, reinforcing a certain morose nature of the posts there; I’m okay with that for now.

The software allows me to assemble these fragments into “mosaics”: those mosaics consist of chains of fragments, with optional nesting. Part of my motivation there comes from my fascination with sutras and commentary: the form supports that, though it supports other compound forms as well. To be honest, I’m not at all sure how often I’ll write mosaics: if my brain is in a mode where it’s thinking about writing content of that length, I may find that my brain is really composing a post for this blog instead. We’ll see; the possibility is there.

Right now, it exists only as RSS feeds: one for fragments and one for mosaics. (Both feeds contain the full text for the posts in question, so there’s very little reason to actually go to the website.) You can go to the top level page for the site and the index pages for fragments and mosaics, but you’ll currently get a blank page if you do any of those. I plan to fix that at some point over the next month or so, but doing so isn’t a top priority for me. (And I’m not at all sure what those aggregating pages should look like in the first place.) I’d also like to improve the presentation of fragments and mosaics on the iPad and (especially) the iPhone; doing that is a slightly higher priority.

As is probably clear from the above, I rolled the software for the new blog myself. It’s all quite straightforward, using a markdown-to-HTML converter plus a bit of Ruby glue. (I used atom-tools to generate the RSS feeds.) It uses plain text files as the source, and spits out flat files that are served up by Apache: no databases, no run-time web page generation. I imagine I’ll throw it up on github once I’ve teased apart the presentation parts from the text for the fragments themselves. Though I’m also not entirely sure what I’ll get out of doing that: I doubt anybody else will ever want to use the software, and it’s not particularly representative of my programming style, in particular containing rather fewer tests than I normally write. It’s certainly nice how easy it is to roll your own blog these days, it’s just a few hundred lines of code in total if you don’t count the libraries that I’m depending on.

In general, I expect that the audience for these fragments will be quite small: certainly I doubt that most people who read this blog will find anything interesting there, and I’m not committing to writing there long-term at all. It’s probably only for people who know me personally, and not even for most of them; there’s a pretty good chance, in fact, that I’m the only audience member for the fragments! If interesting thoughts come out of my writings there, those thoughts will make their way over here.

I’ll use this as an excuse to write down all the places where you can find me. Besides this main blog and the new one, other places where I write are:

• Twitter.
• My linkblog.
• My gaming diary.

You can also find me online playing games and talking about games on Thursday evenings with the Video Games and Human Values Initiative. (Which I highly recommend, the conversation over the last few months has been great.) I’m malvasia bianca on Xbox Live and “davidcarlton” on Game Center; I have PSN and Steam accounts, but never use them, so I’m not even going to go to the effort of looking up what the account names are. And I have accounts on Facebook and Google+, though the content there is a subset of the above, so there’s no particular reason to link to me on either of those networks. (In particular, my Facebook wall consist entirely of forwarded Twitter posts and links to the posts on my various blogs.) If you’re particularly obsessed with the minutia of my life, you can look at the list of games I’m playing (all of which eventually get mentioned on this blog anyways) and books I’m reading, but I recommend seeking professional help instead of going that far.

One song that stood out, however, was She’s Always A Woman. It’s full of chords and chord progressions, to be sure; but the chords are all arpeggiated, and the chord changes are relatively frequent. That (combined with the fact that the game only has you playing with your right hand, so you don’t have the grounding of the bass part) means that, while the chordal structure of the piece is on display, it’s hidden a little bit more than in the other pieces: you can feel it in your hands, but there’s an extra layer of artistry masking it.

I’d been looking for a finger picking piece to learn on the guitar, and I found a good candidate last week: a really lovely arrangement of 風の丘 (Kaze no Oka, which means something like Windy Hill) from Kiki’s Delivery Service. It’s everything that I was looking for: not just lovely to listen to, it also has distinct melody and bass lines, with arpeggiation relating the two.

These two pieces are both somewhat similar, with arpeggiation hiding underlying chordal structure. In 風の丘, you have the added benefit of the bass line grounding you, but the flip side is that the arpeggios aren’t as worked out and there are more purely melodic bits, so on the whole the structure is a bit more hidden.

Or maybe it’s just as obvious but I’m simply a much worse guitar player than piano player (that last part is unquestionably true), so my hands aren’t nearly as good at seeing the structure that’s there? Certainly it’s the case that trying to memorize 風の丘 is like pulling teeth: I’ll play a couple of measures, and by the time I’m done with the second measure I’ll have completely forgotten the notes that began the first one. Or at least that’s the case if I’m approaching the song as a collection of notes: if I can find a chord that’s a decent match for a half-measure, then I have a chance at being able to remember that half-measure the next time I play it.

Only a chance, though: I’m very bad at translating melodic relations between notes into places to put my finger on a guitar, frequently not even choosing the correct string. Also, for me, every guitar chord is an island, I just don’t have common chord progressions ingrained into my hands yet. I’m amazed at how much more easily I can pick out melodies on a violin than on a guitar: the technical challenge should be very similar indeed, and I’m certainly not a good violinist, but apparently those middle school orchestra years stuck with me more than I realized?

Anyways: programming. One of my favorite parts of programming is refactoring; which is a good thing, because I seem to unable to not spend a lot of time reworking legacy code! When it’s going well, refactoring can be magical, with latent the latent structure of the code being teased into visibility by your fingers.

And when I was playing She’s Always A Woman, my main thought was: why isn’t programming like this for me more often? That reaction is certainly a sign that I should step up my game more, really dive whole-heartedly into code and see what I can learn from reworking it.

I’m not sure that this is analogy between musical structure and programming structure is a particularly good one, but if we run with it, where does it lead us? One of the interesting things about She’s Always A Woman is that the structure isn’t completely obvious: there’s an extra level of arpeggiation on top of the chords. Should I try to imitate that while programming, getting close enough to the core structures so that they provide a solid foundation for my code, while masking them with an extra layer of artistry?

Or maybe I’m wrong in fixating on chords: maybe the arpeggiation itself should be thought of as an extra layer of structure, increasing the structural richness of the piece rather than hiding it? I’m fairly sure that my difficulties with 風の丘 support this interpretation, because while figuring out the best chord to match each half-measure has been a huge help, it’s clearly only a first step. In particular, the fact that I’m not comfortable with melody on the guitar, that I can’t play through scale after scale, is a significant hindrance.

Also, returning to chords: it’s not just chords that are important, it’s chord progressions, relationships between chords. Abstracting a bit, what this is pointing out is that patterns alone aren’t sufficient, you really want a pattern language to relate them.

(And: dissonance! Glorious, wonderful dissonance!)

Having written this, I still don’t know how much to make of this analogy, though the response I got from the eight-tweet version of this blog post suggests that I’m not the only person who is drawn to both sides of this discussion. Be that as it may, the next steps are clear: dive into the details, on both the musical side (memorizing 風の丘!) and the programming side, and I’ll be a better person when I come out the other end.

And I should listen to my hands.

$('answer').update("<%= escape_javascript(render :partial =>
'answer', :object => @item) %>");

and I wanted to take apart the HTML returned by that render :partial section.

I eventually came up with a solution that I’m happy with, so I’ll mention it here in case anybody else runs into the same problem and ends up here via Googling.

The partial in question contained a p element with class qa; let’s assume that it’s body is supposed to be text_to_assert_on. Then here’s the test that I ended up with:

  def unescape_javascript(escaped)
    escaped.gsub("\\'", "'").gsub("\\\"", "\"").gsub("\\n", "\n").
      gsub("\\\\", "\\").gsub("<\\/", "</")
  end

  def assert_encoded_update(body, element_to_update)
    assert_not_nil(/\$\('(.*)'\)\.update\("(.*)"\);/ =~ body)
    assert_equal(element_to_update, $1)
    yield(HTML::Document.new(unescape_javascript($2)).root)
  end

  def test_get_answer
    get :index
    post :answer, :format => 'js', :item => @one.id

    assert_encoded_update(response.body, "answer") do |replacement|
      assert_select(replacement, "p.qa", "text_to_assert_on")
    end
  end

I don’t claim that this is perfect (there are probably more cases that unescape_javascript should handle), but it worked well for my purpose.

Which means that people sometimes get woken up in the middle of the night. Initially, it was the same couple of people, but that’s obviously completely unfair (and goes against the Whole Team philosophy that I prefer), so now we’re rotating that job among all the developers. I had the pleasure of being on call a couple of weeks ago, and it was a lot more interesting experience than I expected.

And yes, part of that interesting experience involved staying up later in a couple of evenings than I would have liked, and being woken up a couple of times. The problems there happened to involve a piece of code that I was relatively familiar with; in fact, during that week I’d already been experimenting in test deployments to see where and how it would fall over, I just didn’t manage to get far enough ahead of production scaling to give us quite enough breathing room! But at least it meant that I had some idea of what to look for and what to do, which certainly helped. (And don’t get me wrong, even when I was the primary person on call, a lot of other people were ready and eager to help as necessary, and somebody else implemented the initial stability fix.)

It turned out, though, that being the primary person on call when issues like that come up has an interesting affect on my brain. In the past, when people had talked to me about issues that had come up when they were on call, I was happy to help fix things, but my brain was treating the problem somewhat abstractly and as a distraction to what I’d been planning to do that day. Whereas running into problems when I’m on call rather quickly puts my brain into problem solving mode, with the result that when I showed up at work the next day I knew exactly what I wanted to be working on, what steps I wanted to take, and where I needed to advocate for further work. So the upshot was that I felt a lot more focused for the rest of the week (well, when I wasn’t feeling sleep-deprived!), and it carried over to the next couple of weeks: I can program pretty effectively when I’m trying to answer the question of “what can I do to prevent other people from being woken up for similar reasons?”.

I am, of course, hoping not to always have to keep that motivation in the front of my mind when I’m programming. (And fully expecting that to be the case: we’re doing a very good job of leaping on small problems now and trying to take a systemic approach to solving them instead of a patchwork approach.) But it’s a helpful reminder of the virtues of Whole Team: exposing everybody to problems means that everybody has a chance to really feel their effects and get their brains directly interested in solving those problems.

And, as a side effect, it means that non-bug work can go a lot faster, too: in particular, it’s been great this week to have much faster startup speed for the component involved in the aforementioned issue, because that made it so much easier to run experiments. Goodness all around.

Rails is a moving target, and in particular the release of Rails 3.0 last year brought a fair amount of changes. I didn’t upgrade immediately, partly because I was busy with other things and partly because authlogic took a while to be upgraded to work with Rails 3.0. Eventually, though, authlogic got fixed, and Rails 3.1 release candidates started to appear, so I figured I should upgrade sooner rather than later or I’d be setting myself up for even more pain in the future.

As always, there was a very helpful Railscast. So with the help of it and the rails_upgrade plugin, I created a branch and started working at it.

Getting the basics working wasn’t too hard, so after a couple of hours I had something that passed all of my automated tests without any deprecation warnings. Unfortunately, when I fired it up in a browser, I found that the code to show the answer to a question didn’t work. I wasn’t completely shocked to see that, because I was aware that the move to unobtrusive JavaScript was one of the big changes in Rails 3; I knew some of the things I had to do (make sure that I included rails.js and the csrf_meta_tag), but the exact details of how to handle replacing part of a web page with code from the back end wasn’t entirely clear to me, and I didn’t find a web page that gave a completely braindead cookbook.

Having said that, it didn’t take too long to figure out an answer. And, in case it helps anybody else, here’s what I did: I started with a section of my view that looked like this:

<% form_remote_tag :url => { :action => :answer, :item => ask },
:update => "answer", :html => { :id => "show-answer" } do %>
<%= submit_tag "Answer" %>
<% end %>

and ended up with this:

<%= form_tag url_for(:action => :answer, :item => ask),
:remote => true, :id => "show-answer" do %>
<%= submit_tag "Answer" %>
<% end %>

And in the controller method I removed the render :partial line at the end, and added a view answer.js.erb containing the following:

$('answer').update("<%= escape_javascript(render :partial =>
'answer', :object => @item) %>");

Which is quite straightforward, and certainly the generated HTML is nice. The one thing that I don’t like about it is that I don’t know how to do a good job of testing what the controller method returns: when the controller method rendered HTML, I could use assert_select, but that gets harder when it renders JavaScript. (Update: I figured out a good way to test this.)

The next issue ws that the keyboard shortcut for pressing that button didn’t work. This had actually been an issue when I originally wrote that code, and the method I’d used then (calling the onclick action) no longer worked. The solution I came up with was to modify rails.js to make handleRemote public, and to call it directly, but I’m not thrilled with that, because there’s the danger that the code paths for clicking and for using the keyboard shortcut could diverge. Eventually I’ll probably switch over to using jQuery instead of Prototype, maybe $(...).click() will do the right thing there?

At that point, I pushed the code live, quickly realized that the display for newlines was broken, and reverted back. I’d already converted to using the new automatic HTML escaping mechanisms when they hit Rails 2.x; unfortunately, they changed in Rails 3.0.8 (and stayed changed in Rails 3.0.9), in a way that meant that the result of concatenating html_safe strings was no longer html_safe. I solved it by sticking an html_safe at the end of the entire block, but I don’t like that because it makes it too easy to accidentally introduce HTML-escaping bugs; maybe I’ll file a bug report on the issue.

After that, everything worked, and from start to finish it probably took around five or six hours in total (spread over a week or so), which is a quite reasonable amount of time for a major upgrade. And it feels to me like the code is faster after the upgrade, which was a pleasant bonus! Also, it got me chatting with a friend of mine who also uses memory, resulting in my improving the layout on his Android phone (to match the way it looks on iPhones); always nice to have an excuse to improve software like that. And I’m glad I got this done before Rails 3.1 appeared.

But I also wish I’d been paying a bit more attention to Rails’s evolution, so I would have been a bit more familiar with what I was in for. Honestly, I still feel a little bit conflicted about this—I don’t currently plan to become a Rails expert, and I expect I’ll give Lift a try the next time I want to write a web app—but I like Ruby and Rails enough that I don’t want to lose touch with them. (And I really do depend on this memory program, so I very much want to keep it working!) For now, I’ve subscribed to the Ruby on Rails: Talk mailing list; the signal-to-noise ratio there is, unfortunately, a lot worse than I’d like, but there’s enough signal that I’m sticking with it for the time being. And I’ll try to find time to watch a higher percentage of Railscasts than I had been doing.

In particular, we’ve taken care of a ridiculous amount of house stuff. Earlier this year, we got the only major bit of planned house work taken care of, namely fixing our front door / steps. (And that was before the GTD implementation changes.) But there were a lot of small items to take care of, too, items that had been bugging me for months (some of them for years, actually).

So, when I looked at those items, I decided that yes, they really were high enough priority for me to keep them on my Next Action list. The result was that, within half a week, I’d made a phone call to kick off getting non-plumbing house items taken care of; and as soon as that was done, I made another phone call to start dealing with the plumbing. The upshot:

• Our dryer is no longer blowing lint into our crawl space.
• We are no longer being driven crazy by flickering lights in the kitchen.
• Two towel racks and a rag hook are now firmly attached to the wall.
• Two sinks have working drain catches.
• The showers are all regulating their heat properly.
• The upstairs toilet doesn’t drip. (I can’t take (almost) any credit for that one, though, it was all Liesl’s doing.)

Which is great! And the best thing is: it was really easy. All I had to do was decide that these tasks were important: I actually already had phone numbers for people to call. In one of the cases (the non-plumbing case, I’d already used the plumber in question twice before), I wasn’t sure that he was the right person for the job, but that worked out great. Which means that it will be even easier for us to take care of this sort of thing in the future: in particular, in a couple of years we’re probably going to do some kitchen work, and now we know whom to call when we decide to think seriously about that. Obviously it would have been harder if I hadn’t already had an idea of whom to call, but still, the same principal applies: decide that something’s important, figure out the next step to make progress towards it, and do it.

So, with the house work out of the way, what next? I’m actually working on a few too many things right now: each of Rock Band 3 and Minecraft is taking up rather more time than I’m used to spending on a single video game, I’m going through a book on iOS programming, and I’m reading about CoffeeScript and using it to write a bare-bones game framework for a project that Miranda and I are vaguely working on. And those are all substantial enough that it’s hard to make progress on all of them.

So I should wind them down. Rock Band 3 is far too rewarding for me to want to stop it now—I’m just getting to where I’m actually learning to play guitar!—so I think I’ll keep going with in for the indefinite future. (And, honestly, given that I’ve been playing one Rock Band game or another for three and a half years straight, why stop now?) And the game project with Miranda is the most potentially rewarding of anything on the list, so I’ll keep on going with that.

I don’t have as much active energy to write iOS software now as I did two or three months ago, however; so, while I plan to finish going through that book, I probably won’t actually do anything concrete with that knowledge in the short term. And, as much as I love Minecraft, I may be starting to reach a point of diminishing rewards, so it may be the case that, after finishing my train stations, I’ll give that game a pause, too.

Or maybe not! Who knows, maybe at some point over the summer somebody will come up with a great iPad game proposal to work on with me, and I’ll dive into that; or maybe the Minecraft railroad work will suggest further projects that I have to build. I suppose it’s even possible that I’ll get frustrated with Rock Band Pro Guitar and give up on it in a month or two. All I’m committing to is what I’m doing in the short term, and I’m planning to keep all four of those strands going for the next few weeks; after that, all bets are off.

At any rate: yay for limiting (and being honest about!) work in progress.

• I was making some changes to a third-party library that was already using mockito in its unit tests, so I decided to give it a try. And, after a half-day of experiences, I will tentatively declare myself to be a fan. My previous mocking experience was with jMock, and while jMock may work as well for code that was written in a GOOS style from the beginning, I really appreciated the fact that mockito didn’t insist on tracing every single application; its willingness to mock classes by default was useful in the context of the work I was doing as well. And I liked not having to go to the extra weight of subclassing Expectations in every single test. So I recommend that anybody programming in Java who is curious about mocking but is worried about what it will involve should give mockito a try: it’s remarkably light-weight and pleasant.
• I wanted to add a polling thread wrapper around a metrics class that I’d written, and rather than do that by hand, I decided to look into Java’s reflection / dynamic proxies facility. And wow, writing a dynamic proxy in Java is easy! Maybe it’s not quite as trivial as overloading method_missing, but it’s only a little bit more work than that: I had a proxy up and running in a handful of minutes, and it was doing everything I wanted only took an hour or so. (And the vast majority of my code was talking about threads and caching, which is exactly what I wanted it to be talking about.) So score one for Java.

The code base for my new job is rather larger than the code base at my last job, which means that I have to start thinking about the build process more than I’ve been in the habit of doing recently. I know how to set up a good build system for C-based languages (hint: gcc -MD is your friend), but I’ve never felt as comfortable with the options for Javaish environments, even for relatively straightforward projects that are just building a single program.

And we’re not building a single program: it’s a distributed system, with a collection of programs using some common libraries and some distinct libraries. Which is quite similar to the situation at Kealia, but the build system feels rather different. Part of that is related to the source code layout (we’re putting each module in its own git repository), but part of that is due to differences in the Java/Scala way of compilation and the C-language way of compilation.

At Kealia, our product code was spread across three directories: interface, which had one subdirectory for each library, containing the public header files for that library; lib, which had one subdirectory for each library, containing the .cpp files and private header files for that library; and prog, which had one subdirectory for each program, containing the code specific to that program that we didn’t feel like pulling out to a library. So the build process was in two phases: it built all the library code in parallel, and then all the program code in parallel. (If I’m remembering it correctly, actually, the build system was happy to start working on program code even if some of the libraries weren’t done building, but at any rate dependency chains at the library/program conceptual level were never more than two deep.)

In Javaish languages, though, that doesn’t work, for the simple reason that the language doesn’t have a notion of a header file: if library A depends on library B, then you have to build library B before library A. Java programmers like to talk about how, in C++, header files mean that you have to write your class interfaces twice; that’s a quite valid complaint, but it bites you in situations like this. Though the situation isn’t quite as simple as that description makes it sound: in a lot of situations, Java interfaces end up acting a lot like C++ header files, giving you some amount of separation of compilation while also requiring you to write some of your class interfaces twice. Certainly proper use of interfaces is important in reducing long dependency chains; I don’t think we’ll be able to get down to two levels of dependencies, but what is the shortest chain that we can reasonably get to?

One answer might be three: break each library up into an interface part and an implementation part, like the include and lib directories from my C++ example. Programs should only depend on libraries and interfaces, and library implementations should only depend on other libraries’ interfaces, never on their implementations. That sounds plausible to me, both in terms of being achievable and in terms of being a good idea, but I’m not sure that it’s enough to get us to three levels of dependencies. The problem is that one library’s interface can reasonably depend on another library’s interface: e.g. if you happen to be writing a video server, you might reasonably have some generic MPEG classes that are referred to in the interfaces of multiple libraries, which means that they themselves have to be in a separate library. So that’s four levels of dependency; I can even imagine that it would be hard to avoid introducing a fifth level, because you might have some fundamental data structures (e.g. some sort of widely used numeric abstraction or custom collection) that shows up in the interface of shared classes that are a bit more domain specific.

So: five levels of dependency. That doesn’t sound like a very good rallying cry, does it? Still, at least it’s a stake in the ground, and having those five layers be well defined (programs, library implementations, library interfaces, shared interfaces, and a handful of core interfaces) is something.

Is even that achievable, though? C++ header files define a few different sorts of concepts. There are abstract interfaces; these are a lot like Java interfaces. There are ADTs; these belong in my interface layer above, but contain actual implementation as well. And there are methods that you call without having an object instance at hand: static methods, but also constructors.

What do you do about this latter class of functions? In C-family languages, the linker happily resolves them for you; what’s the analogue for that in Java? I guess the answer there is: if you have a static method (including class constructors) associated to a class that’s not plausibly an ADT, then you have to make sure that there’s an extra layer of indirection involved to let you do the wiring at the program level instead of at the cross-library level. In other words, you have to get serious about dependency injection: library A shouldn’t depend on the implementation of library B, even to do the basic setup for that library. Instead, library B should abstract all those static methods out into an interface, library A should be written in terms of that interface, and every program that uses library A should pass an implementation of that interface to library A. (It can get that implementation from a static method in library B, but the point here is that it’s the program layer that’s grabbing the static method from library B, not library A’s implementation layer.)

At first blush, I think that should work. Actually, it even seems plausible to me that it would lead to better structured programs than you would get if you didn’t worry about rigorously adhering to such standards. Five layers of dependencies: it’s good for your software! (Not the best rallying cry I’ve ever heard…)

Maven

The other aspect of our setup at work that’s new to me is Maven. I’m really not sure what I think about Maven yet: I’m willing to believe it’s better than Ant, but I’m also willing to believe that that is not much of an accomplishment. I like its emphasis on convention, I like the way it’s good at pulling in known versions of external resources (your Scala compiler, your jUnit version, etc.). But I’m less sold on its insistence in separating every artifact into a separate project: what happened to Recursive Make Considered Harmful? And it boggles my mind that, in this day and age, a build system would be written that only supports parallel builds as an experimental feature in its as-yet-unreleased third major revision number bump! We’ve known for most of a decade now that many cores are the way forward, yet I’m using a build system that can’t even keep two cores on my machine busy? That is ridiculous.

Another part of the picture is Hudson: our build system at work is set up so that you’re encouraged to have Hudson build artifacts that you’re not actively touching. (And Hudson is capable of doing those builds in parallel. This perhaps makes it possible to live with the aforementioned Maven limitation, but in no sense excuses it: if I’m starting up a project, I absolutely should not be required to set up a continuous integration server just to get non-braindead compilation performance. I realize that the Java world is not known for its fondness for lightweight systems, but that is… Sigh. I will stop ranting now.) I haven’t yet figured out what the Maven way is here: is Maven perfectly happy for you to have all your build artifacts under your own control, is Maven actively hostile to you having all your build artifacts under your own control, or is Maven agnostic about that question?

This all also bears on the question of source code repositories that I mentioned above. At first, once I got over my surprise, I kind of liked the idea of having each module in its own git repository: let’s take the idea of separate modules seriously. But once we start breaking up one conceptual module into an interface part and a library part, I’m less happy about having them in separate repositories: you’ll want to change an interface and the code that implements that interface in lockstep, which means that changes to them should be part of a single commit. And I’m also not sold on this idea that we should have Hudson in charge of building all these different artifacts for us: maybe I’m conservative, but I still like the idea of checking out a known version of the entire project’s source code, doing a build of it, and getting a reliable, reproducible result.

Lots of interesting questions to think about, lots that I still have to learn. (And that’s without going into my discomfort about dependency info generation for Javaish languages!) Probably the best thing for me to do would be to start a project at home: I should come up with something to write (probably purely in Scala, I don’t think that mixing Java in will either make me happier or clarify the situation) that I can plausibly break out into multiple libraries, so I can really grapple with these dependency issues.

After I wrote that post on precedence, map, and function composition in Scala, I started to wonder: I’ve been thinking that I should experiment more with applying Compose Method. That refactoring recommends that, if I start with the original version of my code,

data.foreach(s => writer.addDocument(createDocument s))

then I should extract the body to a method. Which, I guess, would lead me to something like this?

data.foreach(addStringAsDocument(_, writer))

Except that that’s actually not what Compose Method really recommends: that’s merely one standard way of applying it to languages that are somewhat lacking in expressive possibilities. If all you have are manual looping constructs, and if you want to “keep all of the operations in a method at the same level of abstraction” (Smalltalk Best Practice Patterns, p. 22), then yeah, you’ll pull out your loop bodies to methods, but there are other ways to reach that end.

So, looking at the code that I actually ended up with that post (with the kind help of my readers),

data.map(createDocument).foreach(writer.addDocument)

is everything there at the same level of abstraction? That’s not entirely clear to me: if I wanted to, I could certainly extract a couple of methods out of that, and end up with something like this:

addDocumentsToWriter(createDocuments(data), writer)

Examining Alternatives

We’ve seen four examples of how that code could look; let’s replace the first of those with one that raichoo suggested on the previous post, giving us the following list:

1. data.foreach(createDocument _ andThen writer.addDocument)
2. data.foreach(addStringAsDocument(_, writer))
3. data.map(createDocument).foreach(writer.addDocument)
4. addDocumentsToWriter(createDocuments(data), writer)

Anybody want to argue for any of these being noticeably better or worse than all of the others? I’ll have to say: while they all seem fine to me, I can’t get too worked up over the need for using Compose Method in this case. Though, as I’ve been typing them up, I’ve wanted to add “fromString” in various places, which suggests that the method name createDocument is perhaps not as well chosen as it could be: maybe I should have called it something like stringToDocument instead?

Hard to say, I’m still happy enough with the third option. It says fairly directly that I’m starting with a bunch of data, turning it into a bunch of documents, and adding them to the writer: fine by me. (The first option seems approximately similarly expressive to me, as well.) There are, of course, situations where one or the other composed method would be preferable (as I said at the end of that earlier post, I ran into one an hour after I ran into the above!), but this doesn’t seem like one.

Recomposing and Natural Transformations

Maybe it’s the category theorist in me, but this also raises one other question: consider the two composed methods, 2 and 4 in the above list. Say that you reflexively went with option 2, but then decided that it didn’t seem quite right. You could (probably would) inline the function, and then distribute and regroup to end up with the fourth version; that seems like a pretty standard sort of thing to want to do. (It wouldn’t be too much of an abuse of language to call it a natural transformation!)

So: if we’re going to make a taxonomy of micro refactorings, might we not only also want to list ways of composing them (as, indeed, Refactoring itself suggests; see also Refactoring to Patterns or the hierarchies of patterns in A Pattern Language), but also ways of undoing them and composing them differently, along the lines of associativity laws?

9:30am–10:30am: “The Game Design of Starcraft II: Designing an E-Sport”, by Dustin Browder

2005. Dawn of War just shipped: 4 sides, 63+ units, with more to come. Supreme Commander about to ship: 4 sides 100+ units. Starcraft 2 planned with 3 sides, 45 units. (Some of which are effectively identical!)

This sounded crazy to him: units = choices = gameplay = fun. They need more!

The response: this is an e-sport. That’s new, hard to do. Think of this as “basketball 2″. That means it needs to be: watchable: clear, simple, skill-based, uncertain.

Let’s drill down into these. “Clear” is why the artists hate him. He gives an example of an ultralisk: it’s not nearly as impressive as it could be, it would look a lot better if it were bigger. But if he did that, it would hide smaller units (he showed it hiding 20 zerglings), destroying clarity/readability. Especially important in the case of effects: you don’t want them making an imprecise light show all over the screen, you want to know exactly who is affected and whether it succeeded. 

Simple: minimum number of units. For Starcraft, 12-15 units per race. Too many and viewers are confused, pros have to guess, and some units end up functioning as reskins. But: you still need tons of choices with that small number of units. They started by just experimenting with movers and shooters, fiddling with the stats to bring out differences. (Including area of influence, how they move.)

Interlude on upgrades. Banelings are better than marines; but marines + stim are better than marines. So upgrades don’t just make a unit more like itself, they flip relationships. (And that relationship can get flipped again with a handling upgrade.) Or the roach can be upgraded in two different ways: 1 unit, 3 uses.

Skill: micromanagement is important to them. It’s part of the game: an RTS isn’t just a really fast turn-based game. (Also, micromanagement is fun to watch, important for a sport!) And it allows for degrees of skill, degrees of success/failure. Force field example: easy to use it at a choke point; hard to use it to protect a group on the field; still harder to use it to split an opponent force. (And you can do any of these better or worse: a better player won’t leave as many gaps between force fields.)

(Flanking and terrain examples that I didn’t quite understand)

Uncertainty: that’s why the Zerg rush is there. Anything is possible in the first few minutes of the game. A rush is always going to be possible at some point in the game: so why push out the possibility away from the start?

Those are the core values; now on to ripple effects.

Story: as discussed above, units on screen are smaller than would be ideal for narrative purposes. So they exaggerate in the other direction in story art, so you’ll be able to imagine how cool the units are. Similarly, units are tiny ants on the battlefield, so make them over-the-top characters in story mode.

Solo tech: they had cool, fun units, but they overlapped with other units. So they weren’t suitable for e-sport usage, but still valuable content.

Missions: the narrative arc for the e-sport is exposition (scouting), complication (early battles), climax (deciding battle), resolution (gg, post-game analysis). With single player, though, it didn’t work the same way: a real cost to losing an individual battle, so players would play defensively until they had an overwhelming advantage, at which point there would be a long mop-up period. So they added in lots of different mechanics to the single-player game, to shift the narrative arc. E.g. outbreak: night = terror, day = payback. (Still too much mop-up, though.)

11:00am–12:00pm: “Hybrid Orchestration – Scoring Need for Speed“, by Troels Folmann and Charles Deenen

They’re talking about Need for Speed Shift 2: Unleashed.

Charles started:

Development wants cinematic Gladiator-liked score. Marketing wants youth-relevant licensed songs. Traditionally, you separate these two; they decided to merge them into a single hybrid score. Take very popular tracks, reorchestrate / rescore them.

Different music styles: epic = driver’s win, dirty = battle, two others that I didn’t catch in time. (Surreal = preparation, I think, and then special purpose for full-motion-video?)

They did a concept with a single 30 Seconds to Mars track; worked surprisingly well. So let’s go with it! But required signoffs from lots of different people; and its a huge amount of work even with the bare minimum of 10 songs. And very tight pipeline, with serious risk of having signoffs denied late in the process.

They decided to start with a test bed to get early approval from one of the bands, to reduce risk. They had different composers produce sample orchestrations in the different styles, to see what would work. (Same audio tracks, but everything else was different.) Made about 20; sent top 7-8 to band.

And, fortunately, the band really liked it! Kept feeling of the song while reinterpreting it in really cool ways. This helped convince execs and other bands, too. (Eventually, all 10 targeted bands signed off.)

Now Troels speaking:

The Four Noble Truths: everything is suffering, suffering arises from attachment to desires, … (Ed.: one of the more unexpected slides I’ve seen in a GDC presentation.)

And: what does “hybrid” mean? One important consequence: don’t follow a traditional song structure; this is hard! Also, refine concepts: epic alone isn’t good enough: need epic clean, epic emotion. So a specific hybridization for this project.

(Previous example: mismatch between sound, game. Kill your darlings, listen to client / game. Surprised he was invited back.)

Created a template for this hybridization. Focused on percussive elements, also mention of strings and brass that I didn’t understand. (And what is “RMX and deep-sampled percussion”?) Ethnic choirs, custom signature samples.

First example: “Night of the Hunter” by 30 Seconds to Mars. Showed various refinements, …

Second: “Issues”, Escape the Fate. Lots of revisions. What’s the right number of revisions? 7 was definitely too much.

So he hit the wall. How to overcome this? Communicate; find personal joy; make mockups; face the wall; ignore the wall. Took the last strategy: took three days off completely. Sat in his garden, recorded bees, turned them into different songs. (Hi-hat, Hammond, …) Made a pretty amazing video out of it. Also tried various objects: crowbar, light bulbs, coffee pot, playground poles.

Third: “Take a Load Off”, Stone Temple Pilots. Went a lot faster this time, only a few revisions.

Fourth: (unreleased song) 7 revisions, but all small, so not a big deal.

Back to Charles.

Postproduction. Increased clarity, better instrument and frequency separation, more TV-friendly sound, even composer agreed it was worth it.

Post-mortem: how to approach hybrid? Create template, ensure everything connects textually, identify signature sounds, identify rhythmic elements that merge with orchestral and synth elements.

12:30pm–1:30pm: “The Game Design Challenge 2011: Bigger than Jesus”, by John Romero, Jason Rohrer, Eric Zimmerman, and Jenova Chen

Eric Zimmerman (moderator). For this year’s theme, he wanted to merge games and religion: create a game that could be a religion. (Not about religion: the game itself and the act of playing should be a religion.)

Jason Rohrer

Chain World: A humanistic video game religion that someone will play today. Religions used to try to explain physical mysteries; that role has been usurped by science and technology recently. He talks about a detour that I-77 had to take around a town in Ohio because of a fight his grandfather led. Talks more about visiting that town, about things his grandfather allegedly said. Lots of details about his grandfather that he doesn’t really know whether or not they’re true: his grandfather is turning more into a saint-like figure. We become like gods to those who come after us.

His game idea: you control a world, then pass it on to the next player. Game designer is god, he passes the start state to the player, leading to an end state. But what if your end states somebody else’s start state? Each player is like a god to the next.

You want to do this in a game where modifications don’t screw up the playing field for the next player. (So not like Mario, where you modify the world by destroying blocks.) Players might have intent for how they want to modify the world for the next player; players might wonder what the previous player intended with an aspect of the world.

That’s the frame idea; what’s the actual game? Minecraft! A specific world on a specific USB stick. Play the game, don’t erect signs with text, play until you die. Save, pass it on, never play again.

John Romero

What is a religion? Deity, worshippers, devotion. In the beginning, there were lots of gods, one true god emerged @God6502; he had a son @Messiah6502. Follow him on Twitter: first twelve followers are his apostles. They come down to the front of the room; quite a distinguished bunch. Each gets a pad of sticky notes, to gather followers.

The winner: the apostle with the most miracles: some of the sticky notes have star markers. (@SquirrelTweets) But: to win the game, you must kill him, John Romero. (Doom image.)

Jenova Chen

Here are his slides.

He’s Chinese, so supposed to be an atheist. Did lots of research. Chinese believe in gods, but not the same sort of belief that you see in modern religions: a god is an unknown, a value. Dao = way of life, how to live. Recent China: socialism, then developmentism, then consumerism. These three are all about being happy, which seems fairly fundamental. Or: belief in something bigger.

Inspiration: Campbell, Csíkszentmihályi, Darwin.

What drives happiness? Money is useful at first, but beyond a certain level more money is irrelevant. Hierarchy of needs: top is self-actualization, not addressed by money.

At the end of the hero’s journey, he returns, giving something back to the community.

What is our purpose? He wants one that works for primitive humans, even for nonhumans. Circle of life: propagation is the more interesting part. These days, propagation of ideas is more important.

But what ideas should we propagate? Evolution says: look at the ones that survive, refine them. How does selection happen? Unknown: god. (Editorial note: not really, no…)

TED: Ideas worth spreading. But they’re not good game designers: the website is very passive, even the slogan is. TED: Influence with your ideas. No ranking for videos: rank by view count, or better by number of people inspired by them. Give each video a page, showing whom you’re influencing. Twitter follower count, badges in a Chinese twitter-like site.

Badges alone aren’t a game: you need a feedback loop. So: badges / points lead to promotion system that help draw other people to watch your video.

Propagationism.

(Rohrer won.)

2:00pm–3:00pm: “An Apology for Roger Ebert”, by Brian Moriarty

(Here’s the text of Moriarty’s talk.)

“I am, in fact, Professor Moriarty.” This is an apology not in the sense of anything done wrong, but in the sense of a defense.

(Discussion of 2005 Ebert article, 2010 flaring up of the argument.)

Why return to this? He wants to discuss Ebert’s claim that there isn’t a game worth of comparison with the treasures of world literature, movies, music, paintings.

Discussion of painting: Northcote, Chess Players, c1730. Two chess players: the game industry, self absorbed, satisfied. The golden boy is art itself, looking at us, pointing at a paper containing his secrets.

Read lots of art history; never saw games mentioned as art. (Ed. Nobody stood up for go? Oy.) Math is elegant, but nobody confuses mathematics with art, they’re different categories! Considering games as art is radical; then again, the idea of great works of art is also radical, only 500 years old.

Photography, movies entered realms of art relatively recently; why shouldn’t video games? Because games are old: if chess and go aren’t art, why should video games be?

Interlude: we know what video games are. But we don’t know how to define art, let alone great art. C.f. Duchamp urinal. Also, games can clearly contain great art from other media. But that’s not enough: mechanics and affordances are key. Can mechanics and affordances be considered art?

(Taste, intersubjectivity. Not all movies are Art.)

Eliciting emotion isn’t enough for art. Art is about attraction. (Ed. really??) But how to distinguish sublime art?

Kitsch. Is it art? Somebody claims: yes, art with three characteristics. Highly charged with stock emotions. Instantly and effortlessly recognizable. Does not enrich our associations. Nearly all popular art is kitsch. (Bombast: all adaptations are kitsch? Oy.)

More on games as kitsch, whee.

Celebration of kitsch = camp. Ultimately an evasive strategy.

Big studios won’t make art. Indies won’t. Who will make art? Those who would make art anyways: the artists. Warning: don’t just follow the trappings, then you’ll get something arty.

Technology of film largely stable for more than 100 years.

Structural reasons why games won’t produce sublime art. Ebert talks about direction of artist, inevitability of meaning. (Oy.) Romantic point of view. Schopenhauer: free will and individual choice are illusions, desire a prison. Leap off the wheel of desire via the contemplation of sublime art. Transcends will, frees us from agony of contingency and causality.

“Flow is an an-aesthetic.”

If the purpose of sublime art is to solve the mystery of choice, then …

Sublime art is the still evocation of the inexpressible.

All sublime art is devotional.

Edit: I thought Emily Short’s discussion of this talk was quite good.

3:30pm–4:30pm: “Message Queuing on a Large Scale: IMVU’s Stateful Event Architecture”, by Jon Watte

His slides:

Want: any-to-any messaging with ad-hoc structure. Lightweight (in-memory) state maintenance. Added queues as a building block, with two kinds of messaging: events and states. Integrated into a bigger system.

User to queue: connect, listen, send. Queue to game server: validate users/requests, notification. Game server to queue (didn’t catch it).

Design goal of 1M simultaneous users. (10x current use.) Real-time, meaning 100ms end-to-end. 20M queue creations/day.

Existing solutions didn’t work. (Wished they could buy Gtalk, AIM, etc. solutions!) Inspired by mochiweb: 1M users on a single machine, written in Erlang.

Implementation.

(Journey of a Message diagram: send to queue, validate, forward to other users listening to queue.)

Queue: multiple mounts (chat – message; scores – state; subscriber list).

One machine isn’t enough: doing some math on volumes and memory speed, would take over 3 seconds per message. So need to scale across machines.

Scale in two dimensions: gateway machines and queue machines, connected via a consistent hashing mechanism that allows moving chunks of queues via a central map of buckets to nodes.

Erlang. I’ll skip the details, but: basically, custom designed to solve their problem.

(Dozed off some: load balancing; marshaling via protocol buffers.)

Have a boss node keeping track of what gateway, queue nodes are doing. Looks like a single point of failure, but things keep running without it, you just can’t add more nodes until the boss is restarted.

Message could go out via a different node than where it entered; led to time skew. So sent messages out via entry node.

Hot add node diagram: make sure to forward messages while move is in process.

Problem cases. User goes silent; detect via ping. Reconnection of user, possibly to a different gateway: user-specific queue arbitrates. Node crashes (yet to happen in production, go Erlang!): state is ephemeral, user might get logged out. Gateway crashes: client reconnects, gets resent missed updates, application above queue API doesn’t notice. Sometimes want reliable messages; higher level API stores it in database. Firewalls: use proprietary protocol on port 80/443.

Build and test. Continuous integration, continuous deployment. Erlang supports in-place code updates, but too heavy for them; use failover instead.

Future: replication; scalability limits; open source what they can.

In retrospect, it was kind of amazing how many talks I went to today: two sessions were really three separate talks each, so that adds up to 11 talks! Wow.

• Creating Your Building Blocks: Modular Component AI Systems
• Ethics for Developers
• Game Design by Accidents
• Click Zen: Zynga’s Evolution from FarmVille to CityVille
• Leave Enough Room: Design that Supports Player Expression
• Turning Depression into Inspiration
• From AAA to Indie: Three Start-Up Stories

10:00am–11:00am: “Creating Your Building Blocks: Modular Component AI Systems”, by Brett Laming, Joel McGinnis, and Alex Champandard

This talk (or at least its first third) was my surprise favorite for the day: I’m pretty sure there’s a lot of object-oriented wisdom here, if I understood what was going on better. Anybody have recommended books on the approach presented here?

It was really three talks in one; the first, by Brett Laming on “Component Systems Revisited”, presented the basic foundation.

He started off with problematic approaches:

• The class hierarchy Ogre : Monster is simply wrong.
• Next, he presented a complex inheritance diagram with multiple inheritance, including a diamond. Worse, you run into situations where you have existing classes A and B where A derives from B, but you want A’s behavior but not B’s. So “deep class” is a problem.
• Next, you push common functionality up, leading to a “fat class”.
• Or you use aggregation to get plugins; lots of indirection, though.
• A data driven approach comes next, but it’s hard to debug.

There are seeds of good ideas in all of these, but you need to know what to pick and choose from them. The metaphor that he suggests is that of a “component”, e.g. as on a circuit board: it gives a broad classification (diode, resistor, capacitor, …), with key properties (that aren’t visible in the class hierarchy!), with defined inputs and outputs, that are interchangeable.

He also added a note on reusable AI: its outputs feed to the gameplay, its inputs come from the gameplay world. And disciplined gameplay is naturally linked to good organization, purposeful data, and sensible lifetimes.

The body of his talk was on five aspects of a component architecture. The first was inheritance:

• Classify where necessary, to define key slots. (Surprising mention of RTTI, e.g. for sorting.)
• Name: RTTI Factory creation; ability to serialize.
• Combined: Data driven approach, with a shallow hierarchy.

This discussion of run-time type surprised me, because I generally see it as a smell. But he was pretty emphatic about its virtues: he called RTTI “as important a tool as a smart pointer or a weak reference”! I think naming is one key route into what he’s thinking: he wants to be able to serialize and deserialize objects in a very flexible manner, to increase the power of tools at game designers’ disposal, and sees RTTI as a key part to that. (But I don’t think that’s the only thing going on.) He also gave examples of macros to help with RTTI (as opposed to leaning solely on what C++ provides), which also makes it more efficient.

The next aspect was structure:

• Spatial: reference frame, world transform
• Functional: composition and aggregation
• Dependency tracking: conflict resolution, job ordering

The third aspect was data flow:

• Data flow: world state -> AI -> gameplay -> world state
• Changes to structure: messages upstream/downstream
• Changes to properties: signaling downstream/upstream, message for spatial barriers

The fourth was compartmentalization:

• Smart objects, reconstructable via RTTI
• This is nearly free, given good structure
• External instructions: AI, animation, etc., carried by signaling

And finally, parallelization:

• The ideal is still a way off
• But AI/gameplay still parallelizes, even in game graphs! (Mention of indirection, aliasing)
• Candidates for parallelization: Leaf output: animation, navigation, component update. Leaf input: sensory info, blackboards, ray tests

He ended with some design tricks:

• Remove temptation: minimal data (if per frame, put it on the stack), minimal lifetime (use new/delete boundary, object pools)
• Favor derivation: no equation contradiction, no duplicate data
• Potential deep class problem: generalize
• Locality of reference: abstraction+composition, placement new, embedded lists, object pools
• Minimize NULL checks: use Null Objects instead when necessary
• Non-virtual pathways: use RTTI filtering
• Many virtual pointers: package once and carry downstream

And his conclusion:

• Gameplay gives us fun buttons to press: tight gameplay leads to good, reusable AI
• Think: minimal classes, data lifetime, locality of reference
• Use: generalization, RTTI, placement new/delete, object pools

Next, Joel McGinnis on “AI Design Patterns”.

The pressures you’re under are: resources (compute cycles, memory), and design specificity (or lack thereof…). Component architectures give you flexibility, and allow performance balancing. He warned that it’s not a blueprint, though: you still need to architect, so it’s not a solution, but a framework for how things can get built.

One antipattern he mentioned was putting data on AI component. Instead, think about the data that the AI component needs to consume: focal point, targetable object, cover markup, interaction point, trigger volume… Granularity is great with component architectures, gives lots of flexibility.

Pattern: Component Matrix

Entities, behavior tree, pathfinding, targeting system, animation, standard movement. Makes it easy to substitute parts out: e.g. if going from lithe enemy to hulking enemy, prototype by swapping out pathfinding component. Lets you answer design questions with minimal investment.

Pattern: Find Via Registration

E.g. target selection looks for targetable objects; both halves register with the targeting system, so you don’t need to search all objects in the world. Reduces the search space by scoping, simplifies construction of behavior, easily done via lifecycle management.

Pattern: Late Construction of Types

Lets you change your minds late in the game, do load balancing: try it everywhere, keep it where most effective. Requires things to be light weight, and data driven helps

And the third talk was Alex Champandard on “Performance and Multi-Threading”.

His talk used influence maps as an example component. How do you make it high performance? You want to use vectorization: SIMD instructions give a 4x performance boost. Then parallelization might give another 4x performance boost.

The solution is to build your build your engine as modularly as your entities. And use the same breakdown in both cases.

He gave an entity example. Then he talked about the system, which does: batching and prioritization. Don’t process individual requests, instead schedule jobs. Custom allocation by jobs to allow interleaving, SIMD. (C.f. the mention of placement new in Brett Laming’s talk.)

Summary: very lightweight, simple interface, handles events, data-driven. Pay attention to memory allocation, computation limits, batching, prioritization. This leads to jobs that are computationally intense and support parallelization.

11:15am–11:40am: “Ethics for Developers”, by Miguel Sicart

His question: what kind of ethical knowledge do future game developers need to know? But first, definitions:

• Morality: a public system, governs behavior towards overs and how to avoid harm.   A system of rules, and principles for evaluating those rules; principles stem from ethics.
• Ethics: the philosophical study of morality. Framework for analysis of moral issues via a coherent, philosophically argued scheme. Provides evaluative standards for development of principles/morals, not only to avoid harm but also to help human flourishing.

There are moral issues of: profession, art form/medium, games in society, and play. We need guidelines. And his outline of a method for acting ethically was: Identify potential moral issues.  Analyze and contextualize them. Deliberate about them, applying ethical theories.

He then talked about four ethical theories, linking each with a problem.

The first theory was consequence-based ethics: decisions should be taken based on consequences. Evaluate based on most desirable outcome for society. This is either act-utilitarianism or rule-utilitarianism.

Data mining and profiling raise moral concerns, especially profiling. Utilitarianism suggests: informed profiling is good as long as most players feel it as not harmful.

His second theory was duty-based ethics: centered on obligations towards others, trying to pursue happiness without harming others. The golden rule.

Duty applies to software and hardware dev: duty of developers to players (which is different from consumers!). Software must allow for play (anti-piracy software problems); some games (e.g. educational) need to be played on legacy platforms.

His third theory was contract-based ethics: contracts between individuals that form society. Often used in the case of right-based issues.

Community management shows how you can use this: a game is not just an entertainment product, but also an implicit contract between developer and players. Developers should understand that the way their communities are managed should allow for ethical reflection.

And his fourth theory was character-based ethics: instead of rules, consequences, contracts, we should focus on being good. Development of virtues and good characteristics leads to general morally good behavior, even in unexpected/new cases.

This helps inform our understanding of player behavior: it’s done within spaced created by developers. Developers should think about good virtues of good players, and create appropriate affordances in the design.

One approach towards ethical issues is via professional codes: these give guidelines for solving issues. If an issue affects the profession, professional codes should help. E.g. crunch, bad management, sexism. Do we need a professional code for game developers?

(Time ran out here.)

11:50am–12:15pm: “Game Design by Accidents”, by Steph Thirion

His basic thesis here is that coding is an idea generator: seeing how code behaves is a great way to confront yourself with surprising realities.

Exhibit A: A programmer making a game based on pentominoes, in order to explore a new computer. No graphics, text-based. He’d just implemented bit where pressing key rotates the piece, and spent a while playing with it: this real-time component is surprisingly powerful, opens up a new world.

He simplifies pieces, adds gravity, leads to Tetris. But: when he started programming it, he didn’t even have the idea yet!

Exhibit B: Jonathan Blow talking about how billiards would change if you could see the future. He did prototype, felt weird seeing it unfold, how the balls ended up where they were supposed to. He didn’t figure out how to make a game out of it, but it sparked ideas that led to Braid.

Exhibit C: A Game Mod workshop for graphic design students with no coding experience. He started by giving them a Breakout clone with no void at the bottom (so balls never went away), implemented in a relatively friendly language called Processing.

He told students to download Processing and the code, to change it, and to make something awesome in six hours. He then showed a video of students’ results, which I thought was really impressive.

Exhibit D: He talked about his background: started as graphic designer, evolved into coder, where in his game Eliss almost everything is produced by code rather than static images.

The takeaways:

• Code makes you stumble into ideas.
• Coding is: complex; precise; unpredictable.
• Code is already there: if you discover something while coding, it’s working right in front of your eyes!
• Simplicity first: you can feel the complexity of code, so it encourages you to keep things simple.

Finally, he ended with a live example using Ruby-Processing. Starts with static circle, adds random movement. Leaves trail, which is kind of interesting; then redraws background to remove trail. Makes background white, circle black.

Then does same thing with 100 circles at once: starts as growing blob, then individual circles emerge from it.  Plays with size of circles: makes them small, more like particles. Large, makes everything a big blob. Random starting position, turns whole screen back, but then puts in outline. Then fills them with alpha, leads to smoggy cloud.

I really liked this example: at several points I was really surprised at shapes and behavior that emerged from such simple changes.

Lunch

I had a very nice chat with Ben Abraham, Jorge Albor, and Brendan Keogh.

1:45pm–2:45pm: “Click Zen: Zynga’s Evolution from FarmVille to CityVille“, by Mark Skaggs

Impossible 1.0: Red Alert 2: made by a team with no RTS experience, made it in 9 months.

Leading up to FarmVille: Zynga was “small”, Mafia Wars was the big dog. His team was trying to make a medieval RTS game, but was stuck in design limbo. Bing Gordon: “Wy don’t you just make a farm game?” Decided to take a small team and go for it.

Fast, light, and right. Single strong voice, passionate team, mission. 5 minute design: if you can’t figure out how to make something more fun, just go with the obvious solution. Only design screens and flows: what the player sees and does. Help from organization: took YoVille avatars, borrowed people.

Decision time: Zynga hardware or Amazon cloud? Zynga’s center ran out of space and power; would have had to wait 6 weeks for more servers, so went to Amazon, which turned out to be crucial for rapid scaling.

Minimal art content for shipping. RTS interface to remove friction, set context sensitive cursor, add queuing.

True Minimum Viable Product: no monetization, almost no metrics at launch! Not at parity feature-wise with other farm games, but a better user experience.

Team goal: 400k DAUs by June 30: 11 days after launch. SVP Biz Dev: if you hit 1M DAUs in 30 days, we’ll take you to the French Laundry. CFO: if you do it in 11 days, we’ll send you all to Paris! They hit it in 5 days; they got the dinner, but not the trip…

That’s Impossible 2.0: people kept thinking growth would stall at various points, it didn’t. Thank goodness that they were on the cloud. But still: had to watch the servers, had to scale the team.

Also unusual: keep the brand pure. Would Disney put this in Finding Nemo? Target audience is moms; don’t want anything in there that moms wouldn’t like; this led to tension with Mafia Wars ads.

One surprise: everything is much harder after launch.

Leading up to CityVille: Zynga was much bigger, they’d had another six games under their belt. FarmVille was still the biggest; Facebook had changed what was allowed, players’ expectations had changed, Zynga’s best practices had changed.

So: what’s Impossible 3.0? The wisdom at the time: FarmVille was a once in a lifetime success, Facebook policies mean you’ll never pass 10M DAUs, their internal model showed a city sim stopping at 5M. Lots of questions: gameplay style, who should develop it (send to their Austin studio?), full featured versus Minimum Viable Product. They spent too much time in paper design which led to imagining problems that might not materialize, so they switched to producing prototypes.

They set a date, locked in art style and rules. Lessons and features from FrontierVille: quests, stories, doobers (loot drops). Converged in Aug/Sep: narrowed scope, get real about date, push for quality. Still, story was missing, and fun wasn’t quite there.

Key mile markers:

• Aug/Sep: team gels
• Sep: game playable, but not fun
• Late Sep: first bits of fun emerge
• Oct/Nov: team plays the game
• Nov: hold for quality, public announcements. Was supposed to be launch date, but game wasn’t good enough. Very different approach compared to FarmVille launch.

Proactive launch steps: lined up external teams to help with live services. Quality high: easier to fix bugs before launch. Feature roadmap. Was smooth compared to other Zynga launches.

They reached 8M DAUs in 2 weeks, 14M in 30 days, over 20M now.

What turned out well: Social: people’s faces, franchising your business. Game loop: right balance of simple sim. Quests.

Could be better: Trains are only kind of cool. Simpler interface for franchises. Expansions were too easy to get. Longer runway on the simulation. More surprises and easter eggs.

Could be better in the process: Didn’t have single strong voice with clear vision. Bigger product, hence more test and integration time. Maybe should have done Minimum Viable Product; not at all clear, though. No scaling plan. No features in the back product, ready for quick deployment after launch.

Meta lessons for social game developers: It’s entertainment: good looking, fun art, fun core gameplay loop. You’re building a product, a team, a 24/7 business, a platform. The battle is won before the launch, fix bugs then. Learn the space, know key features/recipes, know the audience. Speed wins: get to market quickly, and it’s a web experience, so performance matters. Deliver fun: “you can’t make up for boring with volume”.

3:00pm–3:25pm: “Leave Enough Room: Design that Supports Player Expression”, by Randy Smith

He started off with pictures from Fallout 3 that involved posing large numbers of teddy bears.

Is player expression for you? (I.e. indies, this was part of the indie games track.) Yes: indie attainable, indie appropriate, for the good of the art form.

How? Don’t have a string of pearls guiding users down a specific route. Don’t include single solution puzzles. Then a Scrabble example: the game looks expressive, but to do well you need to use words that never get used in real life and that don’t say annoying you’d want to express. So: scoring can harm expressiveness.

Example from in-progress Tiger Style game: need to grow biomass to progress. But: all lifeforms contribute biomass, not much is needed to progress. So: tell the player “just play the game”, but there’s also depth on demand.

Also, units have multiple functions: can be enemies or allies depending on the context, depending on what you’re trying to accomplish at the time.

Empower the user to generate data; I didn’t quite catch the example here.

Finally, let the user use the generated data. (E.g. players sharing screenshots of avatars / levels.) Achievements also help acknowledge what the player is trying to do. Stats can do that, too: largest web, longest jump, not just a single score. (In particular, these stats in Spider never block your progress, they’re depth on demand.)

3:35pm–4:00pm: “Turning Depression into Inspiration”, by Michael Todd

Indie developers work at a job that can cause stress, overwork, being unhealthy, being poor, being lonely. And there are also potential personal causes of depression. So: some indie devs are depressed! Not always easily solvable, so need techniques for developing while depressed.

Being unproductive and being depressed reinforce each other. Or: if you can be productive, this gives control over our work, our lives. So, ways to increase productivity.

1) Work on rewarding projects

These are good to build. Get to the gameplay, don’t get bogged down. But be careful: don’t front load the fun stuff to the extent that there’s only slog left over. Instead, make as much of the project be reward as possible!

Complete vs. progressive gameplay. Progressive is semi-playable almost at once; a complete game needs almost all the systems before its playable. Lean towards the latter.

Awesome/crazy ideas are more rewarding, easier to keep the faith.

And: design for yourself. Keeps up day to day interest.

2) Try to stop being a perfectionist.

Don’t overthink everything. Get other people to play the game. Skype somebody else to tell them about the flaw you’re worrying about, they tell you you’re worrying too much. Play lots of games (Steam, XBLIG, demos.)

3) Shorter projects

That way you spend more of your building time in the phase where you’re excited about the game. So: small bad is no good, want small awesome!

4) Measure your hours

Otherwise, you’ll work less and less when depressed.

5) Design the game to suit your abilities

What do you love? What do you hate? Use the resources that are available to you. The trick is understanding what you have.

Finally: how does being depressed change how you work?

A game is a thousand tiny choices. These are affected by your mood, your priorities. The distinct choices of a personality can be an advantage; bad experiences can be a particular advantage. (Artists in love are boring, ones that have gotten screwed over in love aren’t.) And depression is an experience.

4:15pm–5:15pm: “From AAA to Indie: Three Start-Up Stories”, by Jake Kazdal, Daniel Cook, and Ichiro Lambe

Another three-speaker talk. First was Jake Kazdal: “From AAA to aaa”. I mostly napped during this.

Next, Daniel Cook: “Spry Fox, Year One: Lessons Learned”

A portfolio approach is key. Great games are not enough: have to hit right platform at right time with right theme. Portfolio model helps reduce that risk.

Flash portals are so used to taking games essentially for free that they don’t understand your asking for money. Very few portals that respect the needs of developers at all. They also don’t understand payment systems, microtransactions. Most important: bring people off of portal back to your website.

Too many designers are like too many cooks. His teams converge on the fun so much faster now that there’s a single creative director for a project.

Teams should aspire to iterate daily. A week is bad; two week iterations and your design may never converge.

Building meaningful hobbies is hard, but worth it. Want people to be playing ten years from now. Tend to be multiplayer, tend to be a service, tend to monetize well, tend to build relationships. But really, really hard to build. And game developers don’t traditionally have those skills, that’s why web developers are doing better in the social game space.

When hiring people, make them do a real project: that lets you see if they can finish. Great teammate: reliable, able to see big picture, works well with others, respects the game designer.

Missing from list: willing to work long hours. (Crunch is wrong.) Passion isn’t enough, and can mean obstinate. And no need for people to be located in North America.

Finally, Ichiro Lambe; I didn’t catch the name of his talk.

Think holistically. Conventional wisdom: wear many hats. True, but the mistake is thinking of things as separate problems, instead weave them together. (E.g. marketing + bug support.)

Tie marketing into design. Conventional view: marketing = getting people to buy crap they don’t want. Instead, create a game that people give hard-earned money for it, and that is remarkable! Make a game that’s both a game you want to make and a game that people want to buy. So: create a game that we’re excited about, and that will sell for stated reasons.

He ended with a bit on postmortems / retrospectives.

data.foreach(s => writer.addDocument(createDocument s))

(Warning: I’m typing this from memory, without trying it out in the Scala CLI, and I’m new enough to Scala that it’s entirely possible that I’m making silly syntax errors.) That was great, but Scala lets you use underscores in place of explicit argument names for arguments that you’re only going to use once, so I tried doing this instead:

data.foreach(writer.addDocument(createDocument _))

That, however, didn’t work. After looking at the error message and talking to some coworkers, it seemed like Scala was parsing it as the following:

data.foreach(writer.addDocument(s => createDocument s))

And there isn’t a version of addDocument that takes a function argument. Which is good: if there had been, it might have compiled but not done what I wanted, which would have been even more confusing! Still, I was frustrated: why can’t Scala just read my mind? But, honestly, the compiler’s choice was a perfectly reasonable way to parse that expression, and I certainly wouldn’t want Scala’s parsing to be dependent on the types that function calls accept. So I was willing to leave it at that.

Except that, as one of my coworkers then pointed out, there was another way of breaking it down: instead of writing as a single foreach call, I would write it as map plus foreach, as follows:

data.map(createDocument).foreach(writer.addDocument)

Which is much nicer! So, actually, Scala’s parse error was gently nudging me in the correct direction: yes, this sort of thing is potentially ambiguous to parse, but if you break down your function composition properly, then that ambiguity goes away. So it was nice of the compiler to help me write my code elegantly!

The funny thing was, I ran into a very similar situation an hour later: it involved two maps plus a foreach, but the exact same principle applied. That time, though, after writing it out as a chain of three collection functions, I didn’t really like the result: it was going too far into the details of how to use a library that I was integrating with, and I didn’t find the result particularly evocative. So I ended up going back to the single-foreach version, but this time I pulled out the function that I was applying to a member function, so I could give it a name that explained what was going on. It’s nice to have different tools in your toolkit, because ultimately you need to be guided by what makes your code the most expressive rather than falling in love with the most powerful tool.

A few things that amuse me so far, as a C++ fan:

Yet another book which has to explain that a variable being immutable doesn’t mean that the object it’s pointing to is immutable (just that you can’t reassign the variable to point to something else), and that there’s in fact no way to create immutable objects (assuming that the class allows mutation at all, of course). Is C++ really the only language that has a reasonable story about this?

Admittedly, C++’s story is far from perfect as well: all you have to do is hold a member variable via a pointer and then it’s up to the class implementor to declare const methods honestly, the compiler won’t have your back for you in that case. And that also points at C++’s main advantage in this area, that you can have variables that aren’t held via pointers: maybe without that, automatically enforcing constness is impossible, and without that there’s no benefit in letting class implementers declare which methods are const? I’ll have to think about that one; still, it’s certainly not an area that I would have thought C++ would be relatively unique in when I first ran into the language.

And after reading so many complaints about how you can’t tell what “a + b” means in C++ code, it’s great to see another language that unabashedly embraces operator overloading. And having operators that end in a colon be magically reversed to be methods of the object on their right is simply brilliant: not only does it naturally handle the cons case of

1 :: List(2,3)

but having /: be an alias for foldLeft is just brilliant: I think writing

(0 /: list) { _ + _ }

to sum the elements of list is super natural, much more so than a syntax with 0 and list reversed would be. (Think of it as smooshing down list starting with 0 at the front and with the function argument telling you how to do the smooshing.)

So yeah, Scala and I are going to get along just fine, I think.

As soon as Disney’s acquisition of Playdom closed, e-mails from recruiters started appearing regularly in my inbox. Most of them I essentially ignored: I’d been having a great time at Playdom, and while I didn’t expect to stay there for the six years that I’d stayed in my previous job, I certainly wasn’t planning to leave after just over a year. So I sent polite notes back to the recruiters saying that I wasn’t interested, and promptly forgot about them.

Eventually, though, one of those e-mails snuck through my defenses. It was from a startup that I had vague warm feelings about, enough so that I clicked through to their job ads; and, when I did so, I found that they used both Ruby on Rails and Scala. These are two technologies that I’m quite interested in, and that I wasn’t likely to get to play around with at Playdom; also, at that point I was in a bit of a rut at my current role at Playdom. So I responded to that e-mail in a more positive fashion.

That was the first chink in my armor; a little while after that, I got an e-mail from an industry recruiter whom I’d noticed appearing on my twitter followers list a week or two before. So, out of curiosity (or perhaps vanity), I responded to her as well.

This was the middle of December, so it was close enough to Christmas break that not much happened with those conversations for the rest of the year. But the conversations had planted a seed in my brain, enough to shift my mental story so that, when relatives asked me over Christmas how work was going, my answer was “fine, but I’ve been a little bored recently”.

Changing Stories

In retrospect, that was the key turning point. Before, the dominant stories playing in my head were all strongly in favor of my being at Playdom: the story about being in the games industry, the story about how Playdom was on the right side of an Innovator’s Dilemma market shift, the story of being part of a startup destined for great things, the story of learning new technologies. The first two stories were holding up fine; but Playdom wasn’t a startup anymore (and I was a late enough hire that I didn’t have much of a financial incentive to stick around waiting for options to vest), and there weren’t any technologies on the horizon at Playdom that I was actively excited about, so the third and fourth stories were losing their power. And we hadn’t had meetings within Playdom for a while that were reinforcing those stories or generating new stories to replace them. (Playdom had an all-hands meeting in early February that excited me an a couple of ways; if that had happened in December, maybe I never would have responded to that earlier e-mail.)

This meant that my brain had a narrative gap that it wanted to fill. And, right at that moment, the best new stories were coming from seeds planted by recruiters: maybe I wanted to be at a startup again, maybe I wanted to explore Ruby or functional programming. The very act of talking to recruiters and companies gave this a boost: such conversations inevitably turn fairly soon to the question of what you’re interested in, so unless you want to sabotage your chances immediately, you’ll come up with an answer expressing a story leading away from your current company and towards whomever you’re talking to. Yes, you’re doing that because of your audience; still, telling them those stories has a cumulative effect, and if you spin enough such stories, they’ll combine to lead you in a different direction.

Crafting a New Story

But that travel is more haphazard than I’d like. And potentially dangerous: if other people are driving the conversations and leading the stories, they’re not particularly likely to go in directions that will turn out well for me. So that suggested two courses of action:

1. I should think hard about what I wanted.
2. I should talk to as many people as I could manage, to maximize options and prevent any single external story from having undue influence.

The outcome of the first course of action was:

• I wanted to explore different technologies, Ruby and functional programming languages in particular.
• I wanted to be some place that was into the technical side of agile, that focused more on craftsmanship.
• I wanted to be at a startup again, and a smaller one: I’d tried 50-person and 100+-person startups, I’d tried large companies, and it seemed time to head down to the 25-person range.

None of which I was likely to get at Playdom. Now, I like playing and thinking about games, which meant that I liked being in the games industry; but I like thinking about programming, too, and about everything entailed in the art of creating software. And when it comes down to which of those two I’d most be able to make a rewarding career out of, I don’t think there’s much comparison: I’ll do better (both personally and financially) if I follow my nose as a programmer. So it wasn’t crazy to think that I’d gotten most of what I was going to get technically out of Playdom, and move on.

And the outcome of the second question was that I should cast my net more broadly: in particular, I talked to a couple of recruiters that had helped me land with Playdom originally. One of whom was at a different firm, so now I was talking to three recruiting firms plus a handful of companies that I’d met through other means, mostly LinkedIn e-mails that they’d sent.

Going for a Ride

Let me tell you: those recruiters did not mess around. They all did a very good job, and I’d happily work with all of them again: they’d come up with a first pass of ten or so companies that seemed to them to be plausible fits, I’d look at them and agree that all of them were plausible but pick out a few that particularly caught my eye for some reason, and they’d both set up conversations with those few and use that information to come up with further excellent suggestions.

The upshot of this was that I was spending a lot of time on the phone talking to various companies, and some amount of time (mercifully mostly on evenings or holidays) interviewing in person. (It was quite lucky that it was good weather, because I spent a lot of lunch breaks sitting in a nearby park and talking.) And it was nice to feel wanted!

But also a little disconcerting. I’d like to pretend that I’m so super-awesome that anybody would love to hire me; the truth is, though, that while I’m fairly sure I do have several good attributes, there’s also quite a bit of luck involved. I know several other people whom I have a lot of respect for who have had more protracted job searches recently; I’m not about to chalk that up to some sort of essential difference, it means instead that right now I’m in a situation where people are happy to work with me to spin stories where I sound good. So I need to understand what’s going on there, and see how to best take advantage of it and set myself up in the future.

I wasn’t consciously thinking about this during the job search, but I turned 40 last Tuesday. I’m in an industry that, to some extent, overvalues youth; so far I haven’t had any problems with that, but it’s an example of how future job searches could be a lot more prolonged and a lot less fun than this one was. Which helped confirm my feeling that now was the right time to leave Playdom: from a strictly mercenary point of view, it’s almost certainly going to be the case that I have a significantly higher expected value from playing up the story of “being part of a company that has sold for a good amount recently in a high-profile industry” than from the Disney stock options that I’d be giving up by changing jobs.

Ambition

The upshot of this was that I decided that I needed to change the story that I was telling myself and others still more, and to do so by increasing its ambition. Following the nose of technologies that I’m interested in but not yet fully fluent in remained important (both for personal fulfillment reasons and for setting myself up for further growth), but I didn’t want to go too far in that direction at the expense of underplaying everything that I’ve learned over the last decade.

Also, I ended up prioritizing functional programming languages over Ruby: Ruby’s been around enough that I’m definitely playing catchup there compared to a lot of other programmers, whereas I’m hearing a surprising amount of buzz about Scala while not yet getting the feel that there’s a huge amount of existing expertise in the language. (And I’m quite confident that my brain will do well at turning me into a very good Scala programmer: it’s good at that sort of thing.) I’m pretty optimistic that going in that direction will open up a lot of interesting doors a few years from now, positioning me well on the adoption curve.

In terms of company size, I should go still smaller: coming into a 25-person company would be interesting, but even then you’ve missed a lot of the early decisions. I didn’t quite want to be a co-founder or first hire, but being in the 10-15 person range seemed like it would be a plausible fit.

And then there’s The Innovator’s Dilemma. You can never predict what will turn out to be successful, but I figured there’s no sense not swinging for the fences. Which meant looking for companies that could tell a story involving disruption on a significant scale, and companies whose founders have the chops to pull it off.

This all adds up to a great story going forward: I’ll have worked at multiple successful startups, I’ll have had increasingly important roles within those startups, I’ll have a lot of experience in dealing with very large quantities of data, with cloud technologies, with new programming paradigms (or with half-century old programming paradigms that are making a deserved resurgence!), I’ll have the agile chops to look beyond my day-to-day programming to help the effectiveness of the organization as a whole. That is a story that I can get behind, and it will convert my getting older from a potential liability into a tale of valuable experience.

Outcome

At least that’s how I’d like things to go; then again, I certainly wouldn’t have predicted two years ago anything that has happened since then, so I don’t want to get too tied up in this particular story! I’m very glad to have spent time thinking about it, but in the mean time I need to dive in, start programming, work as hard as I can to help make my next company successful, and see where the future leads.

Which means I needed to pick the next step in my future! I was very fortunate to have the opportunity to talk to some very interesting companies indeed; I ended up joining Sumo Logic, and I’m super-excited about them. They have a great disruption story, their founders can pull it off if anybody can, I interviewed with all nine of the current employees and am very much looking forward to having all of them as colleagues. What they’re doing and the way they’re working fits well enough with my prior experience that I should be able to hit the ground running and contribute well, but there’s enough new that I’ll come out of it knowing quite a bit more than I know going in. It looks like a great fit from my point of view, and they seem to agree; I’m looking forward to spending the next several years with them, it’ll be quite a ride.

And I will pay more attention to the stories that are going through my head in the future: they are powerful, they control me more than I realize.

Part of me feels like I should be bothered by the man of great faith who got a long-distance cure for his household member; but I’m really not. “Let the dead bury their dead” (Matthew 8:22) seems a bit harsh, but only a bit.

Matthew 9 repeats much of the same themes, but there’s some new stuff, too. It starts off by saying that Jesus cures blasphemers, too, confirming my feeling that I shouldn’t be bothered by the man of great faith by the previous chapter. In fact, he turns this into a lesson on forgiveness, which I rather like: “For whether is easier, to say, Thy sins be forgiven thee; or to say, Arise, and walk?” (Matthew 9:5)

And then he goes to eat with “publicans and sinners” (Matthew 9:11). Which is a word I had to look up, and Lattimore translates that it as “tax collectors and sinners” instead. At any rate, an interesting pairing, especially in today’s political climate that pairs an absolutist anti-tax line with a refusal to examine the benefits that those taxes are bringing us.

Take, for example, health care. Yes, it would be great if we could have the son of God wandering around healing us whenever we get sick. But even two millennia ago that didn’t come close to scaling to meet the actual need, and these days our shortage of healing deities is even more sorely lacking. Fortunately, our health care has improved enormously over the intervening millennia, though (pace The Rational Optimist) I won’t credit government with much of the improvement there. But I will credit government with some of the improvement, and we need a health care system of last resort, one that will look after those who aren’t financially able to pay for their own care; hence, taxes.

Anyways, continuing on: not sure how I feel about the whole bit about Jesus eating instead of fasting, justified with “Can the children of the bridechamber mourn, as long as the bridegroom is with them?” (Matthew 9:15): I’m all for moderation in appropriate contexts, but I don’t think that’s what’s going on here. Still, I certainly won’t blame Jesus for wanting to have some food in his stomach, though, especially given what’s going to happen to him.

I also can’t say that I understand the “No man putteth a piece of new cloth unto an old garment” bit that follows next (Matthew 9:16)—I get the feeling that I should be learning something there, but it doesn’t quite fit into the narrative flow to me. Or maybe I should read those verses as an affront against the virtues of refactoring, or as a caution that it can be taken too far?

And then I started making changes, at which point I hit the tab key, and Emacs indented the line by four spaces. The problem is, the file used two spaces for tabs. But I’ve done this enough times, surely I can quickly figure out how to configure this? Let’s see: C-h tab-width looks promising, but it has the value 8, so surely it isn’t relevant. The first answer while googling mentions c-basic-offset, which sounds just dubious enough (that c- prefix) to be right; but its value, rather than being a number, is “set-from-style”.

At this point, I have a few options. I can set c-basic-offset to a number, to see if that works, and then figure out the appropriate mode hook to do that for me. I can figure out what set-from-style means, to do it right. I can do more googling, to find a better answer.

But, I think, the best answer is: realize that I have better things to do with my life than to put up with that sort of user interface crap. (Or with the absolute joke that is Emacs’s “Preferences” menu item.)

(Another charming instance of Emacs’s user interface: on a lark, I thought I might as well go through the motions of looking through menus, though I’d be shocked if anything relevant was found there. And, of course, I didn’t find anything relevant; but what I did discover was that one of the menu options was “Read Mail (with RMAIL).” How many people in the entire freaking world are using RMAIL? Is there even one such person? I read my e-mail in Emacs for a very long time, but even I moved off of RMAIL more than a decade before I gave up on reading e-mail in Emacs.)

So, I guess, that’s the reason why I’ll buy TextMate: because I want an editor that doesn’t have an actively hostile UI (and no, don’t suggest vi, its UI is at least as hostile), that can be used for programming, and that isn’t as super-bloated as IntelliJ or NetBeans or Eclipse or whatever. (Admittedly, I haven’t used NetBeans and Eclipse much, so maybe I’m mischaracterizing them. But I doubt it.) $50 still seems like a ridiculous price to pay for it, and I’m worried by its apparently stalled development, but it has enough supporters that maybe it has virtues that I’m missing? If anybody has other editor suggestions, though, I’m all ears.

Things I’ve liked:

• Great teammates: I’ve been on two teams here, and quite enjoyed being a part of both groups.
• Having what I do make a difference in somebody else’s life in a matter of days or even hours; a huge change from my last job.
• Being able to talk to people on the business side about what I’m doing, showing them the current state and asking for (and responding to!) feedback.
• Learning technologies I wasn’t previously familiar with: JavaScript, a bit of ActionScript, a bit of Hadoop. And getting a chance to put a CSS Zen approach to concrete use, too.
• Tools supporting agile programming: getting to use an IDE with refactoring support; using a mocking framework.
• Brushing up on Java isn’t a bad idea, though not inherently exciting; at least it helps reduce my risk of being pigeonholed as a C++ guy.
• Doing front-end work; I love getting to work with what our artists create.
• Being a programmer instead of a manager.
• Working with games; getting back to playing board games regularly.
• Deepening my appreciation of testing by looking at business metrics.
• Getting experience with growing a successful product.

I could probably write one or more blog posts about each of those; lots of great experiences, in retrospect it’s a bit hard to believe all that happened over one year! But that’s last year, what do I want out of next year?

More exposure to new technologies would be nice, though I imagine the rate there will slow down. Still, there are some possibilities: I imagine I’ll get more familiar with ActionScript, I might get exposed to Lua. (And I might get more exposed to PHP, though I can’t say that I’m excited about that.) Might get to learn more about data scaling ideas, too.

Helping add significant new features to an existing game has been rather interesting, and I’m glad I did it. On the flip side, though, I’d like to work on a new game at some point, to get a better feel for the tradeoffs that are relevant there.

And then there are teams and roles. I’d been a manager on a team where we had some agile theory but had a hard time putting it into practice, especially on the business side. It’s been nice being a non-manager, and having a much tighter turnaround for the customers and customer proxies.

Ideally, I’d like to be on a team merging some of my previous experience with the virtues of my recent experience. Adding a bit more agile theory (and lean theory) to what we’re doing at Playdom would help, I think, but not at the cost of losing the virtues of our current approach. And the more the team (broadly conceived, of course, not just the programmers) works as empowered individuals evolving a common creative vision, the better. (I don’t want to be a manager, but I don’t want to be told what to do by a manager, either!)

Good times past; looking forward to good times future.