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.

The Unlikely Role Model

When I first started blogging, I had a vague idea that real, live people might read my blog. Perhaps 3 or 4 people would type in a random URL, end up on my page, and spend a few minutes reading about Yak Shaving.

For the most part, though, I expected that my writings would float out into digital space, bouncing around in zero gravity with all the other unloved bits and bytes of the universe.

What I did not picture was that I would ever get the beautiful opportunity to be a role model for other Unlikely Developers.

When I say “Unlikely Developers”, I’m talking about people who don’t fit the mould: people who, by not fitting the stereotype, are constantly at risk of convincing themselves–or being convinced by others–that they are not cut out for this.

Writing has always been cathartic for me, but what has been even more cathartic is connecting with my readers.

Through my blog, I’ve met several people who were just beginning their journey–women, parents, low income and minority coders-in-the-making who are so passionate about learning to code, and so worthy of a spot in the tech world.

They’ve shared their joys with me as they get their first job or get accepted into their school of choice. They share their frustrations when they can’t get past a problem and wonder, “Am I kidding myself to think I could really be a developer?”

It is such an honor to be a part of these wonderful people’s lives, and to be the one to tell them, “That’s normal. I felt it too. You CAN be a great developer.”

Chaos, Order, and Code

I’ve noticed I go through a certain set of phases each time I move into a new job or get a promotion:
  1. Disorientation: I’m too new to have a clear picture of what it takes to be successful in the job. I complete the tasks, but feel aimless, as I don’t know which actions are truly impacting my success, or even what success looks like.
  2. Chaos: I gain a clear picture of all the skills I must master to be truly effective in my job, but I don’t know how to prioritize the learning. As a result, my approaches to mastering those skills are scattered and chaotic, making it difficult to see my progress. This is the frustration stage.
  3. Planning: I reach the point where I have sufficient information to make a plan. I analyze the skills I must master, prioritize them, and estimate how long it would take to master each skill. I begin to feel in control.
  4. Order: With plan in hand, I attack each skill gap ferociously. I steadily gain confidence as I watch the dominos fall. I am calm and focused.
  5. Knocking on the Door of Mastery: I master enough of the skills that my progress becomes apparent to others. Others start celebrating my successes, but I’m still not satisfied.
  6. Mastery: The dominos have fallen. I have attained a level of mastery that meets my own standards. The difference is small but noticeable to others. The difference is everything to me.
  7. Thumb Twiddling: Having mastered the skills, I wonder what to do now that my list is complete.
Both Coding Bootcamp and the first months of my job felt chaotic. I had too little time to stop, reflect and plan.

Yesterday evening I finally found the time to plan. I laid out every skill I needed to learn, ranked them by importance and by my current skill level, and made a graph showing the intersections between skill level and importance level. (Geeky, yes, I know, but that’s been established).

Other developers often try to be helpful by suggesting obscure tools and languages you should learn. They mean well, but if you try to follow everyone’s advice, you end up with DADD (Developer ADD). Sorting out what is truly important is a very difficult task. The graph helped me visualize the top priorities, which means I can finally stop chasing after every stick another developer throws.

It is such a relief to have a plan again.

Coding Bootcamps: A Fork in the Road for Tech Diversity

For years tech companies have lamented “The Pipeline Problem”: the shortage of female and other diverse candidates in the hiring pool.

The opportunity to change that dynamic may come from a surprising source: Coding Bootcamps.

Computer Science and other STEM majors consistently fail to attract female students. The reasons are complex, but 3 important factors are:

  1. The stereotypical profile of a Computer Science major does not meld easily with the average woman’s self-image. Young women recoil from Computer Science for the same reasons that men recoil from nursing. We simply cannot reconcile our self-image with the image we attach to that career.
  2. Computer Science programs involve intense competition between students. This feels very uncomfortable to women, who are taught to cooperate rather than to compete.
  3. Men get greater exposure to and encouragement in technology and math throughout childhood, meaning that female students arrive at CS101 already at a disadvantage. The teachers assume a certain level of knowledge from their students, and when a student does not have that base of knowledge on day one, she assumes she must be “less talented” or otherwise unsuited to the profession.

Examining the issue more closely, however, we see that girls are given less opportunities to explore computers. Subtle messages from parents, teachers, friends, and popular culture steer girls away from computer games, tech camp, and the joy of disassembling household electronics.

We may never know how much of the difference can be attributed to societal attitudes versus natural preferences, but ask any 3-year-old, and they can tell you what gender a construction worker or a nurse “should be”. The ideas about Software Developers evolve a bit later, but only because toddlers are not yet familiar with that career. Try asking a 10-year-old to draw a Software Developer. If you find one who draws a woman, $100 says her Mom’s a developer.

So, how do Coding Bootcamps factor into all of this?

Coding Bootcamps are in their infancy. There’s still time to mould them into the missing link for tech diversity. Mistakes were made at the inception of college-level Computer Science programs. Those mistakes can and should be remedied, but it will be an uphill battle. Coding Bootcamps have the opportunity to “do it right” from the beginning.

Another advantage for Coding Bootcamps it that their students are generally a few years older than college students. Those few extra years of maturity can make a world of difference. An 18-year-old college freshman still has a relatively unstable self-image and still feels the pressure to conform. A few years later, she will generally shed her desire to conform, accepting both the popular and unpopular facets of her personality.

Coding bootcamps come in at just the right time–late enough to give the student a chance to experience the work world, but early enough to leave years for a fruitful career.

By the time women gain the maturity level and motivation to buck the ideals of popular culture and fight the uphill battle to claim their place in the tech industry, they have often assumed enough family and work responsibilities that the traditional CS degree–with all its forays into interesting but impractical subjects–is so time-consuming as to be impractical.

Coding bootcamps, with their narrow focus on practical skills, give students the chance to learn the critical fundamentals in a short sprint, and then fill in the gaps on their own time.

How can Coding Bootcamps take an active role in changing the dynamic?

  1. Explicitly state all prerequisite knowledge, along with how to obtain it. Never assume knowledge, no matter how basic you believe it to be.
  2. Give added support to diverse students. Recognize that they may have unique challenges, such as the need to balance outside responsibilities and school, gaps in foundational knowledge, impostor syndrome, or feelings of social isolation.
  3. Implement Social Rules: Stepping outside of your socially-ordained role is taxing on the ego. Micro-aggressions, whether intentional or unintentional, can have devastating impacts on diverse students. Hacker School has a very impressive student manual with social rules that I would love to see implemented in every Coding Bootcamp.
  4. Partner with companies that are looking to improve diversity. Large companies can pay for bootcamp training for employees who are looking to switch from a non-technical career into a developer role, or simply hold their jobs while they retrain.
  5. Give up on the ideal of the Natural Super Genius Developer. Natural talent? It’s a myth. Talent does have a genetic component, but genes are expressed differently based on environment. Deliberate practice is the key to mastery of any subject, and propagating the myth that some people are born with the ability to write beautiful code only discourages budding talent.

We are at a fork in the road, and now we must choose: Will we continue with the status quo, checking the box for “minimum diversity level attained” or will we recognize this unique opportunity, and address the systemic issues that sustain our homogenous technical culture?