Code n' Stuff

Last August, I had the amazing opportunity to give my first real technical presentation at NYC.rb! (Here’s a link to its event page). I learnt a lot, found a way to give back to the Ruby community, and had a great time.

This whole adventure started when I was exploring using the repository pattern in Ruby - a language whose ecosystem is very much centered around Rails (which does not use the repository pattern). So to aid further understanding of this pattern, I used a lesser-known framework, Hanami, to show how it compares with Rails' ActiveRecord. While there are other ways to force the repository pattern on Rails such as ROM, after reading a blog post by Piotr Solnica, I guess thoughts about the state of the Ruby ecosystem had been lingering in my mind. What is Ruby without Rails? After all, if someone is a Ruby developer, chances are that they are working in Rails. But if a better Rails alternative comes out then isn’t written in Ruby, what is going to happen to the Ruby language? Is Ruby’s future too dependent on Rails? With these thoughts in mind, I thought it would be fun and educational to learn a new framework. And what better way to solidify learning something new then to give a technical talk?

From experience, I’ve found explaining a concept to someone is a great way to test if you have truly understood what you had been learning. By explaining it to someone else, it forces your perspective on the concept to change - from “just making it work” to truly understanding why it works that way. It changes your priority. It’s easy to copy + paste that piece of code from Stack Overflow to just make your app work but after all, I’m learning to be a full-stack developer, not a full-stack-overflow developer. This technical talk was my way of challenging myself to pause for a moment and reflect on why does Rails use ActiveRecord and what are some alternatives to this architectural pattern? In the end, not only would I learn something but I’ll also be sharing knowledge. So it is a win/win on both sides.

The experience of giving a talk really was a great learning experience. I felt I understood the concepts I was talking about a lot deeper than simply just knowing how to implement them. I became more aware of the different kinds of knowledge that exist. Implementing something is different from understanding it. But to implement something well, requires you to really understand what is going on. It gives you choice. When you understand something, you’ll be able to choose the right tool for the job and make an informed decision. This is an important skill to have as a developer when you are faced with many different kinds of applications that might not fit the Rails model well.

Another benefit in giving a technical presentation is that it helps contribute to the community. I love the Ruby community. It was incredibly friendly when I first started learning and I always felt welcome at meetups no matter my skill level. I learnt so much from more experienced developers. Giving a talk is in a way giving back and hopefully somebody does learn something new in turn.

Finally, while this does not directly relate to programming, giving this presentation helped me gain confidence. I was very nervous initially and struggled a lot with imposter syndrome. Could someone really learn something from me? As much as I felt this talk was a challenge to myself to really understand the tools I was working with, it was also a personal challenge. Simply, could I do it? It’s tough when it is your first time getting up in front of an audience of developers, live coding, and then taking questions at the end. It really tests both your technical knowledge and your ability to keep calm under pressure (especially if you had never done something like this before). But all in all, it helped me to be more confident in myself and my efforts. It’s something that I would definitely love to do again.

So to sum up:
1) Giving a presentation helps you learn
2) It gives back to the community
3) It helps build confidence
4) It’s a lot of fun!