
Programming Mistakes - rs_
http://www.singhrahul.com/2013/07/5-programming-mistakes-you-should-stop.html
======
danso
I have to disagree with a lot of these "mistakes"...in certain (many)
contexts, they might be actual mistakes...but sometimes they are necessary and
efficient practices.

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.

~~~
k3n
With respect to "searching for a fix on Google", I think you made a logical
jump that caused you to overthink it -- he specifically mentions programming
-- as opposed to _debugging_, which is what you seem to be getting at. While
debugging is indeed an aspect of programming, I think the author was
specifically speaking to programming.

And in that case, I couldn't agree more: if you have a programming challenge,
you should at least make an honest attempt at it before consulting Google.
Don't waste a lot of time on your own, but at the same time, at least give it
a shot.

------
hvs
Please review the submission guidelines for HN:

[http://ycombinator.com/newsguidelines.html](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."_

~~~
rs_
My mistake. Shouldn't have included the number in title. If any moderator is
reading this, please change the title. I can't edit it myself. Thanks :)

------
mataug
While I appreciate the writer's intention to write about these things,but I
wish he had read the article titled "5 mistakes never to make as a novice
writer".To put it bluntly, Its way too long and preachy. I am no saint myself
though. Anyway the points put forth are quite right.

~~~
1wheel
Or used a non link baity title.

------
d23
OP should bold the headers. If he doesn't understand how to make an article
readable, it makes me question whether he understands how to make code
readable.

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.

------
lucisferre
I'd argue these are examples of bad habits rather than outright mistakes (and
yes, there is a difference).

------
at-fates-hands
"Sometimes, the code you are copying may be so large that you don't have time
to understand it completely. If you copy any code this way, there is a risk of
making your applications vulnerable and buggy."

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.

------
rhapsodyv
\+ Trial and Error

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.

~~~
pjungwir
That's just what I wanted to say. I call it "debugging by superstition." I
think there's a fine line between this and a useful hunch, but there is a
difference. Superstitious debugging is rapid-fire, change-a-line-and-try-
again. A hunch extrapolates from the evidence and your experience, and it
leads to an experiment to prove or disprove it. In the sysadmin world, Rachel
by the Bay has some great stories about following hunches.

------
sonabinu
I think the one about googling before trying is so true!

------
gailees
Meh. #hackermindsetFTW

------
touristtam
ok, but this wall of text is not very nicely formatted.

------
tlongren
I stopped reading at "more better".

~~~
vowelless
You're penalizing a non-native English speaker for minor English grammatical
problems? Why not offer to help him instead?

~~~
tlongren
I didn't penalize him. I just couldn't read past there. I actually upvoted
him. lol.

------
cheery
If you stumble upon a new problem that's unknown to you, you should ALWAYS
search what others have done. Only after that you'll try yourself if
necessary, knowing the mistakes others made. Good programmers are lazy.

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.

~~~
mattmanser
Why have you made 3 posts on this thread?

~~~
cheery
They contain different points I noted, in the pace I discovered them. I can do
as many posts as I want, do I?

Or did you mean that I can EDIT the single post, until it contains everything
I want to tell? Sorry. I did not figure that out until now.

~~~
dllthomas
Really if they're self contained, I prefer different points in different
posts; makes it much easier to see what people are replying to.

------
cheery
Copy-pasting code without understanding is functionally same as importing
large libraries or linking to them. You'll have same problems even if you
didn't copy anything! This is why good programmers review code and prefer open
source.

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!

------
cheery
I've been always better off by starting with an empty file. It lets me
concentrate on the problem I am solving, with no fringes or bells that belong
to the finished product. Also starting from scratch is great if you're stuck.
If something prevents this behavior, you're better off by tossing it away.

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.

~~~
LanceH
Using a library is just one giant copy/paste, right?

------
cheery
Quick fix can be permanent fix. Those adjectives do not exclude each other
out.

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?

~~~
chc
This is your fifth top-level reply. It becomes a bit overwhelming when one
person is the entire comment screen. Please, in the future, collect your
thoughts and put them into one comment.

~~~
pkroll
Isn't there something to be said for splitting up the comments, so you don't
get a single thread that covers five different points and nests forever?

~~~
chc
No, I don't think there is. They are all still broadly on the same topic.
Imagine if I made each sentence here a separate reply. I mean, they are
separate sentences and could conceivably be responded to individually, but it
would still be pretty silly, wouldn't it?

The only case I can see for doing multiple sibling comments is if you have
several truly unrelated thoughts that each deserve a deep treatment. But
that's not what's going on here. As cheery noted elsewhere, he/she simply
didn't know you could edit comments.

------
cheery
What's the point of having warnings in the first place, if you treat them as
errors?

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.

