Recent Posts

2014 was a huge year. Notably, I moved in with Norma, switched jobs from writing code to teaching how to code, and learned more about how to manage myself.

I've got plenty of things to work on in 2015 so I'm breaking this into a sequence of posts based on subject. I'd like to broadly note that for my first semester (roughly January through March) I might barely get anything done and that is okay. I've never taught before and I expect that learning curve to take up most of my time until early April. Now without any further ado ...

A Few Goals for 2015

1. Personal (forthcoming)
2. Technical
3. Musical (forthcoming)
4. Competitive (forthcoming)
5. Recreational

A Fresh Start

I've been struggling a lot this year. I got stuck in a hole and it took me a while to find my way out. But I learned a few things along the way and I'm very excited about what's coming next.

I've accepted a job as a Ruby on Rails instructor at The Iron Yard. I'll be training people to become engineers in a very short timespan. For over a year, I've been whispering now and then about an interest in teaching, to Norma and friends. Starting January 5th, I'll have my first students. I'm equal parts nervous and exhilarated. I can't wait.

Learning How to Quit

A lot of my happiness and self-worth is tied up in making visible progress on things I care about. Over the past 10 months I lost faith in what I was doing at work and enthusiasm for my personal projects. Rather than recognizing that I should find a job I was passionate about or spend time on projects that excited me, I dug my heels in. No longer.

At one point, I said a Nintendo emulator was my forever project. I'd still like to see it taken further but I'm not going to work on that now. Belligerently sticking to those guns has been limiting my own potential. The only purpose of personal projects is to learn and to grow. They are mine and no one else's.

So until further notice, the emulator is on the backburner. Coleslaw will still get maintenance work but probably not much feature development. There are new things I'm fired up about and my focus will be on deriving as much momentum from them as possible.

Going Forward

I'm playing with Renoise and trying to pick up some music theory. I'm still not really making songs but I'll get there. I'm continuing to learn melee and now that I have a real training regiment in place I'm seeing much faster improvement. Hopefully I'll make it out to local tournaments every now and then.

I want to become more structured about practice. That includes starting to chip away at the stacks of CS and programming books I own that I haven't gotten around to reading. And experimenting with new tools like Ocaml, OpenMirage, and Ansible. And making room for play where nothing gets done.

I need to learn how to love and care for myself in spite of how much I get done, in spite of visible progress made or unmade. Part of that is going to be taking back my online presence, away from the more cultivated space of the last few years. There's a lot I want to accomplish over the next year or so. I'm sure plenty of what I learn won't be according to plan. But it's time to get going. It's time get organized. It's time to dig in.

Disclaimer

This post is mostly written for myself. It assumes familiarity with various terms, people, equipment, etc. If you find it useful or entertaining, whether you play melee or not, cool. This post is not intended to be a training guide. I'm not good enough to be educating beginners, just to observe my experience over the last year.

If you do want to get started with Melee, you need a few things:

• Good condition Gamecube Controller (Nintendo-only, no knockoffs)
• A CRT or lagless setup, I rock a BenQ RL2455HM with the Sewell Wii-to-HDMI converter and an Avermedia LGP for recording
• A Gamecube and Melee disc, or better, Wii and 20xx hack pack on SD card
• Familiarity with the basics of smash as a series and a character to focus on
• A good guide, maybe check the resources at the end :)

Enter Melee

I'm not a gamer. The last time I really put substantial time into video games was high school. I also wouldn't describe myself as a competitive person. But for whatever reason, I've always been competitive in Smash Bros. I want to win.

Late last October, I stumbled on a documentary detailing the history of the competitive smash brothers scene. I was riveted. I was suddenly aware of a massive depth to the game I'd hitherto missed. I had to know more, I had to try to my hand at competitive play.

Why Do This?

In addition, I've always struggled with things I'm not immediately good at. I'm terrible at being patient with myself, at viewing life (and goals) as a journey and not a destination to be reached post haste. Melee remains an excellent opportunity to practice being loving and patient with myself, and handling failure and defeat gracefully.

As I said before, it's a monumentally deep game. Like in chess, character positioning and board layout is paramount. As in poker, bluffing and calling your opponent's bluffs is crucial. There's also an executional aspect. Professional players routinely execute 300 actions per minute and have to perform complex controller inputs in a 20th of a second window or less. Not to mention just learning the properties of 25 characters, their moves, and the Rock Paper Scissors of what beats what in which situations.

I've been at it for a while now. I'm still not good but I'm much more at peace with that than I was when I started. Here are a few things I've learned playing melee the past year. A lot of these things are habits I've had to work hard to break. Just remember not to get discouraged. Melee can be very unforgiving.

Rule Number 1: Keep It Fun

You have to stay motivated. If things get too serious and you're not having fun you're going to play less and your skill will plateau. There are a lot of things beginners have to absorb and a plethora of suggestions, bordering on rules, about how to practice. Feel free to violate anything anyone says in order to keep things fun.

A few semi-regular suggestions I violate in the name of fun are:

• Focus on 1 character

I play 2 seriously (Sheik/Marth), 2 semi-seriously (Fox/Falcon), and 2 for fun (Pikachu/Doc Mario). If I don't switch it up, I find myself getting frustrated with progress on a single character. And when playing with friends, it can be surprisingly rejuvenating to go play a quick falcon ditto after an hour or more of serious play.

Additionally, I find some characters make certain kinds of practice more rewarding. For me, Fox makes it really fun to practice tech skill and Marth makes it really fun to practice spacing. Those characters really emphasize those attributes which makes the practice payoff very clear.

• Don't practice against CPUs ... (above level 5, to hone your mental game, etc)

The big argument here is that CPUs ingrain bad habits. Especially if all you're trying to do is win. So don't try to win. PPMD talks about doing something called shadowboxing, essentially playing the CPU like a human opponent. The 20xx hack pack is supposed to improve their behavior in various ways, especially DI. I find it helpful to practice tech skill at a level where the CPU will punish me if I'm too slow or miss an input.

Rule Number 2: Structure Your Play

Editor's Note: Some of the advice in this section is specific to me because I don't attend or plan to attend lots of local tournaments. The core advice of separating different kinds of play still applies.

To play competitively, you're going to wind up doing 3 things:

1. Practicing tech skill
2. Experimenting with your play
3. Competing seriously

It is important that you keep these things distinct. For example, I try to spend 20-30 minutes a day practicing tech skill. I move around the stage, working on flubs or things I execute too slowly. I try to learn new tech (such as waveshines). I don't go to many local tournaments so I experiment with different approaches and punishes against a CPU. Finally, when I want to be competitive I play (seriously) against friends.

Initially, you'll want to blur all this together. You'll be playing semi-seriously with a friend and be tempted to try "new stuff": platform movement, wavedashing, the "Ken combo", getting an off stage Falcon Punch. Don't give in to the temptation. Melee requires you to adapt to your opponent above all else. If you're too busy obsessing over moves you want to land, you'll limit your options and your play will suffer for it. This isn't to say you shouldn't try to work on specific things in matches with your friends. Just that tech skill you haven't mastered and particular combos are not those things.

To emphasize further, don't practice specific combos. Part of Melee's depth comes from DI, or Directional Influence, the upshot of which is that getting a specific combo might be impossible depending on the opponent's actions. Long story short, DI allows you (and your opponent) to change the direction a hit knocks them in, potentially making follow up attacks miss. The interesting choices in melee come in between hits as you watch what your opponent does and react to it. While there are "guaranteed" combos in specific situations (character a vs character b at XX%), most of our combos come from reacting not planning.

Rule Number 3: Work To See The Neutral Game

If you've spent years playing Smash casually, you'll largely see the game as hitting or being hit, offense or defense. But that brutal simplification will limit your ability to see the larger game. Two common adages fall under this section:

1. Don't Mindlessly Approach (your opponent)
2. Don't Mindlessly Trade (hit for a hit)

The takeaway is, It's better to not get hit than to get a hit.

You'll be tempted to rush in right away, ignore that impulse. You'll be dying to hit them back for hitting you, re-establish good footing instead. The "neutral game" is everything that happens outside of getting a hit or combo and trying to escape being hit. The sooner you can see encroaching on an opponent's space on the stage as a useful form of micro-aggression, the better off you'll be. Just positioning yourself in a threatening way is a hugely useful tool.

Don't force your play into a false dichotomy of attacking or defending.

Rule Number 4: Remember Where Your Good Options Are

Editor's Note: This rule was originally called "Stay Grounded" and came from my reflections on the Marth v Link matchup with my buddy Max. Some of this section will be dependent on the matchup.

Stage position is important. Let's say it again: Stage position is really, really important. When I first started playing Marth, I always wanted to approach in the air. Just all the time. Lord knows why. But being in the air takes away a huge number of movement options. Your opponent can plan around and react to your play more easily when you have fewer options.

I wound up above Max a lot and got punished. Even if your character has good aerial attacks, unless you're talking cross up nairs with Pikachu or Fox there are probably safer, better approaches. So, being above your opponent is usually a pretty negative situation.

In general, center stage is a great place to be, and above the opponent, in a corner, or on the ledge, are bad places to be. Platforms are a bit more of a mixed bag. But remember where on the stage you have advantage and where your good options aren't available and figure out why that is.

In addition, spacing is really important. Spacing is more than just trying to throw out attacks from a safe distance, or thinking about your opponent's range. It also has to do with thinking about the range at which your character performs best. Marth and Falcon, for example, are mid-range powerhouses, while Fox and Sheik generally need to get in close to be really effective. Know where your character performs well and remember to stay in that effective range as much as possible.

Rule Number 5: Do Think About Options, Action States, and Transitions

Kirbykaze's blog posts explain this much more clearly than I will. Any time you can keep most of your options open while limiting your enemy's, do it. That's a huge advantage. And any time you can narrow their range of choices you have a much better chance of predicting their play, or finding a tactic that covers every possible outcome.

Since Melee is so much about movement and positioning, being fast is key. And indeed, most of the executional aspects of high-level play are in service of eliminating as much lag as possible from your character's moves. It's useful to try to build a formal model here.

Every move in the game has a set duration, though certain moves (dash dancing, wave dashing, aerials) can be shortened to varying degrees. Once you've committed to a move, the opponent knows more or less how long the move's hitbox will be active, how long you'll be unable to execute a different move, etc.

Consequently, speed mostly comes from transitioning quickly between moves or, as Kirbykaze's blog says, "action states". The better you get at switching between shielding, standing, walking, dash dancing, wavedashing, and attacking, the faster you'll be. Seamlessly and quickly transitioning between these states is vastly more valuable than L-canceling all your down aerials.

This is something I'm just now realizing and trying to improve on. It's very appealing to just work on l-canceling or short hops or wavedashing but misses the real point. The connecting tissue between action states is where most of our sluggishness comes from.

Don't Give Up

Finally, it should be obvious that regular, focused practice makes a big difference. I'm going to try to practice 20 minutes a day, 5 days a week going forward. I'm still figuring out exactly what that practice regimen will consist of, probably mostly tech skill and movement with Sheik and Marth. Wavedashing and L-canceling are muscle memory, sure, but practicing the basics shouldn't ever really stop.

And I'm still not where I want to be but I've had a few good moments. I hope this has been an interesting post on some things I've struggled with while learning melee. Happy smashing and if you're in Atlanta and want a game, feel free to drop me a line.

Resources

I really enjoy Kirbykaze's blog and writings about the game. Two particularly good posts are Movement Drills, Part 1 and Tactics.

Various people have posted articles for beginners on getting better:

• Mango
• NMW
• sleepyk
• Albert

Read. Them.

Why do Programming?

After going to Strangeloop for the first time in 2012, I was really fired up about programming. I'd only been out of school a year and was already a full-remote Clojure developer making a great salary. Even better, I had made good progress on my lisp emulation project and received some recognition from hackers I respected for it.

The last two years Strangeloop has been a lot more sobering. I told myself things in 2012 about how fast I'd get better and how good I'd be. Even though my expectations were unreasonable it's taken a long time to not feel bad about my (relative lack of) progress. I've been slow to accept the fact that I don't want to fight my way to being the best in my field.

Strangeloop, 2014

I got in Tuesday night, dropped my bags at the hotel, and immediately ran off to drinks and phenomenal conversation at the Schlafly Tap Room. Many of the best experiences I've had at Strangeloop have been at the tap room. Sure there is excellent food, beer, and technical conversation, but I've always gotten a sense of personal acceptance at gatherings there. Strangeloop is certainly a welcoming crowd.

Wednesday was a blast as well, as any day with a trip to the STL City Museum should be, but more and more I found I cared about personal interactions more than the content of the talks I attended.

By the end of Thursday, I was stressed out. I wasn't even excited about the talks, which isn't to say they weren't good. I hated the idea that I was just an average programmer, that I didn't aspire to more than hacking bog-standard Rails apps as a career, that I'd spent almost $2000 out of my own pocket to come to a conference that someone else might have gotten more out of. I went to bed early that night.

I kept my mindset in check much better on Friday. I reminded myself to be excited about others discoveries and creations, not to demand myself learn every tool or technique. The conference wrapped up well and I particularly enjoyed some of the Distributed Systems talks, a subfield I still have no experience with. Not to say I want to go fight distributed heisenbugs soon or design highly reliable systems. The talks were quite entertaining and informative is all.

Back Home

The main takeaways I've had from Strangeloop have nothing to do with tech and everything to do with me. Strangeloop has, in many ways, been a time for me to reflect these last two years. I'm not sure that's a good way to use the conference but it seems to be what I've done.

The first takeaway that comes to mind is that I need to try and respect myself for just being a decent Rails developer. I'm not great at solving algorithmically tricky problems and my CS background is, frankly, pretty damn weak. But no matter what I shouldn't beat up on myself for being "just a programmer". I need to put in an honest day's work and actually pat myself on the back at the end of it.

The second takeaway is that I need to program for me again. I got into programming mostly because I wanted to know more about how computers work. The emulator and talks surrounding it, some of my favorite work, is really more an investigation than artifact. I still want to support coleslaw. It actually has a few satisfied users and I'm one of them. But the only real purpose of the emulator is to sate my curiosity. Not to become a real thing or be special or groundbreaking.

There is plenty I'm still digesting and plenty I'm still not sure of, both technically and in terms of what I want for myself, my career, my life. But I'll leave that for another day. Cheers.

I'm working towards 1.0 and Coleslaw's basic architecture seems to have settled down. The areas of focus for 1.0 will be better error handling, command-line conveniences, more content types, and possibly some new ways to ingest data.

Coleslaw 0.9.6 will be released this Saturday and, not long after, make it into the next quicklisp release. Seeing as it contains big changes, some of them breaking, I thought I'd put out an announcement.

Coleslaw 0.9.6

Coleslaw 0.9.6 unifies how we handles URLs throughout the application and simplifies the deploy strategy. The good news is, this makes the install process easier for new users. The bad news is, if you've got an existing install, you'll need to add a new plugin (versioned) to your config file for the old deploy behavior.

That's not so rough, right? In addition, custom themes and plugins that haven't been upstreamed may need some minor tweaks. The NEWS has more details.

Feel free to grab the basic-deploy branch from my repo and try it out. There are some new docs and the README has been cleaned up. There's also a plugin for Twitter Summary Card support and the usual smattering of bugfixes.

Going Forward

While I'm happy to maintain Coleslaw if no one else steps up to work on it, I'm going to try and shift my focus towards emulation work and weird lisp noodling. If you're interested in taking on a co-maintainer role or working with me on the project please get in touch. I've been very appreciative of the help and interest thus far. If there's anything I can do to make the project more approachable or help people get started, do let me know.

It's time for the best programming conference of the year, again!

I fly out to Strangeloop later today. Here are the talks I'm planning on attending:

Wednesday the 17th: Future of Programming Workshop/Emerging Languages Camp (all day)

Thursdsay the 18th:

• 09:00 - Joe Armstrong, The Mess We're In
• 10:00 - Stephen Kell, Liberating the Smalltalk Lurking in Unix
• 10:50 - Christine Flood, Shenendoah: Open Source Pauseless GC for OpenJDK
• 12:20 - Leo Meyerovich, The Sociology of Programming Languages
• 13:10 - Paul Snively, Type Systems: The Good, the Bad, and the Ugly
• 14:00!! - Core.async Debugging Toolkit, or Production Prolog?
• 15:10!! - Consistency without Consensus, or Aeron: High Performance Messaging?
• 16:00 - Stefanie Schirmer, Dynamic Programming at Ease

Friday the 19th:

• 09:00 - Nada Amin, Programming Should Eat Itself
• 10:00 - Evan Czaplicki, Controlling Time and Space
• 10:50 - Yodit Stanton, The Internet of Things in Practice
• 13:10 - Ian Davis, The Challenges and Benefits of an FRP Frontend
• 14:00 - David Renshaw, Cap'n Proto and Rust: Type Systems for Sharing
• 15:10 - Julia Evans, You Can Be A Kernel Hacker!
• 16:00 - Aaron Bedra, Deterministic Memory Management for Managed Runtimes
• 16:50 - Carin Meier, Sam Aaron - Our Shared Joy of Programming

!! = Denotes time slots I'm uncertain about. Open to suggestions...

(In which I talk about my feeeeeeels)

Disclaimer: This post comes in the middle of an existential crisis. I'm struggling a lot with programming as a career choice and feeling disconnected from a community of excited hackers. These feelings and opinions are my own and I think it's totally fine if you don't subscribe to them or want to write me off as an F-ing idiot.

Love First

A lot of the ideas in this post have been buzzing around in my head since I saw Jen Myers deliver her keynote at Strangeloop last year.

I've been keeping my thoughts in my head mostly because I'm already an established programmer. A lot of the motive for the talk was to be more welcoming to newcomers and minorities that struggled to be included in our communities. But I think this problem affects all of us, every last one, regardless of gender, race, or class.

The short version is that I think the tone of programming communities, especially online ones, is horrific. It's filled with religious debate over things less important than getting people excited about and interested in computing. For me, whether it's smart people posturing for social status or individuals genuinely trying to enlighten others is irrelevant.

Our first reaction to any comrade, any other person passionate about and interested in building things with computers, any human crazy and masochistic enough to try and expand the capabilities of these absurd machines, should be empathy and love.

This may seem ridiculous at first glance. It's harder than it sounds.

The Same Old Arguments

You already know the religious wars I'm talking about. They're silly little things. Are static or dynamic types better? (For some, is there even such a thing as being dynamically typed?) Is Vim or Emacs better? Should I learn programming with PHP or Haskell? Should my app use JSON, XML, or a self-describing binary format? Is programming math, art, or craft? Can code be literature?

For a host of reasons, these are questions we have a vested interest in. And I think, more often than not, our motive is to encourage more learning and exploration. But the conversation is almost always full of condescension and judgment, especially if the medium for response is limited. We simply cannot let supporting curiosity become secondary to proselytizing "the right thing".

Plain and simple, turning a prompt for exploration into a right-or-wrong religious debate is curiosity destroying. And that's precisely the opposite of our intent, the opposite of what we as a community should aspire to.

Our opinions are important, and I'm not precluding the existence of a right answer. But someone pondering a tricky subject isn't best met by bludgeoning them over the head with a conclusion. As long as the principal motive of those we interact with is the fractal question "Why?", we are together.

This connects to a lot of things. It connects to people wondering if they're good at programming, or how to know such a thing. It contributes to impostor syndrome. I've struggled to hack on hobby code for fun because I don't feel like I can be proud of it. Not smart enough, not groundbreaking enough, not important enough. And I know that's silly, because there are more important things to worry about.

So the more we can get away from emphasizing that the most important thing in programming is being right, the better that will be for newcomers, for hobbyists, and I believe, for all of us.

Epilogue

I'm reminded of an Alan Perlis quote in SICP:

"I think that it's extraordinarily important that we keep the fun in computing. ... We began to feel as if we really were responsible for the successful, error-free, perfect use of these machines. I don't think we are.

I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house."

I'm not perfect at this either. It is difficult to never be dismissive, let alone to always be gentle. But sometimes people are just trying to make it through the day. Not use the best tool, not come up with a groundbreaking solution, not fix the world. We need to try to meet other programmers where they are. Not move them to our habitat before empathizing, before loving.

Ironically, I know this has been a bit of a high-horse diatribe. At least let me give you a gift for coming so far and listening to me ramble so much. Here, have something I love, bits of Milosz:

To whom do we tell what happened on the earth,
for whom do we place everywhere huge mirrors
in the hope that they will be filled up and will stay so?

I think that I am here, on this earth,
To present a report on it, but to whom I don’t know.
As if I were sent so that whatever takes place
Has meaning because it changes into memory.

To find my home in one sentence, concise, as if hammered in metal.
Not to enchant anybody. Not to earn a lasting name in posterity.
An unnamed need for order, for rhythm, for form,
which three words are opposed to chaos and nothingness.

What did I really want to tell them? That I labored to transcend my place and time,
searching for the Real. And we could have been united only by what we have in common:
the same nakedness in a garden beyond time, but the moments are short
when it seems to me that, at odds with time, we hold each other's hands.
And I drink wine and I shake my head and say: "What man feels and thinks will never be expressed."

Life is going pretty well. Norma and I have moved into a new apartment. I'm figuring out how to balance work and my other goals. My student loans will be paid off by my 28th birthday in August.

I decided to work from home today. I slept poorly, I think it's the pollen. I've been thinking a lot about what I want lately. Neither Academia nor Industry quite seem to fit. Academia only cares about work that advances the state of the art in specific subfields, Industry only cares about work that advances the bottom line.

My goals don't quite fit in with either of those things. I want to write software to help people understand how other software works. Specifically, a Nintendo Emulator and set of tools for observing and modifying old games on the fly. And so I find myself thinking about how to work fewer hours so I can find more time for my 'art projects' without sacrificing hobbies, relationships, and a social life.

I've been too drowsy today to get meaningful work done on work or hobby projects, but here's what I thought about in the shower:

• I should add a proper JIT compiler to cl-6502 that uses the "compile-to-closures" technique described by xach.
• I should fix trowel so that it can correctly compute the control flow graph of simple (NROM) NES games that aren't self-modifying. Like I meant to do last summer.
• I should implement the UNROM mapper for famiclom using neth, sprocketnes, or tenes for reference if needed. That way, I could play with Mega Man 1 and its annotated code in addition to Super Mario Bros.
• I should start on a lispy macroassembler/compiler to 6502 because there are idioms to capture in these games and neslisp isn't gonna cut it.
• Also, I thought about adding crossposting support and 'embeddables' to coleslaw briefly but that doesn't count. That's my one halfway 'practical' piece of software. People do like to blog.

Seriously, is there somewhere I can do an MFA but really just write weird artsy software for 2 years?

Oh, well. Time to take a nap and then try to write some code to find Biconnected Components in C again.

Long time, no blog.

I've been offline for a while. I burned out last July and only really started hacking on my lisp projects again in March. So what's changed in the last two months? Actually, kind of a lot.

Coleslaw 0.9.4

Coleslaw 0.9.4 is hereby released. I apologize that 0.9.3 which went out in the last quicklisp release had an embarrassing escaping bug.

The most fun part of Coleslaw is trying my hand at API design. Lisp is a great tool for writing extensible software and Coleslaw has been a good proving ground for that since everyone has a slightly different set of requirements for their blogware.

I've been reading Sonya Keene's Object Oriented Programming in CL lately which led to a large refactoring around the new Document Protocol. I'm not prepared to say anything intelligent about protocols yet, but thankfully plenty of people have done so elsewhere. This blog post by sykopomp isn't a bad place to start.

In addition to the document protocol and the usual litany of bugfixes, Coleslaw now has a new theme based on bootswatch readable, user-defined routing, support for static pages, and greatly expanded docs.

The main things to tackle before 1.0 are a plugin to support incremental compilation for very large sites and a twitter/tumblr cross-posting plugin.

cl-6502 0.9.7

Additionally, someone actually found a use for my Readable CPU emulator! Dustin Long was working on a homebrew Nintendo game and wanted a way to unit test his code, so he's been using cl-6502 to get cycle counts and otherwise check behavior. Naturally, the very basic assembler got on his nerves so he sent me a nice pull request adding support for labels, compile-time expressions, and decimal, hex, and binary literals. Thanks, Dustin!

I also rewrote the addressing modes again, reduced consing, and made debugging easier by using Alexandria's named-lambda for all the opcodes. The cl-6502 book has been updated, of course.

Upcoming

With any luck, I'll get back to work on famiclom or tools for analyzing old NES games like Super Mario Bros and Mega Man 2. It's good to be back.

What's new?

I've been away for a while and I needed it. My priorities in the past 6 months have shifted pretty drastically from the last few years "hacking, blogging, hacking, blogging". It was a long overdue shift to grow in new ways, form new relationships, and rediscover old hobbies. So, here's the latest:

I Love Smash Brothers

For years, traditional competitive sports haven't clicked for me. I compare myself to others reflexively but avoid active competition. I'm trying to compare myself to others less, bad habits die hard. But I encountered a documentary series about Smash Brothers back in October and was reminded that a video game is the one place I've found competition fun, win or lose.

It's crazy how much free time I've spent since then learning about a game I'd already put a few thousand hours into in college. There is incredible depth to the game and while I grant that calling a video gamer an "athlete" sounds ridiculous on its face, I now believe eSports are deserving of a mainstream audience even if they never find it.

Personally, I'm enjoying getting better at the game and learning to be patient with my own progress. I've gained some appreciation for how people get so excited about traditional sports. I'd strongly encourage you to watch the first episode of the documentary if you have any interest in competitive gaming whatsoever, even if you think the very notion silly.

I Love Electronic Music

I've told myself for a long time that I would try to make music one day. I've played the guitar and the drums though am self-taught at both and never got serious enough to develop a real aptitude. I also have a long held love of electronic music, particularly sample-based wizardry such as Amon Tobin's Supermodified.

I'm finally pursuing this passion. I've purchased a copy of an old-school "tracker-style" software called Renoise. While I'm not composing actual songs yet, I've been greatly enjoying sampling music and video games from my youth and constructing odd melodies and instruments. I've also been learning the basics of sound synthesis from my friend, Matt Simpson. Sound design is a crazy, crazy thing.

I Love My Job

I've been working for Emcien since May and it's been a great environment to grow as a software engineer. Aside from me, there are 5 engineers and I've been able to pair with people to quickly get up to speed on the products and learn new tools and techniques. In particular, I've enjoyed doing my first serious C hacking ever on the engine that powers Emcien's data analytics products.

Epilogue

I've also spent a huge amount of time this year with my beautiful girlfriend, Norma, and her two dogs. I've tried to see friends in town a bit more, I've played video games and read sci-fi novels a bit more. I'm remembering what leisure feels like and I have no regrets. I still want to finish the Lisp NES emulator and other projects but I'm branching out for a little while ... and my timeframe is flexible. Good luck with your 2014.