- Hm. Books about the underlying principles, protocols and architecture. D.E.K is certainly a classic for algorithms (though I only skimmed some sections). McKusick, Mauro, the Magic Garden Explained, and R.W.Stevens for Unix and network. Small gems like Gancarz' Unix philosophy or Kernighan/Pike's Practice of Programming (that's small as in size).
Get the paradigms and principles down pat, the rest is mostly just intelligently combining/layering/playing with them.
Add small gems like Gancarz' Unix philosophy or Kernighan/Pike's Practice of Programming.
- Cweb (but currently templates being run through embperl and POD is about as near as I go there). Not for real stuff.
- Math: Logic, signatures and reasoning about signatures are probably the most important sections.
- Code reading: a) kind of the impossible approach of 'incremental-proof-by-repetion', with sometimes asking questions of more or less isolated code sections. b) Sometimes. c) Well-structured functional code is enjoyable and doesn't require much documentation and commenting (if the architectural big view _is_ documented).
- Prototyping: Puncture the problem field with a "tunnel-prototype" (also takes care of feasibility), top down with abstracts and stubs, then bottom-up. Afterwards it's just Groom, Grow, Repeat. But the programming projects usually aren't that huge, and more of a side show.
- Being able to abstract and communicate. Perl virtues + Paranoia. Being able to structure and overthrow structure & play with abstraction levels. Background knowledge and interest in the underlying principles and protocols. The ability to not forget about the correct amount of documentation, esp. for the big view. Aversion of both Huffman-encoded source as well as MVS documentation-style.
- Frameworks and skeletons certainly changed some things, with a tendency for a lack of overview/big-picture, and a tendency for excess fat, while requiring more memorization of not-that-relevant details like object names, etc. So memorizing got more important and may even hide a dangerous lack of skill, abstract thinking and background knowledge. See also (6).
- The "hard" boundary between craftsman and artist is a fairly recent misconception. All of the terms describe more or less the same area, when you consider the common historical root of all of (science,) math and arts. A bit of everything, I guess.
Update 1
Ad 6/7: Roboticus point in the first comment about
The "big picture" skills don't change: You need the passion and talent for problem solving. You need good communication skills to work with your clients. The "little picture" skills (programming languages and such) change frequently enough, but it's unimportant, because you can adjust your skill set as needed
is also an important observation. With the little picture skills sometimes hiding (or causing) fatal holes in the big picture.
Of course for a small number of the little picture skills, an intent to improve to expert level is IMHO also required for a good programmer, even if only to anchor/compare other skills or knowledge against.
