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!

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.”

Back in Coding Bootcamp

I’m going back through coding bootcamp. Well…kind of.

I’ve been wanting to improve my Javascript skills, since my original experience learning Javascript was…how to describe this…like having a pie thrown in my face.

My first experience with Javascript was around week 6 of coding bootcamp. I was just starting to understand the basics of Rails when–SPLAT!–Javascript! and then SPLAT!–Jquery. I ducked in time to dodge AngularJS.

It was a poorly-timed introduction, so I ended up initially hating Javascript. I mean, come on…does any language really need that many parenthesis? And don’t get me started on semicolons. (And yes, I have heard of LISP but I will continue to complain about Javascript’s parenthesis until I learn LISP, which I am penciling into my calendar for “never”.)

Javascript and I got off to a bad start, but I’m not one to hold grudges. Javascript, I forgive you for the pies, and I will try to accept you, semicolons and all.

I have decided to start again from scratch, as if I had never seen a line of Javascript code in my life.

Besides wanting to relearn Javascript, I had also become very curious about FreeCodeCamp. I wondered:

Does Free = low quality?

Could you really get an education equivalent to a full-time bootcamp from an online course?

How does one go about making a coding bootcamp free, when every other one charges Harvard tuition?

That curiosity brought me to sign up for FreeCodeCamp, and so far I am very impressed!

I hadn’t expected to learn anything in the first few lessons, since I already knew HTML and CSS quite well. To my surprise, they were much more than a great refresher.

For starters, HTML5 and CSS3 have a lot of major changes. Come to find out, I had not picked up on all of the important ones, despite reading an entire book on it.

Much more important than the additional practice and a deeper dive into the syntax changes, was the quality of the exercises.

I should mention that FreeCodeCamp did not create the exercises. They are simply a curator, serving up the best free resources on the internet, saving you the time of figuring out which resources are worthwhile.

The exercise that impressed me most was an exercise in General Assembly’s Dash program, which teaches you to make an animated robot using only HTML and CSS.

It’s an incredibly creative use of the tools–I never would have imagined that such a thing could be created without Javascript or pre-made images. The exercise really broadened my idea of how I could use HTML and CSS.

FreeCodeCamp has me hooked. It appears that I am once again in Coding Bootcamp.

The Developer Pit Crew

Software development is a roller coaster ride for the ego.

For every “Aha! I’m a genius!” moment, there are 10 “I’m a freakin’ idiot. How did I ever pass Kindergarten?” moments.

It takes a certain amount of ego to survive a job that is 90% error messages, 100% of which were created by “Guess who? Your-very-own-personal-self.”

We like to blame the computer, but deep down, we know it’s doing exactly what we told it to do, which is, again, 90% of the time, to tell us “Wrong! You are a big, fat idiot who should have been held back in Kindergarten.”

It’s no surprise that seasoned developers grow a nice, sturdy shell around their egos that deflects all potential criticisms with a scoff and a raised eyebrow. We must forgive these experienced developers for sounding like they think they are Almighty, Powerful Sun-Gods Who Make Rain as a Side Hobby. They don’t mean to come off as egotistical, they’ve just forgotten to remove their ego shell before socializing.

That, of course, does nothing to help those of us who still have thin, scab-like ego shells. The criticisms bounce right off the seasoned developer’s backs and skewer us like a Junior-Developer-Tortoise-Kabob. (Tortoise because of the shell–get it? No? Well, you probably shouldn’t admit that. Not admitting what you don’t know is one of the unspoken rules of software development. Violators get sent back to Kindergarten.)

So, how does one survive the daily ego-barrage?

This is where the Developer Pit Crew comes in. (Yep, we finally got to the reason for the title.)

The Developer Pit Crew is the group of people who can be counted on to remind you that, “No, you’re not an idiot. Yes, you did graduate Kindergarten, and no, that was not a clerical error.” For a female developer, this pit crew has the additional responsibility of reminding you that “Yes, you do belong, even if it’s a boy’s club,” and “No, being a geek does not make you any less feminine,” and “No, you have not grown a neck beard or a lightening-shaped scar.”

For me, those people are:

1) My husband, who beams with pride when I go off on a Geek Tangent, and tells me there’s nothing sexier than a smart woman. (And who then, patiently answers, “Yes, I mean you.”)

2) My brother, who told me, “There are people much dumber than you who learn to do this. I know you’re way better than you think you are.”

3) My dad, who, because he is also a software developer, is hard to argue with when he says I know what I’m doing. (Not that I don’t try.)

That’s a pretty bad-ass pit crew, if I do say so myself.

2014: The Year of the Giant Leap

Dear 2014,

I am mourning your passing, even as I celebrate the bounties you have delivered.

You will always be remembered as the year I took a giant leap of faith, hung suspended over an icy, shark-infested ocean for 4 months, and then landed smoothly with a fluttering of feathers on a soft, cushy mattress at the bottom of a mountain of ever-softer, ever-cushier mattresses, beaconing me to climb.

I started 2014 on a mid-level deck of a boat that was slowly taking on water: a career in retail banking management, where the lowest level employees were being shed in favor of the technology that would replace them.

All the other sailors on my deck kept their eyes fixed on the stairs, fully focused on climbing up. We could all see the levels flooding below us–the positions below us being cut. And yet, the waters were rising slowly…too slowly to be of concern.

They all recognized the truth of my words when I said, “Our jobs will not exist in 10 years,” but it seemed a far-off problem. We could not feel the icy water on our feet.

I started looking for a new boat, but I did not jump at the first I saw. I waited until I found not just any healthy boat, but one that was sailing in the direction I would like to take my life. That boat was software development.

I had found my boat, but we were separated by dark, murky oceans. To reach the new boat, I would have to abandon the old.

Jumping from a deck with icy water crawling across your toes is easy–there is no other choice. Jumping while your feet are still dry–that is much harder.

To reach my new boat, I had to pass on an imminent promotion, sacrifice 4 months income, and work every day to the point of exhaustion, with no guarantee of return on investment.

My brain screamed, “What if I fall? I’ll be immersed in icy water from my toes to my inner ears, and then there might be SHARKS. Can’t we just stay here? I know the water’s rising, but my feet are warm and dry.”

2014, we took a leap of faith together. We made it to the other boat, and it’s everything we hoped it would be.

Tomorrow I leave you for another year, but you will never leave me. You have forever shaped my destiny.

Farewell, 2014.

How to Answer a Junior Developer’s Questions

One day, and this day may never come, you will be called upon to answer the question of a less experienced developer. When this happens, you will need to find a balance between giving too much information and giving too little.

Struggle is essential to learning. This is especially true in software engineering, where one of the most critical skills is the ability to find a hidden gem of information buried beneath a mountain of irrelevant text.

And yet, a new developer cannot simply be left alone to struggle. Too much struggle leads to frustration, aimless searching, and eventually defeat. Some answers cannot be found without the proper context, and leaving a new developer to struggle toward an answer that will never come is pointless and counterproductive.

Here are some Do’s and DONT’s for answering a new developers’ questions:



Let the learner do the typing Type any commands without explaining why…even if you are still unsure how you will solve the problem
Explain things that you suspect the person already understands. They will stop you if you explain something they know. Ask, “You know this, right?” This sends the message that they should know. They will likely pretend to know even if they don’t.
Praise progress. Praise existing knowledge.
Make sure they fully understand the problem. What does the error message mean? What triggered it? How did you identify the problem? Give them the solution. If they fully understand the problem and know where to look for the solution, they will learn more and get more satisfaction from solving it on their own.
Stick around until the learner shows confidence that they can come up with the solution, and then be accessible in case they need more help. Walk away when the learner still seems confused. Even if you are confident that they can come up with the answer, the learner needs your support until they feel that confidence.

Developing in the Dark

As an aspiring developer, you set out to slay the largest monster in the deepest, darkest cave. You have only a tiny pinpoint flashlight to see by, which is the context of your current knowledge.

You enter the cave and see a couple of tiny little monsters with your tiny little light. You smite them and bathe in the glory of your triumph.

Then a gigantic paw reaches out and claws your side. You hold your bleeding rib and spin around frantically looking for the attacker, but your tiny little flashlight reveals nothing but dark walls.

You run from the cave and return with a slightly larger flashlight, which reveals slightly larger monsters crouching in the corners. You smite them and feel triumphant, but also wary. You spin in circles, but seeing nothing and feeling no claws, you breathe a sigh of relief.

Then you hear a slow, ominous giggle. Again you run from the cave, and return with a larger flashlight, which reveals a fat, giggling, yellow-toothed monster.

You smite him and wait for the repercussions: a claw, a cackle…anything…but nothing comes. Still, you feel uneasy, and back out of the cave warily, returning with an even larger flashlight.

The larger flashlight reveals more of the tiniest monsters, and you wonder, “How did I not see those before? Did they suddenly appear, or did I overlook them?”

You notice that these monsters are as tiny as the ones you first conquered, but they are stone-colored. You must have mistaken them for crevices in the cave wall, but now you know your monsters well. You have learned their movements, and though they look like stones, you sense the difference. You smite them, but not triumphantly…you are beginning to develop a respect for their beguiling ways.

Now tapped into your heightened senses, you listen closely. Yes, you can hear it: the breathing of the monster. No, that’s not right. You’re not hearing the breath…you are feeling it.

The breath is warm and slow as it sweeps up your spine, lingering on each vertebrae, landing at the base of your neck, gently teasing the hairs at the base of your scalp.

You shudder, wondering if you should run and find another flashlight, or a spotlight, or a heat sensor.

And then you see it: the edge of the cave. Those are not stones…they are teeth. You have found the largest monster, and you are clutched inside his jaws.

A Brief Introduction to Vim

After my initial hazing, I have decided I’m in love with Vim.

It turns out that learning Vim is a lot like learning to type properly. At first, it really slows you down because you have to teach your fingers what to do. Later on, after your brain gets the heck out of the way and lets your fingers take over, the investment really pays off.

I’m not yet to the real payoff stage, but I can see it on the horizon.

Here are a few tips for anyone wanting to learn Vim:

Why should I learn Vim?

Because once your fingers learn the keys, you will be able to move through your programs much more quickly, use shortcut commands for every action you can possibly think of, and understand what’s going on if you pair program with someone who uses Vim.

When should I learn it?

Whenever you can afford to temporarily cut your productivity in half while your fingers learn the movements. In other words, NOT when you are in the middle of learning a new coding language or have a major work or school deadline coming up.

How should I start learning?

1. Try out VimAdventures for a fun adventure-game-style tutorial. I only did the 3 free levels, since I didn’t like the idea of a 6-month subscription. (I go through that kind of thing in a week, so I’d want either a 1-month subscription or a permanent download that I could come back to for review.)

Vim Adventures

Vim Adventures

2. Download Vim and then open the Vim Tutorial. Apparently that’s as easy as typing


on the command line. If you read my last post about Vim, you’ll know that I spent a good long time trying to figure out how to get into VimTutor from inside Vim. Do not try that at home.

3. Get more practice by downloading these excellent Vim Exercises. If you have Git installed, you can run the following command in the terminal:

git clone https://github.com/skilldrick/vim-exercises.git

(If you don’t have Git installed, you would probably be better off investing your time learning Git.)

4. Start coding in Vim. Do some Project Euler problems to some other code exercises using Vim.

What else should I know about Vim?

Vim has several different modes that it helps to be familiar with:

Name Description help page
normal For navigation and manipulation of text. This is the mode that vim will usually start in, which you can usually get back to with ESC. :help Normal-mode
insert For inserting new text. The main difference from vi is that many important “normal” commands are also available in insert mode – provided you have a keyboard with enough meta keys (such as Ctrl, Alt, Windows-key, etc.). :help Insert-mode
visual For navigation and manipulation of text selections, this mode allows you to perform most normal commands, and a few extra commands, on selected text. :help visual-mode
select Similar to visual but with a more MS-Window like behavior. :help select-mode
command-line For entering editor commands – like the help command in the 3rd column. :help Command-line-mode
Ex-mode Similar to the command-line mode but optimized for batch processing. :help Ex-mode

The 2 modes you will probably use most at the beginning are Normal Mode and Insert Mode.

Normal mode is where the keyboard keys are interpreted as shortcuts. For example, the letter “j” would move the cursor down. From here you can move into insert mode with several different key commands, such as typing “i” or “a”. The only difference is where the text is inserted. ‘i” will insert text starting at the current position of the cursor. “a” will insert text starting at the position after the cursor.

Insert mode is where whatever you type is interpreted as text. The letter “j” would just put a “j” wherever your cursor is. To get back to Normal mode, you press Esc.

And that’s it. That’s pretty much everything you need to know to get started.

I got some excellent tips from readers on my last Vim post, and they helped me out a lot.

If anyone else has tips or questions, please leave a comment. Thanks!



I’ve finally decided to learn Vim, which is kind of like saying:

“I’ve decided to learn to fly. Watch closely as I dive from the edge of a high-rise building into a hungry bowl of sharks.”

Vim Sharks

Vim Sharks

The first obstacle is “How do I even open Vim?” Because, apparently, Vim is too good for double-clicking, which is fine, but then…why do you need an Icon?

Luckily my wild guess of

                               vim .

on the command line worked.

Into The Shark Pit!

Voila!    Into The Shark Pit!

Now that is a super-helpful start page.

Looking closely, I see this:

Quick Help: <F1>:help  -:go up dir  D:delete  R:rename  s:sort-by  x:exec

Ah, that’s good. Press F1 for help.

Whamp!!! (that’s the Mac sound for “Wrong button, dumb-ass.”)

Okay….let’s try typing


(Bracing self for Whamp sound…) Aha! No whamp!! Making progress.

Dear Lord, what am I looking at? 

Move around: Use the cursor keys, or “h” to go left,
“j” to go down, “k” to go up, “l” to go right.

Okay, let’s try “j” to go down.


What the?! Oh, my fingers are in the wrong place. Why would the keys be “hjkl” instead of “jkl;”? This is not what Mavis Beacon taught me to do!

Scrolling down…


Okay, let’s see…

|tutor|         30 minutes training course for beginners

Oh, great! A tutorial! Not sure why I had to know basic Vim commands to get to it, but at least I’m here. Typing:

 |tutor| Whamp!!

:|tutor| Whamp!!

tutor Whamp!!!

:grep |tutor| (silence)

:cat |tutor| (silence)

:dog |tutor| (silence)

:ostrich |tutor| (silence)

:WTF?!!!!!! (silence…)


Really Vim? Really?

Okay…let me check that Vim book a friend recommended:

 “This book will teach you everything you need to know about Vim…assuming you have already been through Vim Tutor.”

Holds computer above head, prepares to heave it through nearest window…

And then, salvation! I spot a tiny link at the bottom of the page, which takes me to a VimTutor help page. (Yes, there is a Help page for their Help page).

For OpenVMS, if Vim has been properly installed, you can start vimtutor from a
VMS prompt with:


I see. I’m supposed to type “@VIM:vimtutor”.

Because, yes…that is so intuitive.

Thank you, Vim. I have officially been hazed.

Getting Started in Web Development: FAQ For the Absolute Newbie

Not too long ago I decided I wanted to learn to code, and was trying to figure out where to start. I still have a lot to learn, but I’m far enough along to offer some advice to the people who are just beginning their journey.

Here are a few common questions I hear from people wanting to get started in web development, along with my answers.

1. How Do I Get Started?

Start by taking Codecademy’s HTML & CSS course. Then take their Ruby course. This will help you figure out what type of programming you are interested in.

2. How Do I Choose A Focus?

–> What did you enjoy more: moving elements around on the page and seeing the result with HTML & CSS, or working with programming concepts like loops, hashes, and arrays in Ruby?

–> Do you prefer visual things like drawing or design, or do you prefer abstract things like logic problems, puzzles and math?

If you are visual or preferred the HTML & CSS course, you may be interested in Front End Development. This means being the person who develops the part of a website that a user sees.

If you are an abstract thinker or preferred the Ruby course, you might be interested in Back End Development. This means working on the hidden logic that makes complex web applications work. This can be done in many programming languages, such as Ruby or Python.

3. What’s The Next Step?

Codecademy courses give you a good overview of the language, but they don’t give you exposure to some of the tools you will need to know, such as text editors, the command line, and coding documentation. The next step is to do a tutorial that will let you make real, functioning code using the tools that professional developers use.

Front End (HTML & CSS): HTML Dog has some excellent tutorials. Use those as a reference, and build a few websites on your own. Once you feel comfortable with HTML and CSS, try learning Javascript.

Back End (Ruby): Learn Ruby The Hard Way will introduce you to the tools you need, and teach you how to use documentation to solve coding problems. Once you feel comfortable in Ruby, try Hartl’s Rails Tutorial, which will teach you the basics of the Ruby on Rails framework. Ruby on Rails lets you use your Ruby skills to build complex websites.

4. Should I go to a Coding Bootcamp?

That depends: Can you invest the time and money to do so?

If the answer is yes, then a good coding bootcamp is worth the investment. It will keep you on track and give you the opportunity to be surrounded by mentors and other students that can be a great resource for you.

If the answer is no, don’t let that discourage you. It is 100% possible to teach yourself everything you would learn in a bootcamp. You will, however, need to find a mentor (or, preferably, several) who can help you get past roadblocks and figure out where to focus your attention.

5. How can I Find Help From Real, Live Humans?

The Best Places to Get Help:

  • CodeNewbie Weekly twitter chat, podcasts and discussion board (FREE!)
  • CodeMentor Paid individual mentoring.
  • Local Meetups: You may have to try several before you find one that welcomes and encourages newbies. Read the descriptions on http://www.meetup.com, and see how the attendees describe themselves. Look for meetups with a good mix of experience levels.
  • Exercism Work on practice problems and get feedback on your code from other developers. (FREE!)

Have more questions that I haven’t answered? Leave a comment and I’ll do my best to answer.