RUG::B

These topics are super intimidating but they don't need to be. Let's take a look at how Ruby "understands" the code you write and the core of how Ruby is run.

This talk is pretty non-technical, absolutely subjective, and questionably practical. I'll tell you literally about reviewing the code.

All of a sudden, I get tons of pull-requests to review. And as we follow the open-source (internally) model of contribution, people are coming from different teams and have their agenda. I just wanted to keep a piece of mind and at the same time, not be an asshole that holds the gate all the time.

I gave it internally and on Ruby Unconf 2019. And I will be happy to do it again for you.

When I joined Liefery, my current company, the engineering team was remote-friendly. What do I understand here by remote-friendly? People were allowed to work remotely every now and then, but the state of working remotely was something exceptional. This often led to inefficient communication as we were excluding remote folks, postponed meetings, lacked tools and best practices.

It took us about a year to transition to a remote-first team. Remote-first as in: all the processes are optimised for remote work and that's the default way. In this talk I'll tell a story of how this change happened at Liefery, and highlight take-aways that can help your team take the same step.

Come to the presentation and hear me argue that fully co-located teams work, and fully remote teams work, but remote-friendly don't.