Slashdot Asks: What Are Some Programming Books You Wish You Had Read Earlier? 137
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?
Python and Tkinter Programming - by John Grayson (Score:2)
Python and Tkinter Programming Paperback – January, 2000
by John E Grayson
...
What? Didn't I shower?
Zero Bugs & Program Faster (Score:3)
Zero Bugs & Program Faster is an interesting book. It's a collection of single-page ideas. It's the kind of thing to have on your desk (or in your bathroom) to read five minutes a day and let idea sink in.
I believe the author may be a Slashdot member.
Domain-Driven Design (Score:2)
A huge, sprawling book but a lot of gold in them thar hills.
Kernighan (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.
Re: (Score:3)
Yeah, I'm unimpressed with a lot of programming/CS books. The thing is, the core underlying concepts don't change even if the tools and frameworks change around them. Algorithms, data structures, complexity analysis... IMO the best introduction to software development is still Oh! Pascal! 3rd Edition (Doug Cooper).
Re: (Score:2)
1984 (Score:5, Informative)
Nineteen Eighty-Four [wikipedia.org]. Hey, you didn't specify computer programming....
Re: (Score:1)
I would but I can't speak russian
Re: (Score:2)
-- Christopher Hitchens
Re: (Score:2)
Well, at least you're funny, I'll give you that.
Re: (Score:1)
Applied to Obama as well. Pull your head out.
Re: (Score:2)
You have to be careful about redefining keywords with pragmas. The compiler might wind up in an infinite loop! Or would that be the macro assembler?
Re: Trump? (Score:2)
Good. Serves the bastard
Re: (Score:1)
Is that a manual for understanding systemd code?
It's the exact opposite of systemd (Score:5, Insightful)
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.
Re: (Score:1)
GNU's Not UNIX...
Re: (Score:2)
Is the Unix philosophy really the best option for everything though? The obvious example is the kernel, which is a giant monolith for performance reasons. Web browsers too - sure you could have one app that renders HTML to an image, another that displays it, a third that wraps a tab UI around them both, use curl to download each page for processing... But it would suck, performance would be a joke and powerful extensions would be near impossible to implement.
Obviously systemd has a lot of issues... But it a
An OS for people who like the Windows philosophy (Score:2)
> Is the Unix philosophy really the best option for everything though?
Some people prefer the Unix philosophy, some people prefer the Windows philosophy. Today I'm not going to argue that either is wrong. There is an operating system for people who like the Windows way.
Re: (Score:3)
But it also boots a hell of a lot faster
I really wish people would stop pretending this matters a damn in most production systems where uptime is measured in years.
There's an edge case around cloud, but until they stop billing in 1 minute blocks I can't see how 20ms matters a damn there either.
Re: (Score:2)
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.
That, my friend, is a shallow analysis.
If you take a closer look, systemd is actually the init software itself and then a bunch of simple tools.
The reason why people hate it has more to do with the fact that Lennart Poettering takes the crufty old parts of the Unix landscape personal.
He wants to see things move. And he somehow has the energy to make it happen, where others have failed.
This in turn means that parts are moving that didn't use to move, which causes a fair amount of breakage.
IMHO this is someth
Compilation of recommended books from "luminaries" (Score:4, Interesting)
Here's a compilation of other "must-read" books from well known developers like "Uncle Bob, and Kent Beck, [and] Jeff Atwood and DHH:"
On medium, sorry for the interstitial: https://medium.com/@shvetsovdm/essential-books-that-every-programmer-should-read-a61565095781 [medium.com].
Will
Clean Code by Robert C. Martin (Score:1)
After I read this, the quality and readability of my code improved.
Re: (Score:2)
This. It has some errors, but it is worth reading.
Personal favorites: (Score:5, Interesting)
The Art of UNIX Programming by Eric Raymond [wikipedia.org]
and
Expert Programming: Deep C Secrets [amazon.com]
The former does a good job, I thought, of outlining what it means to program in the UNIX style. The latter is perfect for a geek like me who wants to learn all about the ins/outs of semantics of a language that I love!
The Art of Computer Programming - 4 vols (Score:5, Informative)
Do all the exercises.
https://www.amazon.com/Compute... [amazon.com]
Re: (Score:1)
Do all the exercises.
And be sure to publish your answers to the M50 problems.
Re:The Art of Computer Programming - 4 vols (Score:4, Insightful)
The Art of Unix Programming, Eric S. Raymond (Score:4, Informative)
The title is a bit misleading. Yes the book talk about Unix design philosophy but It's not about "Unix" programming per say. It's about good design, good file format, good practices... do ONE thing and do it WELL.
Re: (Score:2)
Great book. When I taught, it was my textbook.
Re: (Score:2)
WOW ... didn't realize he died in Sept. 1, 1999.
His TCP/IP Illustrated and UNIX Network Programming series were also classics.
Press F to pay respects.
Re: (Score:1)
Re: (Score:3)
Thanks for posting the other gems written by Mr. Stevens. His books were instructive and readable. They were of immense help when I started out as a fledgling UNIX network programmer.
I'm the original AC... Here's his entire list of works:
1990 - UNIX Network Programming - ISBN 0-13-949876-1
1992 - Advanced Programming in the UNIX Environment - ISBN 0-201-56317-7
1994 - TCP/IP Illustrated, Volume 1: The Protocols - ISBN 0-201-63346-9
1995 - TCP/IP Illustrated, Volume 2: The Implementation (with Gary R. Wright) - ISBN 0-201-63354-X
1996 - TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols - ISBN 0-201-63495-3
1998 - UNIX Network Programming, Volume 1,
The Pragmatic Programmer (Score:2)
Re: (Score:2)
The Practice of Programmng
Composite/Structured design
There are actually a number of good book from MS press published in that 1990’s
The Mythical Man Month (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.
Re: (Score:3, Insightful)
This!
I'd also add Demarco & Lister's Peopleware: Productive Projects and Teams. Another oldie but a goodie.
The Mythical Man Month made me unemployable. (Score:2, Funny)
The Mythical Man Month, combined with Yourdon's 'Death March' made me unemployable.
I couldn't get through even an initial contact with employers, let alone an in-person interview, without noticing and pointing out that most of their questions and requirements are premised on a delusional, self-serving view of reality.
"Everyone on our teams gives 150%!"
It is really sad how much of technology development is based on magical thinking.
Re:The Mythical Man Month (Score:4, Insightful)
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.
Re: (Score:2)
Yes, that's an actual book.
C++ primer plus... (Score:4, Informative)
... by stephen prata.
Despite many elitists decrying the book, it's the best place to start when trying to understand C and C++ as a language as it gives you a bit of background behind how and why C developed and for anyone who's read through many programming books, the hardest part about learning programming is learning to think and understand how a CPU operates. Probably the most fundamental thing I would require all programmers to learn is some c or c++ AND assembly. Why assembly? Because when you're forced to read assembly code you need to get a feel for how cpu's really work and what the stack is and those strange instructions are when you do assembly read outs.
Also I would highly recommend making basic cheats or playing with seemly code in single player games using something like cheat engine. You get experience through reverse engineering and trying to read assembly code.
IMHO reverse enginering is probably the best way to learn for someone who has the discipline and a deep work ethic. The biggest problems for kid starting out is not having any good teachers who have a clue how beginners to programming struggle. Finding a good teacher who has lived through many programming era's and can kind of explain the fucked up half-baked fly by the seat of your pants nature of how many languages were designed is important IMHO. Because many programming languages were designed by experts for other experts, the weren't the result of scentific usability studies. It was really all engineers and nerds making tools for other engineers are nerds and that's fine but the hardest part of programming is taking a problem and understanding it well first and then building a model for code. Your code is only as good as your model or foundation, aka only as good as your understanding of the problem.
I'd tell new programers don't assume that everything that has been invented or that the tools used to program are finished. If I had infinite lifespan I'd go back and do small scale models of simple machines and cpu's and have a visual display of what the computer is actually doing, something like those old Disk defrag programs, aka what the data is doing, where the data is, what is happening. That hardest part of programming is really wrapping your mind around how the machine works and then realizing that programming is really just structured mathematical workflows, anything you program, often will at some point need to be performant and the only way to get high speed or fast software is to really understand how manage how work is batched and processed. That ultimately requires for you to have a good mental model of how the machine works at a low level. At some point in if you ever want to become good you'll need to understand how the computer underneath actually works. Trying to avoid it is just really living in ignorance.
Re: (Score:2)
As long as we're talking about C++ primers, I would add the one by Stanley Lippman. I found it very helpful, particularly the explanations of how overloading, casting, multiple constructors, and inheritance work together.
Guide to Fortran Programming (Score:1)
This book was published very late in my programming career, I wish I read it when I was younger. Daniel D. McCracken, A Guide to Fortran Programming, 1961.
Re: (Score:2)
Crikey, these young'uns. What's wrong with plugboards? [wikipedia.org]
Steve Krug (Score:3)
Don't Make Me Think [amazon.com]
Database Design for Mere Mortals (Score:1)
The design of everyday things (Score:2, Informative)
- "The design of everyday things", the book gives the principles of how to make a good UI into anything, even doors. Especially doors. This is one book I think everyone should read, not only those who design things. I would make it mandatory in schools.
- "Peopleware", very interesting and somewhat funny if you can laugh at your own misfortune. Book with lots of studies about people, projects and companies.
- "Clean code", a book about programming, it made me realize that reading code is about 10 times slower
Martin Fowler's Refactoring (Score:5, Interesting)
Every fresh-out-of-college kid's first jobs are basically fixing the bugs left behind by the architects and experienced coders who either have left the company or have better things to do with their time.
Understanding how to make code changes safe is a vital part of that job, so the sooner a kid (I'm 48, they're all kids) is comfortable with the ways to restructure code safely for fixing issues and adding features, the better. It is a core part of modern software engineering, but is rarely taught in schools, at least not actively.
I developed a habit of this, but would have done so faster and with more confidence had I had the book and the vocabulary in mind.
Read these books for for free (Score:1)
Re: (Score:2)
Re: (Score:2)
i wish i read (Score:2, Funny)
1001 other jobs better than being a programmer
May not seem related but (Score:3)
The only methodology that works (Score:1)
SQL Antipatterns (Score:4, Informative)
Thinking in C++ (Score:2, Informative)
I learned a lot from it.
Data structures & algorithms (Score:3)
Multipliers (Score:4, Interesting)
Multipliers [harpercollins.com] is not a programming book, but it will make you a better programmer.
Multipliers looks through the lens of the tech industry to show examples of people who are a "multiplier" and people who are a "diminisher". The idea being that when working with a multiplier, people feel that they are working hyper-efficiently, while with a diminisher they are working at sub-optimal.
This book changed the way I think about teamwork: it's not just about being a rock star yourself, but about making your team the rock star. It helped me identify facets of my working style and past experiences that, if acted on differently, will enable people on my team to shine with minimal additional effort from myself.
Algorithms, not code (Score:4, Insightful)
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
MOTIF Programming by Marshall Brain (Score:3)
Re: (Score:2)
Design and Evolution of C++ (Score:2)
Even if you don't like C++ much, The Design and Evolution of C++ [amazon.com] is a great book for understanding why pretty much any language ends up the way it does, seeing the tradeoffs and how a language comes to grow and expand from simple roots. It's way more interesting to read than you might expect (not very dry, and more about human interaction than you would expect).
Other than that reading through back posts in a lot of coding blogs that have been around a long time is probably a really good idea.
Also a side re
What about books that hadn't been written yet? (Score:2)
You young whippersnappers don't 'preciate how good you have it!
Back in my day, the only book about programming was the 1401 assembly language manual!
But seriously, folks, it's pretty clear we still don't know shite about how to program properly. We have some fairly clear success criteria for improving the hardware, but the criteria for good software are clear as mud, and the criteria for ways to produce good software are much muddier than that.
Having said that, I will now peruse the thread rather carefully
TMI, especially PII (Score:2)
Couldn't find any mention of Guy Steele, so I'll throw in The New Hacker's Dictionary , which I once owned in dead tree form. Not sure if Version 4.4.7 http://catb.org/jargon/html/ [catb.org] is the latest online... Also remember a couple of his language manuals. Probably used the Common Lisp one the most...
Didn't find any mention of a lot of books that I consider highly relevant, but that may reflect my personal bias towards history. Not really relevant for most programmers.
TMI, but if I open up my database on all t
Programming is about **Effective Communication** (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 [wikipedia.org]: 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 [stanford.edu]
b) Algorithmic -- Algorithmic complexity or Analysis of algorithms [wikipedia.org] (such as Big-O notation)
c) Data-Orientated Design [dataorienteddesign.com] -- 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
Shared this with my team (Score:4, Insightful)
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.
Re: (Score:2)
> You crammed a lot of good ideas into a short post.
> I'm sending my team at work a link to your post.
I was getting a little worried it might be TOO long but glad you, and hopefully others, found it helpful.
> "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
That's true with all the (great) programmers I've seen. 100% agree with Linus on this.
> Once the data structure is right, the code often almost writes itself
It's almost "funny" oft
Re: (Score:2)
This is a great post.
I wish Slashdot had more thoughtful posts like yours.
A MS book about writing solid code. (Score:2)
Ages ago, Microsoft made a book [amazon.com] for writing bug-free C code. It was surprisingly good for its time.
Thinking Forth (Score:3)
FightClub (Score:1)
Printed manual pages (Score:2)
Old versions of real Unix had printed manual pages. You could start at the beginning and read the whole thing. It was a great way to understand the full scope of a system. Also reading all the entries in a fixed order means your not missing anything.
My list (Score:3)
The C Programming Language
Design Patterns (gang of four)
Advanced Unix Programming
Code Complete
(any book on threading and parallelism)
Core J2EE Design patterns (was a sun press book)
Operating System Concepts (or Modern Operating Systems)
Mac OS Internals
Programming books which have helped me (Score:1)
These books don't appear in Jacobs' list but they are excellent books for becoming a better programmer. Pragmatic programmer is especially useful, I found it changed my approach to Software development such that I would more careful with taking on extra work and managing my work so that I would not fall behind and be able to complete it. Highly
BCPL: The Language and its Compiler (Score:1)
By Martin Richards.