Your code is not forever

So death was one of the main themes of RubyConf. Fun right? If you were there, you already know about all the feelings Andy Croll and Chad Fowler made you feel. If you weren't, let me tell you it got a bit weird.

I'm sure we've all experienced the death of code or the other sad task of working in mind-bending legacy magic. Those two situations are sad. Should we all be sad that we chose this fruitless profession? What does that mean for us as developers? It means our work isn't meant to last forever. Your legacy is not your legacy code.

So what actually matters? Croll claimed it was the experience of actually doing your work everyday. Like listening to a good song — it's not about getting to the ending of the song but about the moment you're listening to it. I liked that, although it's probably too philosophical to help on a daily basis.

Fowler had a more practical answer to the problem of old code, just replace it all the time and assume it's going to fail. No more big re-writes. We should be taking our code down and replacing it consistently. All chaos-monkey, all the time — burn it all.

Ruby is getting old. The second we push out our code it's aging. But that doesn't really matter if we accept that constant change and adaptations are a priority and should be part of our working process.

Everybody is into Clojure and Static Typing

I think almost every talk had some mention of Clojure. Aaron Patterson asks Matz to build macros into Ruby every year in the Q&A. Alex Wheeler re-wrote Rack functionally, framing the re-write around stealing ideas from Clojure. So even in the ruby community we have a strong voice advocating for functional programming. Maybe I'm just new at this but I was surprised. Also happy I picked up a Clojure textbook a few months ago.

Static Typing stood out as another big venue for exploration. Matz seemed pretty excited about it and he's the go to source (if anyone is) for what will be coming to ruby next. Crystal? I'll just leave that there.

Rails does a lot more than I thought

There were a few different talks centered around thread safety and autoloading. Apparently GIL (the global interpreter lock) is only there to protect internal methods implemented in C. So if you were thinking about using Ruby MRI/CRuby (the only implementation of Ruby with GIL) to get GIL benefits think again. Your ruby method defined threads aren't safe. There were some really great solutions offered to get around problems with both topics. After all this ingenious innovation, I realized that Rails gives us both thread safety and autoloading for free. Something to keep in mind when choosing your next project's tech stack.

Tests are software too

I've seen many flaky tests make their way out into the world. Would you be ok if your code were failing in production 30% of the time? No? Ok, me either. So why should we let our tests fail here and there? If we ignore failures we're putting ourselves in the line of danger. Flaky tests are just a problem waiting to be solved. All we need is a process for tackling them (more to come on this in another post). Kind of inspiring right?

What now?

Anyways, if you learned nothing at all yet from my memories of RubyConf let me summarize it for you. TL;DR apparently all you have to do to be a 10X software engineer these days is learn Clojure, write good tests, and throw your code in the trash every few weeks. Oh and maybe build static typing into Ruby if you're feeling adventurous.