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!

What Coding Bootcamp Doesn’t Teach

When I was going through Coding Bootcamp, I wondered if I would really learn the skills I needed to be a software developer.

The answer is that coding bootcamp is only a small piece of the journey. Learning to code is a marathon, and attending coding bootcamp is like sprinting 500 yards to get to the gigantic water station. By attending coding bootcamp, you’re able to dump that refreshing, icy water on your head much sooner than the steady joggers, but the race doesn’t suddenly end. You still have endless miles ahead of you after you reach the water station.

Here’s a snapshot of what you learn in each phase of the marathon:

The Stretch (Learning Before Bootcamp):

  • HTML and CSS: The Building Blocks of Basic Websites. (see General Assembly’s Dash or Codecademy HTML & CSS)
  • Basic Programming Concepts: Exposure to loops, control flow, data types, etc. (see Codecademy Ruby or Learn Ruby the Hard Way)
  • Basic Command Line Skills: changing directories, moving files, etc. (see Learn CLI the Hard Way)

The Warmup Laps (may be before or during bootcamp, depending on school)

  • Object Oriented Programming concepts: Classes, objects, encapsulation, polymorphism, etc. (Lynda.com, $25/month)
  • Basic Database Concepts (SQL / Relational Databases)
  • Model View Controller
  • REST

The Sprint (during Coding Bootcamp)

  • how to solve problems with code
  • how to make websites with code
  • how to get data from other websites through web services
  • practice making and breaking a lot of stuff

The Water Station (reaching your first job, where you get paid to learn and have more resources)

  • Practice coding all day without sacrificing the ability to support yourself
  • Have constant access to experienced developers for help
  • Get company-provided resources: libraries of programming books, Lunch and Learns, etc.
  • Get a clear picture of what specific skills you need to learn

The Rest of the Marathon

  • Learn about design patterns (see Principles of Object Oriented Design in Ruby)
  • Learn about Data Structures (Lynda.com, $25/month)
  • Deepen your knowledge of every subject you studied: databases, Ruby, Rails, web services, command line
  • Learn the operating systems, text editors or IDEs, monitoring apps, deployment and hosting apps, and other tools your work uses. (God help you if you have to learn Vim as a newbie.)
  • Learn Agile best practices. Learn to scream and claw your face if your company uses Waterfall-style development.
  • Learn other languages that give you a new perspective on code: C++, Java, Assembly, and Lisp are frequently mentioned as brain-stretching languages.

The hardest part of the journey is the beginning. It’s like running without water.

Things get easier once you reach your first job. Coding becomes a built-in part of your day, rather than an extra task that must be squeezed into the crevices of your life. Yet, once you start your job, you find that just learning on the job is not enough.

There’s still so much to learn, so you lace up your running shoes and get back on the track. If you’re like me, and you love the feel of the road beneath your feet*, this will be a joy rather than a burden. You never reach the finish line, you just learn to love the race.


 

*You might get the impression from this post that I love to run. HA! I wish. I love running about as much as I love drinking Clorox.

 

 

Rails Magic 2: Bundler & The Gemfile

After creating your new app with “rails new my_app”, the next step is to change directories into your my_app directory and run “bundle install”.

cd my_app

bundle install

Again, we get a ton of output from a simple command:

Using rake 10.4.2
Using i18n 0.7.0
Using json 1.8.2
Using minitest 5.5.1
Using thread_safe 0.3.4
Using tzinfo 1.2.2

etc.

More Rails magic?

Well, kind of. This time most of the magic is coming from a gem called Bundler.

I wasn’t around during the dark ages of Rails development, but I presume that before Bundler came along, Rails developers had to venture out with spear in hand, and hunt down each individual gem their app depended on, and then each gem that those gems depended on.

When you run “bundle install” you’re telling Bundler:

  • Look in the file named Gemfile
  • Go to the RubyGems API (or whichever source is declared at the top of the Gemfile).
  • Find all the gems listed in the Gemfile plus all the gems that those gems depend on.
  • If the gem is already installed, use that. If not, install it.
  • Take a snapshot of the full gem list and store it in Gemfile.lock
  • Add the gems to the load path, making them available to every file in the app. (This saves you the step of having to specifically require each gem in any file that will need it).

Never make changes to Gemfile.lock. That file is for Bundler’s use only.

The problem with editing Gemfile.lock directly is that it will be overwritten the next time you run “bundle install”. Instead, add new gems to Gemfile and run “bundle install”. Bundler will take care of updating Gemfile.lock.

Go ahead and take a look at the default Gemfile and Gemfile.lock that are created when you run “rails new”. See how many more lines are in Gemfile.lock? That will give you an idea of just how much work Bundler does for you.

Rails Magic: Creating an App

The first place a new developer encounters Rails Magic is in creating a new app.

It’s an incredibly simple command, with a dizzying amount of action behind it.

Assuming you have Ruby and Rails installed, you need only open a terminal window and type:

rails new blog_app

BAM! Rails app created.

You now have a massive “blog_app” directory full of files, 100 lines of command line output, and no clue what just happened.

How did the app get created?

Do you really need 40+ files for a simple blog app?

To understand how your Rails app was created, it’s helpful to look at the slow way of doing the same thing:

The Slow Way

1. Make a directory for your app and change into that directory

mkdir my_app

cd my_app

2. Create a subdirectory for each of the subfolders

mkdir app

mkdir config

etc.

3. Create the files that go inside the subdirectories, as well as the free-standing files that are not contained in a subdirectory

touch Gemfile (not inside a subdirectory)

touch routes.rb (not inside a subdirectory)

touch config/environments/development.rb (this file is inside the config/environments subdirectory)

etc.

4. Open each of those files and set some basic configuration settings, such as which database will be used and which gems (packages of pre-written code) will be included.

“Rails new” creates 40+ subdirectories and files, so doing this manually would take quite a while.

However, many of the files that it creates are only used in highly complex apps, and if it wasn’t so much easier to type “rails new”, you would probably create just a fraction of the files that are automatically created.

In the blog post Minimal Rails, Scott Raymond shows how you can create a Rails app with just 6 subdirectories: app, app/controllers, config, config/environments, log and public. It’s a great exercise for understanding the basic Rails framework.

Most apps will use more than the 6 subdirectories listed in Minimal Rails, but less than the “Rails new” command generates.

We’ll look into what each of those subdirectories does in a future post.

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.

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:

DO

DON’T

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.

New Developer Snipe Hunt

Today is day 4 of the New Developer Snipe Hunt. It is theoretically possible to set up the development environment for my company’s massive, monolithic, fire-breathing, underpants-staining legacy-code-laden Rails app on a Vagrant box, and that is exactly what I and the other new Junior Developer are tasked with doing.

I swear to God, that app is running on black magic.

There is no other logical explanation for the fact that so many cobbled-together support applications should find the spiritual harmony to work together and produce a viable application that does not take customers hostage and boil them into a thick, boney stew.

(muffled screams)

Oh, Lord, it ate another developer. If I’m not back in 10 minutes, tell my husband I love him.

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

vimtutor

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!

 

My Thanksgiving Grace List

This year, if I get picked to say Grace, we’re going to end up eating cold turkey. There are just too many people to thank.

In order to make it through a full-time, 60-80 hour/week coding bootcamp and find a new career as a Junior Developer while also raising 2 young children, I needed A LOT of help.

Luckily for me, I got a lot of help from a lot of people.

While I couldn’t possibly thank every person who has helped me, I do want to thank a few people who have been extraordinarily generous.

In no particular order (other than my husband obviously coming first):

My Husband Donnie: For agreeing to ride this crazy roller coaster with me. For hanging on by his nails when it turned us upside-down and the seatbelts broke. For keeping one arm around the kids as he hung upside-down, by his nails, with no seatbelt on a looping roller coaster…and still looking back to see if I was okay.

Bill G: For listening and encouraging me when I was on the brink of insanity. For laughing when I was laughing, and lending a sympathetic ear when I was not.

My Dad: For making this financially possible, and for believing I could do this.

Robert G: For explaining things without being condescending, even when the question was as lame as, “How do you double click on a Mac?”

Saron: For creating CodeNewbie, which gave me a place to find support and meet other people who don’t fit the classic programmer mould.

Johnson and Tammy (My Managers): For approving a leave of absence, even when it wasn’t in their best interest, just to give me a safety net.

Ben B: For putting me in touch with several other Senior Developers and telling me everything he could think of to help me improve my skills and break into the field.

Everyone from Rails Girls: For taking up the cause of getting more women into programming, and creating a meetup where I could learn and connect without the suffocating competitiveness I’ve experience at other meetups.

My Brother: For repeatedly telling me “You’re good enough. You’re smart enough. I have no doubt you can do this.” and for introducing me to Ben.

There are loads of other people who have helped me, in big ways and in small. If I didn’t put you on the list, it doesn’t mean I’m not grateful. It just means my list was very long this year.

Happy Thanksgiving!