

97 Things Every Programmer Should Know - Garbage
http://www.infoq.com/news/2009/09/97-things

======
devmonk
While I think it is great to put together information like this and I look
forward to it becoming more useful as it is expanded, these wiki pages are
currently woefully short and contain generalizations that could do more harm
than good.

Some examples:

\- Only the Code Tells the Truth: "Remember that useful code is used much
longer than ever intended."

The author was trying to make the point that you should name variables,
methods, etc. well and write code that is not too spaghetti-like, such that
those reading your code will easily make sense of it. This statement doesn't
convey that.

\- Speed Kills: "Professionals do not write bad code — ever."

The point that the author is trying to make is that you should take your time
with coding. But professionals do make mistakes, including writing bad code,
and they learn from them.

\- The Golden Rule of API Design: "That's where the Golden Rule of API Design
fits in: It's not enough to write tests for an API you develop; you have to
write unit tests for code that uses your API. When you do, you learn first-
hand the hurdles that your users will have to overcome when they try to test
their code independently."

The point the author is trying to make is that you should _use_ the API you
are writing. That is not what is necessarily conveyed.

\- Write Tests for People: "It is also a good idea to test your tests."

What this means is tweaking the test/etc. so it fails under each circumstance
that it is supposed to test, as much as that is feasible to do. But it sounds
like the author is saying to write tests for your tests... Noooooooo! Don't do
that, unless absolutely necessary, or an infinite loop of writing tests for
tests awaits.

There are a number of other generalizations in them, but basically- there is
good intent there, but it is way too early to be looking to these for
guidance. Please contribute to them, though.

