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.



Human Readable Documentation for Ruby srand

How does the Ruby’s srand (seed random) method work, and why would one use it?


I often come across Ruby methods that seem to be documented for something other than a human being.

When I read documentation, what I’m looking for is:

  1. What is it?
  2. When would I use it?
  3. How would I use it?

Most of the time I can find a blog post that fills in the gaps, but I came across a Ruby method today where I couldn’t find any useful documentation: srand.

After poking at it for about an hour, here’s my attempt at documentation:


First Some Background on Random Numbers:

Here’s a secret: They’re not really random. (Shhh, don’t tell the anti-Geeks.)

In reality, it’s not possible for a computer to generate a list of truly random numbers. What they do instead is take a seed number, muck around with it a bit until it’s changed to another number, and then spit out that number. Since we don’t know the algorithms used for the “mucking around” bit, even if we knew the seed number, the result would still seem random.

Usually the seed number is generated by the computer using a combonation of elements such as the exact time the random number was requested and the process ID of the program. These elements change constantly, so if you request a random number now, and again 1 millisecond from now (because you’re a really fast typer), the seed number would be different. When the seed number is different, so is the resulting “random” number.



Now, onto how srand works:

What is it?

Srand lets you pick the seed number so you can generate a list of numbers that seems random, but is actually predictable.

When would I use it?

Srand is most likely to be useful during testing.

Let’s say you wanted to test a method that normally uses a random number. In order to test if it’s working correctly, you would have to know what result to expect, and that’s not possible if the random number is generated every time the test is run.

Srand would let you simulate the idea of a program handling random numbers, but with results that are still predictable enough to test.

Or you could:

Use method aliasing to overwrite Ruby’s normal rand method, memorize the first 100 results with your chosen seed number, and convince people that you’re psychic by consistently guessing the next “random” number.

How would I use it?

1. Set the seed number:


2. It will return a list of random numbers that would be generated using that seed number:


3. The next method that uses rand will use the seed number you specify.

for i in 1..10

puts i


This will return the same random numbers you got when you first typed srand(1234). In this case it will return the first 10 numbers of the set.


4. The seed you set works only once, so the next time you call rand, it will not use your specified seed number.

for i in 1..10

puts i


–> now returns a different number.

And that, my dear readers, is how srand works.

Pairing with Intent

Why did you pair program today?

No, I’m not asking why you pair program in general. Anyone can list the benefits. I’m asking “Why did you pair program today?”

The articles I’ve read all claim that when pair programming is done right, participants will reap a host of benefits, including:

  • Increased Discipline (Less goofing off)
  • Better Code (2 brains are better than one)
  • Resilient Flow (One pair handles an interruption while the other maintains the flow)
  • Improved Morale (More enjoyable than programming alone)
  • Collective Code Ownership (Less finger pointing, more shared trophies)
  • Mentoring (Natural way to share knowledge)
  • Team Cohesion (Definitely will know each other. Hopefully will like each other.)
  • Fewer Interruptions (People know you’re busy because you’re thinking out loud)

I’m not disputing the accuracy of the list. YES, these benefits result from effective pair programming.

The mistake is in the assumption that all pair programming sessions will produce all of the benefits.

I assure you that is not the case. In reality, each session delivers a small subset of these benefits. The benefits produced depend on several things:

1) The participants’ relative skill levels

2) Their personalities and relationship with each other

3) The goal of the pair programming session.

Let’s look a few of the team roles and how they benefit most from pairing:

The Junior Developer

  • Benefits most when:
    • working on an issue just above his/her current level of knowledge
    • paired with a person who excels in mentoring others
    • NOT paired with the most senior team members (the gap in knowledge becomes frustrating for both)
    • given solo time to fight through simple issues on his/her own (builds confidence)

The Senior Developer

  • Benefits most when:
    • working with someone who has domain-specific knowledge
  • Provides most benefit when:
    • Working on complex or critically important issues
    • Paired with a developer who is only slightly less experienced
    • Paired with the express intent to mentor

The Mid-Level Developer:

  • Benefits most when:
    • Paired with a Senior Dev on a complex issue
    • Paired with another mid-level dev on a standard-complexity issue
  • Provides most benefit when:
    • Paired with a Junior Dev with the express intent to mentor
    • Paired with another mid-level dev on a standard-complexity issue

The Shy Dev

  • Benefits most when:
    • Paired with someone who forces him/her to socialize

The Introverted Dev

  • Benefits most when:
    • Encouraged to pair, but given the freedom to work alone to get a break from socializing

The Extroverted Dev 

  • Insufficient data for analysis.

Pairing is an incredibly effective tool, but it is just that: a tool. No tool is right for every job, and not having a pair can be better than having the wrong pair.

It’s time we start asking ourselves: What am I trying to accomplish with this pairing session? What pair will benefit most from tackling this specific issue? Would pairing be helpful or wasteful on this particular issue with this particular pair?

Learning On the Job

Today a friend who is about to start his first job as a Junior Developer asked me a great question:

“Do you still find the time to study outside of work or has on the job learning become way more valuable?”

Here’s what I told him:

I definitely learn a lot of things at work that I would not learn outside of work, but I also spend quite a bit of time filling in the gaps outside of work.

For example, sitting with a developer who is awesome with Git shows me some new Git features I never would have learned on my own, but it also tells me, “Okay, apparently there’s still a lot I need to learn in that area”, so Iend up studying it at home.

Basically, I’m exposed to a lot more things and get a better idea of what I need to learn, but then I have to put in outside time to learn them. (Which is a little hard because my outside time is so limited).
Overall, I think the best learning experiences are a mix of being taught and teaching oneself.
When I’m paired with someone who likes to teach, I think I learn as much or more than I do alone. When I’m paired with someone who doesn’t stop to explain, I end up wishing I could spend the time teaching myself.
In an ideal world, I’d have plenty of time for both types of learning. For now, I’m soaking up everything I can from my peers, and trying to squeeze self-teaching into the tiny slivers of time left after work and family take their share.

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


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.

Pairing Effectively with a Junior Developer

Pairing a junior developer with a more senior developer is an excellent way to get the junior person up to speed quickly. It can also have unexpected benefits for the senior developer, since the junior team member will often question things that a senior team member would not think to question.

“Why does Bicycle inherit from Grapefruit?”

“Um, I don’t know. It’s been that way since before I got here. At first I thought there must be a reason, but I didn’t want to ask, and then I guess I just got used to it. Yeah, we should probably change that.”

It’s easy to forget, however, that pair programming–especially with a junior team member–is a demanding task that requires a unique set of skills. The greatest programmer on the planet could be utterly incapable of mentoring a junior developer.

A great mentor needs:

  • Patience: He must be able to wait for a person to solve the problem, even when he could have solved it himself in a fraction of the time.
  • Excellent communication skills: He must be able to explain what he does and why. He must also be able to ask questions that provoke thought while boosting, rather than undermining, the learner’s confidence.
  • Awareness of body language: He must pick up on the clues that say, “I get it,” or “I’m lost”, or “I’m thinking. Now is not a good time to interrupt.”
  • Belief in the value of teaching: He must believe that teaching the junior team member is a valuable use of his time–that it is worth reducing his capacity in other areas so that the new team member can learn. He must find satisfaction in seeing the junior team member make a great leap in understanding, even if that leap of understanding was at the expense of short-term productivity.

The best mentors:

  • Meet the learner on their level, without judgment. Rather than assuming a certain level of knowledge, they quietly assess the learner’s current knowledge and make a plan to move them forward from there. If the learner turns out to know more or less than expected in a certain area, they quickly adjust.
  • Let the learner drive, but never forget to navigate: They start by telling the learner explicitly what to type. Next, they hint at what should be typed without saying it explicitly. Later, they simply ask Socratic questions to get the learner thinking in the right direction. As the learner progresses, they give less and less guidance, but they are always ready to step back in when the learner gets lost. Even when the learner is completely lost, they do not take over the keyboard–they simply get more and more explicit in their instructions until the learner is back on steady ground.
  • Gently praise and reassure: Learning something new is taxing on the ego. Hearing an occasional “Good job” or “That’s okay. You’re doing fine,” reduces frustration and keeps the learner motivated.

Mentoring is a complex skill. Anyone can learn to mentor, but it comes more naturally to some than to others. Some developers will see the value in mentoring a new team member, and others would rather be responsible for only themselves.

When a new developer joins the team, it’s critical to pair them not with the best developer, but with the best mentor.

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


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)


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.

Rails Magic

By far the most frustrating part of learning Ruby on Rails was the confusion of dealing with “Rails Magic”. I remember telling someone, “I love Ruby, but I hate Rails. There’s no logic to the things it does.”

It’s a lot like looking at a solution to a complex math problem solved by a mathematician who doesn’t bother writing out the steps she can do in her head.

An experienced mathematician will appreciate not having to write out or read those basic steps, but if someone were to try to learn math by following that example, she would be hopelessly lost.

There are a ton of things in Rails that are helpful shortcuts for experienced Rails developers, but are tremendously confusing for newbies.

For example, there is a seemingly endless number of ways to tell Rails:

If the URL is ‘www.example.com/photos/new’, you should show the template located in the file ‘photos/new.html.erb’

Amongst those endless options, the ones that are most commonly used are the ones that give you the least information about what they are doing behind the scenes.

This is true not just for routes, but for pretty much every part of Rails. It’s chock full of short-cuts and assumptions, and if you don’t know what those short-cuts and assumptions are, it can be quite difficult to understand.

For that reason, I have decided to write a series that will connect the dots between the explicit or long way of doing things and the more commonly-used shortcuts.

Coming up: Part 1: Creating an App

Is Coding Bootcamp Right for You?

I often hear from aspiring developers who wonder if a Coding Bootcamp will teach them enough to get a job as a Junior Developer.

Although I got a great result from Coding Bootcamp, I have seen others who have graduated from coding bootcamp, only to remain stuck in their old jobs.

From what I’ve seen, the main differences between Coding Bootcamp graduates who get jobs quickly after graduation and graduates who go long periods of time without any leads are:

  1. The quality of their job search skills,
  2. Their level of motivation, and
  3. Persistence

There is so much demand for software developers that, with the level of skill gained at a Coding Bootcamp, it is absolutely possible to find a job.

That being said, it is NOT easy. Breaking into a new career never is. Job hunting in general never is. It takes a massive amount of effort to find a job, and entry-level jobs are often the hardest to find. Getting an entry level job means convincing someone that, although you don’t know enough to be immediately useful, you are worth investing the time and money required to train you to be useful.

As in other jobs, employers want to see that you’re passionate about what you do, you’re eager to learn, you learn quickly, and you have a personality that they can handle being cooped up in an office with.

Junior Developers need to demonstrate 2 additional traits:

  1. problem-solving ability
  2. foundational coding skills that can be built upon

So…does Coding Bootcamp teach you what you need to know to get a job?


Coding Bootcamp should give you enough foundational coding skills to meet the technical requirements of an entry-level position. My bootcamp also tried to address problem-solving skills and job search skills, but either one of those skills could consume an entire course on its own.

Yes, most Coding Bootcamps offer job search assistance, but it is just that: assistance. They cannot sit in the interview room and force you to make eye contact. They cannot save you if you become despondent and give up the first time you apply for a job and are not taken seriously. They cannot light a fire under your rosy little cheeks to make you chase a job like your life depends on it.

What they can do is help you get the technical skills you need.

But wait–can’t I get those for free, by working through online resources?

Yes. Yes, you can.

Then why should you go to Coding Bootcamp?

That’s a great question, and maybe you shouldn’t. You can save some big bucks by teaching yourself or by doing FreeCodeCamp.

The benefits of Coding Bootcamp over teaching oneself are:

  1. It’s faster. You will be sprinting for a few months, learning faster than you would ever naturally push yourself to learn. You will be fighting to keep up, and as a result, you will cram more information into your skull in a shorter period of time.
  2. Focus. You will have a period of time that is fully dedicated to learning to code. Having deadlines will keep you pushing forward on days when you otherwise would have prioritized other things. You will also have an excuse to tell your family and friends when they want to distract you from studying.
  3. Live Help. You have access to your teachers and other students, so you spend less time fighting problems and more time moving forward and learning.
  4. Resume Fodder. You will have concrete proof of skill that you can list on your resume, and this could be the difference between getting and not getting an interview.

If you are highly motivated and have time to spare, Coding Bootcamp might not be the best option for you. You can learn the technical skills through FreeCodeCamp and other online resources, and attend meet-ups to get live help and make connections. The job search might take a little bit longer, but you will eventually find something.

The path to the finish line will be faster and easier with a Coding Bootcamp, but it’s not the only option. Whether or not it’s worth the price tag will depend on you: your personality, your timeline, and your finances.

The Trouble with Writing about Work

I’ve received many requests to write about what it’s like working as a Junior Developer.

The point of my blog is to share information that can help others who are trying to break into the field, so I’ve tried to find an angle from which I can approach that subject.

Writing about work, however, is a dangerous endeavor.

I’ve had only one developer job, so if I write about work, there’s no question as to which work I’m writing about.

If I write about the people, I’m invading their privacy. If I write about the company, I’m potentially revealing information they don’t want exposed to their competitors–the tools they use, their processes, etc. It’s hard to write about work without revealing too much about the people or the company.

For those reasons, I can’t write much about my job.

I am, however, completely open to answering any questions you have in a direct message. Send me a message on Twitter, @JulieTorero, and I’ll try to answer as best I can.

Once I’ve put together a good list of questions, I’ll also try to interview a few other Junior Developers and post the cumulative results. Leave a comment if you have anything specific you’d like me to ask, or if you’re a Junior Dev and would be willing to be interviewed.