Looking for your first Developer Job?

It’s been a while since I’ve posted on Rails Mama, and I want to let my readers know about my new site, Dev Ready.

The new site is all about the path to becoming a professional web developer. I’ll be sharing tips on interviewing, job search, surviving coding bootcamp, and finding the best online resources for learning.

Check out my first posts (all related to the Junior Developer job search):

I would love to hear your feedback on the site. Good, bad, or neutral, all feedback is appreciated!

Join me at Dev Ready!

Blogging for CodeNewbie

I’m excited to announce that I’ve started blogging for CodeNewbie!

If you haven’t heard of it, Codenewbie is an organization dedicated to helping people learn to code. They have a Podcast, Blog, weekly Twitter chats, and a ton of other resources for people at any point on the journey of learning to code.

I’ll be writing the Ruby Roundup series, which is published every 2 weeks. My first blog post is live here.

Check it out!

What Every Junior Rails Developer Should Know

Not long ago, I shared a link to an outstanding video called What Every Junior Developer Should Know.

That talk was geared toward Front End Developers, but most of the content overlapped with the subjects that Back End Developers should know.

I happened to come across a diagram that my instructor from The Iron Yard shared on the first day of class.

When I first saw it, I was familiar with only about half of the terms on the diagram, but coming back to it after 6 months as a Junior Developer, I feel that it is a great summary of the tools and topics that I use every day.

As one reader pointed out, although the diagram says “Ruby on Rails Competencies”, it is actually a diagram of the skills required to become a Full Stack Developer. Many Ruby on Rails developer roles will never touch some of these areas, such as Javascript, HTML and CSS–which are Front End skills. Large companies often have dedicated teams handling databases and testing, as well. However, having at least some familiarity with these topics is important.

That being said, the following categories are the primary focus for a Rails developer: operating system, command line, WWW, Ruby language, Rubygems, Rails Framework, Git and IDE/Text Editor.


One blog post isn’t enough space for an overview on all these topics, but here is the first:

  • Operating System:
    • Rails developers generally develop on a Mac or on a Linux Operating System; Windows is not compatible with many software development tools
    • Mac OSX and Linux are both based on the Unix operating system, so they are similar in many ways
    • The Mac OSX is generally easier to use, but less customizable, and only run on Mac computers, which are expensive
    • Linux comes in many flavors, such as Ubuntu, Fedora, and Centos
    • The benefits of Linux are that it is free and customizable, and it can be installed on any computer
    • The downside is that installing and running software can be more complicated on Linux, especially since most users are tech people. The documentation is not very newbie friendly, but fighting through setup issues can be a great learning experience if you have someone to help when you get stuck
    • What you need to learn:

Learning the Mac OSX or Linux operating system is a great place to start.

Leave a comment if you found this article helpful. If it is helpful, I’ll try to go into more detail on the other topics.

Benchmarks of Failure and The Budding Developer Ego

I firmly believe that the most difficult part of becoming a software developer is the psychological aspect: balancing your ego as it morphs into a tomato-shaped pincushion, pricked daily with the bite of tiny, insignificant failures.

As a budding software developer, you cannot simply be satisfied with your current, comfortable level of skill. You must always seek out greater challenges. You must always take on tasks with a high risk of failure. It’s the only way to grow.

The failures come in many forms:

  • Not knowing something you think you should know
  • Not knowing something someone else thinks you should know
  • Failing to complete a task that seemed oh-so-easy
  • Seeing someone else complete that task, confirming that it was oh-so-easy
  • That stupid error message that just will not go away, no matter what you try
  • That stupid error message that goes away when it shouldn’t have
  • Breaking the build
  • Having to swallow your pride and ask for help
  • Having to swallow your pride and ask for help AGAIN
  • Oh, yes, and again
  • And again
  • And again
  • And again

It’s a hard world to live in, and I can’t help but be fascinated by the strange ego dichotomy that it produces, with some egos shrinking into Impostor Syndrome, whispering to their owners that they are morons who have somehow been lucky enough to fool the rest of the planet, and others growing into Lernaean Hydras, sprouting ever more vicious, condescending heads after each ego blow.

We must take steps to protect our fragile egos, lest we become the Incognito Imbecile or the Hydra-veloper that so many before us have become.

One technique I use to protect my own ego is to use what I call “Benchmarks of Failure”.

I had observed 2 things:

  1. With software tests, we expect failure as a step in the process. We set our system up for failure, document the failure (by watching the test fail), do some work, and then watch the failure turn into a success.
  2. The most satisfying things I’ve accomplished as a Software Developer all involved succeeding at something that I vividly remembered failing at previously…solving a problem that I previously did not have the skill to solve.

That led me to the thought: Why can’t we follow a similar process in growing our skills as a Software Developer?

Here is my “Benchmarks of Failure” process:

  1. Try a difficult new task and document:
    • The date
    • Whether you were able to complete it
    • How long it took to complete
    • How many times you had to ask for help
    • (Optionally) The array of curse words you hurled at yourself
  2. Set some goals:
    • What would you like to improve? The time it took? Just completing the task? Not having to ask for help?
    • When would you like to accomplish this by?
    • What would you need to learn more about in order to achieve that goal?
  3. Come back and watch yourself succeed

It would seem that this would only help prevent Impostor Syndrome, but I’m convinced it would also help the Hydra-velopers out there. After all, I think an overactive ego is really just a symptom of deep-seeded insecurities.

I am blessed to work on a super-supportive team, but I know way too many developers who have been planted in toxic soil. Perhaps, if this generation can better shield our own egos, we could help plant a stronger next generation. I’m picturing it now…a world with no Impostors and no Hydra-velopers.

Simple Template for Ruby Test Driven Development

Recently, I decided to spend some time practicing Test Driven Development by solving Project Euler problems with TDD.

This led me to an interesting problem: outside of Rails, setting up a test environment is a time-consuming task.

Inside of Rails, all of the configuration is taken care of for you. But Rails was overkill for my needs–I didn’t need models, controllers, views, Active Record, automatic pluralization, leprechauns, unicorns, fairy creatures, or any other unruly magical beings.

I just needed tests.

So, rather than fight with unwanted magical behavior, I invested an hour in research and created a very, very basic test environment.

If you’d like to use it, feel free to clone my repo:


What Every Junior Developer Should Know

It is very, very rare that I find a video worth devoting 2 hours of my life to, but today I found one. In my case, I actually devoted 4 hours of my life to this 2-hour video, because having children doubles the time it takes to do everything. (Scientifically proven.)

The video is Stuff Every Junior Developer Should Know, a speech given by Laurie Voss to a group of students at Hack Reactor.

Omar goes over the top things that more experienced developers wish Junior Developers knew.

Amongst other things, he goes over:

  1. Security & OWASP Top 10
  2. Performance: Speed, Efficiency, Throughput & Latency
  3. Caching
  4. Coding Antipatterns
  5. Databases: pros and cons of the most commonly used DBs

What really makes this talk unique is that he approaches each of these topics with no assumption of prior knowledge. His explanations are simple and straight-forward. He’s not giving a deep-dive on any of these topics; he’s giving just enough info for you to understand the concepts, identify whether you need to learn more about that area, and be well prepared to digest the resources he recommends for further learning.

If you have time to watch the video, I absolutely recommend it. If you don’t have time to watch the video, there’s a recap on Github, but be warned: it isn’t complete, and you will miss a lot of the best content.

The person who posted the recap, Omar Duarte, asked for contributors, so I put in a pull request recapping the section on security and OWASP. Hopefully it will be merged in, but if not, you can see it on my fork of his repo.

Take-Aways From Alterconf

My biggest take-away from AlterConf, a conference on diversity in tech and gaming, is the profound realization that I am embarrassingly ignorant of the issues of other underrepresented groups.

I know intimately the issues of Women in Tech. I live them, I overcome them, and I am in the loop when something happens–good or bad–to Women in Tech.

I can rant for an hour about the “Barbie: I Can be a Software Developer” debacle or “Gamergate”. Another woman doesn’t have to tell me that women in tech walk a gender tightrope–careful to be neither too feminine nor too masculine, too bold nor too passive, simply so that we can be taken seriously in our careers. I know these issues because I am on the inside.

What really hit home at Alterconf was how little I understand about the issues I’m outside of.

I never imagined how frustrating it must be to wait 20 minutes to use the bathroom because there’s only one accessible stall. Or to be of a non-binary gender and, perhaps, not have a bathroom to use at all.

I would have never thought to ask a transgender person about their pronouns, much less understood that saying “preferred pronouns” instead of simply “pronouns” might be insensitive. I’m also acutely aware that using the wrong wording is probably the least of the insensitive things I have inadvertently said or done.

Every person that spoke opened my eyes a tiny bit further, but what I saw most was how much more I need to learn and how much more we need to amplify these voices.