A Day in the Life of a Ruby on Rails Developer

A Day in the Life of a Ruby on Rails Developer

Today, we're getting a closer look into what it's like to be a Ruby on Rails developer through a recent interview with Paolo Perrotta. Paolo is a developer, coach, Pluralsight instructor and the author of Programming Machine Learning and …

Author: Pluralsight


Part four of a four-part series about Ruby on Rails.

In the past four installments of our Ruby on Rails series, we’ve looked at the highlights of this programming language, its benefits for developers, and the best courses for learning the technology yourself. Today, we’re getting a closer look into what it’s like to be a Ruby on Rails developer through a recent interview with Paolo Perrotta. Paolo is a developer, coach, Pluralsight instructor and the author of “Programming Machine Learning” and “Metaprogramming Ruby.” He shares how he got into coding, why Ruby is so loved by developers and the unique (and often overlooked) form of scalability it offers.

Tell us a little bit about yourself and what you do.

I’m a developer first and foremost, and these days, I mostly teach development. I coach and mentor developers. I’ve been a developer all of my life so I’ve written a lot of code in many different domains. I pride myself on not necessarily having very deep knowledge, but having borrowed knowledge because I’ve tried a lot of different things. I’m a generalist.

How did you get started in tech development? You mentioned you’ve been doing it your whole life.

When I started coding as a teenager, I did it for fun. That was the only thing we could do. It was the early 80s, and we didn’t really understand what to do with computers. We had no use case for them. People in their 20s likely hear a lot that computers were so underpowered and expensive back then. However, if you could get on a time machine and travel back to the 90s, what would surprise you the most? It’s not that computers were underpowered, but that nobody really knew what to do with them. In a way, they were a solution, looking for a problem.

We just wanted to play computer games, but most of us talked our parents into buying microcomputers by saying, “this is the future.” We played computer games and wrote code, but there was no purpose to it.

Fast forward to the early 2000s: now I’m working as a developer, and I’m loving it. I’m writing Java and my unit tests. Everything was so serious in the early 2000s; we were in the midst of huge software evolution. I eventually found myself out of contract because the company I worked for had financial problems. Suddenly, I had spare time and decided to study something new. Ruby was being hyped up because of the Ruby on Rails framework.

I had heard that the framework was doing things in such a different way from other frameworks. However, I didn’t care about that. What brought the spark back to me was it was just fun. It’s just that goofy, happy feeling of putting stuff on the screen, and for me, at least Ruby does that to you. Every language is optimized for something. The creator of Ruby, Yukihiro Matsumoto, said Ruby isn’t optimized for productivity and performance–it’s optimized for developer happiness.

What do you think prepared you for being a good Ruby on Rails developer? What experience may have helped you with that process?

I don’t think I’m good as a Ruby developer, actually. It sounds a bit weird because Ruby’s such a large part of my career. But I rarely use Ruby as my own language in the workplace. I did a lot of stuff with Ruby in my own spare time. It’s a language that grows on you. It may not look super user-friendly at first, but once you’re over the initial impression, then it does get really friendly.

There are languages that you keep learning about because they have dark corners. You can study JavaScript and keep learning stuff about JavaScript that surprises you, but not necessarily in a good way. Not to diss JavaScript–it’s an awesome language. But with Ruby, you keep finding new things, and these things all go together. It’s like you’re slowly building this big puzzle, piece by piece, and the pieces are consistent. I would say that to become a good Ruby developer, you need not necessarily complete the puzzle. But you need to keep adding these tiny little pieces. And then they add up to something that is more than the sum of its parts.

A lot has been said about Ruby being slow and unscalable. It’s never been a speed demon. However, Ruby scales in a different direction.

It doesn’t necessarily scale as well as other languages when it comes to performance, but it scales when it comes to complexity in a very smooth, beautiful way. When you’re solving a problem in the very beginning, you know very little about the problem, right? That’s a constant in programming. In this solution, you can solve it with Ruby. Then as you keep learning, your system becomes more complex. That’s a direction where Ruby scales very well. There are other languages that are specialized for problems that stay simple or for problems that start off complex, but having a language that scales along that direction is important.

What do you like best about the Ruby ecosystem and the tools surrounding it?

I’m not necessarily a huge fan of Rails. I love that it was so disruptive. It introduced a new way of doing things that was so radically different, and yet it worked. One thing that I don’t like about arrays, in particular, is that they’re so magical, they hide so much of what’s going on. You can sew together a few lines, and boom, you have an application. The downside is that a lot of people who code Rails don’t really know Ruby (the language). That means as soon as you get out of the beaten path, it’s easy to make a mess. It’s so easy to get into a situation where you have a huge bunch of legacy code, the classic big ball of mud.

The point of Rails was to avoid that in the first place. And now you’re back to square zero. For the longest time, Ruby was the place where you made experiments. If you look at the landscape of computing, there is always one language in which people are experimenting and trying different things that look kind of crazy. Some of them are, but some others actually proceeded to be the next big thing, right?

That role was taken on by multiple languages across the US. For example, in the late 90s, it was Java, believe it or not. Today’s Java is seen as the most boring corporate thing. It was, but it used to be very different.

Eventually, Ruby rose to take its place and became the place where people try the weird stuff. And some of that weird stuff we use today.

I remember when it seemed like people were trying to throw Ruby at everything and saying, let’s see if Ruby can do this. What do you think people are using it for primarily today?

It’s kind of settled into the traditional server-side web application space. I love Ruby, and it’s still my favorite daily language. But one thing that Ruby doesn’t do as well as Python, for example, is finding new niches and use cases. Python found new jobs such as machine learning. If you need to write middleware and integrate stuff, small programs for your daily tasks, or even large programs for that, Ruby is still the best language for that.

What are some challenges developers are facing right now in that world?

It’s a bit of a Catch-22 in our job: you need to work on the cutting edge, but once a technology is mature, you have a lot of legacy. So you’re actually writing tomorrow’s legacy. Today, Ruby teams have a lot of legacy code to deal with. Experimenting a lot is going to leave you with a lot of half-baked or half-failed experiments as well. In the Rail space, a lot of people are living with this big Rails application and it can be hard to deal with. Dealing with legacy is the bane of a developer’s life.

Tell us a little bit about the day in the life for a developer in Italy.

I don’t actually write code in Italy. I just live here. I’d already been nomadic for around 10 years before the current events where we just couldn’t travel anymore. I work remotely, and I’m not very connected with the local coding community. I know a lot of people here, but they’re all working all over the world. I see that there is this huge global network, and you create your village by picking the community that resonates with you. Or you just pick the technology that you prefer and then build the village around that. I think that’s really awesome. I feel so privileged.

What advice would you give to new developers starting out?

Honestly, I don’t think they need my advice because they’re probably already on GitHub hacking anyway. That’s definitely what they should be doing. The only advice I can give is this: don’t get obsessed with labels in the job market. You’ll see they’re asking for front-end or full-stack developers. Suddenly, everything is about being a full-stack developer, but there’s a price to pay for that. If you’re a generalist, you can be a full-stack developer. But let’s say you like to tinker with user experience. There’s plenty of value in that, as well. I say, do what you want to do. We tend to cluster computer geeks into one basket, but there are many different levels and interests. Try different things and you’ll think about the job market when it’s time.

When you see something new and shiny that you want to check out, what is your approach to learning about that technology?

I can’t claim to be original in looking at these obscure languages; I’m going for what everybody is excited about, and it usually works. Sometimes it doesn’t stick. I understand that Clojure is amazing, but it didn’t stick for me. I’m always looking for that spark. It happened with Ruby. It might not happen anytime soon again, but I’m looking forward to it. What are you working on right now? Do you have any cool projects you can tell us about?

A friend of mine called me on Discord and invited me out to the pub with a few other buddies. He had this idea of building a virtual artist, which I understand is not an especially original idea these days. However, the concept of generative art, generative adversarial networks, and machine learning are pretty exciting. We are actually writing a pipeline in our spare time to generate art.

We’re looking for something that has a recognizable style and is fully self-sufficient and autonomous. It should just look at stuff on the internet and decide to create something out of it. Our hope is that we will get to the point where some of these works of art actually have some aesthetic value we can perceive.

Thanks so much for joining us today. It’s been a great discussion. Do you have any final words for the audience?

See you on Pluralsight. I’m so glad that so much of what I’m doing today lands on Pluralsight because it’s becoming more and more of a go-to destination for people. I’m very proud to be a part of it.

Some Great Courses for Learning Ruby

If you’d like to learn Ruby or Ruby on Rails, check out these excellent courses:

This is the fourth and final article in our Ruby on Rails series. Check out the full series below:

Our Series on Ruby on Rails:

  1. What Every Developer Should Know About Ruby on Rails
  2. Ruby on Rails Developers: Common Roles, Responsibilities and Salary Expectations
  3. RUBY Playlist: Pluralsight Courses Every RUBY Developer Should Take
  4. A Day in the Life of a Ruby on Rails Developer (this article)


Related tags:

programming   Ruby   RubyonRails  
About the author

Pluralsight is the tech workforce development company that helps teams build better products by knowing more and working better together.

10-day free trial

Sign Up Now