Just learn Rails
17 May 2015
Obligatory YoC update: Still going strong, 21 days in a row!
The only real city I have lived in is San Francisco. I assume that in other cities, like New York and Los Angeles, people bring up topics relevant to industries popular there. So I would imagine that in New York, a person could overhear something about: banking, stock trading, fashion, and expensive brunches. While in Los Angeles, you might wander by people having conversations pertaining to: making movies and working at the Cheesecake Factory. I have come to this conclusion because everyone in San Francisco talks about writing software.
I personally love hearing conversations about software as often as I do (I did move to San Francisco for the purpose of writing it). One theme that seems to pop up often is how people can get into writing software for themselves. This is great, more people in the space means more ideas and more innovation. However, some people seem to be under the impression that breaking into software development (specifically web development) is as simple as “just learning Rails”. I hope to explain why that mentality is a little naive.
So what’s the problem with just learning Ruby on Rails? You might be able to pick up software development through learning a framework and even get a job that will pay you real money. However, I sincerely doubt that it will be a pleasant experience for long. Frameworks are a single tool a person can use to correctly and efficiently do their job.
I would wager that everyone is familiar with the type of work that a carpenter might do, but just for laughs, I’ll give you an example. A carpenter could be contracted to build a wooden table and chairs for a client. He would shape the wood, sand, treat, stain and polish it until the dining set was made. I highly doubt he would be able to do all that with just a single tool. Can you imagine the quality of his product if he only used a chisel? This is a bit of a stretch but I feel it portrays the point I am trying to make. Artisans need multiple tools to do their jobs effectively and efficiently (fyi: if you don’t call yourself a software artisan then you are missing a great branding opportunity).
In the same way that a chisel is not enough for the carpenter, a framework is not enough for our software artisan. The beauty of frameworks like Ruby on Rails is that they can get you into making a product quickly. But, as soon as you hit any kind of interesting problems, you’ll have to rely on something else. It might even be something that your framework has abstracted from you and discouraged you from learning for yourself.
For instance, Rails ships with a custom ORM: ActiveRecord. This reasonably straight forward library makes interacting with your database simple enough to start persisting objects. Great! What happens when you start persisting large amount of objects? What happens when the relationships that you have created between these objects start to cause performance losses? Your users get mad. Not great. They get so mad they don’t even know why they are using your product and they bounce. To remedy this problem, you would have to tweak your database indexes in a way that speeds up your queries for you. You’d have to know how a relational database works, how indexes work and when to use the proper ones. If you would be using postgres, it would be imperative that you understand what explain analyze can tell you. As you traverse down this path of improving your product you will be outside of the framework and thus without your only tool.
While this is just one example, I think it makes my point relatively well. We could spend page after page of other examples not given to you by your framework: JavaScript, Redis, Memcache, CSS, Git, a variety of Linux commands dealing with debugging and server maintenance, etc. And even after all of that, after you learn everything about those technologies and can make web software that scales, there are other aspects of software development. Like being on a team that either does agile, waterfall or quick stream methodology. Or how to deal with merge conflicts on a complex system, architectural design decisions, 2 spaces vs 4 (spoiler: its always 2).
The point of this post is not to discourage, I want to simply educate. Learning new tools and technologies is important and a ton of a fun! Just make sure that when you have to get our your toolbox you have more than just a chisel in there. Challenge yourselves to look outside the framework. Figure out what your frameworks are doing for you and learn why someone built it to do those things. Understanding the underlying technologies a framework utilizes is key to your success and to the community’s.
I look forward to seeing what all you software artisans build.