Skip to main content
Juan Villela

Comfort Zone


A few months ago a new client approached me about redesigning their Rails app. It was pretty straightforward; replace Bootstrap with Grid Layout and give the UI a modern look, something I’ve done several times before. But I knew nothing about Rails before this client reached out. So my gut reaction was to say no. But then I thought about what it would mean to take on a challenge like this. I’ve been feeling my work stagnate lately and wanted to branch out into something new. This was a risky move, but ultimately I agreed to do the job.

I work through UpWork where I get rated on performance, which plays a big role in my ability to gain new clients. I’ve had a solid year so far had reached a level where I felt comfortable taking a risk on something new. Now, I wasn’t jumping into this blindly. The client was made aware of my limitations with the framework. I also took a couple courses on Rails and felt comfortable enough in my understanding of its core concepts. Granted, this isn’t the best approach but it gave me the sufficient knowledge to know what I was getting myself into. And although I couldn’t say I was ready to take it head on, I felt competent enough to navigate the code.

But understanding the framework didn’t take the fear away of messing up on something I’ve never touched before. I knew I would hit several bumps along the way. But I decided to push aside that fear and venture into something new.

There’s plenty of resources at my disposal. I need only ask the benevolent Google how to accomplish something with a certain language and there’s bound to be a handful of other developers that have asked the same question already. Which means there’s likely already a solution to my problem. One could even say that venturing into unknown code isn’t all that scary. But it is when my livelihood depends on the quality of my work. It takes a degree of courage. And that’s precisely it. It wasn’t until I stepped out of my comfort zone that understands what I was capable of. And the more I learned, the more encouraged I felt. The more encouraged, the better I worked. And it was this amazing feeling that drove me through this job which brought many rewards.

The client ended up being a team working on the project. Not only was this my first Rails job, but also the first time I’d work with a project manager and lead engineer. It was an entirely new experience for me.

Working independently has its perks; mainly being your own boss and doing things on your own terms. But working with a team thought me a few things I wouldn’t have learned otherwise. Probably the biggest was having my code reviewed by someone else. This was nerve-wracking at first; criticism, in general, can be challenging, let alone when it’s about your work. Nevertheless, I welcomed it. It was tough, but we quickly found our groove. They had a very efficient workflow which took away a lot of the pain of asking how to do certain things. The feedback I got from my work pushed me to work cleaner and more efficiently. And having constant communication helped to clear doubts and uncertainties.

I know that my experience won’t necessarily be the same for others. I’ve had my fair share of potentially good jobs turn sour. But It wasn’t the case this time. It was the first time I’ve stepped out of my comfort zone like this, but I’m glad I did. I’ve come out a better developer. That’s not something I can say often about a job.