Programming Mistakes

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.

http://ycombinator.com/newsguidelines.html

If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."

Anyway, the fact that he thinks these need to be stated is interesting in and of itself. Points 1-3 just come down to judgement that you develop as your career progresses. You start to know when a problem should be googled, when a library is necessary, or when something should be rolled on your own. There's no way to feel this in your bones without practicing and running into what it feels like when it's been violated.

Making quick fixes vs. permanent ones should be dictated by how corner-case the fix is and the time that would be consumed to make an abstraction to handle it cleanly. It's about striking a balance between over and under engineering. Again, this comes down to judgement and experience.

It's seemingly easy to understand this on an intellectual level. Getting on an experiential level is another thing altogether.

Ignoring warnings is an obvious no-no.

This used to be a big one for me. About 6 months ago, I saw a presentation on hacking CMS' and how vulnerable they are. One of the main points was to make sure you pen test third party applications before you install and use them. It was a big eye opener for me.

I'm no longer just assuming the authors did their due diligence and made sure their apps or plugins are secure before releasing them.

The most common error that I see is the programmer trying to make the code works, or trying to fix the error, using trail and error, instead of understanding the problem and make a better solution.

You won't challenge your mind any more by not searching, that way you're just being stupid. Besides, it's much easier to create original works if you know what's original and what's not. This is why you should be studying other's work before you do your own.

His advice about copying is entirely wrong, because even if you don't understand some code, it can still be okay to use it in your project.

The biggest problem with copying is that you easily get more lines of code you have to maintain. This is especially bad if you copy large chunk of code, which may improve later. If that happen you have to do the copying again to get the improvements. Link or import the code you need instead!

I think he should rather state to think clearly. You should always think for yourself about using a library. Does it fit your needs? Use it. If it doesn't, do not use it. You will not save time or your mind by using something that doesn't fit.

I think this article's biggest problem is that he's using running phrases too much, that are correct but without meaning: "If you skip work, you have to work more later" Obviously.

Also anything can be taken as art, even things not made by human! "Think of programming as an art". What does he mean?

Also what's the point of having errors that prevent you from executing the rest of program? One error in one module shouldn't prevent huge suite from compiling.