Blogs about meta
Let us take a little time to compare and contrast printed products with their online counterparts - such as a printed newspaper and the same newspaper's website.
The printed version is tangible and tactile. Once printed, it can't be revised by the creator, though the user can make notes on the paper. Since it's a tangle product, the user must find a way to dispose of the used product; which may be repurposed as combustion or packing material. Each newspaper will probably only be used by one or two users.
The online version is interactive: searchable and sharable. It is easily updated. The website is much more likely to be seen by users outside of the physical area of the newspaper. Many users will use the same "version" of the paper, which can generate comments and discussions.
These are completely different products, even though they share the same content.
Way back in 2013, I decided that it would be good for my professional development to attend some conferences. I had just started a new job, with some savings left over from unemployment time, and so I had some budget to attend conferences on my own dime. I had met Carter Rabasa (founder and long-time organizer of CascadiaJS) by attending the SeattleJS meetup in the previous year. So I arranged a trip to Vancouver, BC for CascadiaJS in November. On the Hacker Train up from Seattle to Vancouver, I met Tracy Hinds, who had organized the Hacker Train all the way up from Portland.
CascadiaJS 2013 was an absolute blast. The talks were interesting and educational, and I met a bunch of new (and now long-time) conf-friends and even got mistaken for a speaker! I followed new friends on Twitter, and CascadiaJS on Github. Not too long after coming home, I wrote up and posted some of my notes and published them on this blog. I knew I would be ready to do it again in 2014.
And I did. CascadiaJS 2014 was in Portland, and I bought a ticket and lodging nice and early. Beyond being excited about attending, I had even begun to think I might be able to speak. I had even submitted a talk. It was pretty awful, but that's the first step. 2014 was just as wonderful as the last year - I made sure to thank Tracy and Carter (head organizers for that year) personally, since I knew it was a ton of work to organize something so big and so lovely. (Organizing a conference is kinda like organizing a wedding, once a year.) Since I followed the CascadiaJS repo, I was able to observe many parts of the organization process, and contributed some (hopefully!) helpful thoughts for the next year.
So, there you go. I got involved by attending first, providing useful feedback to the organizers, and participating in the community.
A while ago, I interviewed for a job with a company that I was absolutely in-love with. I'd been excited to see that they were looking for a front-end developer and I applied right away.
Back to the interview, we'd gone though a few basic questions and the interviewer had moved on to the algorithm questions. It was a little more complicated than Fizz Buzz, but it wasn't too tricky. But I flailed around for a while trying to both understand what the interviewer was asking, as well as trying to logic out the solution. I didn't solve the algorithm easily enough, and I didn't get any further in the interview process.
Why evaluate a front-end developer based on a algorithm? It's such a very small part of the job, and especially over a video conference after a full day of work, and it's the wrong test to get the front-end developer to demonstrate their best. It's like evaluating an NFL kicker based on their tackling skills - sure, they need to do it sometimes, but a proper blocker will always be more skilled at tackles.
Bottom line - your events (from meetup to conference) and even your open source projects need a code of conduct. What is a code of conduct?
- It is an explicit statement about what is - and isn't - appropriate in your space. It sets a social contract that every attendees agrees to, and encourages active enforcement of that social contract.
- It is a promise from you (the organizer) to me (an attendee or speaker). If you break that promise, I am 100% free to leave your project / event without any repercussions.
- It compels a response, even when the organizer would rather ignore a situation.
Let me tell you precisely how a code of conduct works to change interactions during an event.
Last year, I attended a conference as a workshop volunteer. After the workshop, a speaker from the previous day wanted to ask me some follow-up questions about the workshop. While he spoke a little English, he wanted me to step outside to the plaza where his translator was. I agreed.
Let's review the power dynamic here: me = unimportant volunteer, him = very important speaker.
He was from a country where (I suppose), it's common for men to escort women by leading them by the elbow. While we were walking outside, he put his hand on my elbow, and I (being perfectly capable of finding the doors outside) removed it. He again put his hand on my elbow and tried to lead me towards the door. I again removed it, and looked him directly in the eyes and said "no". I then stomped through the doors and found the translator. With the help of the translator, the speaker apologized if he had offended me. I said that I was fine and I answered his questions from the workshop.
Here is how the conference's code of conduct worked: I knew that - regardless of any power imbalance - the conference had my back. I was empowered to enforce my own boundaries and I did so. I was a bit irritated by the incident, but I took care of it myself. Situation resolved, no escalation, no problem. That's how a code of conduct works.
If you're trying to hire software developers (and who isn't?), then local developer conferences (and even meetups) can be really great recruiting opportunities for you. Mozilla, npm and IBM have done pretty well for themselves at CascadiaFest and JSConf in the last year.
To a degree, this depends on who you send to the event. At a developer conference, attendees probably aren't particularly keen on talking to another recruiter; but many would be open to hearing front line stories about your deployment process or upcoming projects. Send members of your technical teams to developer conferences.
Don't send jerks or dudebros. A few months ago, I was at a SeattleJS meetup and happened to be sitting near two fellows from a large and well-respected company. One of them (who really had enough salt in his hair that he ought to have known better) was fooling around with his skateboard in the office meeting space. He insisted that his colleague "video my kick flips"; and inevitably smacked other peoples' chairs when he lost control of his skateboard. Don't send that person. Send your outgoing and thoughtful developers, who can talk in detail about your organization's work without insulting other technology choices.
Do remember to compensate your people with time off if these events fall outside normal working hours. Your developers shouldn't have to do free recruiting work in their off-hours.
More blogs about meta: