“I make stuff move with code.”

When people ask me what I do, that’s what I say. I don’t say I’m a framework author. I don’t say I’m a systems administrator or database administrator. I don’t say devops or infrastructure. I don’t say development tooling. I don’t say optimization.

I say eye candy. Pretty pictures. Interactivity. Programmatic animation. Data visualization.

Ten years ago, in the early days of what we were beginning to call “social media” (back when media in social media meant news), discovered I could use public APIs to build front-end only projects that consumed data from web services and did fun things with them. Sometimes, I needed to run a query that was not the result of a simple API call, so I needed to fetch data, store it somewhere, and then query against my copy of the data. Then, these APIs started introducing restrictions like rate limiting and cumbersome authentication schemes.

As time went on, it became more and more difficult to build 3rd party mashups of data from social networks and other web services. By 2010, after acquiring client apps for most major platforms, Twitter took its 3rd party developer hostility to the next level by placing harsh limits on whether and how 3rd party applications could store or display content. Build something for Twitter and you could easily find yourself locked out, all that work for nothing.

What does this new landscape mean for someone like me? It means I need to put additional work into authorization; manage ever changing API documentation for authentication, parameters, and result schemas; do the part I’m actually good at, the front-end; and then hope after all that my access does not get suddenly get revoked due to an unseen hurdle in the complex and restrictive API Terms of Service. And what if you want to make a mashup of multiple web services? Rinse and repeat that process a few times.

“Build the framework you want to see in the world.”

— Mahatma Gandhi’s nephew who’s really good at computers

What I wanted was a way to make mashups, animations, tools, and visualizations without needing to worry about web service authorization or data acquisition. Let one person (me, at first) solve the problem of connecting to a web service and normalizing its data and then forget about it. After an API has been added, I should only have to worry about how to query the local cache and present it.

With a extensible foundation, I could take it a step further. Plugins could register hooks to further transform data before it gets saved (such as analyzing text content for topics or entities). They could also provide local API endpoints that multiple front-end views could share. The front-end view could be the result of the composition of a series of complementary plugins.

For example, if I wanted to make a calendar travel report (left) or a travel map (right), I would first need to know where I was throughout the year(s). Assuming I have one or more social network API plugin, I could query my local cache for geotagged posts, no matter where they were originally posted, using a plugin that analyzes every calendar date and guesses which metropolitan area I was in that day (aside: time zones suck). Because the data imported from social media might not be 100% accurate, it would also need to provide a way for me to make a few corrections. Then, with the geotagged posts normalized and, if necessary, manually corrected, an API endpoint could expose the daily travel history for any number of derivative plugins to use.

It’s often not worth the trouble for a 3rd party developer to build the entire stack just to build one front-end view. It’s also not very likely for people to sign up to some 3rd party’s web service, grant the developer access to personal data, and then remember it exists days after the first use. As a stand-alone service, it’s not very viable.

If these were features you could simply add to an existing system, it would be an entirely different equation.

The popular term Big Data represents the collection, storage, processing, and analysis of vast quantities of data. At its simplest, it represents a shift in perspective to the belief that just about any piece of data can provide value. More data is better than less data. The trend is mainly apparent in areas like business intelligence and government surveillance, but if you look closely, you can see signs of big data on a personal level.

Fitness trackers log every step of every day (okay, often rolled up into 15+ minute intervals) to provide intelligence on your health, progress, and individual workouts. Using a location based social network to “check in” or rate places yields personalized recommendations. By scanning every email in a GMail account, Google Now can provide automatic reminders for appointments, travel, bills, and more. On many social networks, creating a social graph (connections to friends) results in all data from each connection being combined to surface relevant trends and recommendations.

By providing our data, whether a sensor, access to an account, or information about who we know, people get to easily—and often automatically—reap the benefits of certain types of data analysis.

The problem is too much data is being ignored and we don’t have any ways to prevent meaningful, relevant data from falling through the cracks.

The most obvious area of improvement is location. Location based social networks showed how valuable it can be to know where your friends are. The problem is they only help if everyone actively “checks in” on the same social network. You can see if your friends have checked in nearby, but not if they’ve posted a geotagged post nearby via Twitter or Instagram. Instead, that metadata is lost, missed, forgotten.

Generally, I care more about the words my friends are tweeting and the photos they are sharing than the metadata on those posts, but more data is better than less data.

The root of the problem is silos. Twitter could add location tools to the Twitter app, but it would only work for the subset of my friends that are tweeting. And why would they add that extra functionality to Twitter in the first place? Twitter is not a location based social network.

In order to get value from this content and metadata people are sharing online in one place or another, one must first exfiltrate the data from each silo. Then, geographic data can be analyzed for trends or anomalies based on your current location, text content can be grouped, filtered, or emphasized based on your interests, photos can be browsed in a photostream or gallery, and any type of data could be searched, queried, summarized, grouped, filtered, or highlighted.

We have quite a few useful and magical big data tools operating invisibly on our (and our friends’) data, giving us amazing new insights, alerts, and suggestions. But what they provide is dwarfed by what is possible, at our fingertips, and only just barely out of reach.

When I first got into CoffeeScript, one of the main factors that got me over my resistance to learn a foreign (Ruby-inspired) syntax was that it provided a way to use prototypal inheritance without manually typing `MyObject.prototype.method` or endlessly worrying about what `this` currently means. In a surprising twist, the feature that got me into CoffeeScript is one I no longer use. Instead of writing OOP I have started writing in a more functional style, and have found CoffeeScript to be equally powerful (fat and skinny arrow function shorthand, implicit returns, fewer curly braces and parentheses to close, etc). ES6 has added `class` syntax sugar, but for me, it is a feature I will generally avoid in either language.

Imperative Extensibility

In developing a foundation for an extensible application, I started with a base plugin with helper functions. Plugins would import the base plugin class and call those helper functions to change configuration. From a framework perspective, the goal should be to minimize boilerplate—code that is identical in every place a feature is used. Boilerplate wastes the time of plugin authors, and increases the complexity of plugins with code that is not unique to the problem being solved by the plugin. Helper functions are a great way to reduce boilerplate in an imperative system.

Boilerplate and Housekeeping

Boilerplate is not the only concern. Plugin authors should also be spared of as much housekeeping as possible. Housekeeping is the management of state, through operations to add, update, or remove objects (configuration, functions, etc). In an imperative system, a plugin author is responsible for performing the operations required to add functionality to the system, but must also be concerned with updating or removing functionality. These operations are made even more complex with dependencies, as the order of the operations matters. Suddenly, leaving housekeeping up to the plugin author can turn into a massively complex and error-prone system.

Functional Design in an Imperative World

After studying functional programming languages and concepts, it became clear to me that a more graceful way of handling extensibility and mitigating complexity would be to forgo the object prototype-based imperative approach in favor of a declarative approach.

For a plugin author, the result would not be too different, boilerplate-wise. However, housekeeping would be dramatically different. Instead of performing operations to add or configure functionality, plugins would declare functionality and the framework would be responsible the housekeeping.

The filesystem can be used as boilerplate in a declarative system. That is, by simply being in a specific directory, a file may be defining what it is for or how it should be utilized. This is common with MVC frameworks, where files within a `controllers` directory imply `filename.ext` should handle a request to `/filename` or files within a `models` directory inform the framework to create tables or collections in a database where the table or collection name is the same as the file name.

By composing an object or positioning files in a hierarchy, a plugin simply describes how something is supposed to be. The housekeeping—how to add, update, or remove functionality, and in what order—is left up to the framework.

In my primitive proof-of-concept, I took very naive approaches for each part of the system?—?configuration, event handling, web service route definitions. I also made decisions based on language features in Javascript, like the deep merging of nested objects.

For configuration, a plugin may be designed to have an extensible list by storing a default value in an object `{stuff: {default: ’Default’}}` such that a separate, independent plugin could add an item to that list by specifying `{stuff: {newItem: ’New Item’}}` and allowing the framework to construct the final list by merging the declarations into `{stuff: {default: ’Default’, newItem: ’New Item’}}`. If sort order is important, they could be defined as a more robust object, like `{stuff: {default: {value: ‘default’, display: ‘Default’, sort: 1}}}`.

Drawbacks

The way I designed my architecture, a plugin would synchronously return an object with its configuration. For flexibility, I added an asynchronous initialization function that, if provided, would be called after all configurations had been loaded. The most obvious need for something like this was for configuration that was dependent on an asynchronous resource, such as a database call. A different way to address that problem would be to provide a way for a database query to be expressed in the synchronous result and rely on the framework to trigger the database query and embed the results. Ultimately, I wanted to support other types of asynchronous configuration, and wanted the framework to be decoupled from knowledge of a database (which is itself provided by a plugin).

With a blog, you may have multiple themes installed, and thus selectable in a list, but you will want to store the currently selected theme in a persistent data store. This means a plugin cannot declare “the current blog theme is ME.” This is not necessarily a problem with a declarative design, so much as it’s an age-old challenge with the combination of synchronous and asynchronous systems. Static declaration can only get you so far before you find yourself needing dynamic configuration.

I also worry that by doing things in a different way may alienate plugin authors who are more accustomed to imperative systems, even if they necessitate more complex housekeeping.

Ultimately, I’m very happy with the reduction of complexity I have been able to achieve through this shift in thinking from imperative to declarative designs.

I am curious if there is any literature on the design of extensible systems. There are pros and cons to each method, but perhaps people have discovered clever ways of getting around drawbacks in the declarative approach.

There are two ways of looking at this milestone, which we may or may not be able to call a singularity. Hardware and software.

Hardware

At what point will we be able to construct a single system that matches the processing potential of all the neurons in the brain. Given some derivative of Moore’s Law or perhaps even a conservative estimate of how many transistors we’ll be able to cram into a single system, with or without advancements in materials or architecture, we can come up with a practical estimate of when it will be possible to build a computer with the physical computing power of the human brain.

As digital transistors and analog neurons are not directly comparable, I don’t think we can put a specific number of operations per second as a target. The fastest networked clusters of computers we have today, collectively referred to as supercomputers, may already exceed the raw processing power of a single human mind. It may be 5–20 years before the same capacity is available in an individual system, and only if major breakthroughs are made in construction, design, and energy consumption. We are already seeing that the future gains will likely be in concurrency rather than faster serial operations, which means programs that can be broken down into simpler tasks and distributed simultaneously to many cores will benefit more.

Ultimately, with hardware, progress will continue to march forward.

Software

With software, things are not so straightforward. While improvements and optimizations are made, progress is not so steady. Even if we have the physical infrastructure to mimic a human brain, what software would we run on it? Managing complexity, detecting patterns, efficiently storing and recalling memories, and making decisions are very difficult challenges.

State-of-the-art software can use substantial computing power, and yet still struggle with basic challenges despite being specifically designed for that one task.

Some software improves steadily and incrementally. Far too many others don’t. For every long-running project that steadily improves against benchmarks (such as operating systems, video game engines, Javascript engines in web browsers, etc.), many more are simply shuttered, re-written in new languages or for new frameworks with marginal improvements, or not ported to new architectures or platforms.

There is a thriving open source community, contributing to software at every level of the stack, but more development time is spent on closed source, proprietary software that will no longer benefit society after the organization decides to shut it down or replace it. And, by nature of being proprietary, if another organization seeks to provide functionality similar to another organization—competitor or not—it must spend resources on recreating the same functionality.

Programming language specific package managers are perhaps the best way we have to isolate functionality and make it available for use in any other projects, or even compose multiple other packages to create higher-level functionality. Another great option is containerizing standalone services, which can transcend programming language. A Ruby Gem is nearly useless for a Node.js project, but a containerized service can be utilized just as easily by a Python project just as easily as a Go project. That is, until you upgrade your kernel or lxc container software…

We are making progress, but far too often, our progress feels like two steps forward and one step back. If anything, what we need most is to make progress on improving how we make progress in software.

Choosing a data storage layer is a particularly tricky problem. There are many RDMS and NoSQL options to chose from, and each has its own unique set of strengths and weaknesses. Is the data write or read heavy, mutable or immutable, tabular or schemaless, relational, geospatial, searchable, or streamable? Can you choose one database technology that is ideal for all possible use cases?

Beyond data stores, I wanted a system where any existing standalone software could be packaged, distributed, and reused. What if, for example, Stanford researchers released an open source Named Entity Recognition algorithm and classification data set, packaged in one replicable… Java app?

Enter Containers

Docker, the popular Linux LXC container solution, provides a rich ecosystem and toolchain for building, running, and distributing containers. No more installing or building from source endless dependencies to get a piece of software to work. Inside a container lives a known-good configuration and environment for any process that you can interact with over a network interface. If someone solves that once, using that resource is as trivial as downloading the image, running the container, and connecting via a local IP address and port.

Package Management

While no package manager is without its shortcomings, I’m rather fond of the many things npm does right (and can live with the many other things it does poorly) and how well it works with nodejs.

However, while you can npm-install a node module that makes it trivial to connect to a database, you cannot use npm to download, configure, and run the database service itself. To its credit, docker provides a cli that makes this process as easy as a software package manager.

What neither address is a problem very specific to my use-case. When developing an application, it makes perfect sense to install any services your application will need and then install any packages your application code will require to connect to those services. What if you want to run an application without any services and be able to add new services on-demand at runtime?

Managing Dependencies

By using npm as a distribution mechanism for plugins, the software package problem is handled trivially. All that’s left service dependencies. The solution I devised involved inspecting a plugins declared service dependencies prior to running the plugin’s code, and once the requested containers are available, starting the plugin and providing it with the container’s IP address and exposed port(s).

While this is not an approach I would advocate for common cases, where all services and functionality are baked-in at build time, it works remarkably well for a long-running application that can be extended at runtime.

During the 1980s and 1990s, a powerful revolution took place in computing hardware. Programs had historically been executed on mainframe computers, fed commands manually at first and then from terminals. As computing power increased and chip prices fell, terminals went from thin clients that logged in and executed programs remotely to full-fledged computing devices. Apple and Microsoft notably capitalized on this revolution. Bill Gates’ dream was to put “a computer on every desk and in every home.”

By moving computation on-site, users were given unprecedented power. Even if Internet connectivity was not prohibitively slow, it would be difficult for mainframes to compete against the responsiveness and personalization of an on-site computer.

This selective retelling and framing of history is intended to form the foundation of a present-day analogy. The personal computer revolution of the 20th century is similar to a revolution I would like to see take place in personal computation.
Personal Computation

We can define personal computation as a system that uses data and algorithms to provide a highly personalized experience to a single user. Compared to a massive, centralized, mainframe-like system, a personal computation system would take different approaches on hardware, software, and data.

Hardware

Through virtualization and containerization, hardware is becoming less directly tied to computation. While there are other configurations, let’s compare two: infrastructure you don’t own or have access to (e.g. SaaS/cloud services); and infrastructure where nobody has more control or access than you (e.g. a web host or IaaS).

“There is no cloud. It’s just someone else’s computer.”

Running a “personal cloud” on a web host (or Infrastructure as a Service provider) is still technically using someone else’s computer, but gives you different levels of control, access, privacy, and security. Notably, if you rent a computing resource from a utility, they should not have access to your data and should not be able to dictate what software you can or cannot run on that resource.

This is a comparison between two cloud-based infrastructures. In order to optimize battery life on our mobile devices, we will ultimately need to perform many types of computation on a remote service.

Software

Cloud providers perform personalized computation by developing complex algorithms and running them against the vast amounts of data they collect on you, your friends, and people who resemble you.

Algorithm: a set of rules for calculating some sort of output based on input data.

Facebook’s News Feed, Google Now, and Apple’s Siri give users a lot of functionality, but the algorithms only work within each service provider’s walled garden. You can’t use Facebook’s News Feed to surface important content your friends posted outside of Facebook (if they didn’t also post it to Facebook). You can’t use Google Now to automatically remind you of upcoming travel, appointments, and bills if you don’t use GMail. You can’t use Siri’s speech recognition outside of iOS or OS X. You also can’t get new functionality or features to any of those services unless their engineers add it or if they provide a specific mechanism for 3rd party extensions or apps.

Currently, these service providers’ state-of-the-art algorithms are far more advanced and better integrated than anything you can install and run on your own. However, there is no technical reason you can’t get most of what they provide without connecting to a company’s centralized service. In fact, if you had access to and control of these algorithms, you could apply them to data that exists outside of a walled garden or to personal data you don’t want to share with a 3rd party.

That is to say, despite all the amazing machine learning algorithms deployed by centralized service providers, they’re only able to scratch the surface of what would be possible with software outside of a walled garden.

Data

Today, in order to get highly personalized computation, people give up access to a vast array of highly personal information—where you are at all times, who you talk to and when, what you say to your friends and family, and what you like to eat, wear, watch, listen to, and do. This information is valuable enough to advertisers that ad publishers can profitably invest tons of money into servers and software development and giving the computation away for free.

As we’ve discovered during the last decade, people in general are not at all reticent about giving up privacy in return for being able to be able to basic things like talk to friends online or get driving directions.

If you told everyone it’s not necessary to completely surrender their privacy to many 3rd party companies, would they care? It seems like only a minuscule fraction of people would. Ultimately, if there is a limit to how much privacy people are willing to give up, it would probably (hopefully) be different for a 3rd party company than for a system only the user has access to. Given more comprehensive data about the user, a personal cloud type of system has potential to deliver higher personalization.

The Alternative to the Mainframe

Given the striking resemblance of today’s web services to mainframes, could there be a revolution on the horizon similar to that of the personal computer? There is no shortage of personal cloud projects or decentralized services. Sadly, many of them attempt to be open source clones of existing centralized services, which is akin to installing a mainframe in your living room and calling it a PC.

What would the software equivalent of the personal computer look like? What if we could run whatever algorithm we want on whatever data we want? What if we owned and controlled a system that did not have ulterior motives, or get acqui-hired, or prevent us from escaping a walled garden?

Existing services, like those provided by Google, Apple, Facebook, and so on, set a high bar for ease of use, user experience, seamless integration, and powerful yet simple-looking (“magic”) functionality. But at the end of the day, it is just software, and there is no technical reason why it needs to run in a 3rd party’s data center.

Servers and storage are getting cheaper, software is easier than ever to distribute, programming languages and frameworks are enabling ever more complex and extensible applications, and complex systems are becoming more easily reproducible with containerization.

I’ve been thinking about and working on a rough proof-of-concept of this for a few years, and quit my job a couple months ago to work on it full-time. It’s certainly not as easy or simple as it sounds, but I’ve come up with some interesting strategies and solutions. During the next few weeks, I’m planning on writing about some of these concepts, as I’m stretching the limits of what I can accomplish while working in a vacuum.

January: I booked a flight to Amsterdam for a couple weeks to couch surf with a friend I met at SXSW years prior. While there, I noticed 3 of the most intelligent and interesting people I know from around the world were converging in Switzerland to attend the World Economic Forum and figured, what the heck, why not swing by and try to crash some parties? I found a cheap flight from Rotterdam (less than an hour from Amsterdam by train) to Geneva, where I rented a car and drove across the country to Davos. Turns out you can’t really crash parties at the World Economic Forum; there are too many fully-automatic assault rifles. Driving through the Swiss Alps made the entire trip worth it. Incredible.

February: I attended a small tech conference on a boat in the British Virgin Islands. I figured if I was going to spend all kinds of money to be on the boat for a week, I might as well make a trip of it and spent a week with a friend who coincidentally lives a stone’s throw from where the conference’s boat was docked. There’s not much to do on Caribbean islands when you’re not on vacation or spending money, so I tend to be very, very productive. I remember making excellent progress on a Node.js CLI app to render videos of cars spinning around for my client.

March: I didn’t leave the country, but I went to Texas for SXSW, and that’s pretty close. I stayed with an old friend (since 5th grade!), who recently had a kid. Oh, how fast life whizzes by when you spend your life on the go and only check in with someone every year or two.

April: I went back to New Zealand, and this time I reserved a campervan in advance and spent most of my 3 week stay gallivanting around the kiwi country side while working from wifi-enabled commercial camp sites (“holiday parks”) from Auckland to Queenstown. Two weeks in 2012 wasn’t enough. Three weeks in 2013 wasn’t enough. I desperately want to go back as soon as possible for a greater number of weeks, which I’m sure will also not be enough.

May: I attended another tech conference, this time in Belize with 27 CTOs, investors, and startup founders. It was only a few days long, so I hopped over to Ambergris Caye, which was recently in the news as part of John McAfee’s saga.

June: I spent a week in Germany tending to a 2 year old physical installation I worked on at Volkswagen’s Autostadt.

July: Upon getting my passport back from the Chinese consulate faster than expected, I was free to leave the country during July. I wanted to keep my streak of leaving the country every month (except for March) going, so I hopped up to Vancouver for a week. First time to Canada! I napped in my third hammock of the year, which made me realize I had napped in hammocks in three different countries in 2013, none of which were in the USA.

August: I slowly made my way to Beijing, with a multi-day layover in Hawaii to visit friends. After a couple days in Beijing, I met up with a couple friends from NYC in front of a coffee shop, where we were swooped up and taken to the DPRK.

September: After a week in the DPRK, we returned to Beijing, where I stayed an additional 10 days before slowly making my way back to the Arizona with a 10-day stopover in Hawaii. I didn’t know where I should stay in Beijing, but after reading a summary of some of the districts, I booked a hotel in “the Silicon Valley of China,” Zhongguancun.

October: I wanted to visit a friend of mine in London, but he had to go to Dublin to speak at Web Summit. He was able to secure a spare ticket, so I darted off to Ireland and then England—first time anywhere in the British Isles!

November & December: I ended up just shuttling back and forth between NYC and PHX for Thanksgiving (PHX) and Christmas (NYC).

What an exhausting year! The only downside of my travel in 2013 was that almost every trip was about 2 weeks long, which is not very practical or economical when leaving the country or crossing an ocean. Instead of boomeranging out of the country and back many times, I would prefer to wander more slowly and go to more places when visiting a region. Hopefully I can make that happen in 2014.

2013 was a pretty intense year. Not too intense to write blog posts—I shared updates, photos, and check-ins throughout the year using various social networks.

Lately, I have been getting frustrated with those platforms.

The motivations of the social networking companies (ad publishing businesses) don’t always align with the goals of the users. Are they helping connect people with their friends? Or with brands?

As tools, they tend to break down as people use them differently. What if one friend posts every thought he or she has in a day while another thoughtfully posts one thing per day or week? Facebook, with their Top News feed, seems to do a pretty good job of bubbling up the most interesting or relevant posts and filtering out most of the noise. But the Top News algorithm applies only to what your Facebook friends share on Facebook, not what your friends share online.

Twitter did a much better job of connecting people in 2006-2008, when people posted less frequently (used the service more similarly), followed fewer people on average, and were more likely to read everything. As it turned out, requiring every user to self-moderate prior to posting would not work out in the long run. The closeness Twitter fostered was eroded as it transformed into a chat room and link sharing/promoting service.

Features come and go—or in Google’s case, entire services—based on whether or not the sponsoring ad publisher (Google, Twitter, Facebook, et al) deems it a benefit to their bottom line. Foursquare cares more about fleeting digital rewards (mayorships and badges) and selling deals/sponsorships to brands or venues than it does about doing meaningful things (to users) with our data. In many cases, ad publishers’ agendas align with the needs of their users. After all, they can’t sell advertisements if the users don’t keep coming back.

WordPress—perhaps a dinosaur in today’s post-RSS, social-network-central world—is one of the few options we have to connect directly with each other. I write a post, and save it to one of my computers (a web server). Then, from anywhere—a browser, web app, RSS feed reader, or perhaps some other mechanism—you connect to my computer and fetch the post.

It is saddening to realize I have all but abandoned WordPress in favor of the social networks, but ultimately, WordPress isn’t an ideal method for connecting with each other. Not everything I want to share is an article, and I don’t necessarily want to blend long form blog posts with microblog one-liners (Twitter) and photoblog posts (Flickr, Instagram). Even if I could share these various facets of my life using one tool, it’s not connecting me with my friends if I’m just posting them to some site somewhere while all my friends are using insular social networks.

I deleted my Facebook account in August (dodging the inevitable flood of banal platitudes from acquaintances you tend to receive on your birthday) and my Twitter account will be going soon, too. Twitter was my favorite place to go when I felt like talking to myself, but I could only stand throwing my thoughts away into the ether for so long. I want my thoughts to live somewhere, and an ad publisher’s web site is ultimately the wrong place for that.

For now, I will be stuck with WordPress. As a developer, I feel the urge to figure this out and come up with a way to share my life online while staying connected with my friends no matter where they’re sharing their lives.

If you think about it, it is obviously not possible to completely and accurately describe a person’s personality in one sentence. Unfortunately, that’s about as much thought as most people will give you. The best way to understand how other people summarize you is to listen to how they introduce you to others, because they have one sentence to convey to the new person everything that is important to know about you.

“He’s the guy that jumps.”

In 2007, I was at the after party for a conference and sat down at a table with a couple of strangers. Before my butt reached the chair, the guy on my right who I had never met before said to the guy on my left who I had never met before, “This is Brian Shaler. He’s the guy that jumps.” I was surprised and amused. I rolled with it. If I took myself more seriously, I would insist that I’m not nearly some guy who jumps, but an astute software developer. It’s a strange feeling to be summarized by something silly you did instead of what you’re most proud of.

I learned a lot by being the guy that jumps. I learned about how people try to put you in a box and how they decide to represent you internally and externally. Not everyone can appreciate my skills. Like my parents, for example, who would probably describe me the same whether I did data visualization or made WordPress themes—”he does stuff with the computer,” or “he makes web sites.” Now, my parents actually care, and they try to understand. So what happens when people don’t care, or don’t try? As it turns out, they’ll try to put you in the easiest box that seems to fit, based on the most vague knowledge about you. It will tend to be the first thing they learned about you, the thing they most understand (often the simplest), or the thing they find the most intriguing or unique.

Boxes are hard to escape.

Once someone puts you in a box, it will be very difficult to get them to change how they summarize you. This is part of the reason first impressions are so critical. If you say something offensive within a few seconds within seconds of meeting someone, they’ll likely see you as a crass person from then on, even if what you said turns out to be uncharacteristic of you. If someone meets you as “the guy that jumps,” chances are they will introduce you to the next person in the same way.

If you don’t fit their understanding, they’ll fit you to their understanding.

If you’re an impressionist artist, someone who doesn’t understand Impressionism will describe you using the things in your art, rather than what is being being conveyed in the art. For me, my skills with programmatic animation, data visualization, and interactive interfaces are often summarized as “making web sites,” because some of it may exist on the web and people are more likely to understand what making web sites means. Ideally, you would be described as what you are, but if the person doing the describing doesn’t share your knowledge on the subject, they will make up something that sounds close enough to them.

If you do something sticky, it’ll stick more than anything else, no matter how relevant it is.

There are pros and cons to being known for something more interesting or intriguing than what actually defines you. On the plus side, people with know, remember, and perhaps even talk about you. Unfortunately, most of those people won’t have any idea who you really are or what you really do. This was the case with the jumping persona. It would be great to have strangers introduce me to strangers as a talented interactive developer, but the people who understand my work deeply enough to appreciate it are few and far between. It also sounds less glamorous and exciting than a zany set of photos.

It was clear jumping was much more memorable and it was certainly a conversation starter. It didn’t convey anything of meaning about me or command any sort of respect, but it opened the door and got people’s attention. It showed me the power of intrigue, which I will ramble about in more detail in another post.

I re-evaluated what I enjoyed about running my business and what I didn’t enjoy. It turns out following that typical path to “success” would involve focusing most of my attention toward the parts I didn’t like. What would my business look like if I instead focused as much as possible on the aspects I enjoyed? I wouldn’t have employees, I wouldn’t work excessive hours, I wouldn’t take on every project that comes my way, and I wouldn’t accept projects on unreasonable timelines.

Sure, I would make more money if money was my top priority. If my top priorities are quality of life, travel, and working on interesting challenges, I have to be selective about which clients and project I take on. Focusing on the fun comes at a cost, but I think it’s worth it.

If you can make a profit doing as much work as you want and enjoy what you do, isn’t that a successful business?