Web Developers Need to Know JavaScript

or at the very least, jQuery. The web is a fast moving target and is constantly being pushed forward. Most websites have some type of dynamic component about them: shopping cart, blog feeds, content that magically appear/reappear when you click on a link. What makes all that happen? JavaScript.

Rails developers are notorious for their hatred of JavaScript. That’s how sub-languages like CoffeeScript emerge. With Ruby, we’re very spoiled. Semicolons, curly brackets, and function names are either nonexistent or minimal. A lot of new developers turn to Ruby as their first programming language, so seeing something like JavaScript is terrifying. As much as we all hate it, you will undoubtedly need to know it. And guess what? It’s actually not that bad.

jQuery is an amazing library. Chances are, the app you’re going to be working on is using jQuery in some form. It gets rid of all the clutter that is JavaScript. It has a steeper learning curve than Ruby, at least at first. But once you can get through the brackets and semicolons, it actually starts to make a lot of sense. The structure of the language will begin to seem logical and, dare I say, you will begin to like having all the parenthesis’ and curly brackets. I’ve even gotten to the point where my Rails apps will have the optional parenthesis’ for method parameters. When I pass in an argument? It’s in the parenthesis.

This is going to be controversial, especially coming from a Rails developer, but avoid CoffeeScript at all costs. It does some things well, but white-spaced languages are evil (looking at you too, Haml). Once you play around with jQuery for a few weeks, it’ll come together. You will enjoy being able to bring dynamicism to your application, even if it is just manipulating the DOM. I consider it more of a procedural type of language. It can be a pain trying to cover every single thing that needs to happen when you’re calling a “`click“` event, but once you figure it out, it’s amazing to see the magic happen in the browser.

Moral of the story:

  • Learn JavaScript/jQuery. You’re not a (full stack) web developer if you don’t know it.
  • Avoid CoffeeScript. Dumbing languages down is not the answer. And, do you really want to go through another preprocessor?
  • Stick with it. It’s intimidating at first and takes a little longer to learn, but once you know it, you’ll see the light at the end of the tunnel.

Not Everyone Has to Know How to Code

In the past few days, I’ve had the privilege of teaching others what I’ve learned so far in Ruby on Rails. I’ve given some folks my Craigslist Clone course for free to get a peer review of what people think. Some are good…some were bad. Constructive criticism is fantastic and welcomed. However, after hearing some complaints, I’m now starting to really believe what I’ve heard from many others: some people are not meant to be developers/programmers.

One of the criticisms I received was that I didn’t explain how I pulled up the search bar when I searched for files. Part of being a developer is learning how to learn. Conducting research is an enormous part of development/engineering/programming. Most folks would simply open up Google and conduct a 2 minute search on how to use their chosen text editor. I was literally told that I shouldn’t expect people to be masters of “Google-fu.”

Another one was that I wasn’t going over what a database schema was or how it all relates to the application. Some folks were looking for Computer Science 101, which can’t be covered in a 4 hour course on how to build an application. I think some people have the misconception that they’re going to receive the equivalent of a semester’s worth of a computer science class, which just isn’t the case. Most developers, especially Ruby/Rails developers, taught themselves how to code.

Learning how to program is a long, treacherous uphill battle that can never be won. Some of us just aren’t prepared to go through that journey, nor will we enjoy it. Some of us are. If you’ve decided that you want to teach yourself how to code, be prepared. You will experience frustration, loss of hope, and the will to continue. However, for those of us who are able to push through those experiences, there is a light at the end of the tunnel. The euphoria of getting something to work or finally fixing that bug makes it all worth it. It takes a special person to want to go through that process over and over and over again.

So, you have to ask yourself, are you really sure you want to learn how to code?

REST API is Not Simple…

If you’re working as a professional developer, you’ll more than likely be (at the very least) consuming an API. With everything turning to the web, having an API to let outside applications interact with yours (or vice versa) has become a very hot trend. One concept that is really taking the lead is RESTful APIs. I won’t get into the details, but essentially it provides a URL that can be called to do certain things in an application.

Conceptually, it’s easy. A web app like Twitter has an API that you can you use to post your tweets without ever having to log into Twitter. You just need your credentials (ex: username/password), get a few extra things to send along with your request, and you’re good! Well…not really. In practice, it’s a huge pain in the *ss.

There are a million different ways people implement APIs for their applications, so no one application is the same. Also, a simple username/password may not be enough. Sometimes you’ll have to go to the “developer” page of the application. Sometimes that page requires you to sign up (and if the username you use for the regular application is already taken…well, you’ll need to set up a new one). Sometimes, you’ll need 2..5 different “tokens.” Oh, guess what? Those tokens are only valid for 20 days, so you’ll have to generate a new one by logging in to the application again which kind of defeats the purpose of the API.

So if everyone is implementing an API for their applications, why can it be so hard? I have a theory…one that comes directly from my own experience. It really boils down to one person: the developer. They’re the ones building it, and, you guessed it, they’re the ones documenting it. I hate to admit it, but as a developer, I love building things. What’s the thing I hate most? Documenting them.

I think there in lies the problem with APIs. Not so much the technical capabilities, but the documentation that goes along with it. Unless you’re told what to do with the API, you have no idea how to actually use it. The biggest, most well respected companies in the world have some of the worst documentation for their applications. Even if they do, it’s extremely hard to find. And who’s the one to blame? The developer :).

My recommendation to all the development teams out there: hire a documentation specialist!

Heroku: Missing secret_token and secret_key_base for ‘production’

If you’ve been following good conventions when pushing your Rails application out to Heroku, you’ll know that you’re not supposed to push your secrets.yml file to your repo. As such, when you push your code to Heroku, the file won’t be there either. Heroku will try looking for this file, and when it doesn’t find it, it throws this error message:

“Missing secret_token and secret_key_base for ‘production’ environment, set these values in config/secrets.yml”

After spending hours online figuring out how to fix this, there was only one easy answer. You could rely on a few gems out there (Figaro being the biggest one), but you know my philosophy: be a minimalist when you can.

Don’t worry about the secret_token. I think the newer Rails versions deprecated the secret_token.rb file, so you won’t find that if your Rails app is new. To fix the issue, simply add this one line to your production.rb file:

config.secret_key_base = ENV[“SECRET_KEY_BASE”]

This will automagically create a token and assign it to your secret_key_base. Push to Heroku and you’re all set.

Easy as pie.

Best Cities for Ruby on Rails Jobs

Most of us learning how to program are doing it because we want a job. Now, if you’re looking to be an entrepreneur and are learning to program to start your own startup, I still think you should get a job first. I’ve said it before: there is no better way to learn how to code than by getting paid to learn from senior level developers. How do you do that? By landing a full-time gig.

I’ve been keeping an eye on the market to see what the Ruby on Rails job trends are. If you’re looking to become a junior level developer, your chances of getting a job are exponentially higher in a bigger market. It took me a year to get mine because I’m in the Twin Cities. A friend of a friend spent 3 months learning Rails when he landed his, and I’m absolutely convinced it’s because he’s based out of Los Angeles. After desperately looking for jobs for months before (thankfully) getting my current job, here are the cities that I’ve found to have the most Ruby on Rails positions.

**Disclaimer: this is strictly based on me scouring Indeed, Dice, and StackOverflow Careers and seeing the amount of jobs. I didn’t use any sort of advanced algorithm to come up with my findings.

  • San Fransico – Bay Area
    No surprise here. With a new startup seemingly being created every minute, a lot of them turn to Ruby on Rails. That’s how Twitter and a lot of other now-successful companies got started.
  • Los Angeles
    Another huge city in California. In a place full of celebrities and Hollywood wannabes, I’m surprised at the amount of tech jobs in Los Angeles. You don’t often hear about too many companies whose headquarters are here, but there definitely are a lot of job postings.
  • New York
    I love New York, especially the New York City area. I’ve only been there once, but if I was a billionaire (not millionaire, wouldn’t be able to afford it), I’d live here. In a world of stock traders and financial advisors, I am a little shocked that New York has one of the biggest markets for Ruby on Rails developers. I did a triple-take and thought about uprooting my family to move here when I was looking for a job. Thankfully, I found my current one and have a much lower cost of living.
  • Boston
    Facebook, anyone? Boston, along with most of that northeast region, has a strong tech scene. I think all the wannabe Mark Zuckerberg ivy league students are the culprits. There are a ton of startups trying to be the next #{insert startup here}. A lot of jobs out here, if you can handle the crazy amounts of snow they’ve been getting these past few winters.
  • Denver
    Two of the most highly regarded coding bootcamps reside here: Turing and Galvanize. It’s no secret that Denver has become a hotbed for technology, especially web development. We were also considering moving here as well. It has well balanced seasons, never gets too hot nor too cold, isn’t overpopulated, and has a progressive community. A lot of openings here go unfilled.
  • Washington D.C., North Carolina, Atlanta, Austin
    The rest here are in dire need of Rails developers. They’re at that sweet spot where there is an emerging tech market, but they don’t have the supply.

Which city is best depends on where you’re at in your career. If you’re looking to land a junior developer role, you’ll probably want to move to a bigger market like San Francisco or New York. Those places will have all the senior level talent and are more likely able to afford taking a risk on new learners. If you’ve got a few years under your belt and are at an intermediate level, a smaller market might benefit you more. There’s a ton of demand but not enough people to fill the positions. Someone with 3-4 years of experience will look like gold and you’ll definitely have your pickings on who to join. If you’re a senior level developer to knows how to architect an application, forget all of these locations! Find a job where you can work remote!

There you have it. My opinion on which locations have the most amount of Rails positions. If you’re in a small town where there isn’t a tech scene, moving might be a good option. Being around fellow developers and having a community will definitely give you an advantage as far as your learning and your job opporutnities.

Learning and Using Git

Although most tutorials will have you use Git for version control, they can’t possibly go into as much detail as you’d like. Before last week, my Git knowledge was this: git add, git commit, git push. Github has taken the lead in being the repository (repo) of choice for most people/companies. It’s what we use at my current gig. If you’re just starting out and learning how to program, chances are, you aren’t working with a whole lot of people…if any at all. So you haven’t had the opportunity to use Git to its fullest potential.

I’ll be honest, I felt like a complete idiot when I first started pushing code to production. My worst nightmare: pushing code to the main code base and breaking everything. That or accidentally deleting the entire repo. I’ve heard of many SQL commands that omit just a few words or added some accidentally and taking down entire applications worldwide. I definitely didn’t want to do that. But when my manager asked me if I knew how to create a branch or make sure how to get the latest changes that people have committed, I had no clue. So hopefully this will help anyone who’s reading. Here are a few commands I use often and my general workflow with Git:

  • git checkout -b <name> 
    Example: git checkout -b fix-scrolling-bug
    Before working on any issue/feature/bug, you’ll want to create a branch. Some teams use branching differently, but generally, you’d have a branch for the one specific piece of work you’re doing. This helps keeps things concise and will help collaborators understand what your branch is trying to do. So try to name it so people will know what the code is doing. Or, simply put the issue number on it (more on that in a later post). If you’re just working on minor bugs and enhancements, sometimes it might make more sense to have a generic branch that you can push to that you’ll use all the time. More than likely, you’ll never want to be directly on the master branch.
  • git status
    This let’s you see what your current status is. If you’ve made any modifications to your code and it differs from the repo, you can see what files have changed. You can also see what you’ve added to be committed. So depending on when you run this command, you’ll either see red (modified files that haven’t been added) or green (modified files that have been). I like running this command before I add and after just to make sure I’m committing what I want.
  • git diff or git diff <path> 
    Example: git diff app/controllers/users_controller.rb
    I like using this when I’m not quite exactly sure what I’ve changed, especially if I’ve touched many different files. Almost all the time, I’ll forget what I’ve done, so I’ll want to compare my files to what’s in the repo. If I only want to see the changes for a specific file, I can add the file path to the end of the command. I use this frequently throughout my development. I’ll usually use this right after I do a git pull too (mentioned below).
  • git pull origin master
    This will pull whatever changes have been committed by others in the master branch. It’ll sync up your code so that when you’re ready to push to the repo, you’ll have the most up to date code. This is an important step because anytime you push your code, you want to make sure you have all the changes up to that point. It’ll make merging your code to the master branch a lot easier. Plus, you can take a look at whether or not someone has edited code where you’re doing your work. So if you changed something and then someone else changed that exact same line, you’ll have conflicts that you’ll need to resolve, which basically means you’ll need to either fix more of your code or talk to that other person to see who’s code remains. Important command here.
  • git add
    Basic command. Prepare the files you’ve changed to be committed. Make sure you do this before you do a commit or a push.
  • git commit -m “<your message here>” 
    Example: git commit -m “fixing javascript for scrolling bug”

    You’ll almost always want to add a message to your commit. It’s normally just what you’ve fixed. Don’t be too descriptive, just make it a one-sentence line. Chances are, it’s tied to an issue/ticket tracking number (ex: JIRA). Doesn’t hurt to append that number at the end.
  • git push
    Everyone should know this command. This actually pushes your code changes to the repo. If you’re on a specific branch, you’ll be pushing this to that one branch. This is another reason why it’s a good thing to be on a branch versus the master. Even if you push code here that breaks, you won’t be affecting the main code base. Someone will be able to review your code before they merge it in with master.
  • git stash or git stash save “<name>” 
    Example: git stash save “work for scrolling bug”

    This is another command that I highly recommend you use. As a developer, it’s common you’ll be asked to switch gears at the drop of a pin. Chances are, you’ll be right in the middle of something. You’re not quite done with it and it’s too incomplete to commit. That’s when stashing becomes the best option. Running this command will take all of your changes and put it in a stash. It’ll revert all your code back to what it was before. Whenever I stash, I normally like to run a pull too so I have the latest changes before stashing. Or, I want to test original functionality. So I’ll stash my code, test how the app originally worked, and the reapply my changes to test how my code makes it work now. This is a great command.
  • git log
    This is one that I don’t use too often. This is probably more for the person who has to manager the repo, but nonetheless, it can become handy. It’ll give you an audit of all the changes to the repo. You can see who committed code in what branches, when. It’s good when you need to do some detective work to see when changes were made.

 

There are a ton more commands and even more options you can append to them. Personally, these the most common ones that I use. I haven’t done a whole lot of merging since that’s normally done by the person managing the repo, but I think these will give you a pretty good head start. I know I wish I knew these before going in to a development shop. There are also plenty of free tools to make this process a little easier, like giving you a gui so you can visually see what’s going on (ex: SourceTree by Atlassian). Most hardcore developers will just work straight through the terminal, but if you’re coming from an Eclipse or RubyMine world, having a gui like SourceTree might ease the transition.

Just a final note: if you want to keep your code private, use BitBucket. It’s just another git-based repo. You can have unlimited repos for free and not display your code to the entire world.

Happy gitting!

My Development Philosophy – Be a Minimalist

Having been at my new gig for nearly 2 months now, I’ve learned very quickly what it’s like to use other people’s code. And when I say using other people’s code, I mean using libraries (gems). I’ve always been a proponent of staying as close to the bone as possible. When you start mixing in gems that seemingly make things easier, you begin to rely on them. A great example of this is using the simple_form gem. I have no doubt in my mind that the contributors of this gem know their sh*t and this is not a bash on the gem itself. But what it essentially does is makes Rails forms look cleaner (depending on who you ask). At first glance, things seem perfectly fine. Forms are cut in half because you don’t need a separate line defining a label. But I remember when Bootstrap 3 initially came out and simple_form hadn’t had the chance to update yet. Boy was it a mess. You couldn’t simply define a class on a form like you regularly do because on the backend, simple_form was mutating the default functionality. Long story short, you had to either hack your way around it or wait for the gem to update.

When you start relying on other people’s code, things are fine at that moment. However, as technologies change, you become a lot more susceptible to bugs and upgrade problems. Imagine a Rails 3 application with 50 gems. Now you want to upgrade to Rails 4. Well, guess what? You need to ensure that every gem is compatible, and if not, figure out which ones need to be upgraded or completely abandoned all together. Or let’s say you rely on a particular gem for connecting to your APIs. Whenever an API changes, you have to worry about whether or not it breaks your program. Granted, this is just the nature of software. Things change. But, personally, I want to minimize the impact of change. And one way to do that is to make sure your code is as self sustaining as possible.

The point I’m trying to make is that there are no shortcuts to becoming a great developer. Don’t rely heavily on other people’s code and simplify only when needed. Personally, I’m not a huge fan of compilers that make code look good in the editor but completely different when debugging *cough* Haml CoffeeScript *cough*. I can see using those technologies if you understand what they’re doing. However, I wouldn’t advise a beginner to start outright using Haml or CoffeeScript. Take the time to learn the grass roots of programming languages. Don’t add another layer of unnecessary complexity, or else you’ll always be wondering if it’s your code or the compiler’s/library’s/gem’s. I’m not saying you should learn C or Assembly, but at least learn (for example) vanilla JavaScript. It’s an extremely intimidating language to a beginner. However, if you can climb the initial hump and learn its syntax, you’ll appreciate its complexity. Same goes for any other language.

Be a minimalist. Not in the sense that you use less code to do what you want to do, but in the sense that you rely more on the core language. In the long run, you will become a stronger developer (at least in my opinion). Put it this way: if I were put in a position to hire someone who only knows CoffeeScript versus someone who knows JavaScript, I’d choose the JavaScript person.

Working on a Mac Development Team

I’ve only ever known what it’s like working in a corporate environment. Cubicles, business casual, and Windows PCs dominate the corporate world. Every computer at every company I’ve ever worked at before came pre-installed with Windows 7 and Microsoft Office. Outlook, Word, Excel, PowerPoint, and Outlook, Outlook, Outlook ruled 90% of my time. Did I mention Outlook? I’ve gotten so used to working with MS Office that when I started using a Mac when I began learning Rails, I couldn’t get over the fact that I didn’t have a word processor. I took all my notes in the Notes application.

My new gig uses Macs, which now seems more common than ever for development. They basically handed me my Mac and said, “Here you go. You can use whatever you want.” It was so foreign to me. At my previous job, we all had one text editor: Eclipse. Here, we can choose whatever we want.  I think the only other application that our systems guy installed was Apple TV. Everything else was out-of-the-box Mac. We’re heavy Google Apps users, so we have most of the business applications. We don’t have shared drives, everything is through Google Drive. We don’t have Windows Exchange servers for email, we use Gmail. We don’t have Outlook, we use Google Calendar to manage meeting invites. All of our repositories? On Github. It’s insane to think that everything we do is in the cloud, which has actually become very convenient since I can access everything from an internet connection. I went from a very structured environment with standard applications to working on a completely different operating system where I’m free to choose whatever I want.

That all being said, I’ve gotten used to using what I like. It’s great knowing that I can setup my machine with the applications that I like and what I use at home. In the beginning, it was a little hard because I wasn’t sure what to use. But as I played around with different applications, I’ve grown to like the ability to choose what I want. Another great thing is that Mac users are generally open-sourced believers, so there are a lot of great things people are putting out for free. So instead of paying Microsoft X amount of dollars for Lync, you can use Adium for free. Instead of paying for an Eclipse license, you can use Atom.

So a heads up to all of you who are looking to work on a Ruby/Rails development team. Chances are, you’ll be using a Mac. And chances are, you’ll be given the freedom to choose whatever application you’ll want to use (and if you’re lucky, they’ll pay for the ones that cost money).

The applications I use:

  • Email: Apple Mail. I still haven’t found a good email client that’ll incorporate Gmail and Google Calendar together. I’m so used to Outlook that I’m trying to find something comparable. I want to be able to send an invite via my email client, just like Outlook. If anyone has any suggestions, let me know!
  • Messenger: Adium. Great, free application that you can tie to your Gmail.
  • Atom: Another free application. Text editor that is very similar to Sublime Text. Will probably make the switch to Vim once I become comfortable with Ruby development.
  • Office: Google Drive. Still trying to get used to this one. Automatic saving of files is a little scary. Sometimes I just want to run some calculations real quick in Spreadsheet without saving it.

If anyone has recommendations, I’d love to know. I’m still trying to maximize my efficiency but am neck deep in code, so I haven’t had the chance to do more digging.

 

Minneapolis Coding Bootcamp: Prime Digital Academy

The Twin Cities area isn’t necessarily a hotbed of technology. It’s more of a mature, stagnant market full of corporations that move slowly when adopting new technologies. However, in the last decade or so, the tech scene has really started to blossom. It’s definitely not Silicon Valley, or even Denver, but there is a small beacon of light that is breaking through and companies are successfully growing in this area of the country. Buzzfeed just bought a small development shop, looking to expand by creating an office here. Big corporations like UnitedHealth Group and Best Buy are incorporating modern languages like Ruby and Python. It’s not just a .NET or PHP market anymore. Another testimony to this growing tech scene? We finally have a coding bootcamp!  (I kind of take that back. One was started by a local private college, but their focus was more on .NET and Java).

Prime Digital Academy will be starting their first wave of students in March. Their focus is primarily JavaScript, so the millions of frameworks/tools you’ve heard of will be taught to students (Ember.js, Angular.js, Node.js, etc.). It’s actually a breath of fresh air from the hundreds of Rails bootcamps. It’s a full time, Monday through Friday, in-classroom experience. Prime was actually started by The Nerdery employees (a mid-size development shop), so the folks definitely have the right resume. One thing they did that I haven’t seen any others do was hold live Hangouts for anyone and everyone to join. They answered a lot of questions and talked about their “employer network”. They really stress the importance of preparing you for a job after graduation, something others seem to have forgotten. No one spends $12,500 to learn a hobby (which is how much Prime costs). It’s not an obnoxious amount. They advertise an 18 week course, but if you read the fine print, the initial 6 weeks are homework to do before in-person class actually begins. Granted, you’ll have access to teachers during those initial 6 months. So all in all, this is a very standard bootcamp with a focus on JavaScript.

I posted a few months ago my opposition to joining a bootcamp. I personally believe that learning how to code should be affordable. Obviously, the comparison of $12K versus a $30K college education always comes up, but let’s be honest, you’re comparing 12 in-class weeks to 4 years. Whatever your stance is, $12K is not cheap. It’s a bit ironic that, as an open source community, we charge folks trying to learn it. It’s one thing to build a robust product and charge millions, it’s another to charge an arm and a leg just to learn the darn stuff.

All that being said, I applied to the program (this was before I got my job offer). I was in a state of desperation, having self taught Rails for a year while applying to jobs. As I’ve stated before, Minnesota isn’t a huge technology market. I got desperate and applied, not for the education, but for the network of employers. If I needed to spend $12K in order to land a $60K job in 3 months, it would be well worth it, which is why when I applied, I was only interested in the first wave of students. Employers are more likely to take a risk with the first group as a way to test the waters. Not only that, but Prime has pressure to produce quality talent or else they would lose their reputation.

The first part of the application consisted of a short quiz to test your logic (determining patterns, matching words, low level math). The second part was to create an HTML resume, which wasn’t too hard if you’ve spent a little time with HTML/CSS. After I applied, it was about 2 weeks later that I was contacted and invited to meet with them in-person. Thankfully, I received a job offer for a Ruby developer role before I was committed to Prime. I told them I wouldn’t be able to participate in the program and they graciously congratulated me on my new role.

I suppose the point I’m trying to get across is that the Twin Cities has a growing tech market that will need talent. This is a great time to be a prospective developer. With Prime creating a bootcamp, you can jumpstart your path in development with a positive outlook on job opportunities. If you have a little bit of time, I’d highly recommend learning on your own and using all the available resources you can find for free or for cheap. However, if you want to learn as fast as you can and be introduced to employers, Prime could be a great option. I personally will be keeping a close eye on graduates of the program, especially this first group of students. If you decide to apply, I’d say do it quick. There are only so many junior developer roles. Be one of the first few cohorts and you’ll have a much better chance at snagging one of those openings. I would’ve loved to have gone through it to report my experience, but I’m glad I was able to find a junior role on my own. As many bootcamps as there are, I’m surprised you can barely find any graduates willing to share their experience. Let’s just all hope they’re too busy at their new jobs!

How I Landed a Software Developer Job

It’s taken me a year’s worth of hard work and lots of dedication to get to this point. I’ve officially accepted a software developer position and will be starting at the end of this month. I’d like to share my experience with others so they know what a possible route in landing a developer gig could look like. Full disclosure, this is my path and I definitely don’t believe it’s the only one.

First, I’d like to put everything in perspective. I think level setting the field will give you an idea of who I am and what my skill set was at the time I decided to start my journey to Ruby/Rails development.

I’d say the story starts back in middle school. I was always interested in computers. I was an avid PC gamer and built a few websites when Geocities was huge. I took a semester long course in high school that covered the basics of HTML. This was back in 2004 when web development wasn’t all the rage it is today. I even (dare I say) played around with MySpace for a short while. It was in high school that I strayed away from technology and decided to pursue a career in human resources (they said average salary was $90K…boy were they wrong). I graduated with a bachelor’s in HR, got a job in HR, then made a pivot into becoming a business analyst at a software company. I played around with a few WordPress sites here and there, but this is where it gets interesting.

The BAs at this company weren’t your traditional BAs. Not only did we do all the requirements gathering and analysis, we actually did all of the coding as well. We build HR software, working in our own DSL and framework. So we are actually grouped with the development department. That being said, we went through the typical SDLC. Although we worked within our own framework that nobody else would ever know, we were still a development team that went through the same process any other development team does: analysis, design, coding, documentation, maintenance, etc. What I’m trying to get across is that I was essentially a developer already, just not working with common frameworks. This, I strongly believe, was an advantage over someone who comes from a completely different background.

After a few months in my new role, I came to the early conclusion that none of my technical knowledge was transferable. If I wanted to stay in development, I needed to learn other languages. That’s when, almost exactly a year ago, I decided to learn Ruby on Rails.

First off, why Ruby? In all honestly, it was because of the simplicity of the syntax combined with the power of Rails. My primary interest was web development, and there are plenty of resources for Rails. I ignored all the JavaScript-is-the-new-way comments. A simple job search on Indeed showed Rails was still flourishing. After all, if PHP is still around, Ruby/Rails shouldn’t die all that fast.

January 2014

  • I bought a used mid-2009 Mac Book Pro 13″ for $300. Rails development does not require a whole lot of power, so this thing has gotten me very far. It was strictly used for Rails.
  • The first tutorials I started: JumpstartLab’s Blogger, Rails Guide’s Blog Tutorial, and Hartl’s tutorial.
  • Started this blog (something I highly recommend everyone does).

February 2014 – April 2014

  • Attended a few Meetups. There’s a great one here specific to Rails.
  • Continued my learning path. I started a personal project to help learn since tutorials are a bit of a spoon feed.
  • Scoured Google and StackOverflow.

May 2014

  • Landed an interview with a local company for a Ruby developer. It was a decent size company. I think they said it was around 140 people. I want to stress that this was for a Ruby development position, not strictly Rails. This deserves its own post because boy was I humbled. There was an initial lunch meeting to get a feel for who I was, then a 4 hour interview where I was grilled by 8-10 people on my technical knowledge. We pair programmed for the last part of the interview and it did not go well at all. I have an HR background and did recruiting for many years. I’m generally comfortable in interviews, but boy was this an eye opener. I’ll explain my experience more specifically on this in a separate post. For now, just know I bombed a Ruby developer interview.

June 2014 – October 2014

  • After my dismal interview, I actually became more encouraged. It really showed me what to expect if I wanted to break into real development. I NEVER want to feel like an idiot again.
  • I continue my personal project and actually have a few under my belt. I use a variety of resources to further my knowledge.
  • Things start to click for me during this time. I start to understand a little more on how to tackle certain issues and can build skeleton apps.

November 2014 – Today

  • I release a Udemy course that goes over how to build a Craigslist Clone. I’ve received good feedback. 24 students and counting!
  • I apply for a Ruby/Java developer position and get an interview. It’s with a smaller company, 40 – 50 people. It’s actually a great thing because then I have more chances to get my hands dirty with all different parts of development. I start my new role end of this month :).

Essentially, a lot of persistent and resilience to the challenges that you will most definitely encounter. Being a self taught developer takes a strong will, and I think companies know that. Ruby is one of the few languages I’ve seen to be primarily self taught. The community is very supportive and it seems like most of the senior developers have all been in our shoes. There is a certain level of empathy, and if you’re willing to learn and stick with it, it shows commitment and perseverance. All of which, regardless of your title, are great assets to have in an employee.

Depending on where you are located, your path may be a lot shorter. I’m located in the Twin Cities. We don’t necessarily have a booming tech scene. Therefore, it took me a lot longer to find a gig since companies were less willing to take a chance. If you were out in California or New York, I’m positive you will take a lot less time than I did to land a developer position.

Here’s a blog I posted a few months ago on what I used to help my learning:
List of Resources to Learn Ruby on Rails

My hope is to further my knowledge, only to return the favor and help others learn.