Eric Holscher - Posted in 2017

Breaking Cliques at Events: The Snowball Rule

2017-12-02T00:00:00+00:00

I’ve been going to professional events for a number of years, and one of the trickiest dynamics I have seen is that most events develop an “insiders” group who has been going for a long time. These groups tend to feel like exclusionary cliques for first-time attendees, and actively hurt the community’s goal of inclusion.

I’d like to propose a simple rule that we have at the events I run, which I think makes inclusion easier for everyone.

Difficulty meeting new people

Meeting new people is scary, especially if you’re new to a community and you’re not sure if you belong. People that have been attending an event for years are much more firmly planted in the community. They are able to help newcomers understand the norms and standards of a place.

This means that long-time attendees should be the ones introducing themselves to first-time attendees.

With that in mind, I came up with a new rule that properly assigns the responsibility.

The Snowball Rule

The rule is:

For every year you have attended an event, you should try to meet that many new people each day.

An example makes it clear:

If you have attended an event for three years, you should try to meet three new people each day.

The organizer’s responsibility

As an organizer, you’re asking a lot of the long-time attendees. Particularly in the software industry, a lot of people (including me!) have anxiety around meeting new people.

By using the Katamari Rule, it’s the organizer’s responsibility to make meeting new people easier.

So here are a few ideas for how to make meeting new folks easier: [1]

Organize lunches and dinners around topics so that people know they have shared interests
Give folks “Ask me about ____” stickers to wear, so that breaking the ice is easy!
Have an Unconference or open space, where there are tables or rooms labeled by topic in 30 minute blocks
Have a Welcome Wagon, which is a few folks who are designated friendly faces for the event

Outcomes

New people only have to meet one new person each day, a useful and attainable goal
People coming back for the second or third year feel a bit more responsibility to be stewards for the community, a valuable role for them to play
The organizers and long-time attendees need to meet the most people, and they are the most valuable in spreading the culture of the event – they are also the most exciting for new people to meet!

In the events that I have run, this rule has turned out quite well. I have gotten feedback from people, who turned it into a game: “My friends and I competed to see how many new people we could meet each day”

However, the most important outcome is how it changes the dynamic of the event itself. It goes from an event where it feels like people aren’t accessible, to one where people know it’s their job to meet new people. This makes it easier for everyone to meet new people, make connections, and really build the valuable professional networks that we all need to be happy in our careers.

Giving everyone at the event the direction to meet new people makes it much easier to meet new people.

The Pac-Man Rule at Conferences

2017-08-02T00:00:00+00:00

I firmly believe that conferences can provide a lot of value for people in an industry. Conferences allow people to create a network, which helps them feel integrated in a community and profession.

In order to build a network you need to meet other people at events, and for this to happen attendees need to feel empowered to reach out and connect to people they don’t already know. We do this by having specific events that encourage collaboration, but also by giving people explicit permission to meet other people.

Give people explicit permission to join groups

In the events that I help organize, I try to solve this problem by giving people explicit permission to join new groups of people. In the introduction of the event, I tell attendees their job is to meet people and make friends. They are supposed to join groups, battle past that awkward silence that occurs when they do, and have a great time with new people.

This solves one side of the equation, making a person feel empowered, and like they are doing the right thing by talking to new folks. There is a second part of this equation, which is the group of people a person joins, and that’s where the Pac-Man Rule comes in.

The Pac-Man Rule

The rule is:

When standing as a group of people, always leave room for 1 person to join your group.

More memorably, stand like Pac-Man!

The new person, who has been given permission to join your group, will gather up the courage, and join you! Another important point, the group should now readjust to leave another space for a new person.

Leaving room for new people when standing in a group is a physical way to show an inclusive and welcoming environment. It reduces the feeling of there being cliques, and allows people to integrate themselves into the community.

Video

Dylan Beattie has made a wonderful video that captures this quite well.

Download video as an mp4

Going to a conference? Yes! Introduce yourself. Say hello. Chat to people. They're lovely. Really! And if you're already chatting in a group, make your group approachable using @ericholscher's Pac-Man Rule.

Here's how it works.

Have fun! pic.twitter.com/QklklD43Me
— Dylan Beattie 🇪🇺 (@dylanbeattie) March 29, 2019

Your mission

If you choose to accept it, is to try and build the largest Pac-Man in the room. Invite new people into your groups, make new friends, and build a community full of people who feel included. We all benefit.

Documentation is JSON for the Brain

2017-02-13T00:00:00+00:00

When you are writing software, you build a mental model of the program in your brain. This is how you make decisions and reason about how the program might work, how data flows, or what designs make the most sense.

A large amount of the time spent “programming” is actually building a mental model in your brain. You spend time understanding how and why things are put together. Programmers often talk about how interruptions can stop them from being productive for 15-30 minutes afterwards. This is because they are losing the mental model that they have spent time building.

Reading documentation is the quickest way to load mental state into your brain. It gives you a shortcut, faster than reading code, to understand what the code is doing, and why. Writing documentation is the best way to preserve the mental model in your mind, and turn it into written words for later.

Documentation is JSON for your mental state. You should write docs so that whoever is maintaining your code will be able to get up to speed quickly, and understand why certain decisions were made. That person might even be you in 6 months.

“My Code is Self-Documenting”

2017-01-27T00:00:00+00:00

Self-documenting code is one of the biggest documentation myths in the software industry. This view generally conflates documentation with code comments. I’d like to make two arguments in this post:

Code comments have value
Documentation has more value than just explaining how software works

Code comments have value

Generally the argument for “self-documenting code” boils down to:

I can make small objects/functions that have one specific use
That specific use will be represented in its name
I don’t need to explain anything else because now it’s obvious how this program works

Code comments document the why, not the how. They are important to transfer knowledge to both people reading the code or developers working on the code.

Some common uses of comments:

Explaining previous approaches that didn’t work
Presenting an example usage of the function and example output
Explaining trade offs in the current implementation
Marking possible improvements (TODOs) in the code
Anything else you’d like to communicate with someone reading or developing the code

Object names document the how, not the why. They are effectively inverses of each other. An argument against comments is an argument against communication. It’s effectively saying “anyone who needs to know how to use a piece of code is best served by reading that code”. This is true for a vanishingly small amount of software users.

Once you start writing quality code comments, you can use a tool like Sphinx or Javadoc to include them in your documentation. This allows you to include your up-to-date code comments in your guides and references. Making use of your code comments this way adds incentive to keep them up to date, since they will be shown to your users.

Documentation is more than code comments

The other fatal flaw of the “self-documenting code” mindset is that it is myopic. It takes a developer-only point of view, only seeing the value of documentation as allowing people to understand how code works. Documentation is for every possible user.

I have a few rhetorical questions about this philosophy:

Where does the tutorial go in your self-documenting code?
How do you put installation instructions in your variable names?
What do the answers to questions from your users go in the code?

Developers only thinking about developers when they are working on software is a problem. A vast majority of software users are not people who develop that software. Saying that variable names are the only documentation needed means that only people who read your code can use it.

One of my goals in the world is to make software more usable. Having good documentation makes software approachable and usable by people who aren’t developers. People who believe in a world of self-documenting code are making it harder for normal people to use our software.

If you want to have users for the software you write, you have to write documentation.