Yesterday at RUG::B I tried something I’d never done before: a more personal, story driven talk. And in order to adequately illustrate it and how different Open Source feel to me I also opted paint some very special drawings.
Open Source is something I’ve been doing for longer than people pay me to do programming. I’m immensely passionate about it and it felt like it was some kind of blind spot that I never gave a talk about it so far.
If you know of a conference this talk would be a good fit for, please let me know.
What’s it like to work on Open Source projects? They’re all the same aren’t they? No, they’re not – the longer I worked on Open Source the more I realize how different the experience is for each one of them. Walk with me through some stories that happened to me in Open Source and let’s see what we can take away.
In a trial run for Heart of Clojure I gave my talk Functioning Among Humans yesterday at RUG::B. It covers topics very close to my heart and is a talk I wanted to give forever. It’s sort of a “best of” soft/social/people skills that I learned going back all the way to high school and that are useful to me in every day life.
If you happened to have seen the talk, please feel free to reach out to me with feedback as I still want to improve upon it for future versions.
In the development world most people are striving for technical excellence: better code, faster run times, more convenient interfaces, better databases… But is that really what helps us create better software?
In the end software development is done by groups of people creating products together. To do that communication and collaboration are essential. You can be the best programmer ever, but if you can’t efficiently work with others what good does it do you?
This talk will introduce you to relevant, easy to grasp concepts of collaboration and communication as well as give you food for thought.
I had a wonderful time at Ruby On Ice! I gave a talk, that I loved to prepare to formulate the ideas the right way. You’ll see it focuses a lot on the problems, that’s intentional because if we’re not clear on the problems what good is a solution?
You can find the video along with awesome sketch notes on the Ruby on Ice homepage.
(in case you wonder why the first slide is a beer, the talk was given on Sunday Morning as the first talk after the party – welcoming people back was essential as I was a bit afraid not many would show up but they did!)
Abstract
Rails apps start nice and cute. Fast forward a year and business logic and view logic are entangled in our validations and callbacks – getting in our way at every turn. Wasn’t this supposed to be easy?
Let’s explore different approaches to improve the situation and untangle the web.
I gave my first ever keynote yesterday at Ruby on Ice, which was a lot of fun. A lot of the talk is based on my “Where do Rubyists go?”-survey but also researching and looking into languages. The talk looks into what programming languages Ruby developers learn for work or in their free time, what the major features of those languages are and how that compares to Ruby. What does it tell us about Ruby and our community?
Many Rubyists branch out and take a look at other languages. What are similarities between those languages and ruby? What are differences? How does Ruby influence these languages?
When I was at the excellent Pivorak meetup I had the chance to give an “inspirtational” lightning talk. So I took this chance and prepared a lightning talk version of a talk I’ve been submitting to a lot of conferences but always got rejected. The talk is about “soft” skills, not the usual “hard” skills talks that you might be used to 🙂
The topic is very close to my heart as applications aren’t developed in a vacuum – they are developed with and for humans. I hope you enjoy it and that at some point I submit it to the “right” conference which will accept that type of talk 🙂
In the development world most people are striving for technical excellence: better code, faster run times, more convenient interfaces, better databases, faster deployments… But is that really what makes us better at developing software?
In the end software development is done by groups of people creating products together. To do that communication and collaboration between humans is essential – you can be the best programmer ever, if you can’t efficiently work with others what good does it do you?
This talk will give you a primer and food for further thought.
My slides & video from visiting the excellent WRUG (Warsaw Ruby Users Group). The talk is a variation of the similarly named elixir talk, but it is ever evolving and here more focused on Ruby. It covers mostly how to setup and run good benchmarks, traps you can fall into and tools you should use.
“What’s the fastest way of doing this?” – you might ask yourself during development. Sure, you can guess what’s fastest or how long something will take, but do you know? How long does it take to sort a list of 1 Million elements? Are tail-recursive functions always the fastest?
Benchmarking is here to answer these questions. However, there are many pitfalls around setting up a good benchmark and interpreting the results. This talk will guide you through, introduce best practices and show you some surprising benchmarking results along the way.
The following is the first part of my visit to Warsaw in April (sorry for the super late post!). As part of the visit, I also visited Visuality and spent an evening there giving a presentation and discussing the topics afterwards for a long time. We capped it off some board games 😉 I had a great time and the discussions were super interesting.
The talk is a reworked old goldie (“Code is read many more times than written” / “Optimizing for Readability”) and is about readable code and keeping readable code. It’s evolved as I evolve – I learn new things, assign differing importance to different topics and discover entirely new important topicss.
The publishing/video partner of Full Stack Fest was amazingly fast in publishing the video. Kudos to them! So after publishing the slides here goes the video!
In case you want to see it live, the talk will be up again at Codemotion Berlin.
Abstract
This year AlphaGo shocked the world by decisively beating the strongest human Go player, Lee Sedol. An accomplishment that wasn’t expected for years to come. How did AlphaGo do this? What algorithms did it use? What advances in AI made it possible? This talk will briefly introduce the game of Go, followed by the techniques and algorithms used by AlphaGo to answer these questions.
PS: Yes, Lee Sedol probably wasn’t THE STRONGEST human player – more like Top 3 or Top 5 at the time of the game (most people would probably call Ke Jie the strongest player at the moment). Lee Sedol is the dominant of the last decade though, and when the match was announced nobody on the computer-go mailing list complained about the opponent, so I just assumed he was the strongest or among the strongest but only found out after submitting the talk 🙂 . Plus, sadly “How did AlphaGo beat one of the top 5 Go Players” isn’t as catchy as a title.
A meetup is usually divided into a couple of phases: Before, Arrival, Main and Goodbye. To easily see what there’s to do, the format of this post is slightly different than the others. It’s not so much discussions but more of a check list for each of the phases, so you don’t forget anything.
Before
As you might have noticed during the first two posts, most of the work done for a meetup happens before the meetup. The preparation is the real work, if it is good, then the meetup is mostly fun. The foundation for a great meetup is great preparation. Most of the things to prepare (online presence, atmosphere, talks, regular schedule, …) were discussed in previous posts. This is about what to do in the days leading up to the event.
Check with the hosts if everything is still set and clear up any questions (how many people are expected to come, how long the meetup will run, do they have a projector etc.) and remind them of important things (putting up signs etc.)
Check with the speakers if they are ready and everything is good to go for the meetup day and remind them of the CoC
See that you announce the meetup via the mailing list and twitter (I usually like to tweet about every talk individually to give the speakers some exposure and let interested attendees know what topics will be covered)
On the day of the meetup tweet again, make sure that the directions to the meetup are clear and let them know if there’s food at the meetup
Arrival
For Arrival I like to be the first person at the venue, so I get there 30 to 45 minutes before the official meetup start. If the meetup involves presentations of any kind, be sure to bring your own laptop. The laptop of a speaker might break down, they don’t have their adapter with them… lots of things can happen, so it’s good to have a backup on your side.
For the Main part I’ll make sure I found enough speakers to fill the content before the break and then start relatively on time. Starting a bit late is fine, as people always arrive late. The Ruby User Group Berlin even has this “tradition” where we always start 15 minutes late (pssst).
First comes the welcome and an overview that should include:
thanks everyone for coming
quick introduction to the format (talks, lightning talks)
today’s topics and speakers
where are the bathrooms
where are food & drinks
wifi (also good to show on a projector or have signs around)
mention general rules such as the CoC
host & sponsors (if you have some), I usually give them maximum 5 minutes to introduce themselves while advising for a shorter time – people get bored easily
Then it goes on to announcing talks, as well as different parts of the meetup (break, lightning talks) and tell people that we are always looking for talks and encourage them to approach me to bounce talk ideas around.
If there are small pauses in between speakers (while connecting to the projector) I like to share some related news (new version of major library X released, security vulnerability in Y, conferences) and ask the audience if they also have any news to share. I just don’t like sustained periods of silence while the meetup is supposed to be running.
To get the attention of people and have them be silent a long extended “Shhhhhhh” while standing on the stage usually works best in my experience. Sometimes it’s just enough to stand there, wait and look like you are going to say something. Holding up one hand (maybe with a balloon) also has worked pretty well for me.
Trying to get some attention at a Rails Girls Berlin workshop
Goodbye
For the Goodbye the essential topics are mostly:
thanks for coming!
next meetup place + time
call for talks
if there’s an after party place, tell them where it is and where to form a group to get going there
ask kindly for help cleaning the space up (stacking chairs, collecting bottles etc.)
thank the speakers once again for their talks
And that’s basically it… but don’t forget – after the meetup is before the next meetup and it’s always a lot less stressful to have things already organized a long time in advance. I try to aim for having the venue and a couple of talks confirmed a month in advance, admittedly I often fail at that.
And that’s also an important takeaway here, nothing is ever perfect and it doesn’t have to be. Don’t worry if you don’t get all of this straight, if you forget something… it happens. I’ve been doing this for a long time and I still forget things but usually everything goes just fine. If I forget something, people remind me or ask. People also know that meetups are organized by volunteers, so they are forgiving and willing to help when something goes wrong.
So, let me know if this helped you or if I forgot to cover something and you have any remaining questions. This marks the end of this little series, so I hope that this helps you get your meetup started or that you got the insight into organizing meetups that your were looking for.
Journeys of a not so young anymore Software Engineer 