Press "Enter" to skip to content

Posts tagged as “Development”

[twenty twenty-four day eighty-two]: your abstractions are leaking

centaur 0

SO! My Facebook AND my credit card were both hacked within the last few months, so I was understandably freaked when I logged into the Library the other day and got a security warning. This SSL warning sometimes shows up when your network configuration changes - or when someone is trying to hack you - so I got off the conference network and used my phone's mobile hotspot. Unfortunately both the Library's WordPress control panel AND the main page showed the error, and I got a sinking feeling. Credit card got hacked a few months back, remember? And when I checked the certificate ... it had just expired.

Assuming that whatever service I use for SSL had expired due to that credit card issue, I tried to track it down in the WordPress control panel, but pretty quickly decided that digging through notes, credit cards and passwords in a public conference hall was one lapse in opsec too far. Later that night, I tried resolving the SSL issue, but found that something was wrong with the configuration and it couldn't update itself. Exhausted after a long day at the convention, I decided to get up early and attack the problem fresh.

The next morning, I found I had apparently set up WordPress to use an SSL tool which didn't play nice with my hosting provider. (I'm being deliberately vague as y'all don't need to know all the details of how my website is set up). Working through the tool's wizard didn't help, but their documentation suggested that I probably needed to go straight to the provider, which I did. After digging through those control panels, I finally found the SSL configuration ... which was properly set up, and paid through 2025.

WAT?

I re-logged into the control panel. No SSL warning. I re-opened the website. No SSL warning. I doublechecked on both another browser and another device. Both listed the site as secure.

As best as I can figure, yesterday afternoon, I hit the website in the tiny sliver of time between the old certificate expiring and the new one being installed. If I was running such a system, I'd have installed it an hour early to prevent such overlaps, but perhaps there's a technical or business reason not to do that.

Regardless, the implementation details of the "website is secure" abstraction had leaked. This is a pervasive but deceptively uncommon problem in all software development. Outside the laws of physics proper, there are no true abstractions in reality - and our notions of those laws are themselves approximations, as we found out with Einstein's tweaks to Newton's gravity - so even those laws leak.

Even a supposedly universal law, like the second law of thermodynamics that Isaac Asimov was fond of going on about, is actually far subtler than it first looks, and actually it's even subtler than that, and no wait, it's even subtler than that. Perhaps the only truly universal law is Murphy's - or mathematical ones.

Which brings us to the abstractions we have in software. In one sense, they're an attempt to overcome the universal growth of entropy, in which case they're doomed to ultimately fail; and they create that order with a set of rules which must be either incomplete or incorrect according to Godel's Incompleteness Theorem, which means they'll ultimately either fall short or get it wrong.

When developing and maintaining software - or deploying it and managing it in production - we always need to be on the lookout for leaky abstractions. We may think the system we're working with is actually obeying a set of rules, but at any time those rules may fail us - sometimes spectacularly, as in when my backup hard drive and internet gateway were struck by lightning, and sometimes almost invisibly, as in when a computer gets in a cruftly state with never-before-seen symptoms that cannot be debugged and can only be dismissed by a restart.

So my whole debugging of the SSL certificate today and yesterday was an attempt to plug a leak in an abstraction, a leak of errors that created the APPEARANCE of a long-term failure, but which was ACTUALLY a transient blip as an expired certificate was swapped out for its valid replacement.

What's particularly hard about leaky abstractions, transient failures and heisenbugs is that they train us into expecting that voodoo will work - and consciously trying to avoid the voodoo doesn't work either. On almost every Macintosh laptop I've used that has had wireless networking, it can take anywhere from a few seconds to a minute for a laptop to join a network - but once, I had the unpleasant experience of watching a senior Google leader flail for several minutes trying to get onto the network when I had to loan him my laptop to present in a meeting, as he kept switching from network to network because he was convinced that "if the network we're trying to join is working, it should immediately connect." Well, no, that would be nice, but you're sending bits over the fucking air like it was a wire, and connection failures are common. This was a decade and a half ago, but as I recall I eventually convinced him - or he got frustrated enough - to stop for a moment, after which the laptop finally had a chance to authenticate and join the network.

Debugging software problems requires patience, perseverance - but also impatience, and a willingess to give up. You need to dig into systems to find the root cause, or just try things two or three times, or turn the damn thing off and on again - or, sometimes, to come back tomorrow, when it's mysteriously fixed.

-the Centaur

Pictured: a blurry shot of downtown San Francisco, where the abstraction of taking a photo is leaking because of camera movement, and the same intersection, with less leakage from motion.

[twenty twenty-four day seventy]: fix it the way that works

centaur 0

So, this is worthy of a longer blog post, but the short story is, looking under the streetlight for your keys may provide visibility, but it won’t help you find them unless you have reason to think that you dropped them there.

A lot of time in software development, we encounter things that don’t work, and problems like stochastic errors and heisenbugs can lead software developers to try voodoo solutions - rebooting, recompiling from head, running the build again, or restarting the server.

These “solutions” work well enough for us that it’s worthwhile trying them as a first step - several times recently I have encountered issues which simply evaporated when I refreshed the web page, restarted the server, retried the build, or restarted my computer.

But these are not actual fixes. They’re tools to clear away transient errors so we can give our systems the best chance of properly functioning. And if they don’t work, the most important thing to do is to really dig in and try to find the root cause of the problem.

On one of those systems - where I literally had tried refreshing the web page, restarting the server, refreshing the code, reinstalling the packages, and rebooting the computer - the build itself was something that you had to run twice.

Now, this is a common problem with software builds: they take a lot of files and memory, and they can get halfway through their builds and die, leaving enough artifacts for a second pass to successfully solve the problem. I had to do this at Google quite a bit.

But it isn’t a real solution. (Well, it was at Google, for this particular software, because its build was running up against some hard limits that weren’t fixable, but I digress). And so, eventually, my build for this website failed to run at all, even after a reboot.

The solution? A quick search online revealed it’s possible to change the parameters of the build to give it more memory - and once I did that, the build ran smooth as glass. The “run the build again” trick I’d learned at Google - learned where, for one particular project, it was not possible to fix the problem - had led me astray, and overapplying this trick to my new problem - where it had partial success - kept me from finding a real, permanent fix.

So, if a fix feels like voodoo, stop for a minute - and search for a better way.

-the Centaur

Pictured: What do you mean, you haven't updated the package configuration for THREE YEARS?

Enter Colaboratory (AKA “A Spoonful of the Tracking Soup”)

centaur 0
As an author, I'm interested in how well my books are doing: not only do I want people reading them, I also want to compare what my publisher and booksellers claim about my books with my actual sales. (Also, I want to know how close to retirement I am.) In the past, I used to read a bunch of web pages on Amazon (and Barnes and Noble too, before they changed their format) and entered them into an Excel spreadsheet called "Writing Popularity" (but just as easily could have been called "Writing Obscurity", yuk yuk yuk). That was fine when I had one book, but now I have four novels and an anthology out. This could take out half an a hour or more, which I needed for valuable writing time. I needed a better system. I knew about tools for parsing web pages, like the parsing library Beautiful Soup, but it had been half a decade since I touched that library and I just never had the time to sit down and do it. But, recently, I've realized the value of a great force multiplier for exploratory software development (and I don't mean Stack Exchange): interactive programming notebooks. Pioneered by Mathematica in 1988 and picked up by tools like iPython and its descendent Jupyter, an interactive programming notebook is like a mix of a command line - where you can dynamically enter commands and get answers - and literate programming, where code is written into the documents that document (and produce it). But Mathematica isn't the best tool for either web parsing or for producing code that will one day become a library - it's written in the Wolfram Language, which is optimized for mathematical computations - and Jupyter notebooks require setting up a Jupyter server or otherwise jumping through hoops. Enter Google's Colaboratory. Colab is a free service provided by Google that hosts Jupyter notebooks. It's got most of the standard libraries that you might need, it provides its own backends to run the code, and it saves copies of the notebooks to Google Drive, so you don't have to worry about acquiring software or running a server or even saving your data (but do please hit save). Because you can try code out and see the results right away, it's perfect on iterating ideas: no need to re-start a changed program, losing valuable seconds; if something doesn't work, you can tweak the code and try it right away. In this sense Colab has some of the force multiplier effects of a debugger, but it's far more powerful. Heck, in this version of the system you can ask a question on Stack Overflow right from the Help menu. How cool is that? My prototyping session got a bit long, so rather than try to insert it inline here, I wrote this blog post in Colab! To read more, go take a look at the Colaboratory notebook itself, "A Sip of the Tracking Soup", available at: https://goo.gl/Mihf1n -the Centaur  

Meanwhile, Back at GDC

centaur 0

on-the-road-2015a.png

View from my hotel in San Francisco. It may seem strange to get a hotel for a conference in San Francisco when I live in the San Francisco Bay Area, but the truth is that I "live in the Bay Area" only by a generous border-case interpretation of "Bay Area" (we're literally on the last page of the 500-page Bay Area map book that I bought when i came out here). The trip from my house to the Moscone Center in the morning is two to two and a half hours - you could drive from Greenville, SC to Atlanta, Georgia in that time, so by that logic I should have commuted from home to Georgia Tech. So. Not. Going. To. Happen.  

So why am I heading to the Moscone Center this week? The Game Developer's Conference, of course. At the request of my wife, I may not directly blog from wherever it is that I am, so I'll be posting with a delay about this conference. So far, I've attended the AI Game Programmer's Guild dinner Sunday night, which was a blast seeing old friends, meeting new ones, renewing friendships, and talking about the robot apocalypse and the future of artificial intelligence research. GDC is a blast even if you don't directly program games, because game developers are constantly pushing the boundaries of the possible - so I try not to miss it. I've been coming for roughly 15 years now - and already have close to 15 pages of notes. Good stuff.

One thing does occur to me, though, about games and "Gamer Gate." If you're into games, you may or may not have heard of the Gamer Gate controversy; some people claim it's about corruption in games journalism, while others openly state it's motivated by the invasion of gaming by so-called "social justice warriors" who are trying to destroy traditional male-oriented games in favor of thinly disguised social commentary. Still others suspect that the entire controversy is a manufactured excuse for misogynists to abuse women in games - and there's evidence that shows that at least some miscreants are doing just that.

But let's go back to the first reason, ethics in games journalism. I can't really speak to this from the inside, but in the circles in which I've been playing games for the past thirty-five years, no one cares about game reviews. Occasionally we use game magazines to find neat screenshots of new games, but, seriously - everything is word of mouth.

What about the second, the "invasion of social justice warriors?" I can speak about this: in the circles that I've traveled in the game industry in the past fifteen years, no one cares about this controversy. At GDC, women who speak about games are much more likely to be speaking about technical issues like constraint systems and procedural content generation than they are about social issues - and men are as likely as women to speak about women's issues or the treatment of other minorities.

These issues are important issues - but they're not big issues. Out of a hundred books in the conference bookstore, perhaps a dozen were on social issues, and only two of those dealt with women's culture or alternative culture. But traditional games are going strong - and are getting bigger and better and brighter and more vibrant as time goes along.

People like the games they like, and developers build them. No-one is threatened by the appearance of a game that breaks traditional stereotypes. No-one imagines that popular games that appeal to men are going to go away. All we really care about is make it fun, make it believable, finish it in a reasonable time and something approximating a reasonable budget.

Look, I get it: change is scary. And not just emotionally; these issues run deep. At a crowd simulation talk today, a researcher showed that you can mathematically measure a person's discomfort navigating in crowds - and showed a very realistic-looking behavior where a single character facing a phalanx of oncoming agents turned tail and ran away.

But this wasn't an act of fear; it was an act of avoidance. The appearance of an onrushing wall of people made that straightforward algorithm, designed to prove to the agent that it wouldn't run into trouble, choose a path that went the other way. An agent with more options to act might have chosen to lash out - to try to force a path.

But none of that was necessary. A slightly more sophisticated algorithm, based on study of actual human crowd behavior, showed that if an agent choose to boldly go forward into a space which slightly risked collisions, avoiding a bit harder if people got too close, worked just as well. It was easily able to wade through the phalanx - and the phalanx smoothly moved around it.

The point is that many humans don't want to run into things that are different. If the oncoming change is big enough, the simplest path may involve turning tail and running away - and if you don't want to run away, you might want to lash out. But it isn't necessary. Step forward with confidence moving towards the things that you want, and people will make space for you.

Yes, change is coming.

But change won't stop game developers from making games aimed at every demographic of fun. Chill out.

-the Centaur

P.S. Yes, it is a bit ridiculous to refer to a crowd avoidance algorithm that can mathematically prove that it avoids collision as "simple", and it's debatable whether that system, ORCA, which is based on linear programming over a simplification of velocity obstacles, is really "simpler" than the TTC force method based on combining goal acceleration with avoidance forces derived from a discomfort energy gradient defined within a velocity obstacle. For the sake of this anecdote, ORCA shows slightly "simpler" behavior than TTC, because ORCA's play-it-safe strategy causes it to avoid areas of velocity space that TTC will try, leading to slightly more "sophisticated" crowd behaviors emerging naturally in TTC based systems. Look up http://motion.cs.umn.edu/PowerLaw if you want more information - this is an anecdote tortured into an extended metaphor, not a tutorial.

Working Hard, Working Smart

centaur 0

stress-relieving-doodle.png

I had planned to post a bit about my work on the editing of LIQUID FIRE, but this image in my Google+ photo stream caught my eye first, so you get a bit of opinionating about work instead.

Previously, I've blogged about working just a little bit harder than you want to (here, and here), the gist being that you don't need to work yourself to death, but success often comes just after the point where you want to give up.

But how do you keep yourself working when you want to quit?

One trick I've used since my days interning with Yamaha at Japan is an afternoon walk. Working on a difficult problem often makes you want to quit, but a short stint out in the fresh air can clear the decks.

Other people use exercise for the same purpose, but that takes such a large chunk out of my day that I can't afford to do it - I work four jobs (at my employer, on writing, at a small press and on comics) and need to be working at work, damnit.

But work sometimes needs to bleed out of its confines. I've found that giving work a little bit extra - checking your calendar before you go to bed, making yourself available for videoconferences at odd hours for those overseas - really helps.

One way that helps is to read about work outside of work. What I do frequently pushes the boundaries of my knowledge, and naturally, you need to read up on things at work in order to make progress.

But you also know the general areas of your work, and can proactively read ahead in areas that you think you'll be working on. So I've been reading on programming languages and source control systems and artificial intelligence outside work.

Now, not everyone reads at lunch, dinner, coffee and just before bedtime - maybe that's just me - but after I committed to starting my lunch reading with a section of a book that helped at work, all of my work started going faster and faster.

Other tricks you can use are playing music, especially with noise canceling headphones so you can concentrate - I find lyric-free music helps, but your mileage may vary. (I often listen to horror movie music at work, so I know mileage varies).

Another thing you can do, schedule permitting, is taking a week out to sharpen the saw and eliminate blockers in your common tools so everything goes faster. I recently started documenting this when I did it and that helped too.

One more thing you can try is inverse procrastination - cheat on one project you really need to do by working on another project you really need to do. You use different resources on different projects, and switching gears can feel like taking a break.

Quitting time is another technique; I often make a reservation at a nice restaurant at the end of my workday, and use the promise of going out to dinner to both motivate me to work efficiently and as a reward for a job well done (I tell myself).

Some people use caffeine to power through this - and sometimes I even describe myself as a caffeine powered developer - but I've seen a developer stop in shock at their trembling hands, so beware stimulants. But at quitting time? That hits the spot.

20150201_212020.jpg

Oh, and the last thing? Use a different channel. My wife is a painter … and listens to audiobooks ten to twelve hours a day. I'm a writer and programmer … so I doodle. Find a way to keep yourself engaged and going … just a little bit longer.

-the Centaur

Word! What are you DOING?

centaur 0

Screenshot 2013-11-03 15.36.00.png

I love Microsoft Word, but when I cut and pasted that excerpt from MAROONED into Ecto and published, I noticed a huge blank gap at the beginning of the quoted passage. When I looked in Ecto's raw text editor to see what was the matter, I found 336 lines of gunk injected by Microsoft Word … a massive amount of non printable goop like this:

<!--[if gte mso 9]><xml>

<o:DocumentProperties>

<o:Revision>0</o:Revision>

<o:TotalTime>0</o:TotalTime>

<o:Pages>1</o:Pages>

<o:Words>246</o:Words>

<o:Characters>1183</o:Characters>

<o:Company>Xivagent Scientific Consulting</o:Company>

<o:Lines>18</o:Lines>

<o:Paragraphs>11</o:Paragraphs>

<o:CharactersWithSpaces>1418</o:CharactersWithSpaces>

<o:Version>14.0</o:Version>

</o:DocumentProperties>

</xml><![endif]-->

<!--[if gte mso 9]><xml>

<w:WordDocument>

...

This is apparently XML text which captures the formatting of the Word document that it came from, somehow pasted into the HTML document. As you may or may not be able to see from the screenshot above, but should definitely be able to see in the bolded parts of what I quoted above, for 1183 bytes of text Word injected 17,961 bytes of formatting. 300+ lines for 200+ words. Oy, vey. All I wanted was an excerpt without having to go manually recreate all my line breaks …

I understand this lets you paste complex formatting between programs, I get that, and actually the problem might be Ecto taking too much rather than Word giving too much. Or perhaps it's just a mismatch of specifications. But I know HTML, Word, Ecto, and many other blogging platforms like Ecto. What is someone who doesn't know all that supposed to do? Just suffer when their application programs get all weird on them and they don't know why?

Sigh. I'm not really complaining here, but it's just amusing, after a fashion.

-Anthony

Treat Problems as Opportunities

centaur 0

Treat Problems v1.png

Recently I had a setback. Doesn't matter what on; setbacks happen. Sometimes they're on things outside your control: if a meteor smacks the Earth and the tidal wave is on its way to you, well, you're out of luck buddy.

But sometimes it only seems like a tidal wave about to wipe out all life. Suppose your party has lost the election. Your vote didn't stop it. You feel powerless - but you're not. You can vote. You can argue. You can volunteer. Even run for office yourself.

Even then, it might be a thirty year project to get yourself or people you like elected President - but most problems aren't trying to change the leader of the free world. The reality is, most of the things that do happen to us are things we can partially control.

So the setback happens. I got upset, thinking about this misfortune. I try to look closely at situations and to honestly blame myself for everything that went wrong. By honestly blame, I mean to look for my mistakes, but not exaggerate their impact.

In this case, at first, I thought I saw many things I did wrong, but the more I looked, the more I realized that most of what I did was right, and only a few of them were wrong, and they didn't account for all the bad things that had happened beyond my control.

Then I realized: what if I treated those bad things as actual problems?

A disaster is something bad that happens. A problem is a situation that can be fixed. A situation that has a solution. At work, and in writing, I'm constantly trying to come up with solutions to problems, solutions which sometimes must be very creative.

"Treat setbacks as problems," I thought. "Don't complain about them (ok, maybe do) but think about how you can fix them." Of course, sometimes the specific problems are unfixable: the code failed in production, the story was badly reviewed. Too late.

That's when the second idea comes in: what if you treated problems as opportunities to better your skills?

An opportunity is a situation you can build on. At work, and in writing, I try to develop better and better skills to solve problems, be it in prose, code, organization, or self-management. And once you know a problem can happen, you can build skills to fix it.

So I came up with a few mantras: "Take Problems as Opportunities" and "Accept Setbacks as Problems" were a couple of them that I wrote down (and don't have the others on me). But I was so inspired I put together a little inspirational poster.

I don't yet know how to turn this setback into a triumph. But I do know what kinds of problems caused it, and those are all opportunities for me to learn new skills to try to keep this setback from happening again. Time to get to it.

-Anthony

Pictured: me on a ridge of rock, under my very own motivational poster.

P.S. Now that I've posted this, I see I'm not the first to come up with this phrase. Great minds think alike!

The Centaur’s Guide to the Game Developers Conference

centaur 1

gdc2013logo.png

Once again it’s time for GDC, the Game Developers Conference. This annual kickstart to my computational creativity is held in the Moscone Center in San Francisco, CA and attracts roughly twenty thousand developers from all over the world.

I’m interested primarily in artificial intelligence for computer games– “Game AI” – and in the past few years they’ve had an AI Summit where game AI programmers can get together to hear neat talks about progress in the field.

Coming from an Academic AI background, what I like about Game AI is that it can’t not work. The AI for a game must work, come hell or high water. It doesn’t need to be principled. It doesn’t need to be real. It can be a random number generator. But it needs to appear to work—it has to affect gameplay, and users have to notice it.

gdc2013aisummit.png

That having been said, there are an enormous number of things getting standard in game artificial intelligence – agents and their properties, actions and decision algorithms, pathfinding and visibility, multiple agent interactions, animation and intent communication, and so forth – and they’re getting better all the time.

I know this is what I’m interested in, so I go to the AI Summit on Monday and Tuesday, some subset of the AI Roundtables, other programming, animation, and tooling talks, and if I can make it, the AI Programmer’s Dinner on Friday night. But if game AI isn’t your bag, what should you do? What should you see?

gdc2013people.png

If you haven’t been before, GDC can be overwhelming. Obviously, try to go to talks that you like, but how do you navigate this enormous complex in downtown San Francisco? I’ve blogged about this before, but it’s worth a refresher. Here are a few tips that I’ve found improve my experience.

Get your stuff done before you arrive. There is a LOT to see at GDC, and every year it seems that a last minute videoconference bleeds over into some talk that I want to see, or some programming task bumps the timeslot I set aside for a blogpost, or a writing task that does the same. Try to get this stuff done before you arrive.

Build a schedule before the conference. You’ll change your mind the day of, but GDC has a great schedule builder that lets you quickly and easily find candidate talks. Use it, email yourself a copy, print one out, save a PDF, whatever. It will help you know where you need to go.

Get a nearby hotel. The 5th and Minna Garage near GDC is very convenient, but driving there, even just in the City, is a pain. GDC hotels are done several months in advance, but if you hunt on Expedia or your favorite aggregator you might find something. Read the reviews carefully and doublecheck with Yelp so you don’t get bedbugs or mugged.

Check in the day before. Stuff starts really early, so if you want to get to early talks, don’t even bother to fly in the same day. I know this seems obvious, but this isn’t a conference that starts at 5pm on the first day with a reception. The first content-filled talks start at 10am on Monday. Challenge mode: you can check in Sunday if you arrive early enough.

mozcafe.png

Leave early, find breakfast. Some people don’t care about food, and there’s snacks onsite. Grab a crossaint and cola, or banana and coffee, or whatever. But if you power-up via a good hot breakfast, there are a number of great places to eat nearby – the splendiferous Mo’z Café and the greasy spoon Mel’s leap to mind, but hey, Yelp. A sea of GDC people will be there, and you’ll have the opportunity to network, peoplewatch, and go through your schedule again, even if you don’t find someone to strike up a conversation with.

Ask people who’ve been before what they recommend. This post got started when I left early, got breakfast at Mo’z, and then let some random dude sit down on the table opposite me because the place was too crowded. He didn’t want to disturb my reading, but we talked anyway, and he admitted: “I’ve never been before? What do I do?” Well, I gave him some advice … and then packaged it up into this blogpost. (And this one.)

Network, network, network. Bring business cards. (I am so bad at this!) Take business cards. Introduce yourself to people (but don’t be pushy). Ask what they’re up to. Even if you are looking for a job, you’re not looking for a job: you want people to get to know you first before you stick your hand out. Even if you’re not really looking for a job, you are really looking for a job, three, five or ten years later. I got hired into the Search Engine that Starts with a G from GDC … and I wasn’t even looking.

Learn, learn, learn. Find talks that look like they may answer questions related to problems that you have in your job. Find talks that look directly related to your job. Find talks that look vaguely related to your job. Comb the Expo floor looking for booths that have information even remotely related to your job. Scour the GDC Bookstore for books on anything interesting – but while you’re here: learn, learn, learn.

gdc2013expofloor.png

Leave early if you want lunch or dinner. If you don’t care about a quiet lunch, or you’ve got a group of friends you want to hang with, or colleagues you need to meet with, or have found some people you want to talk to, go with the flow, and feel comfortable using your 30 minute wait to network. But if you’re a harried, slightly antisocial writer with not enough hours in the day needing to work on his or her writing projects aaa aaa they’re chasing me, then leave about 10 minutes before the lunch or dinner rush to find dinner. Nearby places just off the beaten path like the enormous Chevy’s or the slightly farther ’wichcraft are your friends.

Find groups or parties or events to go to. I usually have an already booked schedule, but there are many evening parties. Roundtables break up with people heading to lunch or dinner. There may be guilds or groups or clubs or societies relating to your particular area; find them, and find out where they meet or dine or party or booze. And then network.

gdc2013roundtables.png

Hit Roundtables in person; hit the GDC Vault for conflicts. There are too many talks to go. Really. You’ll have to make sacrifices. Postmortems on classic games are great talks to go to, but pro tip: the GDC Roundtables, where seasoned pros jam with novices trying to answer their questions, are not generally recorded. All other talks usually end up on the GDC Vault, a collection of online recordings of all past sessions, which is expensive unless you…

Get an All Access Pass. Yes, it is expensive. Maybe your company will pay for it; maybe it won’t. But if you really are interested in game development, it’s totally worth it. Bonus: if you come back from year to year, you can get an Alumni discount if you order early. Double bonus: it comes with a GDC Vault subscription.

gdc2013chevys.png

Don’t Commit to Every Talk. There are too many talks to go to. Really. You’ll have to make sacrifices. Make sure you hit the Expo floor. Make sure you meet with friends. Make sure you make an effort to find some friends. Make time to see some of San Francisco. Don’t wear yourself out: go to as much as you can, then soak the rest of it in. Give yourself a breather. Give yourself an extra ten minutes between talks. Heck, leave a talk if you have to if it isn’t panning out, and find a more interesting one.

Get out of your comfort zone. If you’re a programmer, go to a design talk. If you’re a designer, go to a programming talk. Both of you could probably benefit from sitting in on an audio or animation talk, or to get more details about production. What did I say about learn, learn, learn?

Most importantly, have fun. Games are about fun. Producing them can be hard work, but GDC should not feel like work. It should feel like a grand adventure, where you explore parts of the game development experience you haven’t before, an experience of discovery where you recharge your batteries, reconnect with your field, and return home eager to start coding games once again.

-the Centaur

Pictured: The GDC North Hall staircase, with the mammoth holographic projected GDC logo hovering over it. Note: there is no mammoth holographic projected logo. After that, breakfast at Mo'z, the Expo floor, the Roundtables, and lunch at Chevy's.

An open letter to people who do presentations

centaur 0

presentations.png

I’ve seen many presentations that work: presentations with a few slides, with many slides, with no slides. Presentations with text-heavy slides, with image-heavy slides, with a few bullet points, even hand scrawled. Presentations done almost entirely by a sequence of demos; presentations given off the cuff sans microphone.

But there are a lot of things that don’t work in presentations, and I think it comes down to one root problem: presenters don’t realize they are not their audience. You should know, as a presenter, that you aren’t your audience: you’re presenting, they’re listening, you know what you’re going to say, they don’t.

But recently, I’ve had evidence otherwise. Presenters that seem to think you know what they’re thinking. Presenters that seem to think you have access to their slides. Presenters that seem that you are in on every private joke that they tell. Presenters that not only seem to think that they are standing on the podium with them, but are like them in every way – and like them as well.

Look, let’s be honest. Everyone is unique, and as a presenter, you’re more unique than everyone else. [u*nique |yo͞oˈnēk| adj, def (2): distinctive, remarkable, special, or unusual: a person unique enough to give him a microphone for forty-five minutes]. So your audience is not like you — or they wouldn’t have given you a podium. The room before that podium is filled with people all different from you.

How are they different?

  • First off, they don’t have your slides. Fine, you can show them to them. But they haven’t read your slides. They don’t know what’s on your slides. They can’t read them as fast as you can flip through them. Heck, you can’t read them as fast as you can flip through them. You have to give them the audience time to read your slides.

  • Second, they don’t know what you know. They can’t read slides which are elliptical and don’t get to the point. They can’t read details printed only in your slide notes. They can’t read details only on your web site. The only thing they get is what you say and show. If you don’t say it or show it, the audience won’t know it.
  • Third, they probably don’t know you. But that’s not an excuse to pour your heart and soul into your presentation. It’s especially not a reason to pour your heart and soul into your bio slide. Your audience does not want to get to know you. They want to know what you know. That’s an excuse to pour into it what they came to hear.
  • Fourth, your audience may not even like you. That’s not your fault: they don’t probably know you. But that’s not an excuse to sacrifice content for long, drawn out, extended jokes. Your audience isn’t there to be entertained by you. We call that standup. Humor is an important part of presentations, but only as a balanced part. We don’t call a pile of sugar a meal; we call it an invitation to hyperglycemic shock.
  • Fifth, your audience came to see other people than you. You showed up to give your presentation; they came to see a sequence of them. So, after following a too-fast presentation where the previous too-fast presenter popped up a link to his slide notes, please, for the love of G*d, don’t hop up on stage and immediately slap up your detailed bio slide before we’ve had time to write down the tiny URL.

Look, I don’t want to throw a lot of rules at you. I know some people say “no more than 3 bullets per slide, no more than 1 slide per 2 minutes” but I’ve seen Scott McCloud give a talk with maybe triple that density, and his daughter Sky McCloud is even faster and better. There are no rules. Just use common sense.

  • Don’t jam a 45 minute talk into 25 minutes. Cut something out.
  • Don’t have a 10 minute funny video at a technical conference. Cut it in half.
  • Don’t leap up on stage to show your bio slide before the previous presenter is done talking. Wait for people to write down the slides.
  • Don’t “let the audience drive the talk with questions.” They came to hear your efforts to distill your wisdom, not to hear your off-the-cuff answers to irrelevant questions from the audience.
  • Don’t end without leaving time for questions. Who knows, you may have made a mistake.

Ok. That’s off my chest.

Now to dive back into the fray…

-the Centaur

Pictured: A slide from ... axually a pretty good talk at GDC, not one of the ones that prompted the letter above.

Back to the Future with the Old Reader

centaur 0

theoldreader.png

As I mentioned in a previous post, Google Reader is going away. If you don't use RSS feeds, this service may be mystifying to you, but think of it this way: imagine, instead of getting a bunch of Facebook, Google+ or Twitter randomized micro-posts, you could get a steady stream of high-quality articles just from the people you like and admire? Yeah. RSS. It's like that.

So anyway, the Reader shutdown. I have a lot of thoughts about that, as do many other people, but the first one is: what the heck do I do? I use Reader on average about seven times a day. I'm certainly not going to hope Google change their minds, and even if they do, my trust is gone. Fortunately, there are a number of alternatives, which people have blogged about here and here.

The one I want to report on today is The Old Reader, the first one I tried. AWESOME. In more detail, this is what I found:

  • It has most, though not all, features of Google Reader. It's got creaky corners that sometimes make it look like features are broken, but as I've dug into it, almost everything is there and works pretty great.
  • It was able to import all my feeds I exported via Google Takeout. Their servers are pretty slow, so it actually took a few days, and they did it two passes. But they sent me an email when it was done, and they got everything.
  • The team is insanely responsive. They're just three guys - but when I found a problem with the Add Subscription button, they fixed it in just a couple of days. Amazing. More responsive than other companies I know.

There are drawbacks, most notably: they don't yet have an equivalent for Google Takeout's OPML export. But, they are only three guys. They just started taking money, which is a good sign that they might stay around. Here's hoping they are able to build a business on this, and that they have the same commitment to openness that Google had.

I plan to try other feed readers, as I can't be trapped into one product as I was before, but kudos to The Old Reader team for quickly and painlessly rescuing me from the First Great Internet Apocalypse of 2013. I feel like I'm just using Reader, except now I have a warm fuzzy that my beloved service isn't going to get neglected until it withers away.

-the Centaur

Context-Directed Spreading Activation

centaur 0
netsphere.png Let me completely up front about my motivation for writing this post: recently, I came across a paper which was similar to the work in my PhD thesis, but applied to a different area. The paper didn’t cite my work – in fact, its survey of related work in the area seemed to indicate that no prior work along the lines of mine existed – and when I alerted the authors to the omission, they informed me they’d cited all relevant work, and claimed “my obscure dissertation probably wasn’t relevant.” Clearly, I haven’t done a good enough job articulating or promoting my work, so I thought I should take a moment to explain what I did for my doctoral dissertation. My research improved computer memory by modeling it after human memory. People remember different things in different contexts based on how different pieces of information are connected to one another. Even a word as simple as ‘ford’ can call different things to mind depending on whether you’ve bought a popular brand of car, watched the credits of an Indiana Jones movie, or tried to cross the shallow part of a river. Based on that human phenomenon, I built a memory retrieval engine that used context to remember relevant things more quickly. My approach was based on a technique I called context directed spreading activation, which I argued was an advance over so-called “traditional” spreading activation. Spreading activation is a technique for finding information in a kind of computer memory called semantic networks, which model relationships in the human mind. A semantic network represents knowledge as a graph, with concepts as nodes and relationships between concepts as links, and traditional spreading activation finds information in that network by starting with a set of “query” nodes and propagating “activation” out on the links, like current in an electric circuit. The current that hits each node in the network determines how highly ranked the node is for a query. (If you understand circuits and spreading activation, and this description caused you to catch on fire, my apologies. I’ll be more precise in future blogposts. Roll with it). The problem is, as semantic networks grow large, there’s a heck of a lot of activation to propagate. My approach, context directed spreading activation (CDSA), cuts this cost dramatically by making activation propagate over fewer types of links. In CDSA, each link has a type, each type has a node, and activation propagates only over links whose nodes are active (to a very rough first approximation, although in my evaluations I tested about every variant of this under the sun). Propagating over active links isn’t just cheaper than spreading activation over every link; it’s smarter: the same “query” nodes can activate different parts of the network, depending on which “context” nodes are active. So, if you design your network right, Harrison Ford is never going to occur to you if you’ve been thinking about cars. I was a typical graduate student, and I thought my approach was so good, it was good for everything—so I built an entire cognitive architecture around the idea. (Cognitive architectures are general reasoning systems, normally built by teams of researchers, and building even a small one is part of the reason my PhD thesis took ten years, but I digress.) My cognitive architecture was called context sensitive asynchronous memory (CSAM), and it automatically collected context while the system was thinking, fed it into the context-directed spreading activation system, and incorporated dynamically remembered information into its ongoing thought processes using patch programs called integration mechanisms. CSAM wasn’t just an idea: I built it out into a computer program called Nicole, and even published a workshop paper on it in 1997 called “Can Your Architecture Do This? A Proposal for Impasse-Driven Asynchronous Memory Retrieval and Integration.” But to get a PhD in artificial intelligence, you need more than a clever idea you’ve written up in a paper or implemented in a computer program. You need to use the program you’ve written to answer a scientific question. You need to show that your system works in the domains you claim it works in, that it can solve the problems that you claim it can solve, and that it’s better than other approaches, if other approaches exist. So I tested Nicole on computer planning systems and showed that integration mechanisms worked. Then I and a colleague tested Nicole on a natural language understanding program and showed that memory retrieval worked. But the most important part was showing that CDSA, the heart of the theory, didn’t just work, but was better than the alternatives. I did a detailed analysis of the theory of CDSA and showed it was better than traditional spreading activation in several ways—but that rightly wasn’t enough for my committee. They wanted an example. There were alternatives to my approach, and they wanted to see that my approach was better than the alternatives for real problems. So I turned Nicole into an information retrieval system called IRIA—the Information Retrieval Intelligent Assistant. By this time, the dot-com boom was in full swing, and my thesis advisor invited me and another graduate student to join him starting a company called Enkia. We tried many different concepts to start with, but the further we went, the more IRIA seemed to have legs. We showed she could recommend useful information to people while browsing the Internet. We showed several people could use her at the same time and get useful feedback. And critically, we showed that by using context-directed spreading activation, IRIA could retrieve better information faster than traditional spreading activation approaches. The first publication on IRIA came out in 2000, shortly before I got my PhD thesis, and at the company things were going gangbusters. We found customers for the idea, my more experienced colleagues and I turned the IRIA program from a typical graduate student mess into a more disciplined and efficient system called the Enkion, a process we documented in a paper in early 2001. We even launched a search site called Search Orbit—and then the whole dot-com disaster happened, and the company essentially imploded. Actually, that’s not fair: the company continued for many years after I left—but I essentially imploded, and if you want to know more about that, read “Approaching 33, as Seen from 44.” Regardless, the upshot is that I didn’t follow up on my thesis work after I finished my PhD. That happens to a lot of PhD students, but for me in particular I felt that it would have been betraying the trust of my colleagues to go publish a sequence of papers on the innards of a program they were trying to use to run their business. Eventually, they moved on to new software, but by that time, so had I. Fast forward to 2012, and while researching an unrelated problem for The Search Engine That Starts With A G, I came across the 2006 paper “Recommending in context: A spreading activation model that is independent of the type of recommender system and its contents” by Alexander Kovács and Haruki Ueno. At Enkia, we’d thought of doing recommender systems on top of the Enkion, and had even started to build a prototype for Emory University, but the idea never took off and we never generated any publications, so at first, I was pleased to see someone doing spreading activation work in recommender systems. Then I was unnerved to see that this approach also involved spreading activation, over a typed network, with nodes representing the types of links, and activation in the type nodes changing the way activation propagated over the links. Then I was unsettled to see that my work, which is based on a similar idea and predates their publication by almost a decade, was not cited in the paper. Then I was actually disturbed when I read: “The details of spreading activation networks in the literature differ considerably. However, they’re all equal with respect to how they handle context … context nodes do not modulate links at all…” If you were to take that at face value, the work that I did over ten years of my life—work which produced four papers, a PhD thesis, and at one point helped employ thirty people—did not exist. Now, I was also surprised by some spooky similarities between their systems and mine—their system is built on a context-directed spreading activation model, mine is a context-directed spreading activation model, theirs is called CASAN, mine is embedded in a system called CSAM—but as far as I can see there’s NO evidence that their work was derivative of mine. As Chris Atkinson said to a friend of mine (paraphrased): “The great beam of intelligence is more like a shotgun: good ideas land on lots of people all over the world—not just on you.” In fact, I’d argue that their work is a real advance to the field. Their model is similar, not identical, and their mathematical formalism uses more contemporary matrix algebra, making the relationship to related approaches like Page Rank more clear (see Google Page Rank and Beyond). Plus, they apparently got their approach to work on recommender systems, which we did not; IRIA did more straight up recommendation of information in traditional information retrieval, which is a similar but not identical problem. So Kovács and Ueno’s “Recommending in Context” paper is a great paper and you should read it if you’re into this kind of stuff. But, to set the record straight, and maybe to be a little bit petty, there are a number of spreading activation systems that do use context to modulate links in the network … most notably mine. -the Centaur Pictured: a tiny chunk of the WordNet online dictionary, which I’m using as a proxy of a semantic network. Data processing by me in Python, graph representation by the GraphViz suite’s dot program, and postprocessing by me in Adobe Photoshop.

A Ray of Hoops

centaur 0

rayofhope.png

So, after my scare over almost losing 150+ files on Google Drive, I've made some progress on integrating Google Drive and Dropbox using cloudHQ. The reason it wasn't completely seamless is that I use both Google Drive and Dropbox on my primary personal laptop, and cannot afford to have two copies of all files on this one machine. The other half of this problem is that if you only set up partial sync of certain folders, then any new files added to the top folder of Google Drive or Dropbox won't get replicated - and believe it or not, that's already happened to me. So I need a "reliable scheme" I can count on.

The solution? Set up a master folder on Google Drive called "Replicated", in which everything that I want to keep - all my Google Docs, in particular - will get copied to a folder of the same name called "Replicated" in Dropbox. For good measure, set up another replication pair for the Shared folder of Google Drive. The remaining files, all the Pictures I've stored because of Google Drive's great bang for the buck storage deal, don't need to be replicated here.

The reason this works is that if you obey the simple anal-retentive policy of creating all your Google Docs within a named folder, and you put all your named folders under Replicated, then they all automatically get copied to Dropbox as documents. I've even seen it in action, as I edit Google Docs and Dropbox informs me that new copies of documents in Microsoft Word .docx format are appearing in my drive. Success!

At last, I've found a way to reliably use Google Drive cloud. Google doesn't always support the features you want, or the patterns of usage that you want, but they're deeply committed to open APIs, to data liberation, and to the creation of third party applications that enable you to fill the gaps in Google's services so that you aren't locked in to one solution.

Breaking News: Google Reader canceled. G*d dammit, Google…

Next up: after my scare of losing Google Reader, a report on my progress using The Old Reader to rescue my feeds...

-the Centaur

Pictured: A table candle at Cascal's in Mountain View, Ca...

Rescuing Google Drive?

centaur 0

IMG_20121029_235958.jpg

Ok, the above is a rescue cat, but the point remains. In an earlier post I understandably got a bit miffed when moving a folder within Google Drive - an operation I've done before, many times - mysteriously deleted over a hundred and fifty files. I was able to rescue them, but I felt like I couldn't trust Google Drive - a feeling confirmed when the very next time I used it to collect some quick notes, the application crashed.

But I love the workflow of Google Drive - the home page of Google Drive can show you, very very quickly, either your hierarchy of folders, your recently accessed files, or a search of all your files, and once you've found a file it appears far quicker than most normal applications like Microsoft Word, Microsoft Excel, or Photoshop. Word, Excel and Photoshop kick Google Drive's ass on specialized uses, but many documents don't need that, and Google Drive is a great alternative.

But what about files disappearing? A non starter. However, there are ways around that problem.

Google Drive of course has the ability to export files. You can even export an entire directory in this fashion. If you really want to get serious, you can use Google Takeout, a data migration tool by Google which enables you to export all your Google Drive data, part of Google's Data Liberation Front.

But all those rely on one time manual operations. I want something that works automatically, so for my money it's the Google Drive API that really comes to the rescue. That enables developers to create applications like cloudHQ, which syncs between Google Drive, Dropbox and several other services. I've tried out cloudHQ experimentally and it works on a single folder.

Next I'm going to try it on a larger scale, though it will require a little re-sorting of how I've got Dropbox and Google Drive working. Most likely, I'm going to need to either uninstall Google Drive from my primary computer and sync all its files into Dropbox by CloudHQ, or else manually unsyc certain folders so I don't get double-storage on this machine.

Regardless, there is a silver lining. Now let's see if it's also a silver bullet.

-the Centaur

Pictured: Me holding Loki, our outdoor rescue cat. He's large marge, let me tell you.

The End for Google Drive

centaur 0

Screen Shot 2013-03-03 at 1.13.54 PM.png

Recently I was doing some task and needed to track down some information. I couldn't find the document I wanted at first in my Google Drive, but once I did, I realized I had several documents, all on the same topic, so I did with Google Drive the same thing I'd done before on Google Drive: I went to the Google Drive folder and reorganized the files.

Big mistake.

Quickly red "x's" started appearing in my folders. More and more "unsyncable" files started showing up in the Google Drive status list. And then a status message popped up: "The files you have deleted are now in Google Drive's Trash."

Uh-oh.

Understand: I had deleted no files or folders. I simply moved them around - and I've done this before. A lot. On Google Drive, not just Dropbox. But something apparently happened in the sync, and Google Drive thought I'd deleted the folders.

So it trashed all those files.

Understand, Google Drive "documents" on your hard drive aren't "documents"; they're little text files with pointers to a location in Google Drive, like this (where UNREADABLE_IDENTIFIER is a string of alphanumeric gobbledegook):

{"url": "https://docs.google.com/document/d/UNREADABLE_IDENTIFIER/edit", "resource_id": "document:UNREADABLE_IDENTIFIER"}

This pathetic little bit of nonsense is all I would have had left of a 200 word start to an essay - if I hadn't acted quickly. I started to look online, and found this alarming bit of information:

https://support.google.com/drive/bin/answer.py?hl=en&answer=2375102

Declutter your Google Drive by removing unwanted and outdated files, folders, and Google Docs from your Google Drive. Anything that you own and remove from Google Drive will be in the trash until you permanently delete or restore them.

Moving Google Docs files out of your Google Drive folder will cause their counterpart files on the web to be moved to the trash. If you then purge the trash, those files will become permanently inaccessible. Because the Docs files in your Drive folder are essentially links to files that exist online, moving these files back into your Drive folder after purging the trash online will not restore the files, as their online counterparts will have been deleted.

OMG! The contents of my documents may be lost forever if I purge the trash. But it gets worse...

http://support.google.com/drive/bin/answer.py?hl=en&answer=2494934

If something in Google Drive is moved to the trash, you'll see a warning and you may lose access to it at any time. Read one of the following sections to learn how to restore it to your Google Drive from the trash. When you restore something, it'll be recovered in Google Drive on the web, to the Google Drive folder on your computer, and to your mobile devices.

If the item is in a folder, you’ll need to restore the entire folder to recover any individual items inside of it.

So I quickly returned to Google Drive. Everything you see above with a little red X was gone, all those files and 150 more. I hunted down the Trash (which was harder than you might think, as there was some persistent search in my Google Drive window that was removing the Trash folder from my view) and restored EVERYTHING that I had never deleted in the first place.

Now, this shouldn't have been a surprise. I always knew this could happen, ever since I gladly installed Google Drive on on my Mac in the hope that it would data liberate the Google Documents I had, only to find in my horror that Google Drive wasn't a syncing system, like Dropbox, but a cloud system, which is useless.

In case anyone misses the point: If you use Google Drive to store documents and also have the Google Drive client stored on a machine, Google Drive can get tricked into thinking you've deleted files, at which point it will move them to the Trash, at which point, unlike things you've deliberately trashed, it can delete them at any time - and you'll never get them back.

After some thought, I'm calling a hard stop on all use of Google Documents, except those I'm using to collaborate with others, where the collaboration features of the Google Doc outweigh the potential of risk. I can always save those files to a hard backup of a Word document or an Excel spreadsheet.

But I work for a living as a writer. And I can't work with a system that can arbitrarily trash hundreds of files and thousands upon thousands of words of documents with no hope of recovery just because I moved a folder … correctly.

Like Ecto, I have to rethink my use of these online tools - rethink them in a way that ensures that for every significant thing that I use in some convenient online system, I have a saved copy in an archivable backup.

More updates as I develop a new system.

-the Centaur

Approaching 33, Seen from 44

centaur 0

33-to-44.png

I operate with a long range planning horizon – I have lists of what I want to do in a day, a week, a month, a year, five years, and even my life. Not all my goals are fulfilled, of course, but I believe in the philosophy “People overestimate what they can do in a year, but underestimate what they can do in a decade.”

Recently, I’ve had that proven to me.

I’m an enormous packrat, and keep a huge variety of old papers and materials. Some people deal with clutter by adopting the philosophy “if you haven’t touched it in six months, throw it away.” Clearly, these people don’t write for a living.

So, in an old notebook, uncovered on one of my periodic archaeological expeditions in my library, I found an essay – a diary entry, really – written just before my 33rd birthday, entitled “Approaching 33” – and I find its perspective fascinating, especially when you compare what I was worried about then with where I am now.

“Approaching 33” was written on the fifth of November, 2011. That’s about five years after I split with my ex-fiancee, but a year before I met my future wife. It’s about a year after I finished my nearly decade-long slog to get my PhD, but ten years before when I got a job that truly used my degree. It’s about seven months after I reluctantly quit the dot-com I helped found to care for my dying father, but only about six months after my Dad actually died. And it’s about 2 months after 9/11, and about a month after disagreements over 9/11 caused huge rifts among my friends.

In that context, this is what I wrote on the fifth of November, 2011:

Approaching 33, your life seems seriously off-track. Your chances of following up on the PhD program are minimal – you will not get a good faculty job. And you are starting too late to tackle software development; you are behind the curve. Nor are you on track for being a writer.

The PhD program was a complete mistake. You wasted ten years of your life on a PhD and on your ex-fiancee. What a loser.

Now you approach middle fucking age – 38 – and are not on the career track, are not on the runway. You are stalled, lacking the crucial management, leadership and discipline skills you need to truly succeed.

Waste not time with useful affirmations – first understand the problem, set goals, fix things and move on. It is possible, only if you face clearly the challenges which are ahead of you.

You need to pick and embrace a career and a secondary vocation – your main path and your entertainment – in order to advance at either.

Without focus, you will not achieve. Or perhaps you are FULL OF SHIT.

Think Nixon. He had major successes before 33, but major defeats and did not run for office until your age. You can take the positive elements of his example – learn how to manage now, learn discipline now, learn leadership now, by whatever means are morally acceptable.

Then get a move on your career – it is possible. Do what you gotta do and move on with your life!

It appears I was bitter.

Apparently I couldn’t emotionally imagine I could succeed, but recognized, intellectually, that if I focused on what was wrong, and worked at it, then maybe, just maybe, I could fix it. And in the eleven years that have past … I mostly have.

Eleven years ago, I was enormously bitter, and regretted getting my PhD. It took five years, but that PhD and my work at my search-engine dot-com helped land me a great job, and after five more years of work I ended up at a job within that job that used every facet of my degree, from artificial intelligence to information retrieval to robotics to even computer graphics. My career took a serious left turn, but I never gave up trying, and eventually, I succeeded as a direct result of trying.

Eleven years ago, I felt enormously alone, having wasted a lot of time on a one-sided relationship that should have ended naturally after its first year, and having wasted many years after that either alone or hanging on to other relationships that were doomed not to work. But I never stopped looking, and hoping, and it took another couple of years before I found my best friend, and later married her.

Eleven years ago, I felt enormously unsure of my abilities as a software developer. At the dot-com I willingly stepped back from a software lead role when I was asked to deliver on an impossible schedule, a decision that was proved right almost immediately, and later took a quarter’s leave to finish my PhD, a decision that took ten years to prove itself. But even though both of those decisions were right, they started a downward spiral of self-confidence, as we sought out and brought in faster, more experienced developers to take over when I stepped back. While my predictions about the schedule were right, my colleagues nevertheless got more done, more quickly, ultimately culling out almost all of the code I wrote for the company. After a while, I felt I was contributing no more and, at the same time, needed to care for my dying father, so I left. But my father died shortly thereafter, six months before we expected. I found myself unable not to work, thinking it irresponsible even though I had savings, so I found a job at a software company whose technical lead was an old friend that who had been the fastest programmer I’d ever worked with in college, and now who had a decade of experience programming in industry – which is far more rigorous than programming in academia. On top of that, I was still recuperating from an RSI scare I’d had four years earlier, when I’d barely been able to write for six months, much less type. So I wrote those bitter words above when I was quite uncertain about whether I’d be able to cut it as a software developer.

Eleven years later — well, I still wish I could code faster. I’m surrounded by both younger and older programmers who are faster and snappier than I am, and I frequently feel like the dumbest person in the room. But I’ve worked hard to improve, and on top of that, slowly, I’ve come to recognize that I have indeed learned a few things – usually, the hard way, when I let someone talk me out of what I’m sure I know, and am later proved right – and have indeed picked up a few skills – synthetic and organizational skills, subtle and hard to measure, which aren’t needed for a small chunk of code but which are vital as projects grow larger in size and design docs and GANTT charts are needed to keep everything on track. I’d still love to code faster, to get up to speed faster, to be able to juggle more projects at once. But I’m learning, and I’ve launched things as a result of what I’ve learned.

But the most important thing is that I’ve been writing. A year after I wrote that note, I gave National Novel Writing Month a try for the first time. I spent years trying to perfect my craft after that, ultimately finding a writing group focused just on writing and not on critique. Five years later, I gave National Novel Writing Month another try, and wrote FROST MOON, which went on to both win some minor awards and to peak high on a few minor bestseller lists. Five years after that, I’ve finished four novels, have starts to four more, and am still writing.

I have picked my vocation and avocation – I’m a computer programmer, and a writer. I actually think of it as having two jobs, a day job and a night job. At one point I thought I was going to transition to writing full time, and I still plan to, but then my job at work became tremendously exciting. Ten years from now, I hope to be a full time writer (and I already have my next “second job” picked out) but I’m in no rush to leave my current position; I’m going to see where it takes me. I learned that long ago when I had a chance to knuckle down and finish my PhD, or join an unrelated but exciting side project to build a robot pet. The choice to work on the emotion model for that pet indirectly landed me a job at two different search engines, even though it was the skills I learned in my PhD that I was ultimately hired for. The choice to keep working on that emotion model directly led to my current dream job, which is one of the few jobs in the world that required the combined skills of my PhD and side project. Now I’m going to do the same thing: follow the excitement.

Who knows where it will lead? Maybe it will help me develop the leadership skills that I complained about in “Approaching 33.” Maybe it will help me re-awaken my research interests and lead to that faculty job I wanted in “Approaching 33.” Maybe it will just help me build a nest egg so when I finally switch to writing full time, I can pursue it with gusto. Or maybe, just maybe, it’s helping me learn things I can’t even yet imagine how I’ll be using … when I turn 55.

After I sign off this blogpost, I’m going to write “Passing 44.” Most of that’s going to be private, but I can anticipate it. I’ll complain about problems I want to fix with my writing – I want it to be more clear, more compelling, more accessible. I’ll complain about problems I want to fix at work – I want to work faster, to ramp up more quickly, and to juggle more projects well while learning when to say no. And I’ll complain about martial arts and athletics – I want to ramp up working out, to return to running, and to resume my quest for a black belt. And there are more things I want to achieve – wanting to be a better husband, friend, pet owner, person – a lot of which I’m going to keep private until I write “Passing 44, seen from 55.”

I’m going to set bigger goals for the next ten years. Some of them might not come to pass, of course. I bet a year from now, I’ll have only seen the barest movement along some of those axes. But ten years from now … the sky’s the limit.

-the Centaur

Pictured: Me at 33 on the left, me at 44 on the right, over a backdrop shot at my home at 44, including a piece of art by my wife entitled "Petrified Coral".

Ecto, Strike Two

centaur 0

Ecto just ate a HUGE post. Second time this has happened.

Time for a new blogging client?

-the Centaur

A Really Good Question

centaur 0

layout.png

Recently I was driving to work and thinking about an essay by a statistician on “dropping the stick.” The metaphor was about a game of pick-up hockey, where an inattentive player would be asked to “drop the stick” and skate for a while until they got their head in the game. In the statistical context, this became the action of stopping people who were asking for help with a specific statistical task and asking what problem they wanted to solve, because often solving the actual problem may be actually very different from fixing their technical issue and may require completely different approaches. That gets annoying sometimes when you ask a question to a mailing list and someone asks you what you're trying to solve rather than addressing the issue you've raised, but it's a good reflex to have: first ask, "What's the problem?"

Then I realized something even more important about projects that succeeded or failed in my life – successes at radical off the wall projects like the emotional robot pet project or the cell phone robots with personalities project or the 3d object visualization project, and failures at seemingly simpler problems like a tweak to a planner at Carnegie Mellon or a test domain for my thesis project or the failed search improvement I worked on during my third year at the Search Engine that Starts with a G. One of the things I noticed about the successes is that before I got started I did a hard core intensive research effort to understand the problem space before I tackled the problem proper, then I chose a method of approach, and then I planned out a solution. Paraphrasing Eisenhower, even though the plan often had to change once we started execution, the planning was indispensable. The day-to-day immersion in the problem that you need for planning provides the mental context you need to make the right decisions as the situation inevitably changes.

In failed projects, I found one or more things – the hard core research or the planning – wasn’t present, but that wasn’t all that was missing. In the failure cases, I often didn’t know what a solution would look like. I recently saw this from the outside when I conducted a job interview, and found that the interviewee clearly didn't understand what would constitute an answer to my question. He had knowledge, and he was trying, but his suggested moves were only analogically correct - they sounded like elements of a solution, but didn't connect to the actual features of the problem. Thinking back, a case that leapt to mind from my own experience was a project all the way back in grade school, where I we had an urban planning exercise to create an ideal city. My job was to create the map of the city, and I took the problem very literally, starting with a topographical map of the city's center, river and hills. Now, it's true that the geography of a city is important - for an ideal city, you'd want a source of water, easy transport, a relatively flat area for many buildings, and at least one high point for scenic vistas. But there was one big problem with my city plan: there were no buildings, neighborhoods, or districts on it! No buildings or people! It was just the land!

Ok, so I was in grade school, and this was one of my first projects, so perhaps I could be excused for not knowing what I was doing. But the educators who set up this project knew what they were doing, and they brought on board an actual city planner to talk to us about our project. When he saw my maps, he pointed out this wasn't a city plan and sat down with all of us to brainstorm what we'd actually want in a city - neighborhoods, power plants, a city center, museums, libraries, hospitals, food distribution and industrial regions. At the time, I was saddened that my hard work was abandoned, and now in hindsight I'm saddened that the city planner didn't take a minute or two to talk about how geography affects cities before beginning his brainstorming exercise. But what struck me most about this in hindsight is that I really didn't know what constituted an answer to the problem.

suddenclarity.png  

So, I asked myself, “What counts as a solution to this problem?” – and that, I realized, is a very good question.

-the Centaur

Pictured: an overhead shot of a diorama of the control room of the ENIAC computer as seen at the Computer History Museum, and of course our friend Clarence having his sudden moment of clarity.

Viiiictory Seven Times

centaur 0

spectralironwin.png

For the seventh time, I've won the National Novel Writing Month "contest", completing 50,000 words of a new novel in just 30 days. Actually, it took me just 29 days. Woohoo!

Winner-180x180.jpg

This year's entry, SPECTRAL IRON, is the fourth book in the Dakota Frost series, my urban fantasy series featuring the best magical tattooist in the Southeast (and she's not afraid to tell you that herself). SPECTRAL IRON was a bit of a detour from the work I was doing to edit LIQUID FIRE, the third entry in the series, but I'm glad I did: SPECTRAL IRON taught me a lot about what makes a book coherent and I can use that to edit LIQUID FIRE.

So what is SPECTRAL IRON about? Originally, I was thinking the story was about a villain that murders ghosts, but now it's looking like the villain is a ghost who's a murderer. Maybe. There are some very interesting plot complications developing. Let me see if I can pull out an excerpt that doesn't give much away. Well, maybe it spoils a minor surprise, but it doesn't give away the plot. This is the kind of thing they'd put in a movie trailer. Regardless ... SPOILERS:

Now, all that was left was to walk down a hundred more yards of train tracks in the dark.

The dolly had left us, but the spotlight had not. The mobile klieg operator wheeled it forward, slowly, tracking me, Ron and Sunny as we walked down the pathetic, waterlogged track. The further we went, the more layers of mystery were stripped off, one by one, by the light.

By the end, we no longer stood in a chasm of night. We merely stood in a dilapidated warehouse loading bay, a long, low brick-walled chamber, weathered with graffiti, with chained-up wooden doors atop its loading dock and beer bottles in the puddles between its train tracks.

“Nothing here,” the Lady Nyissa said. “Nothing obvious, at any rate.”

I stopped before the back wall of the loading dock. It stretched up before us, a mottled wall of brick thirty feet wide and fifty feet high, with a notch cut out of its bottom right by the platform and another cut out the top by a door. Rusted zig-zag metal stairs led up to it.

“Well,” I said, putting my foot on the train-brake at the end of the tracks, staring down at the pathetic mud puddle rippling before us between the end of the tracks and the wall. “It looks like The Exposers have found another Al Capone’s vault.”

Oh, me and my dumb mouth.

From the water erupted a foul spray of black—topped by a bone white mask.

So, there's a few thousand more words of brain dump to go, and then it's back to editing LIQUID FIRE, revising THE CLOCKWORK TIME MACHINE, and working on the DOORWAYS TO EXTRA TIME anthology, oh, and revising my own story for the anthology, "The Doorway to Extra Time" ... aaaa! But at least I have this year's Nano victory to console me:

Screen shot 2012-11-29 at 10.13.37 PM.png

Regardless, now that Nanowrimo and 24 Hour Comics Day and the Google Holiday Toy Collection are all behind me, I'm looking forward to getting back to my other projects, including all my writing, the Dakota Frost blog, and, heck, I dunno, my wife, friends and cats. Onward and upwards!

-the Centaur

Derailed

centaur 0

spectral-iron-day16-progress-1.png

Software launches. Anthology editing. I am now officially behind. Time to get back to Nano.

Fortunately I have the next nine days off, starting with tomorrow!

This is why I plan Nano carefully ahead ... this always happens, so you need to plan to have a buffer ... not just getting ahead early, but a place and time to catch up later for if and when you fall behind.

-the Centaur

Just add a dimension

centaur 0

Screen shot 2012-11-13 at 12.19.30 PM.png

At long last, the project I've been working on at the Search Engine That Starts With A G is live. The Google Shopping 3D experience has been launched to the world. From the blogpost:

Explore products in 360-degree detail on Google Shopping Having trouble imagining what a toy actually looks like from the online picture? Now, when searching for a subset of toys on Google Shopping, you can see 360-degree photos of the products. These interactive images bring the in-store feeling of holding and touching a product to your online browsing. Look for the “3D” swivel icon on the product image to see a toy in 360-degree view, on HTML5 enabled browsers. We’ve also put together a Holiday Toy Collection featuring this enhanced imagery—explore the collection on this site. 360-degree imagery is coming for other types of products soon.

Depending on how you count, we've been working on this project for six months, a year, a year and a half, or two years. We've been in launch crunch proper for six months or so, but planning for the launch began a year ago after the launch of the Galaxy Nexus in glorious 3D WebGL (and yes, it did take us the whole year to get this far, and it was really tight down near the end).

The technology demonstrations that led to that launch and made this launch possible began six months before that, and the actual team that was working on them started just over two years ago - and, honestly, it feels like we've been in crunches and sprints for the entire time. Christmas 2012 seemed both far away and far too soon a year ago. It was barely possible.

But we made it.

I don't share much about the innards of The Search Engine That Starts With A G, especially on a project like this, so I'm going to draw to a close with this thought: I work on a wonderful team filled with fantastic people, geniuses and innovators and hard workers all, and each and every one of them were really critical to making this possible (and I mean that. We had NO slack).

I'd be proud to go into [software] battle with you wonderful guys and gals, any time, any where.

-the Centaur

Pictured: the 3D (well, really 360-degree spinner) of the Lego Jabba palace. Article title shamelessly stolen from Asimov. Final quote thieved from Patton.

Postscript: You know, I said "geniuses and innovators and hard workers all" but it occurred to me afterward that most of what these geniuses achieved is not at all obvious. The greatest things we did in this project are completely invisible; you would only notice them if we had failed. Despite seeming to be very simple - a few links, a 3D icon, a rotating swivel - this project actually was the most technically rigorous one I've ever worked on, including both my PhD and the search engine startup I worked on. So when I said these guys are geniuses, I really mean that - they delivered perfection so great it becomes almost invisible.