

The pragmatic programmer tips - kunqiana
http://pragprog.com/the-pragmatic-programmer/extracts/tips

======
j_baker
If there's one thing in here that I wish I could drill into every programmer's
head, it's that abstractions are longer-lived than details. So few programmers
seem to understand how important abstractions are.

~~~
hga
According to the Antipatterns book, only 1 in 5 programmers "get" abstraction,
which roughly matches my quarter century experience in the real world.

A corollary of this is that absent really good hiring practices, "democratic"
design processes are _doomed_ to fail, since the non-abstractionists
invariably out vote the ones who get it.

~~~
dpritchett
This is a fascinating comment. As someone who thinks he gets abstraction I'd
love to hear some real world examples on the off chance I'm deluded. How do we
know if we're actually non-abstractionists?

~~~
hga
Pretty much by definition you'd have to be told by an abstractionist ^_^.

More usefully, look at some APIs that have earned serious respect, especially
by people who clearly are abstractionists. If you don't "get" too many of the
reasons why, then you probably aren't (yet) an abstractionist.

This also applies to languages and idioms in them. If you grok SICP, you're
probably an abstractionist (if you don't, I wouldn't say you necessarily
aren't one).

The best self-test, and it's eerie when it happens, is that you design a
greenfield (new) architecture and start building it, and then discover that it
solves problems you didn't realize you had. I suspect this requires a fair
degree of experience: it happened to me in the mid-90s, having stared
programming in 1978 ... although maybe I got a taste of it in 1992. But it
might have happened earlier if I'd had a chance to do a greenfields project
earlier.

Some facility with abstract math is a good sign, e.g. can you do pure
algebraic manipulation, especially outside the context of solving a real world
problem?

------
GFischer
"Test Your Software, or Your Users Will Test ruthlessly. Don’t make your users
find bugs for you." At my current workplace, this is seen as a feature, not a
bug! (having the users find the bugs). And no, I don't work for Microsoft.

------
ledger123
I have not read this book but the list of tips seemed to be bit too much. I am
really a fan of all simplicity and tips from getting real book.

But someone who has read both books can explain it better.

~~~
Sukotto
Well, for what it's worth, I really liked it and consider it a keeper. It's on
my bookshelf between "Programming Pearls" and "Mythical Man month".

It's less about programming per se and more about how to _think_ about
programming.

