Getting a job using any certain technology is kind of a chicken-and-egg problem. You can’t get a job using Ruby on Rails until you have experience with Rails, but then you can’t get Rails experience until you have a job using it. Frustrating.

Is there a way around the catch-22? There is.

But first, here’s what not to do

One popular piece of advice when you’re trying to break into new skills is to work for other people for free. I don’t think this is the absolute worst idea in the world, but it does have problems. Here are some:

It sets a precedent with your client that your work is worth isn’t worth much. Not every client has worked with a software engineer before, and the only notion they have of market rates might be their experience with you. So if you charge a client $200/hr, $20/hr or $0/hr, that very well might be what gets stuck in his or her head as to the value of your work. It is of course possible to tell the client up front that this kind of work normally goes for a three-figure rate and that you won’t be working for free forever. I think it’s probably likely, though, that the client will get attached to whatever rate you charge him or her initially. That’s been my experience.

Not every client has worked with a software engineer before, and the only notion they have of market rates might be their experience with you. So if you charge a client $200/hr, $20/hr or $0/hr, that very well might be what gets stuck in his or her head as to the value of your work. It is of course possible to tell the client up front that this kind of work normally goes for a three-figure rate and that you won’t be working for free forever. I think it’s probably likely, though, that the client will get attached to whatever rate you charge him or her initially. That’s been my experience. It’s kind of tricky to limit project scope. When you’re working with a client for money, you work however many hours they can pay you for. When you’re not requiring the client to pay you anything, there’s kind of a battle between “I can’t just work an unlimited amount of time for free” and “I don’t want to be a dick to my client.” That’s the tug-of-war that has always happened in my head whenever I’ve done free work in the past. Again, you can attempt to somehow limit scope in the beginning, but I don’t know that any mechanism you might set up would be nearly as effective as the “that would cost more actual money” mechanism.

When you’re working with a client for money, you work however many hours they can pay you for. When you’re not requiring the client to pay you anything, there’s kind of a battle between “I can’t just work an unlimited amount of time for free” and “I don’t want to be a dick to my client.” That’s the tug-of-war that has always happened in my head whenever I’ve done free work in the past. Again, you can attempt to somehow limit scope in the beginning, but I don’t know that any mechanism you might set up would be nearly as effective as the “that would cost more actual money” mechanism. You’ll probably get shitty clients. This one probably doesn’t need much explaining, but it’s a phenomenon that not everyone seems to be aware of. Penny-pinching clients tend also to be the most painful to work with.

The simple solution

My solution is not very complicated: instead of working for other people for free, work for yourself for free. This approach has the following benefits:

You own what you create, and can show off the source code freely if desired

You get to pick all the technologies with which you work

You call the shots with regard to features, timelines, workflows, etc.

If you build a useful product, you might even be able to earn some money off of it

There are also drawbacks, like the fact that you don’t get the “real world” experience of interacting with clients. To me the trade-off is worth it.

I’ve used this approach multiple times with success. Examples:

Throughout the mid-1990s I built my own websites using HTML. Later, around 2000, my dad hired me to build his business’s website.

In 2005 I started tinkering with Linux and PHP. Later that same year I got a job using Linux, PHP, and other technologies I already had experience with like HTML and CSS.

In 2011 I started my first Ruby on Rails project. I built a product that did scheduling for hair salons. Later that year I got my first minor freelance Rails gig, and then in 2013 I was hired at a full-time (contract-to-hire) job doing Rails. Now Rails is all I do.

In fall 2013 I started building a side project using Ruby on Rails and AngularJS. Just a couple months later I got a freelance gig where I had the freedom to choose AngularJS as the JavaScript framework. Then, in early 2014, I did several mentorship engagements where it was my job to teach AngularJS. I was seen as not only competent but expert.

I’ve used this same approach to get paid to teach guitar lessons, do rudimentary SEO, and manage a Google AdWords campaign. The bar for “competent enough to be paid” is not all that high.

How to come up with something to work on

It might be easy or hard for you to come up with an idea for a project to work on. My advice would be to find a problem that real people actually have, and, crucially, actually want a solution for. Two products I’ve built that have gotten a certain amount of traction include scheduling software for hair salons and a tool for office workers to coordinate their lunch outings. Here are some ideas of untested viability that you’re welcome to use:

Storage facility management software

Logistics software for transportation companies

A CRM specifically for credit card processors

I’m not suggesting that you set out to build a software company, but if you’re going to pour time into a side project, might as well make it a side project that has a chance of earning some money. If you are interested in building a software company, though, you might want to check out the Micro-ISV community.