Case Study —

Background

Should designers code? I. do. not. care. Should I code? Yes, because I enjoy making things and I enjoy the process of learning and problem solving and typing into dark terminals to impress my friends. And Ruby was one of the first times that this all clicked with me.

Back in the day I couldn’t “get” Actionscript, and as a result Flash. And I still don’t “get” Javascript. I tip-toed around Python one time, and it was fine, but Ruby was different. It just made sense to me more than anything I’d looked at before. The same with Rails. The syntax, the design decisions, the opinions, and the logic — it was the first time things clicked.

So I read a bunch of articles, tutorials, code samples, etc. I got my footing and had some basic understanding, but I never actually built anything.

This Time Is Different

I wanted to change that. So I started fresh, back at square one: registering a domain name. Or course.

After that I ran through Try Ruby a few times until it seemed second nature. I then dug into the Rails Tutorial by Michael Hartl. I read it front to back, then started again from the beginning, this time applying it to actual code and a working project. I can’t say enough about how great this resource is — it got me to the point where I could actually build something. And then I was hooked.

I also heavily relied on the Rails Guide, Rails Casts by Ryan Bates, and Go Rails by Chris Oliver. Each of these is also greatly recommended and I continue to appreciate the way people share knowledge — there is a new beginner every day, and these are invaluable.

The Rough In

I’m a measure twice, cut once kind of person. I’m also a visual thinker, so that’s where I started on this project.

I put together some rough designs that helped me envision the final product. They weren’t perfect, and they aren’t intended to be. But they were enough of a north star helped me stay motivated throughout. Time: 10-15 hours over the course of a few weeks.

I also took some of these directions and put together a static teaser page with a newsletter signup. This is a fairly standard practice that ends up being a very passive way of doing customer research, but at the time it seemed productive. It also put another flag in the ground to keep me moving along.

I then worked on the data model. In my opinion, this is one of the more under-appreciated parts of design. I believe designers should be heavily involved in this part of the process, and data models should be heavily debated and thought through. Many problems later on can be traced back to data model decisions early on. This is design as much as choosing the right interaction. So I took my own advice and worked through the model and learned a lot about Rails ActiveRecord along the way. Time: 10-15 hours over the course of a few weeks.

Next up was to “bootstrap” the Rails app — a term which never made much sense to me. Anyway, this was easy thanks to the the CLI which is pretty well designed. Time: a few hours over the cours of a few nights.

The Build Out

With everything roughed in I was ready to start full development. This was a long process full of fits and starts, dead ends, epiphanies, frustrations, abandonment, reinvigoration, and achievement. In other words, it was software design and development.

I was learning how this app should work as I went, and at the same time learning how to build how the app should work. There were many helpful tutorials and resources (mentioned above) along the way, and after a while I got the app to the 80% point. We all know thats only 20% of the work, but it was still an important milestone. It had a full User account system, full CRUD capabilities, and gave me a pretty solid understanding of how all this stuff works in Rails.

Overall, this took me tens of hours, over the course of almost an entire year. I’d have streaks of clarity and productivity, followed by pits of frustration. There were times I figured I’d never finish, but again, I wanted this time to be different.

So I pushed through. 10% inspiration and 90% perspiration as they say. In the end, I got there. I got the app to the point where it worked, it looked good, and it represented the vision I had at the beginning. Knowing when you cross this threshold, where the product is at a good enough point to “ship” even if its not complete (it never will be) is not a science. Knowing how much to consider part of your v1 (I refuse to say MVP) is all about taste, aided by experience. I believe this skill is something is immensely important but rarely talking about in software design, and it’s something I hope I’ve honed.

I was at that point. Now it was time to put it out there for the world to see. That required a server, so I figured, why not learn server admin while I’m at it.

Deploying

What have I done. I just added months to this project. I should have just used Heroku, and if this was not a “learning experience” I would have (back to knowing when it’s time to ship). But I couldn’t shake the desire to learn how to deploy this thing on a server I set up and managed. So I did just that.

I purchased a server on Digital Ocean for $5, and ran through a tutorial on Go Rails. This went surprisingly smoothly at the beginning. I learned about ssh and Linux distros and package installs and Passenger nginx and Postgres and google searching error messages and got things up and running in about 10 hours or so. I then cloned and pulled the apps git repo to the server and voila, the app was live. This was extremely satisfying.

Until I had to upgrade something on the server for the first time.

But after another few hours of troubleshooting, I got the server back into an operable state and was ready to see what I could do with this site.

On Working Remote

The idea of remote work as a concept interested me more than a list of jobs, so I had the idea to create an magazine of sorts with interviews with remote workers, companies who have distributed teams, and even people who are not on the remote working train.

So I put together a list of people who I’d like to talk to, and sent out a bunch of emails. I got more responses than I expected. I then got nervous: how was I going to find the time to interview all these people? This proved to be a problem, but at the time I just figured I’d start plugging away and interview the first person: Nathaniel Talbott, CTO of Spreedly.

With this interview complete I went about designing and building a page that would present these interviews in an interesting way. This ended up being another pretty substantial project (yes, notice the trend) and took few weeks, a few hours at a time. But I got there.

Final Product

Despite all this, I still needed one thing, remote jobs to list. Duh.

These were fairly easy to find, I emailed companies who were posting jobs on other job boards and offered them some free trial listings (with the idea that when I could grow traffic and exposure I’d begin charging). People rarely turn down free, so I had myself a good set of jobs from some reputable companies.

With the app built and pushed live, some additional content that would make the site notable beyond the job posts, I now felt like I had enough content to make the site worth someones time.

Missed Opportunities

And then 37signals (as they were called at the time) launched We Work Remotely. An evolution of their existing job board, but focused solely on remote jobs.

I mean this happened literally within days of me doing a launch effort. And job boards are a traffic play as much as anything, and it was going to be a slog to go from being maybe one of 3 remote-focused job boards to one of 4 with the main one being the ultra popular child of 37signals.

Despite a pep talk from Jason Fried, it was disappointing. I should’ve launched sooner — which is a lesson I hope to have learned after all this.

Now this ship early thing is something that people always say on their unified-theory-of-everything Medium posts, and to me it’s a concept that gets abused and results in a lot of craft-less junk polluting the software space, but it does have some validity. Now the line is still more art than science, but the lesson I learned is to not let one project turn into 20. Stay focused on the core problem you are trying to solve and get that out into the world as soon as its not a piece of crap. Stay small, do it well, but keep it focused. Have discipline to get it out into the world as soon as possible, and not a second too early or too late.

Takeaways

The end result here is no real catastrophe. This was ultimately a side project for the purpose of learning, and I feel it was wildly successful there. I really did learn a ton. But its still stung to be beaten to the punch, and I’ll remember that the next time I work on something with more serious business implications.

But I now know Rails enough to be dangerous; I know the basics of server admin; I learned a lot about data models in Rails and database management in Postgres; I lived the lesson of waiting too long to launch because you were bitten by scope creep; And after all that all I got was this lousy case study in my portfolio!