Building Startup Communities in Emerging Markets: Promiscuity, The Hive Mind and Conference Calls in Bathroom Stalls

I’m in London this week as we set out to grow @Apigee in the UK and throughout Europe. With the aid of sleeping pills, alcohol and the in-hotel gym, I’m fighting the good fight against jetlag and managing to stay sober for scrum calls and 2:00 am BST meetings with developers and designers in the US, all while meeting with customers, prospects, users and community people here. This is hard, I want to go shopping.

I won't cheat on you again baby.

Good news though: I’m about to make status on my airline despite now much-regretted trysts with Virgin [because it's sexy] and Alaska [because it's cheap], a good sign I’ve been really busy working with startup and tech communities across the country – New York, Atlanta, Seattle, San Diego, Chicago, D.C., more. Tonight I attended the Hacker News London #hnlondon meetup, and talking to startup people there got me thinking about the “startup scene” across, well, everything. I spend more and more time working with startups, organizers, and aspiring entrepreneurs in emerging tech centers, and they all want to know what strong startup communities have in common, and how they can boot up those same conditions. So this post is about where emerging startup markets can invest to build a better ecosystem.

Create promiscuity*

*which lines the virtuous road to community. 

Startup Scene as Salome

Every healthy tech community is mad promiscuous. Promiscuous in the sense of variate and frequent coupling - of companies, startups, students, technicians, hackers, weavers, schemers, groupies, marketers, spaces, locations. Promiscuity is what underlies our experiences of “richness”, “diversity”, “creativity”, “vibrancy,” “buzz”.

The promiscuity you find in mature startup communities is only possible with:

• Available, highly permissive common spaces
• Adoption of low-barrier online tools that describe communities and their interactions
• Promiscuous, open, accessible, extensible product ecosystems

Emerging startup scenes must invest in the growth of each to succeed. 

Common Space 

Successful startup communities have anywhere from 4-5 to many dozens of spaces or organizations that serve as the physical and social “home” of communities. In San Francisco you’ve got gems like Hacker Dojo, willingly loaned corporate spaces like PayPal and LinkedIn, coworking hubs or the offices of startups who open for tech events, office hours, conferences and hackathons. PROTIP: these places are available free or cheaply, with adequate resourcing for good wifi and comfy seating, and a permissive attitude towards content and hopefully booze. Available space is, at its core, an economic issue.

Successful common spaces are created by one of two models: a.) benefactor [typically a large, profitable company with a benevolent interest in community building and innovation];  b.) estate [space-focused organizations that are financially invested in community building of small businesses/startups, i.e. coworking spaces, coffee shops, etc.].

London has beautiful examples of both. It is palpable how on one side TechHub (a coworking center), and on the other the Guardian (yes, the media company) have fostered community by providing this necessary space. Excitingly, you see the beginning of this community infrastructure in emerging startup hubs like Chicago- Morningstar is one company making powerful gifts to the community in the form of open, accessible space.

In the weakest tech communities, appropriate space for community-building is extremely difficult to find, expensive, or suffering from content control of large corporate sponsors.

Online Community is Predictive of Offline Community. 

Community Tools Reflect the Community Back to Itself

Another common theme in successful startups scenes is the adoption of community tools (Meetup, Eventbrite, Lanyard) that serve as logistical centers as well as social, cultural repositories or breadcrumbs into people, what they are doing and why.

Weaker tech communities have much more fragmentation in tools usage, much higher use of tools that are proprietary or highly segregated from a larger network, and tools that don’t do a good job of showing you the other people in your community and what they are up to.

Tools matter. Online visibility into communities is predictive of the offline community. Use tools that illuminate the community and you will grow it. I encourage community organizers in smaller markets to really think about pushing adoption of a small set of appropriate tools to gain critical mass of adoption on a limited set of distribution engines, weather that be a mailing list, a fancy social network or something you build yourself.. Having 100 or 200 people using a common tool is much more powerful than groups of 30-40 using 3-6 different tools each.

Promiscuous product builds community too. 

Silicon Valley is the shining example of how promiscuous products hinge great communities. Promiscuous product ecosystems inherently encourage community. Promiscuous products are ones with open APIs, with source code, with awesome documentation and GitHub accounts, with extensible hooks, with integrations of data services, with visible opinions but viable options. Promiscuous product ecosystems have a focus on transmitting knowledge, sharing best practices, and enabling other products to benefit from yours. Promiscuous products hook into a vaster technical, social and cultural fabric that inherently predicts community.

Early startup markets tend to have more clustering around proprietary, inaccessible and high-barrier technology and lack promiscuous startups built with promiscuous technology. They have less focus on knowledge sharing, and skew towards experts (the few), not learners (the many).     

Tim Falls of SendGrid predicted in our #twiliocon panel on developer community management that the future would see more cross-pollination of API communities as we tear down technical and adoption barriers to community (better interface design, standardized authentication, adherence to REST) and find synergies and, therefore, more effective ways to work together from a community and marketing perspective. This is a fantastic example of how technical trends are actually key to the cultural development of startup scenes.

There is no questions that light-weight BD, extensibility and permeability offered by open tools and open APIs contributes to healthy startup scenes – for example, one of the startups that presented tonight at #HNlondon was Stickygram, a company built on the Instagram API that lets users easily order fridge magnets of their photos. In doing so, Stickygram tapped into a significant local ecosystem of users as well as an international community of Instagram users. Their success helps build interest, content and activity in APIs and “lean startup” companies in London. ITS LIKE A VIRTUOUS CIRCLE OF PROMISCUOUS BEHAVIOR. I encourage people invested in building a startup community in their city to think about how to leverage product promiscuity and education about promiscuous technology into broader community engagement.

At #HNLondon, Harj Taggar of Hacker News spoke about the need for emerging scenes to support experimentation, “failing fast”, and rapid release. He commended one of the startups that presented as an example of the cultural attitude emerging markets need to cultivate: “It started with someone who had an idea… hack together a very quick prototype, release it, and find out that people are actually interested in it.”

This gets to the heart of the promiscuous product ecosystems that predict amazing startup culture: adoption of technology that supports lean, agile, rapid bootstrapping; and accessibility to the knowledge gained from fucking around with it.

Tap Into The Hive Mind. 

Achievement Unlocked!

Technology is a hive mind. Jack in. Living in Silicon Valley, it’s super easy to forget ALL THE OTHER PLACES IN THE WORLD. But then you go to London, to Atlanta, to Haystacks, Squirrels and Misquitoville Minnesota, and you realize we are all talking about the same things. Lean startup. Launch early. Iterate often. Listen to users. HTML5. Touch. Geolocosocialplatformification. 

Successful startup communities align with global trending. 

We are separated by vast differences in location but we are often united in extremely powerful ways: use of the same mass media and distribution tools (Hacker News, StackOverflow, tech news outlets, Twitter), global dissemination of trends (mobile hardware, cloud computing, open APIs, high-level languages, HTML5). Successful startup scenes have more proportional attention to the trending hive mind. They have more meetups and education on things like open APIs, mobile frameworks, new languages. They are trendy. Trendy works. Invest in fashion. Bring the hive mind home. Successful communities feel engaged in building some kind of future, connected to some kind of global happening. They show up because they are scared if they don’t, they’ll miss out on the next big thing. When they go home and read Hacker News, they now see themselves. They feel aligned. There is a sense of vitality and movement. If you’re trying to build startup community, bootstrap it on the back of global trending.

But Do Reinvent the Wheel

This Should Not Be a Safe Place for Scrum Calls

I haven’t been to a single tech event in a single city where I couldn’t do a conference call in the women’s bathroom. Why? It’s quiet in there.

The underrepresentation of women in the startup community is at a fucking monumental global scale. All tech communities I’ve encountered similarly struggle with issues like outsourcing, lack of racial diversity, lack of accessible education, prevalence of elitism and social media douchebags.

I have a lot of hope that emerging startup scenes will take the opportunity to create a better model that is both more inclusive and diverse. So as much as new scenes should try to emulate the conditions and successes of others, they also shouldn’t forget they have the chance to build the world anew.

Jetsetting: Where I Be At

Fall is bringing tons of travel and events. If you’ll be in SF, New York, London or DC – let’s meet up!  

This Wednesday I’ll be moderating a panel at Twiliocon, Twilio’s first-ever conference. Over the course of the panel we will endeavor to answer the question: Developer community management, how does it work?

I’m really psyched about the speakers: Jason Costa from Twitter, Sara Ford from Black Duck Software and Tim Falls from SendGrid, plus I have it on good authority that Twilio’s Danielle Morrill will have a front-row seat to ask the hard questions. I’m particularly interested in speaking with the panelists about where community management fits into product development. Join us on Wednesday at 1:20 pm and @ sign me if you have questions in advance – but we’ll be taking lots of audience questions too. I’ll try to write up a blog on the panel afterwards so STAY TUNED.

Shanley Goes to London. We are expanding Apigee’s presence in the UK and Europe, which means I’ll be traveling “over the pond” more than I usually have an excuse for. There are a number of fantastic startups with APIs and enterprise platforms both established and emerging that call London home, so I’m excited to get a chance to smooze up the local scene. I hope to get a chance to do more international travel – there are, after all, Apigee users literally all over the globe (really makes you realize the global scale of the so-called “API Economy”.) Anyways, in London you can find me checking out the mobile developer conference Over the Air on September 30 and on Saturday, October 1 we’re hosting API Developer Day, a one-day coding events highlighting presentations from API teams including Twitter and Pusher (which I wrote about in my blog on FdeveloperUE). It’s sponsored by BlueVia, hosted at TechHub and even though we’re ALL FULL already, still looking for a few more APIs to present, so shoot me a note if you want a demo slot – shanley @ apigee.com

I’ll be making a brief stop in New York for one of my favorite conferences – Web 2.0, October 10-13. My colleague Sam Ramji will be giving a talk on successful API strategies and I will be meeting with customers and scouting out the local scene. Alex Donn (my co-organizer at Mobile App Hackathon) are looking to host an event there early next year, so I’m looking for space, local contacts / friends and general API party people.

After New York, I’ve got two weekends in a row with Mobile App Hackathon. Hard to believe that in January Mobile App Hackathon was just an idea, and now we’ve held events in Seattle, Redmond, Chicago, San Diego, Atlanta and Silicon Valley – we’ve seen hundreds of amazing developers, dozens of great apps and business ideas, and mind-blowing support from sponsors. On October 15th we’re coming to Washington, DC; and on October 22nd we’ll be getting back to basics in San Francisco (with a great lineup of super hot Valley startups including Twilio and Heroku).

“Hello World” Candy: 5 FUEs for Developers to Love

TTFHW, via @kellan

 GIVE SOME SATISFACTION! 

“First developer experience.” I’ve been thinking about it lots lately, in my day-and-night-job at Apigee and alter-life as a brownie-eating code princess in a trice-weekly knife-fight with Ruby. This post is about 5 developer frameworks/APIs/tools/platforms that give great FUE, my fav 5 inspirations of the now.

They all do something awesome: They get you to request/response, action/reaction, bell/salivation, to their own personal Hello World as fast as possible. They constrain TTFHW (Time To First Hello World), if only in a test environment, to get you to the I TOLD YOU TO DO SOMETHING AND YOU DID IT moment, that moment of I SEE WHAT YOU DID THERE. If we  subscribe to Matz-ism, “We are the masters. They are the slaves,” then we shall call this “accelerating the master/slave moment.”

These 5 examples recognize the innate pleasure of machine responsiveness to human touch, the weight of speed in net pleasure, and the value of that pleasure as a conversion catalyst. And they are getting biblical delivering some seriously fast Hello World satisfaction.

1. PUSHER API  

The Pusher API. Realtime events for mobile and web apps. Right on the FRONT PAGE of this sucker they have this big beautiful button that says “Test It Out” and when you do, it gives you this code to paste into your terminal, so you do, because you’re a conformist, and you press enter and voila. A notification pops up in the browser. TIME TO SATISFACTION: SECONDS.  (Thanks to hot-shot designer @itchymutt for sending this one my way).

2. SINATRA 

First let me say I’ve had a beautiful experience with Sinatra. Actually it’s the only thing I’ve loved so far about Ruby. Sinatra is to Ruby what skinny boys who play guitar are to high school. Even being super Explain this Clarissa with Ruby frameworks, I was able to Hello World real fast… in part because their ENTIRE FRONT PAGE is about getting you there. TTFHW. Get sum.

3. PAPER.JS 

Just let me say that if you are trying to build a great first developer experience, the first time you check out Paper.js might be emotional for you – it was for me and my team. It’s “an open source vector graphics scripting framework that runs on top of the HTML5 Canvas.” And it is beautiful. When you first load the page, your mouse can manipulate the graphics. And when you click “Source” you can NOT ONLY SEE, BUT ALSO EDIT the code, then run it. And there are tons of fun examples, including ones that involve rainbows. #winning. Paper.js uses CodeMirror to make the magic happen.

4. BASHO 

Riak (open source scalable data store) is a slightly different flavor from the rest, but I picked it as an example of addressing complexity and varying knowledge in FUE , while still getting users to “Hello World”.  The “Riak Fast Track” is a 45-minute course to get started and on step 2 they’ve already got your sweet n00b ass building a cluster. They also have an information scheme for getting around to the parts and complexity levels that are relevant to more knowledgable users. Despite all the Paper.js rainbow-fanciness that is emerging in the world, good solid text/video documentation that focuses on getting to a first moment of triumph is still super important… and sometimes more appropriate.

5.  JS Bin 

It’s a few years old now, but JS Bin is still a shining example of the value and addictive quality of play, touch, responsiveness and rapid prototyping in developer tools. JS Bin is a pastebin with the added sex of YOU CAN RUN THE CODE. A super slick collaborative debugging/sandbox tool that is still much beloved today. I love how when you load the page THERE’S CODE THERE ALREADY BRO, which makes it super easy to figure out what-exactly-is-going-on-here. I think that at some point we’ll see code you run, prototype/preview, and edit in the browser become more and more expected by first users but in the meantime, JS Bin offers a simple, shining view of a better future.

The Only Two Things You Need to Know About People to Do Good Startup Communications, Son

** OK not quite “Good,” but good enough to bat the 90th percentile most of the time, which would technically be “Good by Relationship to Other Startups, Most of Which Totally Suck at Communicating,” but you’ll take it, because you know in your heart that consistent mediocrity is almost like winning. 

Let us begin. One of the first things that they tell you when you learn to write is that you must imagine the reader. Sounds like basically a stroke of genius, predicated on the perfectly sound theory that when you write something, you should do it with an audience in mind that is gonna read your shit. 

This would be totally fine and you would merrily ascend to startup marketing superstardom except for one tiny little logical fallacy, which is that this whole magical parlor trick of “imagining your audience” assumes there is a “reader”, which of course depends on having someone-who-reads, and pretty soon you are running around like an idiot with this mythical archetype in your head of someone-who-reads,  AKA one of the biggest lies in the history of the world since they invented Geocities.

Geocities Doesn't Exist Anymore And Neither Do People Who Read Shit

People Do Not Read 

How do we know this? People who ostensibly DO READ (hint: people who work at universities), study people like you and me (who DO NOT READ) and figure out stuff like this:

52% of all web page visits, including repeat visits, are shorter than 10 seconds. Almost 50% of visits to new pages are less than 12 seconds.  
Not Quite the Average: An Empirical Study of Web Use 

The other 50%? Not a whole lot better, and made up of lots of people leaving their browsers open while they do other things like take showers. So what are people doing if they aren’t reading your shit? Basically here’s what happens when someone loads something that has words on it:

Looks like a toddler went batshit in some spaghetti. But no. It’s a graph of a ton of aggregate data that tracks eye movement on webpages. If this picture had a caption, it would be: People aren’t reading your shit. In fact, they are barely scanning it. They are looking at anything that is either big, colorful or moving and then they are looking for the next place to click. If you study users at all, you will quickly find out something fundamental about people: They hate to read, but boy, do they love to click shit.

Simple lesson: Stop writing things for people who read. Start writing things for people who don’t read.

Now I hope you’re ready for some more knowledge to get dropped on you. Here it is.

People Want to Get Shit Done 

There are only four reasons why people do anything on the internet:

• Fix shit that is broken
• Do shit that already works better   *
• Stalk people
• Acquire sex, music or television **

* “faster” is part of “better”

** “food” is covered under the category “sex”

Good news: these things provide the only incentive there could possibly be for anyone to read your stuff in even the half-assed way that typifies “reading” online. (In language theory, we have a fancy word for half-assed called ‘satisficing’. It’s a combination of ‘satisfy’ and ‘suffice’. Amazing.)

Here’s where it gets rough. The Golden Rule of Users (people want to complete TASKS) is in conflict with the Golden Rule of Reading (people don’t want to read), even though you usually have to Read in order to Complete a Task. We can express the resulting behavior in the following graph, where “Pain of the Status Quo” refers to  a.) how painful the broken shit is b.) how painful the shit that sortof works is c.) how strong the desire to stalk people or d.) how extreme the compulsion to acquire sex, music or television.

As the graph clearly shows, there is a point at which the pain of reading your # Ruby gem documentation  shit grows so unbearably painful that it doesn’t matter how much original pain or desire I’m in, I’m going to stop reading it. Guess what? This threshold is way, way lower than you think.

In summary, your writing only has two possible goals: 1.) Convincing people that your stuff can help them do something they want to do AKA intensifying the pain and desire of the status quo 2.) Give them what they need to finish the job AKA sate the pain and desire of the status quo.

And you must do this WITHOUT making them ragequit (see: Point at Which It Does Not Fucking Matter how Bad the Status Quo Is).

Minor Lesson: Pain and desire. A necessary part of every unhealthy relationship. And you know. reading.

Major Lesson: Your writing must help people get shit done while allowing them to read as little as humanly possible. 

Conclusion

I know by now you’ve reached the only logical conclusion there is to reach, which is.

There is never any reason good enough to merit writing a press release. 

No seriously. STOP THE MADNESS.

*** thanks to @solidsnack for fixing my dyslexia in this post. 

Radical Culture in Ruby: The Gender, Fetish and Race of Programming

This a thought experiment in examining programming communities as cultural, semiotic and socioeconomic artifacts. The main goal is to explore the analysis of emerging languages outside of technical criteria, which while imperative, often fail to explain the complex causes and consequences of trends in our sector. It focuses on Ruby as an example of radical culture functioning as a constructive agent of code. NOTE: This post is both US and Silicon Valley-centric.

 

PREMISE:  The Tangled Web of Code and Culture

1. Programming languages are economic forces.

Code provides the basis for ecosystems that are fed by, and feed on, investment, revenue, careers and education. In many ways, languages are distribution networks for libraries, tools, platforms, packaging and licensing, communities. Thus the viability and spread of programming languages is not at all disinterested in economic factors.

2. Programming languages are political and socioeconomic.

Coding is, at its core, the ability to control machines and ultimately, to control users and shape their lives and behavior. Historically the barrier to power inhered in programming has been extreme. In the United States, programming and its associated culture, power and economic benefits have been restricted to middle America white males. Where programming as craft can be moved further towards the commodity line, it is outsourced as cheap labor in acts that skirt imperialism in their mildest form; in their extreme represent the systematic exploitation of foreign resources and the gutting of domestic ones. All specialized, non-commodity knowledge with economic bearing risks must serve a wealth distribution model, often patriarchy and nationalism.

3. Programming Languages are Cultural Artifacts

As a cultural artifact, race, Manifest Destiny, criminality, education, gender, war and pop culture all affect, intersect, and are projected, fetishized, commoditized and absorbed by coding culture.

4. Programming languages are inherently viral and massively resilient.

A language’s foundational political and socioeconomic contexts and consequences are codified in proportion to its rooting in the technological fabric. Code spreads. Code bases are shared, forked, modified, copied, re-purposed, built on top of. Code is spawned in underlying infrastructure, embedded in stacks, shared inside of and on top of a thousand intersecting stacks and networks. In its most contemporary form, it propagates in a social graph rift with economic, social and sexual consequences. Code is hard to rip out, it is costly to rewrite. It grows webs of dependencies. Code carries its political and socioeconomic consequences into the technical infrastructure, where it can enforce and maintain the power systems that contextualize it.

Radical Constructions of the Actor in Programming

Coding communities both reflect and construct an actor base – or the people who use and implement code. As much as primarily white, male coding communities REFLECT an actor base, they also CREATE and PROJECT an actor base. Most coding communities functionally eliminate the possibility of a female actor except as a sacred and/or sexualized exception.

The fact is:

The vast majority of the technical infrastructure has been created by men.

The technical infrastructure….. as in, all of it.

Against the culture backdrop of a male-made global technical infrastructure, Ruby as a community is unique in constructing the possibility of a female or minority actor, with several emergent institutions specifically addressing adoption in the gender group, and perhaps more importantly, a consistently inclusive rhetoric:

Common Descriptive Words

open source simplicity   general purpose lowering barriers learn fast easy newcomers beginners human

Look at these words as opposed to those that appear most frequently  in Java:

Sun Oracle expert certification JVM Applets Applications Runtime specification Technical

The Big Shift

While very basic, this list of word typifies the ongoing friction between the programming languages of the traditional enterprise and high-level, “humanistic” languages such as Ruby, specifically as they relate to the construction of an actor.  Today, technological ubiquity (the iOS platform, mobile networks, massively scaled social sites, etc) is not only possible but births a volatile and virtuous tension between the caustic, newborn socialist/capitalist hybrid clusterfuck of Free (massively scalable social networks, open source) and the patriarchal elitist vanguard of luxury, capex prohibitive hardware and white male bourgeoisie machine control.

As an economic, viral organism, Ruby lacks the historical legacy, the deep roots in infrastructure, the corporate control, and the barrier to entry that would make it profitable on yesterday’s programming ecosystems and business models-  models which emerged in part as a function of programming as a highly specialized, expensive or outsourced skill functioning as an agent of patriarchy and racial supremacy. (Systems that are reliant on extremely specialized knowledge breed business and economic models that make that specialized knowledge highly profitable. See: Maintenance contracts. Services. Training. Lock-in. Proprietary technology. Computer science degrees). As a result, Ruby focuses on amplifying its inherent virality through the more democratic, social community values that have emerged alongside “Web 2.0” (Systems which are reliant on making knowledge (services, tools, etc) more highly available breed business and economic models which make adoption highly profitable. SEE:  Advertising. Software libre. Social applications. Open source. API platforms. The new large-scale adoption imperative.)

This in part explains why Ruby is unique, even among higher-level languages, for its focus on making coding more accessible and inclusive. Descriptions of the language and its community often focus on learning, speed, and ease of use. Ruby is a front-runner in education of beginners and enabling under-represented or emergent populations, such as women and children, to program. Ruby as a cultural artifact and semiotic object represents the emergence of programming  – and thus machine control and the access to power & wealth it implies – as a viable, available, community-enabled tool for minority populations. It is a step in re-creating how we construct gender as a function of, and actor of, programming and technical ability, and how we conceive programming and machine control in the context of actors.

 

MYTHOLOGY, FETISHISM AND CULTURAL TENSION

The technology industry, especially in most magnified and concentrated form factor (Silicon Valley), is equally if differently subject to the same fetishes, mythologies, sexualization, xenophobia and xeno-fascination as popular culture.

Machine Control Fetish

Mankind has a bizarre, normalized and omnipresent machine fetish that pervades every aspect of culture high and low, technical and consumer. Apple is a classic example of the sexualization and fetishification of machine power; this is also seen in consumer products like Svedka Vodka (ever seen their sexy robot ads?).

Ruby is constructed as a sexual, sensuous, and exotic language as a function of its core rubrics and the semiotic/anthropological contents of the ecosystem built around it. The names used to describe it have a certain luxury and rarity: Ruby, its libraries Gems.  Two of the most popular Ruby PaaS platforms, Engine Yard and Heroku, illustrate the semiotic duality of the language: Engine Yard with its highly industrialized codification and Heroku with its visual sensuality, elegance, and appropriation of Japanese cultural symbols.

 

Race and Code

The Ruby community itself has been significant in the commercialization of the geek pop culture meme of “beautiful, elegant, simple code” and variations. In Ruby, programming is constructed as an aesthetic art, its ecosystem blending the dehumanized austerity of machine control automation with the evocative fetishification of Japanese culture and a new or reborn aesthetic sensibility of programming as art – all semiotic tactics that can flourish in the mass-marketing opportunistic breeding ground of a high-level, accessible programming language.

Whereas many programming languages appear ethnically neutered, Ruby’s heritage as a Japanese-originating language is a pervasive element of how it describes and documents itself. The strong ties between the US coding community and the Japanese Ruby community, as well as the ongoing geo-centricity of Ruby core maintainers, has presented both a unique marketing opportunity and the need to navigate cultural tension through symbolism.

The pervasity of Japanese culture in the symbols and language used by US Ruby coders borders the practices described in Said’s Orientalism - the co-option and re-contextualization of stereotypes, which often serves to ease racial tension by the reduction of complicated racial relationships to simple linguistic and visual signs which can be used as (often sexual) propaganda by the dominant culture. For example, the relationship of popular stereotypical Japanese visual and religious aesthetics to the new maxim of beautiful, elegant code is not coincidence, representing the borrowing and re-contextualizing of sensual/sexual stereotypes as a vessel for mass marketing of coding philosophy.

 

The Collision of Geek with Mainstream

While problematic for a number of reasons, including the reduction of cultures to objects in the service of differentiating machine control systems, Ruby’s Japanese fetish does indicate something about the larger trends and context of programming languages as they spread beyond their roots in search of large-scale adoption as a basis of economic viability.  As higher-level languages and frameworks which increasingly abstract from the binary language of bare metal into something which everyday resembles English and simple games more and more, geek cultures normally defined by technical differentiators will encounter, co-opt and blend with the established propaganda of pop and consumer culture.

 

The Role of Founding Mythology

The centricity of Japanese culture in the Ruby community seems deeply related to the technical community’s fixation on founding mythology. Successful companies will build or discover the cult of personality – I was only in Silicon Valley for a few months and I had already heard more than I ever wanted to know about how Twitter and Apple were founded, about the cultures and philosophies of their founders, etc. Blown to new proportions by the availability of founder personality in the form of media, social networks, and events, the “founding myth” of a company, whether true or not, can play a large role in how we view a technology either favorably or disfavorably, and how we determine a technology’s relationships to our own lives and its future path.

In this climate of technical community obsession with founder’s stories and mythologies, it is no surprise that Ruby’s founder “Matz” has become something of a cult object, and his origination (Japan), a central part of the “Ruby story” that is told and marketed in the community.

 

Conclusion

• As programming languages and machine control become increasingly accessible to minority populations, the impact they have on constructing actors, power and community is a critical area of inquiry.
• With the increasing ubiquity and availability of machine control made possible through innovations in high-level languages, coding communities will increasingly be associated with, both opportunitistically and by force, a larger propaganda machine.
• Programming is about sex, gender, money and race. Evaluating programming languages and their communities as merely technical artifacts obscures and silences a massive range of context and implication.

Dirty User Feedback, Done Dirt Cheap

A Graphical Representation of How Patriarchal Marxism Affects Perspective. Or, A Waste of A Good User's Time.

There is a whole science behind user feedback. If you’ve ever gone to grad school to learn about product design, you understand how Maoism, Feminism, Neo-Radical-Feminism, Objectivism, Bertolt Brecht and gamification impact user feedback.

But shit is about to get real. We’re out of grad school. Or we never went to grad school. Hell, we barely finished high school. Either way, its time to ship some software now and we just don’t have the time or the resources to conduct exhaustive user interviews. And while it would be nice to “provide our users with a safe, comfortable location and plenty of water,” we only have enough funding to “make sure our users survive the session without dying of starvation or a bladder infection.”

This is a post about quick, dirty, cheap ways to get user feedback. Because we don’t have the money. And our users don’t have the time, either. We’re all busy here!

1. First User Experience: The Street Team Strategy

Remember the early 90s? Remember those seriously committed punk kids working the corner outside the concert with a cardboard box of mixtapes and a cassette player? “Hey man, hey. I got this really great new band, man. I got a mix tape man. You can have one. Take two. Hey brother, take a listen, borrow my headphones.”

Yeah. That punk kid could be you. And that concert could be a hackathon, Google I/O, the time you crash that VC party, whatever. Walk up to someone. Start talking. In the real world, aka “The Internets,” that’s how it’s gonna be. Your user is going to be on Twitter, or Facebook, or StackOverflow, or their buddy is all “hey dude check this out”, and then they’ll go to your website. But they’ve got work to get back to and you’ve got 3 minutes. So thrust your laptop in someone’s face, respect their time (and their personal space) (also take a shower first), but ask if they can take a look and tell you what they think. Be the interrupt driver that your user experiences in the world. Then thank them and peace out to go write a better riff re-do that sign-up process. FUE in a Flash!

2. Massively Distributed… User Feedback!

Sometimes we make the mistake of thinking that only one person – or a group of people – in the organization are responsible for getting user feedback. Watch out for a blog post soon on the 7 Concentric Circles of User Feedback Hell on why this is an AWFUL mistake but let’s focus on the ruthless efficiency part of making sure everyone in your company is involved in talking to users and understanding how they feel, what they want and what SUCKS about what you’re doing.

Let’s say you have six people. Make it a requirement for everyone to talk to 6 users every week. THAT’S 64 USERS/WEEK if you trust basic math skills. Let’s not belabor the point. But get everyone on your team to talk to users, all the time, in their own quick and dirty ways – and maximize the user generated goodness.

3. Release the Kraken Top Secret Preview Edition!!!

Inside, we all have a sneaking suspicious that we’re The Next Big Thing, or that we’re building it. We read about all those artists who never let anyone see their work until they died. Then we get all precious about our Next Big Idea. WHAT IF THOSE BASTARDS STEAL IT!!!

A Bird! A Plane! That UX Idea You Had After Lunch!

But let’s be honest. If someone can steal your customers, your business model or your secret infrastructure sauce from seeing some mock-ups or the top three bullet points on what you’re releasing next month, you’ve got worse problems.

An easy, low-cost, efficient way to get fast user feedback is to openly Tweet, Facebook, or blog initial thoughts around new features, a mock of a new interface, a few choices of how a process could work… you get the point. Give people a quick and dirty way to respond and get super valuable feedback at low cost.

If letting all your junk hang out makes you or your investors nervous, consider assembling an email list of “beta testers” that you can shoot quick “hey guys, what do you think of this?” notes to. This lets you control distribution but achieve similar results – with the caveat that your user feedback might not be as diverse, instant or organic as a more “open” strategy.

4. Feedback Using Zombie Machines!

What if your product could be like the Police? Catching users in the act? (OK, bad.)

One thing I’m really interested in around user feedback is this old – but remerging and reimagined – concept of including in-page widgets that let users give really fast, easy, anon feedback on what they have questions about, how they feel, what they wish you would do better, and more. These take really good design and foresight to incorporate well, but Get Satisfaction has a good example of the basic concept – and you can definitely build your own as well.

The idea is providing users a really easy way to send you those fleeting thoughts, dreams and suggestions as they come. I’m not a huge fan of taking the human element out of user feedback, but I hate live chat (which is a ghetto hack hybrid of IM and feedback widgets), and I like how widgets can remove a lot of the barriers to entry of engaging person-to-person while allowing you to capture that super precious “in the moment” feedback – all the stuff a user wishes they could say but doesn’t have time to email you about.

5. Get Religious with the Pizza + Beer on Thursday Afternoons

There are tons of meetups out there. One of my favorite things is user meetups, where you, your team and some of your users (and hey, invite some non-users for fun!) a chance to meet, network, talk about ideas and share new ones. Provide pizza, beer and a bathroom key. Keep it informal. Let your designers go crazy with all the In-Real-Life A/B testing they want. Encourage people to go to your strategy guru and delight her with their wildest hopes and dreams. Let the engineers risk pissing someone off with their plans for the code base, in the flesh.

Be religious about having and keeping these, even if only a few people show up. You’ll get there, but only by being there. Be disciplined and persistent and you will amass more feedback than you imagined, more ideas than you can build, more champions than you deserve, and a really close relationship with your pizza joint.

The end game? Never let lack of time or resources, an impending release date or over-obsessing  prevent you from getting the user feedback you need to avoid massively screwing up your product, wasting your funding, and completely missing out on the next big thing.

Where Online Collaboration Fails: 3 Lessons from MMORPGs & LDRs

For all of the talk about “web 2.0″, “enterprise 2.0,” the new “collaborative, distributed workforce,” and don’t get me started on “cloud 2.0,” collaborating online is basically full of excessive, unending, ragequit pain. This is a blog about what collaboration software needs to learn from MMORPGs and LDRs (long distance relationships.)

Some Context

His and Hers Flying Gryphons

I’m in a long-distance relationship. For two geeks, in love, separated by thousands of miles and even more United Mileage Visa Select Plus points, a long distance relationship is as much of a technical challenge as it is an emotional challenge. We are constantly working on ways to not just “chat” online, but to actually collaborate and share various projects and activities. This is everything from watching the same movie, to sharing pictures, to making travel plans, editing content and more.

Surprisingly, the best collaboration platform we use is…. World of Warcraft. World of Warcraft is a Massive Multiplayer Online Roleplaying Game. You pick a character and fight demons. With other people. It’s also very romantic when you do it with your awesome tank boyfriend. Here are some things World of Warcraft nails that I wish collaboration software would take to heart:

1. Actual Collaboration Requires a Shared Experience

When playing WoW together, you are looking at the same landscape. When something new happens in the game space or one of the characters does something to modify it (like starts attacking a demon), the rest of the players can see that action, as it happens. If Warcraft can do it, why can’t my document collaboration software also update the document as others make changes to it?!!? If I’m trying to book a flight or explore flight options, why do I have to email someone through a booking platform so they can see the options I’m looking at?

I’m not talking about screen-sharing, either. I’m talking about maintaining independently accessed “instances” of a shared problem space that is subject to the modifications of all parties, in real time. Most collaboration software or collaboration features end up resorting to some version of screen sharing. Screen sharing  is not a collaboration tool. Screen sharing violates user autonomy, creates a hierarchy of control rather than a flat collaboration space (only one person can make changes), and is basically a ghetto hack to overcome a real problem.

Without ripping into specific platforms (nudge Google Docs), this does reveal an underlying theme that collaboration software just doesn’t get – users need to be able to share an experience, object, document, problem space, media, etc – and  share control over it.

2.  User Autonomy is Possible. Complexity is Manageable.

While in World of Warcraft you are operating on a shared environment, you are able to configure your version of the problem space with your own setup. You can set hot keys for different weapons and spells, add plug-ins that 3rd parties have built with the API (oh hey, we love that!), try out different screen perspectives…. the list goes on. Not all users are forced into the same config just because they share a problem space.

Collaboration software addresses the complexity issue by… well, completely removing complexity so everyone has to deal with the same n00b settings! The way Warcraft does this is much better. There is a separation between how the user experiences the problem space and the problem space itself- a separation that doesn’t impact the group experience.

3. Communication Features != Collaboration App

World of Warcraft has a ton of awesome ways to communicate. Wanna chat with just one of your friends? Done. Talk to the local castle defense channel? Done. Talk in a dungeon raiding group? Yep. Voice? Yes. (OK, WoW voice sucks, we still have to use Skype for that, but you get the point.) World of Warcraft understands that people want to communicate in different ways around the problem space. It doesn’t need you to run other bulky apps alongside it just to have a conversation about what’s going on inside of the game app.

Collaboration software has set itself to the lowest bar possible: letting you communicate. “Twitter for The Enterprise” is not a collaboration tool. It’s a messaging feature. Collaboration is about objects and problems spaces (a document, a business plan, a piece of content, etc.), not the ability to instant message someone or make a phone call. We’ve had that stuff for awhile. Nothing new.

So why are we focusing on communication features instead of actually making it possible to experience the internets and its objects in a shared and collaborative way?

The Final Countdown

The internet has largely been designed as an individual experience. You access content in your own way, on your own time, from the privacy of your machine. Hey, if you wanted to like, work with people, you’d leave the house, right?

Well as we all know things have changed. We’ve broken down the individual-oriented nature of the web in only the most superficial of ways – basically, allowing you to share what you are seeing with others. A link-based World Wide Web, emerging and established social networks, and screen sharing technology are all geared at getting people to look at the same things, not create things together.

People talk a lot about “where the internet is going.” My hope for the future is about making the internet a place not just for individual experiences, but for shared experiences. A web that recognizes that individual users are not the only units to calibrate for. A web that’s only designed for users to share things is really prejudicial against people in long distance relationships ignores the larger potential of an internet that lets users experience and create things together.