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?
Most of the backlash against systemd isn't because it's *bad* per se, but because systemd is in so many ways the opposite of the Unix philosophy.
Windows and Unix have very different approaches. Windows has MS Office and Word, a multu-gigabyte word processor with literally thousands of functions. Unix has sed, awk, grep, sort, and cut. Each a few kilobytes at most, each doing one small job. In Unix complex jobs are done by piping together small, simple pieces.
Unix manages complexity by building on top of simplicity. Windows manages complexity by hiding it under a veneer, putting the complex stuff at the base and trying to build simplicity on top of complexity. Each approach has its own strengths. The first, building complex systems by putting a simple on top of simplicity, stacking simple layers, is very much the Unix way. Systemd is very much the Windows way of having a bunch of complexity underneath and then throwing a UI on top that is supposed to make it appear simple.
TAOCP's exercises are great. They're crafted so that once you're through them, you will have a great conceptual knowledge of the algorithms. This is important as you will rarely be told to simply "write this algorithm" -- instead, you'll need to decipher real-world requirements and be able to recognize when one of the algorithms can be applied.
Sad to see these are all books about coding and coding style. Nothing at all here about algorithms, or data structures.
My vote goes for Algorithms by Sedgewick
This!
I'd also add Demarco & Lister's Peopleware: Productive Projects and Teams. Another oldie but a goodie.
Mythical Man-Month is pretty much dated by now. While Brooks had a lot of excellent insights, he had some clinkers too, and most of his insights have become common knowledge. There's a few chapters still worth reading, but most of the book is either common knowledge or wrong or irrelevant. Lots of people still haven't absorbed its lessons, but if they haven't by now they aren't going to be helped by any book.
There was a Silver Anniversary edition twenty-five years after initial publication that had his essay "No Silver Bullet", which is also very insightful for its time. It also contains some notes on what in the original was right and wrong. If you're going to read the book, try to get this edition.
A lot of the charm of the book is simply the writing. Brooks is an excellent writer, and doesn't even try to have excuses for the mistakes he made.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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:
And:
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
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
You crammed a lot of good ideas into a short post.
I'm sending my team at work a link to your post.
You mentioned code can data. Linus Torvalds had this to say:
"I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful [â¦] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important."
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
I'm inclined to agree. Once the data structure is right, the code oftem almost writes itself. It'll be easy to write and easy to read because it's obvious how one would handle data structured in that elegant way.
Writing the code necessary to transform the data from the input format into the right structure can be non-obvious, but it's normally worth it.