The concept behind the Swift Alps

The Swift Alps is an experimental conference, as stated in the website. The question is: why?

What is the reason to experiment in the conference space? My goal for this post is to clarify everything.


There are many reasons to try something new in the conference space, some of these reasons are problems speakers and attendees are facing
at every event which are:

Back to the routine

After the conference has ended, it is very common to get back to the office, fire the code editor, try some new stuff and… just forget about it after a week.
All the new coolness just learned during the last event has been completely lost. Sometimes it could also happen that with a co-worker we are able to try something new for longer, but it’s usually only a single idea that gets adopted, forgetting the others N things learned during the conference. Experimenting and failing is part of our daily job, sometimes we have zero time, sometimes we have a little bit more, but experimenting is the first step for adoption and during regular confs it’s hard to do it.


We usually collaborate only with our co-workers and rarely, with people we don’t know personally over an Open Source project, but still, most of the time is just us and the code. In a classic conference the code on the screen seems interesting in a first place, but right after the talk is over, it’s unlikely to remember it for further usage. Again, the coolness of the conference has been pretty much forgotten.


Socializing is an important part of a conference, for some people is the main reason to go to a conference, but the chances to socialize are limited to breaks and after-party.
I never saw anybody starting a random-chat while somebody else was on stage presenting something, this is generally rude. What I also never saw is a couple of attendees socializing in front of a screen talking about a piece of code, which sounds strange, considering we spend 6–8 hours of our daily job time in front of a screen.


Learning is a complicated process, we go trough many steps while learning something. The current conference model makes learning hard, listening to somebody on a stage
is a small step, because the result is usually resume like “I just got aware of something cool”, leaving in front a lot of steps, but… how do we learn something? Usually failing, while experimenting.
Failure is part of our daily routine, we: code, fail, learn, fix, do it again. From other attendees we can learn a lot, most of the times we work with other people which we already know, sharing failures and learning together. How many times we work with an absolute stranger who can teach us something new and cool or, on opposite, which we can teach something new? Rarely.

The Alps

This event is about community. Period. The major goal is to experiment with the Swift programming language with all the other attendees, trying to learn, while failing, as much as possible.
Ash Furrow wrote two amazing pieces about Normalizing Struggle and later about Empathetic Civilization, which are two great readings for somebody interested in joining us for this event. Both these articles are summarizing what The Swift Alps wants to tackle and what is going to be as event.

The Format

The format has been developed by many people, collaborating in a single document, trying to get the best of other formats like hackathons and un-conferences. What is the results?
As you might have seen in the official website, there are already some mentors (not speakers!) listed. These mentors are going to be an important part of the event, but the most important one is going to be the attendee — you!


The introduction is going to be a 5–7 minutes presentation from the mentors about a topic to run experiments (examples: cross-platform Swift, server side Swift, testing, security, extensions, asynchronous programming, etc…), every attendee can then understand what the group is about and later join it for experiments.


Every mentor is going to have a group of people, experimenting on the topic they prepared, maybe with a final goal in mind (examples: sample web app, Android app in Swift, fix of tedious bug in a widely used OS library, Swift Evolution Proposal, etc…), but they might also be totally open (bring your own bug). All the attendees are going to work with other people they probably never worked with, exchanging knowledge while normalizing the struggle. We’ll shake things up regularly and have 3–4 sessions with eachother. What you will bring back home goes far beyond what you bring back home from a regular conference.


Hacking is important, broadcasting knowledge even more. One mentor is going to be dedicated to help attendees interested in presenting what they have done during the day to all the other attendees in a fire-talk, a 5 minutes technical presentation about a topic, which are going to take place at the end of day (day 1 and 2).


The day after the conference, we will organize social events, considering the location some options are going to likely be: hiking, culture visits, wine tasting, SPA, etc.. all these social events are going to be used to talk about what just learned and how the future of Swift looks like.


The format is basically the following things combined: best of confs + best of un-confs + best of hackatons = The Swift Alps.


We already have dates, which means we also have an amazing venue! On the official website there’s a link to reserve tickets. We are also working hard to give an extra option for transportation, which is going to be cheaper than public transportation, from the closest major airport: Geneva. We believe that also the journey from the airport to the town where the event will take place has to be part of the experience of the Alps.

For accommodation we have the plan to open a dedicated forum to discuss potential solutions, also to encourage sharing a chalet/apartment with other attendees whenever is possible.

We will release all the final details as soon as possible, with the complete list of mentors, so stay tuned, we are working hard for this event!

Nore: a big thanks to Ash Furrow for reviewing this and also for making the awesome graphics!