I'm a Washington, DC-based full-stack developer and designer. After working independently for a while, I'm looking to become part of a product-focused team again. I'm open to relocation for the right opportunity.
As a developer, I value good code design, well-architected systems, and nice APIs. I frown upon cargo cult dev practices, "religious" debates, and over-specialization.
In general, my focus over the past few years has gradually shifted from the web to native (iOS and Mac) development. I enjoy native dev but am not committed one way or another.
I've used a lot of languages and technologies over the years. As a programmer, I feel that the ability to adapt to new tools and technologies as required is of much greater importance than claiming n years of experience with any given specific product.
Up until a couple of years ago I was very active in the SproutCore and Ember.js communities. More recently, I've used other frameworks, including React and Angular 2. Each ecosystem has its advantages and in general I'm comfortable working with any modern approach to JS. HTML5 and CSS3 are great, but I feel it's important to recognize their limitations, and not to lionize them as the equal of native apps.
I really enjoy working in Swift. It's not perfect, in particular the inability of bridged Cocoa protocols to deal with some native Swift types is a major pain point. Swift isn't a functional language, but its value types, generics, and support for immutability are very welcome FP-like additions to native iOS and Mac development.
Despite its relentless object-orientation, hostility toward immutability, and dependency hell, Ruby is still bar-none my preferred server-side language. I believe Ruby applications can still be well architected, and written with good coding practices, and as such I favor keeping the focus on business code rather than the framework.
I'm happy to work with Rails as part of an application, but do not consider "the Rails way"—or other received wisdom—to outweigh solid and time-tested principles of good code design.
I like structured data. I feel that well-normalized relational databases are still appropriate for most applications. Proper database design has to be approached separate from the immediate concerns of programmers, and as such I avoid dev practices that focus on "just dumping JSON" or that allow the web-based API to dictate the structure of the underlying database.
That said, I'm not a DB admin, so don't bother quizzing me on replication strategies or arcane SQL syntax.
I spent a year working on an Objective-C app as part of a team (not reflected in the chart above,) and am perfectly comfortable navigating legacy code as necessary.
I've recently begun programming Haskell only over the past year or so. Haskell code makes up a very significant fraction of my under-development graphics application, Penumbra.
I did my time in the PHP mines, and haven't looked back. If there's a legacy system floating around in the dark recesses of a server somewhere I could wrangle it easily enough.
I graduated from high school. Not much to say about that.
I did not graduate from university. Things happen, y'know? For what it's worth, though, I was a Political Science major... so, it really wouldn't be relevant either way.
Various short-term programming and other technical jobs. PHP
Primary dev responsible for a legacy PHP-based web survey research platform. Rewrote it in Ruby 2007–2008.
AirPair (no relation to the current company) was a short-lived startup in Los Angeles focused on technology to make air travel more social. SproutCore (JS)
I was the primary UX designer and a supporting engineer (iOS, Ruby) for a rewrite of a successful iPhone application targeted at air travelers.
I was the sole developer, on a contract basis, for this DC-based marketplace for live entertainment and events professionals. I was responsible for the Ruby server-side app, the Ember.js dashboard app, and the UX design for both.
I was tasked with creating an Ember.js app to integrate with a SharePoint backend. The product was a visual forms builder, and the JS app enabled WYSIWYG drag-and-drop specification of data forms. The actual forms themselves were implemented in .NET.