The history and vision of the Develer conferences

TL;DR

The communities of various languages like Rust and Go do their best to maintain a respectful atmosphere in various meeting places, both physical and virtual.

Unfortunately, however, sometimes people don’t behave with the same level of respect when they come into contact with people from other communities.

Develer conferences are intersectional spaces for multiple communities. As a meta-community, we have the same goal: to create an environment that respects everyone’s ideas.

We don’t have a secret for doing it, but we’ve found out through experience that a little humility and a great desire to share passions have helped to create this atmosphere in Develer.

We’d like to have the same atmosphere within the conferences, primarily when different languages ​​and technologies meet. Intersectionality gives us the chance to have a dialogue about things that are fundamentally different which can change our way of thinking.

This post is a bit complicated; it wants to combine many connected aspects into a single narrative. The flow of speech will look something like this:

Triggering event

Friday, lunchtime, it’s time to get away from work and see what’s going on in the world. In short, Twitter, since half of the real world is in lockdown.

There’s an interesting thread, it talks about a particular scheduling problem, how it was resolved in Go and how, according to the author, it’s difficult to apply a similar solution in Rust.

As a conference organizer, I’m interested. I like the idea of ​​talking about an evolved runtime like Go’s which has thousands of man hours invested and tested on a global scale. Even at a Rust conference. So we try to invite the author of the thread to explain his opinion further.

But something unexpected happens: for this series of messages, the author was flooded with comments (including hostile ones, unfortunately); comments of principle and not of substance, or even personal attacks, and then he wrote that, no, he didn’t want to face that same fate again.

Who actually wants to receive comments without rhyme or reason on a random thing that they like and that a random person in the world can freely dislike? There’s a difference between “Shut up, tofu sucks!” and “I don’t like tofu”. I’m taking tofu as an example to make you understand how easy it is to fall into the trap. The spread of unpleasant communication doesn’t change its nature.

This made me think about the reality of the people I talk to about technical topics: with them I can share opinions of any kind about any topic without devolving into meaningless arguments while always ending up more enriched after the exchange. What’s the secret to having a community with this spirit?

Analysis of the past

Can a single story describe the spirit with which technology and work are experienced by so many people? I don’t know, but I can try.

Years ago, Develer made a big bet on Python. In those years, the Italian Python developers were few, we all knew each other by name, and we physically found ourselves in a room to give life to what would later become the Italian Python Association. In the beginning, the company would stop during the PyCon period because many employees were volunteers during the event and others were attendees. And the clients accepted this reality (I don’t know how willingly they accepted it :P, but sometimes they were also in the meetings). One client in particular, Comelz, confirmed a few years ago that they shared the vision that the training and passion of developers are fundamental not only for the health of a company, but also for the success of a good product. They did so by acquiring a majority stake in Develer and giving us a huge responsibility for its products.

C/C++, Python, and then Go… Develer has always had a very pragmatic approach in technological choices: trying to use the right tool for each job without exaggerating the number of languages ​​or technologies used and always looking for a good compromise.

But there’s a problem: a company’s technology stack can be renewed every few years, but in the meantime, how can you hold 20, then 30, then 50 passionate developers back from proposing the use of technologies that they appreciate and consider most suitable?

The first way is to give them space to talk about it together. Sharing your knowledge is both a way to … share it, and to make sure that you have everything clear enough in your head to be able to talk about it and answer questions. From this habit (which has always accompanied every team), first the workshops (now TechLabs), and then the other Develer conferences emerged. That’s how Go joined our company: first out of a widespread interest, and then someone became enough of an expert to be able to talk about it (… the CTO) and to do some theme nights, and then Go became a widespread and “sellable” skill.

Reflection

One aspect that’s always distinguished the culture of developers in Develer is the awareness of not being able to be experts in everything, but maybe experts in something, sure. Everyone tends to create in-depth expertise about their passions and therefore becomes a point of reference for questions on this topic or that one. That same person who is a reference for questions about Go can ask others for Python advice. And with the explosion of (damn interesting) available technologies, everyone knows what it means to be beginners in something.

With this culture of continuous training, we began organizing conferences on languages ​​or technologies that were not yet widespread in Italy. As in the past, the topics of the internal workshops (or ones open to friends) emerged naturally from the interests of the Develerians. Even today we try to move in the same way with the conferences: we look for interesting uses, insights, and/or innovative perspectives that can help us think more openly.

In fact, everyone has their preferences, their languages, ​​and their favorite libraries without being arrogant. Quite the opposite, it’s normal to appreciate a part of something and believe that other parts could be improved. It’s normal to appreciate the idiomatic use of concurrency in Go and the quality of its standard library, and then complain about the absence (for now) of generic C++-style programming or the ease with which it’s possible to overcome the lack of introspection in Rust with macros (or the opposite of all of this). This positive dialogue leads to people trying to take the best out of every language or technology and trying to bring it to where it’s missed.

Actions for the future

With this practice of cross-pollination, we’ve started various conferences, first QtDay, then GoLab, and RustLab (and LinuxLab ☹️). In these conferences, we try to bring light to both what works and what could be better, because only in this way can things improve. It’s useless to tell ourselves that everything is fine if it’s not true or if we’ve settled on a sub-optimal solution. Sometimes a fresh pair of eyes is all it takes to get out of a rut and find new goodies. On the one hand, however, the ability to give constructive criticism is needed, and the humility of knowing how to listen to said criticism is on the other.

An old Italian scientific TV program (Quark) taught us from an early age that knowledge taught with passion is able to enrich even people who cannot understand every single detail; in the end anyone will know at least that 1) they exist 2) what they are called 3 ) whom to ask.

This is what we ask of all the speakers and participants of our conferences: to arrive with an open mind to discover what a colleague who does a different job is passionate about, perhaps in a different place in the world.

We’d like every person to feel free to express their opinions. We’d like to create a place where everyone can express themselves trying not to offend anyone and assume that others do the same. Even when we leave “our” community and look out into our neighbors’.

And so I’ll ask the author of the thread again if he wants to come and tell us his story and I’ll let you know how it turned out.