Slashdot Mirror


Slashdot Asks: What Are Some Programming Books You Wish You Had Read Earlier?

A blog post from developer turned writer Marty Jacobs caught my attention earlier this morning. In the post, Jacobs has listed some of the programming books he says he had discovered and read much sooner. He writes, "There are so many programming books out there, sometimes it's hard to know what books are best. Programming itself is so broad and there are so many concepts to learn." You can check out his list here. I was curious what books would you include if you were to make a similar list?

4 of 137 comments (clear)

  1. Kernighan by brausch · · Score: 5, Interesting

    They are old, but all of the books that Brian Kernighan was involved with: Software Tools, The Elements of Programming Style, etc. The writing and editing in these books is excellent. Too bad there isn't a new generation of them.

    --
    "Almost every wise saying has an opposite one, no less wise, to balance it." - George Santayana
  2. 1984 by Anonymous Coward · · Score: 5, Informative

    Nineteen Eighty-Four. Hey, you didn't specify computer programming....

  3. The Mythical Man Month by bobbied · · Score: 5, Informative

    The Mythical Man Month is a MUST READ for anybody who is or manages any kind of software development staff (Really, any kind of engineering staff). Fredrick Brooks remains spot on in his observations of how software development processes and teams actually work in real life. This book was written back in the 60's, revised in the 70's but remains applicable to modern projects. Brooks is exceedingly insightful and his observations which boil down the real issues of software development still apply decades later. He may have worked on what's now considered antiques using languages which have fallen out of fashion long ago, but his focus on the practicalities of software development makes this book timeless.

    Yea, it's not a "programming" book per say, but if you develop software using a team, or do any kind of engineering work with others, the insights in this book are invaluable to you and your management. I read this book every few years and share it with my management when appropriate.

    --
    "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
  4. Programming is about **Effective Communication** by UnknownSoldier · · Score: 5, Insightful

    I've been programming for the past ~40 years and I'll try to summarize what I believe are the most important bits about programming (pardon the pun.) Think of this as a META: "HOWTO: Be A Great Programmer" summary. (I'll get to the books section in a bit.)

    1. All code can be summarized as a trinity of 3 fundamental concepts:

    * Linear; that is, sequence: A, B, C
    * Cyclic; that is, unconditional jumps: A-B-C-goto B
    * Choice; that is, conditional jumps: if A then B

    2. ~80% of programming is NOT about code; it is about Effective Communication. Whether that be:

    * with your compiler / interpreter / REPL
    * with other code (levels of abstraction, level of coupling, separation of concerns, etc.)
    * with your boss(es) / manager(s)
    * with your colleagues
    * with your legal team
    * with your QA dept
    * with your customer(s)
    * with the general public

    The other ~20% is effective time management and design. A good programmer knows how to budget their time. Programming is about balancing the three conflicting goals of the Program Management Triangle: You can have it on time, on budget, on quality. Pick two.

    3. Stages of a Programmer

    There are two old jokes:

    In Lisp all code is data. In Haskell all data is code.

    And:

    Progression of a (Lisp) Programmer:

    * The newbie realizes that the difference between code and data is trivial.
    * The expert realizes that all code is data.
    * The true master realizes that all data is code.

    (Attributed to Aristotle Pagaltzis)

    The point of these jokes is that as you work with systems you start to realize that a data-driven process can often greatly simplify things.

    4. Know Thy Data

    Fred Books once wrote

    "Show me your flowcharts (source code), and conceal your tables (domain model), and I shall continue to be mystified; show me your tables (domain model) and I won't usually need your flowcharts (source code): they'll be obvious."

    A more modern version would read like this:

    Show me your code and I'll have to see your data,
    Show me your data and I won't have to see your code.

    The importance of data can't be understated:

    * Optimization STARTS with understanding HOW the data is being generated and used, NOT the code as has been traditionally taught.
    * Post 2000 "Big Data" has been called the new oil. We are generating upwards to millions of GB of data every second. Analyzing that data is import to spot trends and potential problems.

    5. There are three levels of optimizations. From slowest to fastest run-time:

    a) Bit-twiddling hacks
    b) Algorithmic -- Algorithmic complexity or Analysis of algorithms (such as Big-O notation)
    c) Data-Orientated Design -- Understanding how hardware caches such as instruction and data caches matter. Optimize for the common case, NOT the single case that OOP tends to favor.

    Optimizing is understanding Bang-for-the-Buck. 80% of code execution is spent in 20% of the time. Speeding up hot-spots with bit twiddling won't be as effective as using a more efficient algorithm which, in turn, won't be as efficient as understanding HOW the data is manipulated in the first place.

    6. Fundamental Reading

    Since the OP specifically asked about books -- there are lots of great ones. The ones that have impressed me that I would mark as "required" reading:

    * The Mythical Man-Month
    * Godel, Escher, Bach
    * Knuth: The Art of Computer Programming
    * The Pragmatic Programmer
    * Zero Bugs and Program Faster
    * Writing Solid Code / Code Comp