As someone has said already, copying-and-pasting code is little different than implementing a library...and I'll be the first to admit that I don't understand how many of the libraries I use work underneath...but what I do understand is the ability to read tests/specs and see if the library behaves as it should, regardless of how it works underneath the hood.

And I would say "searching for a fix on Google" is almost always the first thing a beginner should do. Some bugs are just undecipherable (segmentation faults in Ruby, for example) and could result for reasons that are far beyond a beginner's knowledge. At least with Google, you have a chance of finding a solution, and being good at Googling helps you also get better at recognizing the relevant parts of an error message (i.e. don't include your local variable names in your Google search).

The one mistake that the OP omitted...and I think this is a huge one...is that beginners try to do too much. They want to build a Rails app...OK, fine, but they don't realize there's a lot of middleman steps worth doing before launching an app...such as organizing/visualizing the data, or deploying a simpler stack, etc., that all builds toward the goal of making a Rails app.

And this is the way it is with method composition. Don't make a method that scrapes data, parses it, and stores it into a hard-coded named database....write a method that contacts the website, another method to read the appropriate section of the site, then another method to parse it, line by line, and then a host of methods that acts on each line: cleaning, validating, and storing it.

When working with beginners, I find that there is a great inability to see how that last unit method fits into the bigger picture...because it just seems like that line-focused method should be a part of all the other methods...and yet that is where madness lies...I would argue that all of the other 5 mistakes mentioned by the OP stems from this inability to understand orthogonality.