Before you start to organize a meetup

I’ve been running the Ruby User Group Berlin for over 3 years now. Additionally, I’ve been running the React.js Berlin meetup for about a year now. These are meetups with 60 to 90 attendees per meetup right now (ruby used to be 100+) and rather well known. Also I run the lovely rails girls project group “rubycorns” together with Til, bringing you rorganize.it. As a result I regularly get asked “Tobi, how do I organize a meetup?”. So instead of repeating myself I’ll write up some basic thoughts on organizing meetups of different sizes. This is my own opinion based on my experience, so other advice may vary.

As this came out to be rather large on the first writeup I decided to split it up into three posts as follows:

First meetup I moderated. Photo by @wikimatze (link)
First meetup I organized and moderated (back in 2012). Photo by @wikimatze (link)

So let’s get started with the first one:

So you want to organize a meetup?

First of all: That’s great thanks! It’s a valuable contribution to the community! Before we get into the details of what will define your meetup and how to rune a single meetup, let’s see what you’re getting yourself into.

Organizing a meetup is a reoccurring activity that will eat time and energy. Most of the actual work is done before the meetup when you look for locations, talks and coordinate all of that. Naturally there are also communication channels through which you have to be responsive (which I still sometimes fail at) and be active in announcing and promoting the meetup.

I always feel like it’s not that much work, but it always ends up being more work than I normally think. Some sort of passion/excitement for whatever your meetup is about is required to keep it going and help you pick good talks and have a nice atmosphere.  If you’re reading this because you want to organize a meetup solely for your company’s or your own good my tip is simple: Don’t. People will realize and neither your nor them will enjoy the experience. If you enjoy it yourself, it also won’t feel like work, which is probably why I always underestimate the effort 🙂

Get a team

Also, make sure that you’re not alone – get a team. You’re human, you can’t always deal with everything as there are more important things in life. Be it vacation, sickness or whatever. It’s good to have someone you know to take over the meetup or just to bounce ideas off each other. I mostly do RUG::B by myself these days for instance, but when I need advice or can’t make it I know I can count on Thilo and Nico. And I couldn’t support the rubycorns on a weekly basis which is why I split that with Til. Also sometimes I can’t make it to the react meetup and then Chris & Bodo thankfully take over.

Me (middle) on the first rug_b meetup I moderated (totally nervous). My then organization mentor @freaklikeme to my right. Photo by @wikimatze (link)
Me (middle) on the first rug_b meetup I moderated (totally nervous). My then organization mentor Thilo to my right. Photo by @wikimatze (link)

Also don’t underestimate the “bouncing ideas off each other” part. Should we allow job ads? Is this a suitable talk? Does anyone know a good last minute location? Can we do anything different? It’s vital to have a trusted team to talk about these. Without them the Berlin Code of Conduct would have never seen the light of the day, among other things.

Your Online Identity

Got a team? Great. The next post will talk about what defines your meetup, but you need to get some place to announce it. Your online presence – a website and most likely also a twitter account. Some form of mailing list/forum is also great to have discussions, announce meetups etc.

Lots of meetups are on meetup.com, it is a good place to get started out and be found (there are people that search for meetups only on their home page). However, I don’t really like it (and really want to move the react meetup off there). Meetup gives you messages, comments and a description for scheduled meetups. It’s nice, but for meetups with talks they are missing the whole talk management. E.g. “Which talk proposals do I have?” and “I want to schedule this talk for this meetup”. It’s a hell to manage. Plus the RSVPs are way off, from experience I can tell you that only ~40% to 50% of that people that said they’ll go will actually show up. Plus it costs money. So what are alternatives?

Berlin.js had a nice workflow where they have a github pages website and you submit talks by opening pull requests to the repository to add them to a meetup. I love the simplicity of this. My favorite is on_ruby though, a white label site for ruby communities. It understands what topics are, people can propose them, you can schedule them, there is a maps integration for locations etc. It’s a great solution overall. And I think the site is also open to hosting non ruby meetups. RSVPs have a different “problem” here though, more people show up than are registered 🙂

Our meetup page - containing all important information at a glance: time, venue (with map), topics, attendees and links to share
Our meetup page – containing all important information at a glance: time, venue (with map), topics, attendees and links to share

For twitter, it is a great and easy way for people to get in touch with you and give your speakers and event some coverage before and after the event. I usually tweet talk teasers in the days leading to the event and photos during talks. Also good for ad-hoc communication like “the door is closed, how do we get out?”.

The mailing list/forum is great to discuss topics further, announce the next meetup date (link to website as the “source of truth”), ask for talks and discuss talk ideas. It can also be used for job ads or other discussions.

These days lots of meetups also have a slack group. The ruby berlin one is quite nice (join here), of course you can also go with the good old IRC but that doesn’t seem to be as hip and cool any more.

Also note, that you don’t have to create and manage all of those yourself or by the team. E.g. I created neither the slack nor the IRC, they were created by members of the community.

Recruiters and other promoters

One of the less well known side effects of running meetups is that you are contacted by a variety of people. Most of them are nice and great people. People who want to give a talk, people that ask if they can help you and people who want to host your meetup. Some are less nice and more nagging though. Recruiters want to promote their jobs at your events and others want to advertise their conferences, workshops or whatever. Be prepared for this and settle on a stance how to handle this.

I “inherited” my stance on recruiters from the previous organizers and it is “no recruitment pitches at the meetup”. Speakers can quickly mention that they are hiring, so can host companies but that’s it. There is a [JOB] tag on the mailing list where jobs may be posted. As for events, community events are fine to announce at the meetup others can also go to the mailing list. “Why?” you ask?

Most developers I know are tired of recruiting messages (enough of that on LinkedIn, Xing etc.). Getting them on the mailing list you can just ignore the [JOB] tag or look at them if you’re interested. Devs usually are at meetups to enjoy talks and connect with peers.

My view on this is enforced by the fact that ever so often I meet Berlin Ruby developers telling me that they stopped coming to the Ruby User Group Berlin 5+ years ago. Their reason (so far) always is because there were recruiters at the meetup somewhat aggressively trying to recruit them, which they found very annoying. So much even, that they never came back. Sad, but true.

That said – meetups are about the participants. I’ll gladly offer some stage time to participants looking for jobs or the like, especially Junior developers.

If you think I’m a bit overcautious, some highlights:

  • Startup founder offered 50€+ plus to be allowed to pitch his startup
  • Plenty of lengthy discussions with recruiters and founders about why they can’t pitch at the meetup and no that is not unjust and not excluding them (pro tip: explain your stance once and then don’t engage in lengthy discussions – sadly I still haven’t mastered this)
  • people wanting to organize their “own” Ruby user group Berlin at their office, announcing that “official” ruby user group Berlin meetup on our mailing list
  • people scraping our website for emails, twitter handles etc. and then writing each member recruiting emails/messages, sometimes pretending they were at the same meetup (Oh I wish this only happened once…)

With that said, luckily this remains the exception. Lots of people understand a simple no and carry on with their lives. Then, of course there also are the nice people wanting to help you, being awesome hosts etc which usually outweighs the others.

It’ll all be alright

If you’re worried now – don’t be. Mostly organizing a meetup is fun. That’s why I do it in the end. I always say that every meetup feels like a birthday party to me – so many great people there that I want to talk to all of them! But I can’t talk to them nearly as much as I’d like because in the end I run around and organize things(tm). And the best is seeing the happy people enjoying the meetup.

Also standing on stage as an organizer for the first time will almost certainly feel weird, but don’t despair – you’ll get used to it rather quickly (at least I did). Also not everything has to be perfect, so don’t pressure yourself 🙂

Make sure you have a small team (one person is enough) to back you up, an idea about your online presence and then we’re ready to get going with the second step – figuring out the 5 basics for your meetup, in the next post!

Advertisements

Slides: Optimizing For Readability (Codemotion Berlin 2015)

Yesterday I gave a talk at Codemotion Berlin, it was “Optimizing For Readability” – an updated version of my “Code is read many more times than written”. It features new insights and new organizational practices to keep the code base clean and nice. Abstract:

What do software engineers do all day long? Write code? Of course! But what about reading code, about understanding what’s happening? Aren’t we doing that even more? I believe we do. Because of that code should be as readable as possible! But what does that even mean? How do we achieve readable code? This talk will introduce you to coding principles and techniques that will help you write more readable code, be more productive and have more fun!

CS5j0v_WEAAm7S9.jpg:large
(pictures by Raluca Badoi

And here you can see the slides, sadly there is no video 😦 Slides are CC BY-NC-SA.

Hope you like the code, please leave some feedback. I’d especially love suggestions for a better talk title 🙂

Video: Shoes talk at JRubyConf 2013

Finally the video of my talk at JRubyConf 2013 in Berlin is online. It was my first full length talk at a conference, I gave it almost a year ago – some difficulties with the video material and getting it online caused this delay. Nonetheless it is finally here! The talk was titled “Shoes – the Ruby Way to GUI applications” and now  you can go ahead and watch it or you can watch all the other amazing talks.

While that is a bit old, some of the information isn’t up to date anymore. Most importantly about what still needs to be implemented as we made tremendous progress so far. We have a preview release and are happily looking into the future 🙂

Hire motivated talented Ruby/Rails engineers from an educational program today!

So if you are here, you are probably looking for some Ruby/Rails engineers. Many companies (and therefore recruiters) are but they are hard to find. Luckily we have programs in place to get more people, especially woman, into coding, such as Rails Girls (and our local Berlin group) and Open Tech School. With the current shortage of programmers I want to urge you to give alumni of these programs a chance. The programs go far in their support, it ranges from workshops, to weekly meetups and even a full 3 month hands on learning program with good coaching/mentoring like Rails Girls Summer of Code (I wrote about ways to continue to learn here). But the last step of success is mostly out of the hands of those programs. It’s in the hands of companies to give the alumni a chance and hire them as an intern, trainee or junior developer (yes I believe some are ready to be a junior developer).

Why should I hire alumni?

I believe there is one thing you need to especially consider when thinking about alumni from such a program: those people made a deliberate choice to quit whatever their former career was and get into programming. You know it can be hard and rough – especially when you are starting and you are mostly on your own. It takes a lot of determination to go through with it. Determination to sit at home and figure out that one bug in your sample application instead of watching TV or whatever. And a lot of passion.

Also they bring in all their rich experiences from their former careers which can help in a number of ways that none of us can predict. They’ve got ideas that I couldn’t even dream off.

Moreover programming and technology is full of self-taught individuals, so it should be second nature for us to give them a chance. At a recent Berlin JavaScript user group I asked how many attendees had undergone formal computer science education – just ~60% of them raised their hands. Which means ~40% didn’t – quite impressive!

These are not your common graduate students

When you assess these programmers for a position please keep in mind that they haven’t undergone any formal education. They know about Ruby and Rails but they might not know about Java or the lambda calculus or the inner architecture of a CPU or whatever they teach you at a university… (note: I’m studying and am at the end of my Master studies).

The question is: is all that knowledge really important? In my opinion: No it mostly is not! I believe that a lot of this knowledge is not necessary for a specific job and that you can pick up what you need when you face a problem. Example: UTF-8. It’s really great to know how UTF-8, Unicode etc. work but what are the practical implications? For me it mostly boils down to: “Oh look some character is not displaying correctly. Okay let’s change the encoding to UTF-8. Works.”

There also are a lot of things that you rarely ever touch again like Turing machine, formal grammar, details of how the Windows Kernel works, higher math, TCP/IP stack… I could go on. Of course this all depends on your field of work: If you do 3D computation you probably need higher math. If you do network security or some optimizations you need good TCP knowledge (which is totally interesting by the way). But most of the time you don’t and then when you get to it you will have to refresh your knowledge again either way.

Also alumni sometimes might not know what a specific term means (e.g. polymorphism) but chances are they already use the concept – they just don’t know the name.

Meet some Rails Girls Summer of Code alumni

As you might know I’m from Berlin and so I know some of the local teams. A lot of them are looking for jobs right now and I asked them if I could include them in this blog post and here are the people that I know, asked and said yes. I want to highlight that I know all of them as extremely motivated and capable learners and programmers. All of them were coached during the summer by coaches I know and highly respect 🙂

I might not be up to date with their current job status, so some of them might already have a position. In that case, keep them in mind for the future 😉

So without further ado, let me introduce:

Susanne and Tam from Team Highway to Rails

I’ve known Susanne and Tam for some time – they are among the founding members of the rubycorns, a weekly study group that Til and I coach. The two of them have always shown a great interest, motivation and effort (especially when working on homework) in the study group. So it was no surprise to me when they applied for Rails Girls Summer of Code. Unfortunately they were rejected. But here comes the real surprise and what really impressed me: they didn’t even think of giving up. Nor for a second. They buckled up, put in the extra effort and looked for an opportunity how they could make it happen for them either way. That’s some real motivation right there. And they found Absolventa where they did their voluntary Summer of Code as Team Highway to Rails. They worked on event_girl an “open event-logging system with triggers/hooks to run arbitrary tasks when an event is matched or not matched.”.

Want to get in touch with them? Great!

Carla Drago from Team Inchworms

Carla has been one the first students we ever had at Rails Girls Berlin and went on to be one of the founding members our famous first study group the Ruby Monsters. After finishing their initial project the group went on to their next project: the speakerinnen liste. The “monsters”, as we call them, now help on multiple workshops as coaches teaching new attendees Ruby on Rails, which is awesome. As a little fun memory from myself: I once went to their project group meetup several months ago eager to help them with problems. Many didn’t need any help at all and when they did it was a hard problem, that took me quite some time to figure out. During this summer of code Carla worked as a member of team inchworms on sinatra and farmsubsidy. Here is Carla’s LinkedIn.

Laura Wadden from Team Railsgrrls

I met Laura for the first time when she was in my group at our Rails Girls Berlin anniversary workshop. Right from the start I noticed that she had an extraordinary fascination for programming. Laura has a strong background in working with nonprofit organizations, fundraising and event organization as this is what she mainly did before her journey into coding. During this summer she worked on the learners directory and a new programming language on top of Rubinius called lani. I’ve been the mentor for the learners directory, but her deep interest into how programming languages work really impresses me. During the summer of code this team had their own table at the Soundcloud offices – giving them one of the best learning environments one can think of with lots of awesome people around to help. Oh and here is her LinkedIn profile.

Nina Breznik of Team Spree Girls

Nina also had the luck of being able to work from the SoundCloud offices, that’s where I met her. Her team is working on the spree commerce project an online web shop written in Rails. It’s quite the challenge to understand a system as complex as spree, even more so as a beginner. As far as I can tell they are doing well and making progress – also thanks to the supporting environment. You can find her on LinkedIn.

A few words of thank you

Last but not least I want to thank everyone who was ever involved in a free educational program. Be it sponsor, organizer, coach or mentor. You are awesome! Without you all of this would not have been possible. I especially want to highlight Sven Fuchs and TravisCI without whom Rails Girls Summer of Code would not have happened. Period. Also github for their gracious donation (and for being super supportive and awesome in general). And to SoundCloud once again not only for their donation, but for offering work spaces and coaches  to 5 students (did I forget anyone?) and the possibility of an internship for two students afterwards.

I’d really like to thank each individual but this blog post is too long already. So this heart will have to do: But really, thank you so much!

And as for the purpose of this blog post: If you want to hire or just talk to any of the programmers listed here please do so. This of course not only goes for them (those are just the ones that I happen to know pretty well and got permission to “advertise” them). This goes for everyone. There are lots of people out there who want to make a career change and lots of companies in need of good, passionate developers. Get together, together you can reach your goals. Help them make the next step and I’m sure you won’t regret it.

8 ways to enable workshop attendees to keep learning

Workshopping
A Rails Girls workshop (Photo credit: Kerstin Kollmann (CC) NC-ND-BY)

There are many great movements out there teaching people how to code: Rails Girls and RailsBridge among the most prominent. Those movements host free workshops with a superb coach/student ratio to get more people into coding. However there is one problem: How to keep on coding? After the workshop the attendees are mostly on their own again, but we want them to continue! How can we do that? Here are methods we use in Berlin, that I hope can help other movements, subgroups and organizations to keep students engaged.

1. Project Groups

At Rails Girls Berlin we have project groups. These groups are usually formed after the workshop on the mailing list. Someone can suggest a project to work on or just join a project group. Project groups usually are supported by one or two coaches and have 4 to 8 students. Of course there are bigger and smaller groups. You then meet (usually) every week for a couple of hours to work on the project or talk about concepts. As once a week is not a lot there often is some kind of homework.

This concept has been very successful for us. I know of 8 project groups running right now, but I’m told there are ~12 of them which is amazing. Our first project group, the RubyMonsters, have been working as a group for roughly a year now. They already finished their first app and help coach at Rails Girls Berlin events now 🙂

I also heard of similar groups spontaneously forming in Poland after workshops, which made me really happy!

2. Advanced Workshops

At Rails Girls Berlin we often also let advanced applicants join the workshops (we have a workshop about every one to two months). Advanced meaning that they already visited a workshop or have other programming experience. They get their own groups and don’t follow the normal curriculum but rather work on something of their own (with the help of a coach).

We also sometimes host workshops solely for more advanced learners. I spent one such workshop with an experienced Java developer from Brazil talking about differences between the Rails and the Java world. It was a lot of fun!

3. User Groups

We try to encourage the attendees to attend user groups. Here it helps if they already know someone at the user group, e.g. a coach or an organizer. With us I organize the Ruby User Group Berlin and many coaches go there regularly too. Sadly we didn’t have too much success attracting learners to join us, but those that did, always told me that they liked it a lot 🙂

However there is something more suitable for learners: A user group for beginners! Our friends from Open Tech School have just the thing: The Learners Meetup. This happens once every month and there are learners and coaches present. The coaches may introduce themselves and the technologies they are familiar with.  Then there is a talk about a basic programming topic suitable for beginners.  After that there is a break and people can write down topics they are interested in on cards. Then the different topics are clustered and groups for discussions about those topics are formed. I really love this format and the event.

4. Informal Meetings

Project Groups are great, but they have a drawback: A couple of hours per week at a specific time isn’t really flexible and too much for some. Some also prefer to learn on their own, but how to get help when things aren’t going that well? Well that’s what informal meetings are for. Those are meetings where anyone might drop by and work on something or ask questions. You are mostly not guaranteed to have a coach around but learners can help other learners. And mostly you can check beforehand who is there and then see if someone may help with the problem you’re having. Open Tech School has the Learners Hangout every Saturday, which is a brilliant place to go. And in the future I want to try to establish a regular schedule where you can be certain that a coach is present.

5. Show them resources

During the workshop present some good resources to deepen the knowledge of whatever you taught in the workshop. That might be websites, books or user groups to go to. I think this is most fitting at the end of the workshop. Also make sure to publish that list online so attendees can refer back to it later and don’t have to write everything down. I have such a list on this blog myself.

This might be pointing out the obvious, but it’s important nonetheless.

6. A Summer of Code

You might have already heard of Rails Girls Summer of Code – it’s a worldwide program started in Berlin. The idea is to get more woman into coding – or rather further into coding when you continued after your workshop. It’s 3 months, full-time, paid, work on open source and students get supported by coaches and mentors. It’s an amazing program. And we’re still looking for some sponsors – so if you’re willing to help and want to allow us to accept more students please donate. And thanks a ton to all our sponsors so far!!!

7. Have former attendees coach at a workshop

When a former attendee of the workshop continued to code (which we hope!) then it is a brilliant opportunity to let them coach at a workshop. This works beautifully in three ways:

  1. Motivation for attendees: Attendees love to meet someone who has been down the same path before. When we had our lovely Ruby Monsters project group coach with us for the first time a record-breaking number of 3 project groups were founded afterwards. For me that’s the primary measure of success – the people we convince to keep on coding.
  2. Affirmation for former attendees/new coaches: They see all the things that they have learned, up to the point where they can help others learn which is an awesome feeling. Moreover teaching is the ultimate learning (a topic deserving of a blog post of its own…) – explaining something forces you to really understand something and often times leads to looking at things from a different angle which greatly benefits your own learning.
  3. Better coaching: Former attendees remember pretty well, what it was like as a beginner as this hasn’t been too long ago for them. Therefore their explanations often work very well.

See – everyone wins!

I at least know that in Poland they did the same, where former attendees are now coaches which is amazing. At Rails Girls Berlin when we did this for the first time we paired our new coaches up with an experienced coach in order to have a good mix of experience levels for coaching.

8. Share your learning story at the workshop

It is extremely cool to have someone at a workshop who taught themselves how to program. They can share all their insights and tips. Attendees can really relate to a talk like this as well as the person. You might also tell them, that sometimes learning to code is hard, sometimes it’s fun but in the end it’s worth it and a lot of fun. Tell them that it’s ok to make mistakes and that even the most experienced developers resort to search engines more often than you’d think.

Our Ruby Monsters often give a lightning talk about their story of learning in a project group at our workshops. And regularly Joan Wolkerstorfer also tells her story and gives tips. You can watch her talk about this and read about it.

When talking to attendees weeks after the workshop and asking them why they kept on coding meeting someone who has done it and hearing their story is almost always mentioned first.

A lightning talk is also an ideal time to introduce git or github, as these tools enable you to cooperate with others on your project! And we all know that working together with others, building something together, is a great motivation!

Conclusion

There are lots of ways to motivate workshops attendees to keep on learning. These are ways that worked for us or that I think work. Do you have other ideas how we can help people to keep on coding? Have you tried something? I would love to get some input! As a result of initial comments this blog post already grew from 6 to 8 ways 🙂