Sponsoring underrepresented people in tech

Inspired by @aphyr’s tweet on sponsoring people who are underrepresented in tech, I’ve decided to also jump in. Time to put my money where my mouth has only previously been.

As such, I’ve also joined (read: stolen) Aphyr’s idea and created a similar page of my own. So please reach out.

This is hopefully just the first step for me. I want to try and take this idea further, beyond the idea of helping people attend tech conferences.

Do you have any ideas for how I could do that?

The toxicity of arrogance

(This is an auto copy over from my old blog at Joe8bit.com, some links may be broken)

How ego and hubris puts up barriers to inclusiveness in technology

The community of people that work in technology have a problem, we’ve built a meritocracy of assholes, and it’s toxic to inclusivity. Taking a look at the public face of technology reveals a place where the cult of ‘meritocracy’ has resulted in the creation of ego’s and attitudes from some of our industries leading thinkers and practitioners that fundamentally violate the thing so succinctly summed up in Wheaton’s Law *.

“Q: What is Wheaton’s Law? A: “Don’t be a dick!” – Wil Wheaton

Three of the main avenues of public discourse in technology (social media, Github and conferences) are infected with the kind of skewed, adolescent, male power structures that are more at home in a school playground than a professional environment that self-describes itself (rather hubristically) as wanting to change the world.

When talking to people about this post there were suggestions that I should ‘name and shame’ some individuals involved, but I’m not going to do that. The only purpose it would serve is to frame this post as a personal attack, and more than that I think it violates the “Don’t be a dick” rule.

I won’t be dealing with why a meritocracy is a bad thing, other people have done it better than I ever could.

Social media

Social media has been the best thing to happen to our community, it has lowered the barriers to communication and collaboration in a way that I don’t think anyone could have predicted, but it has also led to a terse culture of dismissal and attack.

Far too often you watch people engage in the kind of nasty, personal attacks that naive experience tells you people would never indulge in real world interactions.

I’m not talking here about the toxic cesspool of social media that seeks to degrade and abuse people at every opportunity, particularly so if you’re female or (heaven forfend!) just not a member of the young, white, male and heteronormative morass. That part of the internet deserves to be fired at high speed into the nearest star. I’m talking about what is seen as the positive side of social media, the place where the value lives.

Too easily nasty adjectives are thrown around, describing ideas or even the people that produce them as ‘stupid’ or ‘idiotic’. Too easily do what start out as constructive discussions end in name calling and barely concealed personal attacks. Too easily are we ready as a community to throw people’s ideas and work under the train of subjective ‘reality’.

Do bad ideas need to examined and dismissed? You bet. Do people spreading misinformation need to be called out? No question, but do we need to do with it with the attitude of condescending indifference and barely controlled mocking laughter? No, we don’t. Look at pretty much any Hacker News submission to see the kind of attitude I’m talking about here.

Building positive and constructive discourse on social media is a key to building an inclusive community, that means not dismissing people who know not quite as much as you so easily, giving feedback and accepting it in return. Is it your responsibility to reach out and spend time doing this? Maybe not, but it is your responsibility to treat people with the dignity and respect they deserve when dealing with them on social media? Yes, it is.


Github has come to represent, for me at least, a lot that is good about open source and community building in modern software engineering, but due to it’s size and rambling complexity it also attracts the kind of attitudes I talked about above.

The arrogant dismissal of issues or bugs, the language and pronouns that are used in documentation can serve to alienate a sizable chunk of the community. Others have written on this subject far more eloquently that I ever could, Coraline Ada Ehmke in particular, who has created what I think is becoming one of the most valuable documents available to the open source community: the Contributor Covenant, which in it’s words is:

An easy way to begin addressing this problem [the startling lack of diversity of participants, including women, people of color, and other minority populations] is to be overt in our openness, welcoming all people to contribute, and pledging in return to value them as human beings and to foster an atmosphere of kindness, cooperation, and understanding.

The Contributor Covenant can be one way to express these values. Pledge your respect and appreciation for contributors and participants your open source project by adding an explicit CODE_OF_CONDUCT.md to your project repository.

The adoption of the Contributor Covenant is growing, with notable projects like AngularJS (and many others!) adopting it’s values. To demonstrate it’s obvious necessity, read it and then apply it’s principles to your favourite project on Github, what would have to change? In many cases, it’s quite a lot.

Tech conferences

Having conversations with others in the community about the above will usually lead to an easy to form conclusion: sure, people aren’t nice on the internet, but they’d never be like that in person!

If you’ve ever been to a tech conference, you can attest to the fact that it unfortunately carries over to in person encounters to. Curiously impersonal ones admittedly but face-to-face nevertheless.

There’s a few examples that illustrate the problem:

  • Questions after a talk. Too often these ad-hoc questions are not used to push forward a discussion on a topic or get as much value from a persons experience as possible, they’re used to demonstrate the cleverness of the person asking the question. A question that lasts for 60 seconds can be 45 of public ego-stroking and 15 of perfunctory or provocatory question at the end.
  • Holding court. People with (sometimes rightfully) great reputations in communities can use conferences (usually when they’re speaking at them) as proxies to hold court. Seeking to spend their time holding court with a coterie of admirers and quickly dismissing questions they deem unworthy with a knowing smile or subtle eye roll.
  • The “dudes at the bar” problem. There’s a lot of bullshit ladishness at conferences, too often when a group of <30 year old men get together in one place with cheap or free alcohol a predictable atmosphere is created. It’s not good, it makes people feel uncomfortable. Being the vaguely liberal, vaguely well educated group or predominantly white straight men that we are we think this “isn’t really that much of a problem”, but it is, just ask someone who isn’t part of that group who’s been to a tech conference if you don’t believe me.

Finally, there’s an even more insidious and flagrant group of people at tech conferences, those who still loudly decry their misogynist, transphobic, homophobic and racist bullshit. This has to stop, these people need naming and shaming and ostracising from our community, only then can we deal with the more subtle problems our conferences face.

The positive thing is that there’s a growing movement at tech conferences to have well documented and enforced Code of Conduct. This is awesome and is to be applauded, but we as attendees and organisers need to do more to hold ourselves and others to the high standards these conduct documents require us to.

Why is tech so bad?

It’s not, having worked in legal, financial and other fields the tech industry is no worse than some and better than others, but I think there are a couple of things that in combination lead to a particular nexus in the tech community:

  • The nature of our work is, in lots of cases, an introverted intellectual one. This can lead to the stereotype of the brilliant anti-social engineer that we all know. It is hard to relate to the world when you spend all day in your head. When you form hypothesis and ideas internally it’s difficult for people to relate to them in exactly the way you do. However, we forgive people too much their lack of social niceties.
  • The startup circle-jerk (apologies for the crassness of that, but it’s a good summation) has led to the kind of inflated, ego driven cult of personality and individual worship that means keeping a level, modest head on your shoulders can be hard. “I’m paid really well and sought after by some of the most important, innovative organisations in the world, of course my opinion’s important!”

So what can we do?

Follow some simple rules when interacting with people, be it online or off:

  • Be open to other people’s ideas and opinions.
  • Welcome everyone to contribute regardless of their experience, gender, sexual identity, race, physical ability or religion.
  • Be kind, be cooperative, be understanding.
  • Be thoughtful with your language, particularly when it comes to personal pronouns or sexually or racially inappropriate names or words.

If you feel these things are being violated and make you uncomfortable, please don’t stay silent. This is easier said than done, but know that there are people who care and will help.

* I realise using this language runs the risk of using of doing exactly what this post is talking about (gendered language etc), but I hope the generalness and non-sexual connotation of the phrase allows me to just use it in the original spirit it was meant. Please contact me on Twitter if you think this is wrong!

On conference topics

(This is an auto copy over from my old blog at Joe8bit.com, some links may be broken)

Trying to cover too much leaves no one happy

This post is based on my experiences speaking at 50+ conferences in the last cfew of years, and how my thoughts have developed. This isn’t in reference to one particular conference, but a summation of my general thoughts.

Conferences are expensive things. They’re expensive to put on and expensive to attend. They require an investment in time and money from a group of people putting them on that’s scary, especially when you’re doing it without relying on an existing conference brand.

There seems to be an easy way to mitigate some of this risk: broaden your customer base. Don’t narrow the focus of your conference too much, make it appealing to the greatest number of people possible. The more people that want to buy tickets the better, right?

When it comes to ‘web’ focused conferences, that tends to mean one thing: combining design and engineering topics into one cohesive agenda.

On the face of it, this is a great idea. Not only do you potentially derisk your ticket sales, but you ‘bring people together’ to talk about the future of the web! What’s not to love?

But there is a problem, and it’s a problem that leaves people unsatisfied.

The purpose of tech conferences

In my experience there are two types of tech conferences: broad and deep. Broad conferences are those that have lots of ‘101 in this thing’, ‘intro to this other thing’, whereas deep conferences are (exactly what they sound like) deep dives on narrow subjects.

The first are places where people can be introduced to a broad number of concepts that are not quite on the bleeding edge of the field, the second is a place where people at that edge can talk and push the communities knowledge even further.

My personal preferences are for the later, but I am the first to recognise the value of the former, people new to the ‘web’ ecosystem need a place where they can learn and grow their knowledge and these types of conferences are a great place for it! Now, I think it’s a really expensive place for them to learn about it, but that’s neither here nor there.

Why we shouldn’t mix the two

The problem I highlighted in the first paragraph’s occur because design + engineering conferences tend to mix the two types of conferences. I’ll illustrate this with a fictitious conference schedule:

Attendee Intro to tech 1 Intro to design 1 Deep dive of tech 2 Deep dive on design 2
Experienced designer Interested Bored Can’t follow Interested
Newbie designer Interested Interested Can’t follow Can’t follow
Experienced engineer Border Interested Interested Can’t follow
Newbie engineer Interested Interested Can’t follow Can’t follow

From this table, which reflects a lot of the experiences I’ve seen people having at these types of conferences, you can see that nobody is taking value from more than 50% of the program!

Considering how expensive these conferences can be, only really enjoying less than 50% of the program is not conducive to building a strong conference brand, or a good experience for your customers.

Chasing unicorns

But Joe, what about all those awesome designer/developer switch-hitters?!

People who are great engineers are incredibly hard to find, people who are great designers are equally hard to find. People that do both well? Those are the unicorns you’re chasing. There are not enough of them to fill a conference.

There are people that do both, but I’ve rarely met people (there are some exceptions!) who do both any better than average. So the broad conferences make a lot of sense for these people. They have to cover so much content to do both well that the broad conferences make a lot of sense for them keeping track of current trends.

So what should I do? Cancel my conference?!

Of course not, but there are a couple things you should do:

  • Be honest with your potential attendees, tell them of the type of program your building before they buy. This means having a reasonable idea as to your schedule before most people buy tickets.
  • Don’t try and do to much. You want to build an awesome design conference? Do that! Don’t shoehorn in some 101 technical topics just to try and sell some tickets.

The first conference you put on is going to be hard, building a brand and an audience is even harder (the number of one-off conferences can attest to that) but both get easier when you leave a smaller number of people incredibly satisfied than a broader group feeling a little disappointed.

Abandoned Tube Stations

(This is an auto copy over from my old blog at Joe8bit.com, some links may be broken)

An interactive data experiment with Angular, Mapbox and GeoJson

Growing up around Kentish Town there were always rumours about an old abandoned tube station. It was variously claimed people had held raves down there in the 80’s; that it was used as some kind of bizarre goth sex dungeon; or even, that it was the place ‘they’ buried that kid who just left school suddenly. While none of these were true (except we still haven’t found little Timmy, coincidence, I think not!) the truth was it self like part of a (quite literally) forgotten underground. A part of London that existed, and yet very people knew anything about, save the innuendo of bored adolescents.

Only when I grew up and Google made researching these things easy did I discover that the station did actually exist: it was South Kentish Town and that it was every bit as real as all out stupid stories had been imaginary.

South Kentish Town former tube station 2005“. Licensed under CC BY-SA 2.0 via Wikimedia Commons.

In hindsight, it was obvious: the tiling, the colour, the second exit that stands just behind where this photo was taken that leads down to nothing.

Not only are there dozens of these stations dotted around London and outside it, there are entire lines that have been closed that lead dozens of miles out of London. In my search to get more information about this subject, I came across this wonderfully 1990’s website where someone has loving indulged and curated a very good list of the stations, when this was combined with another fantastic Wikipedia resource I knew I had the beginnings of a cool data project.

Over the course of a couple weekends I put it together using AngularJS, MapBox and and some GeoJSON. However, I ran into a problem, what would I use to indicate the tube lines? I’d need a geographically accurate map of London’s Tube network. Uh oh.

Only when I found this Google map did the project come to completion. One of the issues I had, and that I found a little perplexing, was the way that MapBox rendered the default KML output from Google Maps, it never rendered the Polyline output right and never seemd to respect the styling data. What I really didn’t want to do was spend hours/days/months hand converting KML to GeoJSON, there are lots of tools for automating this process but none of them supported the conversion of the (god awful) XML based styling syntax of KML layers to the (just a little but less awful) GeoJSON styling metadata, but having tried a couple of tools I ended up using MapBox’s own toGeoJson which while it didn’t solve the styling problem it did produce very clean GeoJSON output that I would then (ugh) manually annotate with the correctly styling information.

So take a look at the project!

As with most experiments, this one is available and open sourced (under the MIT license) on Github. If you run into any issues with the little app, I’d really appreciate it if you would reach out Twitter or file a Github issue!

MapBox: HTML markers with GeoJson layers

(This is an auto copy over from my old blog at Joe8bit.com, some links may be broken)

Using HTML markers with rendering GeoJSON layers

I’m a big fan of MapBox, I use it wherever I can when I need maps (CartCSS + TileMill is a ray of sunshine in the otherwise crappy world of custom maps).

One of the main reasons I love their service so much is the quality of their documentation, which rarely fails to present an answer to a question I’ve had, until this instance.

So in the interest in saving a few minutes of pissing about, below is my solution to using custom HTML markers when rendering GeoJSON layers with Mapbox.js.

// Create your map is you normally would
L.mapbox.accessToken = 'YOUR_TOKEN';
var map = L.mapbox.map('map', 'YOUR_MAP').setView([YOUR_LAT, YOUR_LONG], YOUR_ZOOM);

// Add a layer with no data set as the first arg to featureLayer()// This is done to prevent the default marker icons rendering
var layer = L.mapbox.featureLayer().addTo(map);

// When the 'layeradd' event is fired (when we add the geoJSON below)layer.on('layeradd', function (e) {
var marker = e.layer;
var feature = marker.feature;

// This is where the magic happens...
    className: YOUR_ICON_CLASS, // Make sure you set an icon class here, otherwise default styles will be set by Mapbox's CSS
    html: '
<h1>Hello World</h1>
', // The content of your HTML marker, you can build a string based on the marker properties by using 'feature.properties.your_property'
    iconSize: [60,60] // The bounds for your icon

// Now set your data and render the maplayer.setGeoJSON(YOUR_GEOJSON_DATA);

I can’t say for sure this is the best way to do it, but it works nicely and performantly for me.

Jekyll: generate body class

(This is an auto copy over from my old blog at Joe8bit.com, some links may be broken)

Adding a Liquid tag to generate contextual classes

In the process of moving the site you’re reading from WordPress to Jekyll (NB: lol and back again), one of the things that most appealed to me was Jekyll’s plugin API. I can now say with great pleasure, that gone are the days when I’d spend hour pouring of the (not great) WordPress plugin API docs. Not to mention that the fact there is no longer any dark corners of my life where PHP lurks, waiting to jump up and bite me in the ass.

In an attempt to get to grips with this new wonderland, I created a small plugin for Jekyll that allows you to add contextual classes to a body element. In the context of this site, it is the thing that powers the ability to have radically different styles and layouts on different pages.

The code is relativley simlple, simple add this to your _plugins directory (create it at the root of your site, if it doesn’t exist) and name it anything you like, I choose bodyClass.rb.

class BodyClassTag &lt; Liquid::Tag

    def generate_body_class(prefix, id)
        id = id.gsub(/\.\w*?$/, '').gsub(/[-\/]/, '_').gsub(/^_/, '') # Remove extension from url, replace '-' and '/' with underscore, Remove leading '_'

        case prefix
        when "class"
            prefix = ""
            prefix = "#{prefix}_"


    def render(context)
        page = context.environments.first["page"]
        classes = []

        %w[class url categories tags layout].each do |prop|
            next unless page.has_key?(prop)
            if page[prop].kind_of?(Array)
                page[prop].each { |proper| classes.push generate_body_class(prop, proper) }
                classes.push generate_body_class(prop, page[prop])

        classes.join(" ")


Liquid::Template.register_tag('body_class', BodyClassTag)

Utilising it is then as simple as adding this Liquid tag to whichever layout you choose, for instance _layouts/default.html

<body class="{% body_class %}">;