
Things Every Programmer Should Know - swah
http://programmer.97things.oreilly.com/wiki/index.php/Contributions_Appearing_in_the_Book
======
davedx
#1: Don't waste your time reading pointlessly generalised "N things that you
should something" blog posts.

~~~
qompiler
But I have noticed that constantly programming and thinking about software
design is hurting the quality in the end. Letting the mind drift of once in a
while helps me slow down a bit.

It kind of feels like I'm offloading my thoughts for re-factoring in the back
of my mind while I'm doing something else.

~~~
jaredmcateer
John Cleese has a great talk on creativity[1], a big part of it is essentially
guided day dreaming where you let your mind wander but gently come back to the
topic you're trying to work on from time to time.

[1] <http://vimeo.com/18913413>

~~~
leetrout
Thank you so very much for this. Pure gold.

------
ryanbrush
Funny to see this here. That wiki was used to put together the contributions
for the book, and the fact it wasn't planned as a high-volume site is pretty
obvious right now.

There are a number of items worth reading from some pretty good writers in
there (Verity Stob, Michael Feathers, Scott Meyers, Uncle Bob, to name a few.)
Mostly short vignettes but I enjoyed them.

(Disclosure: I wrote 2/97 of that book, but there are many chapters in there
better than mine).

------
tokenadult
As a foreign language major in my undergraduate studies, I have to like item
49, "Learn foreign languages," and of course many participants on Hacker News
practice that by learning English as a second language. (You know the old
joke, right? Q: What do you call a person who knows two or more languages? A:
Multilingual. Q: What do you call a person who knows only one language? A:
American.) Learning a human natural language and its arbitrary rules (which
will always differ from the arbitrary rules of your native language) provides
a test case of what's involved in comparing different computer programming
languages.

I was surprised that over 97 items there isn't even one item mentioning the
importance of knowing a lot of mathematics. I would emphasize that as one of
the top ten items if I were compiling a list like this. I have learned from
working programmers who know a lot of mathematics that they think many of
their fellow programmers could spot solutions for industry problems easier if
only they recognized the mathematical structure of the problems they are
trying to solve. In general, learning mathematics thoroughly at the primary-
to-undergraduate level in a problem-solving curriculum builds problem-solving
skills

[http://www.artofproblemsolving.com/Resources/articles.php?pa...](http://www.artofproblemsolving.com/Resources/articles.php?page=problemsolving)

that generalize well to solving programming problems.

~~~
csense
I found foreign language study to be entirely irrelevant to programming.

In my experience, foreign language study consists of the memorization of
lengthy lists of vocabulary words and verb suffixes. There's almost nothing
_but_ memorization, and if you forget a word or something, you're dead in the
water unless you can remember it. I wasn't very good at it, it wasn't very
much fun, I never used it and I've retained almost nothing. Other than
satisfying graduation requirements on paper, I've gotten absolutely zero value
out of it.

Whereas with programming or mathematics, the memorization is minimal, the
focus is on abstract ideas you use to represent problems and the way you put
together the building blocks you know. You might memorize a string of symbols
like this:

    
    
        x = (-b +- sqrt(b^2 / 4*a*c)) / (2*a)
    

But if you happen to forget that string of symbols and need to know the
quadratic formula, you can start from first principles "I have an equation of
the form:

    
    
        a*x^2 + b*x + c = 0
    

and I need to get x by itself." With a little algebra (completing the square),
you can re-derive the quadratic formula. Or if you only care about numerical
solutions, you can use Newton's method or bisection. Or you can use your
trusty TI-89 to derive the answer for you. The point is that, because
everything is abstract ideas that fit together, forgetting things isn't
usually a showstopper, because you can just use the problem-solving skills and
tools you _do_ remember to come up with a good-enough replacement.

Likewise, with programming, once you know how to do "everything" (i.e. have
mastered the bare minimum amount of syntax to write Turing-complete programs),
if you forget about a standard library function or the implementation details
of a particular algorithm, you can always write your own version with enough
time, patience, and debugging.

~~~
ColinWright
Your experience exactly matches my experience at school. However, I have since
learned that I _can_ acquire other languages, and I can communicate
effectively in them, and it's nothing to do with pure memorisation.

Yes, you need to memorise some things, but I've found that once I've got a few
hundred words, the structures start building themselves in my brain. I don't
bother memorising verb endings, they start to come of their own accord when
I'm communicating with people. I read simple novels in my target language,
spotting when the same words turn up multiple times and looking them up to
make sure I've got the right definition.

Things accrue, the structures emerge, and suddenly I'm a parody of a
foreigner, but I can communicate.

Your characterisation of math and programming needing effectively no
memorisation is similarly counter to my experience. You need to know some
things, they need to be as natural as breathing, otherwise when confronted by
a huge structure to build, you have nowhere to start. Without knowing some of
the standard results, sometimes even the statements of problems in math make
no sense.

Try working with code written by complete beginners as they've struggled, and
failed, to implement something beyond their current skill set, and you will
find that you know, and have memorised, much more than you think. Pair program
with a beginner and you will be frustrated at how little they know, things you
take for granted, things you have memorised.

So my experience is that learning a foreign language is not entirely
irrelevant to programming. For you to say it is, from your personal
experience, makes me wonder if you have actually ever learned one.

Can you tell us your experience base? How many (natural) languages can you
communicate in?

------
piqufoh
One thing O'Reilly 'programmers' should try; cacheing their websites before
posting on HN

~~~
duiker101
They already do, or at least hope that google does for them...

------
stevejalim
Related to this: [https://leanpub.com/97-Things-Every-Programmer-Should-
Know-E...](https://leanpub.com/97-Things-Every-Programmer-Should-Know-
Extended)

------
suchabag
This link has been posted several times before
([https://www.hnsearch.com/search#request/all&q=97+program...](https://www.hnsearch.com/search#request/all&q=97+programmer&start=0)).
What's the HN best practice for this?

~~~
swah
I guess "You should post again when you read it and find it interesting,
independently from previous postings". HN detects reposts, but I don't know
the algorithm.

The other day it didn't let me repost a link last posted almost 2 years ago.

------
oemera
Google Cache:
[http://webcache.googleusercontent.com/search?q=cache:vmu82nX...](http://webcache.googleusercontent.com/search?q=cache:vmu82nXiMmoJ:programmer.97things.oreilly.com/wiki/index.php/Contributions_Appearing_in_the_Book+http://programmer.97things.oreilly.com/wiki/index.php/Contributions_Appearing_in_the_Book&hl=de&client=firefox-a&gl=de&strip=1)

------
edwintorok
The title reminded me of a good article series from 2007 "What every
programmer should know about memory": <https://lwn.net/Articles/250967/>

~~~
Shamharoth
pdf version : <http://www.akkadia.org/drepper/cpumemory.pdf>

------
optymizer
#2 "Apply Functional Programming Principles" talks about passing your input as
parameters to functions performing some work based on those inputs.

Yeah, "functional". Hello, C.

~~~
viscanti
I've seen lots of legacy code that's had parameters hard-coded. I don't know
that parameterizing functions (with things you might want to be variable in
the future) is "functional", but it's still sometimes useful.

------
lignuist
Such lists are supposed to be short to be memorable ...

Otherwise you can call it "1001 Things Every Programmer Forgets".

------
keithtom
making this for my kindle <http://readlists.com/c130caf3/>

------
xradionut
98: Programming subject matter books have errors and practices that don't
always apply to real world programming.

------
martinced
_"Know your IDE"_

I'm getting to the point where I can write elisp functions adding cool
functionalities to Emacs (like jumping to a function whose name appears in a
comment), does this count as knowing my IDE? ; )

I must have it all wrong: I did follow pg and Steve Yegge's advices and
learned Emacs and Lisp ; )

I'm probably not a programmer...

~~~
Sandman
I'm confused as to why you think that you're not a programmer. I think it's
awesome that you've become such a master with your development environment
that you're able to integrate various functionalities not normally found in
mere text editors into it.

~~~
jasonlotito
He's being facetious.

------
1qaz2wsx3edc
Link bait

~~~
triplesec
Yep. Really annoying since I might actually like it if they presented it to us
as a book. It's a nerdy kind of rickrolling this.

~~~
andrewcooke
it _is_ a book. [http://www.amazon.com/Things-Every-Programmer-Should-
Know/dp...](http://www.amazon.com/Things-Every-Programmer-Should-
Know/dp/0596809484)

~~~
triplesec
Yes, that much is obvious! what I meant, but it seems wasn't very clear about
is that I wish they'd said this in the title of this blog / HN post.

