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!

Advertisements

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.