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?
Python and Tkinter Programming Paperback – January, 2000
by John E Grayson
...
What? Didn't I shower?
A huge, sprawling book but a lot of gold in them thar hills.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
...it would be cool to add a download link for a pdf file :D
Thanks :D
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
Nineteen Eighty-Four. Hey, you didn't specify computer programming....
by Gancarz
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.
Will
remove nospam. to email!
After I read this, the quality and readability of my code improved.
The Prince by Niccolò Machiavelli.
Gang of Four: https://en.wikipedia.org/wiki/Design_Patterns
Martin Fowler's Refactoring book: https://martinfowler.com/books/refactoring.html
Kent Beck's TDD Book: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
The Art of UNIX Programming by Eric Raymond
and
Expert Programming: Deep C Secrets
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!
remove nospam. to email!
Do all the exercises.
https://www.amazon.com/Compute...
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.
Will $CURRENT_YEAR be the year of the Linux Desktop?
I almost can't believe he's been gone for 20 years...
W. Richard Stevens, Advanced Programming in the UNIX Environment.
Andy Hunt and Dave Thomas
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
This book by Mark A. Ludwig was a really good read. Not that I intended to write viruses, but it really helped me understand assembly language and OS organization. I wish I had read it as a teen.
The unabridged version, of course.
... 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.
https://www.amazon.com/CLR-via-4th-Developer-Reference/dp/0735667454
Really don't see why I would need to..?
Would have saved the world from enduring even more shite code.
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.
Don't Make Me Think
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.
By Michael Hernandez Not a line of code in the book, but perhaps the best volume on how data is organized and how database elements are related, linked, connected and how to use things like keys and constraints and what normalization does. The best book to read before you begin to write code if you are doing anything at all that requires a database or connects to one.
- "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 than writing it, so spending extra time making code more readable is worth of it.
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.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
Shameless plug for the company I work for: several of the books mentioned in this thread are available online in the O'Reilly platform (aka Safari Books Online). Free trial for 10 days, no cc required, completely opt in. I especially like the Mythical Man Month, it changed the way I handle estimates and and scheduling" Operating System Concepts 9th Edition https://learning.oreilly.com/l... Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition https://learning.oreilly.com/l... Artificial Intelligence for Games 2nd Edition https://learning.oreilly.com/l... Free trial is at: https://learning.oreilly.com/r...
IT-related standards from renowned organisations and certain governments/public institutions. And I am saying this despite trusting a lot in my expertise and systematically relying on learning-from-practice ideas. There are many options depending on the exact problem, but I have found lots of nice (and completely free!) stuff from IETF, NIST and EU organisations. From detailed instructions about how to reliably account for the slightest issue, up to pretty light but informative guides about quite generic aspects.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
1001 other jobs better than being a programmer
by W. Richard Stevens. Fully understanding how modern UNIX OS works is a fantastic start to approach other program problems; and this book is simply the best I've ever read on this topic.
Amazon, The Dictionary of Corporate Bullshit
Programming, motherfucker!
except K&R.
It wasn't the Visual Basic part of the book that helped me so much as the explanation of color theory and how image processing and filters work.
"SQL Antipatterns: Avoiding the Pitfalls of Database Programming" by Bill Karwin. If you design database schemata from scratch, it's well worth your time! For a lot of web applications, the database is the foundation upon which the rest of the app rests. You can have the best frontend and backend code in the world but if your database schema is a mess, you application will still be difficult to work with. This book saved me coworker and I at a previous job from making some serious errors that we definitely would have regretted, especially after years of data were accumulated.
I learned a lot from it.
Probably the most needed and useful book for programming.
I've always said English was my second language. Had Romeo and Juliet been written in C, I might have understood it.
Multipliers 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.
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
Amazing how little memory and CPU MOTIF applications take. Once you get over the callbacks, it's actually not bad!
Even if you don't like C++ much, The Design and Evolution of C++ 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 recommendation is Strunk & White Elements of Style, which apply somewhat to coding style as well as human writing. Very short. There are probably better books about writing words but none so applicable to coding I think (open to suggestions if people know of better ones).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Agreed, 110% + I have versions of it here implemented in Pascal, C/C++ & JAVA (helps save 'port time' between diff. languages IF I use its implementations of various things like sorts etc.).
* SAVES TIME & POTENTIAL MISTAKES!
(... & I've said PRETTY MUCH the same as you have here on /. TONS of times since 2006)
APK
P.S.=> The coursework for it taught me a lot (considering it has things that some folks probably spent a GOOD chunk of their lives coming up w/ so you don't HAVE to "reinvent a wheel" & possibly badly)... apk
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.
you'd think after 7 volumes they could spell "HOLES"
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.
systemd-as-init replacement isn't bad. systemd-as-kitchen-sink-replacing-everything is of questionable utility.
journald (non-ACID, corruptible file format), networkd, timedated, it's subsuming of udev, resolved (it's hard-coded fall backs, and strange behaviour): most of these are WTF? stuff.
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 looking for interesting books to read. Nothing but time these years.
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
War is peace
Trump is the only president yet to invade anyone new, and actually talking about withdrawing from places like Afghanistan and Syria - which Democrats are against...
Who is I claiming "War is Peace" again exactly?
And if you want to look at who has solid dominion over absurd twists of logic, look no further than any of the "there is no such thing as gender" crowd, all solidly leftists.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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
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/ 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 the computer science stuff, the "score" is 352, of which the first 22 are in Japanese.
http://shanenj.tripod.com/cgi-...
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
Ages ago, Microsoft made a book for writing bug-free C code. It was surprisingly good for its time.
Genectic Engineering For Dummies.
Short books suit you, moron.
The Art of UNIX Programming - Gain an understanding why small is beautiful and huge programs (typical of Windows) are a blight on our systems. Finally understand why Gnome and Systemd need to be flushed for modular, loosely coupled, solutions.
Effective C++ - lots of smart people came before us. Learn from their knowledge. Pick the language you use version of their "intermediate" guide. I'm also a fan of "Mastering Perl", which is beyond intermediate skill level.
The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary - how F/LOSS works and why it is almost always better for companies.
Just for Fun - the Linux story.
And for general money management, "The Wealthy Barber". Remember devouring that book in an afternoon. Changed my life. I was able to retire at age 42.
Always keep learning.
Every student should be conversant in MIX and have worked through Volume 1 by the fifth grade.
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.
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.
John Ousterhout, who was the advisor for the founder of VMware and also co-invented the log-structured file system and is now active working on more recent "RAM-cloud" research for Stanford wrote a great book on writing larger software projects: A Philosophy of Software Design.
Some of his big pearls of wisdom:
* "Shallow" APIs or functions are bad: functions which have very short implementations and tend more toward wrapping vs. abstracting
* Comments are the real documentation and should essentially save you from having to read the implementation of a function
* A great example of a powerful and deep API is the POSIX file system API: abstracts away IO, buffering, caching, file offset management for appends, etc...
* Code should be easy to read, not necessarily "simple" but not unnecessarily obfuscated, e.g., for brevity of typing: code is read many more times than it is written
There is lots more but generally it is a book driven by the wisdom of doing lots of code reviews for students submitting their implementations of the same program requirements and observing higher level patterns that made some code simpler and more elegant and easier to read.
https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201
I wish I had read Thinking Forth by Leo Brodie ISBN-10: 0976458705 ISBN-13: 978-0976458708 much earlier. It is an amazing book to really show you a different way to approach programming problems. It is available online these days.
> 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.
as an introduction how to deal with corporate culture. =/
Truely a well written in depth treatise on the subject.
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.
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
MidnightBSD: The BSD for Everyone
Uh, no one in this thread was doing a whatsboutism. Syria has ALWAYS belonged to Russia / USSR in the modern era. Wtf are you smoking?
This is a great post.
I wish Slashdot had more thoughtful posts like yours.
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 recommend this one.
By Martin Richards.
Watch this Heartland Institute video
It's a good read, if not redundant. You really get to peer into the mind of a "creative" and get a feeling how their thought processes function.
Truly Chilling. They are NOT actually intentionally saying and acting the way they do to be ironic.
Don't read it at night.
Funny how some many anti-Trump "liberals" seem to be homophobic. So I'm gay, Trump is gay, ghosts are real, I'm tiny and don't have testicles?
Well, at least you're funny, I'll give you that.
If you aren't programming every day you will never be as good as someone who is. Programming is about solving interesting problems. Practice solving puzzles to develop your intuition and lateral thinking. The more you practice the better you get.
This is practical, but I do not agree fundamentally with it. Programming is a subset of problem solving, but you can practice problem solving without programming. As a child, I thought up hypothetical problems or looked at real problems that I heard about and made assumptions. Then I would attempt to "solve" them in a hypothetical sense.
By the time I wrote my first program, which was post college, I found it trivial to write it using concurrency to effectively speed it up with near linear performance gains and I wrote my own concurrent data structures. All of this with virtually zero experience or education on the subjects. Everything that I did was based off of ideas that I thought about between the age of 6 and 12.
Problem solving is about thinking. Anyone can think. Just practice thinking. I pretty much did this my entire life. When I say "entire", I really mean almost entire. Even as a 2 year old, my mother said I would sit quietly in a corner staring at the floor or wall. when she'd ask me what I was doing, I would tell her all of these complex thoughts and ideas that I was busy thinking about. Around the age of 3, I became obsessed with why the sky was blue during the day, but clear at night. My mother said that's all I thought about for weeks. The internet was not a thing back then. We were poor. No TV, almost no books. All I had was my own thoughts. I didn't know anything about atoms or photons, I was only 3. but holy crap did I spend time thinking about it.
"The C Programming Language", K & R 1st Edition, 1978
Wish I had (proof)read it in 1968, before I sent it to the publisher:
still, and forever, jealous of the wit and style with which structured source code was demonstrated, years too late, as a foundational model for decades of devotees who would attempt, with sadly limited success, to replace "writing programs" with "designing software", before the stampeding hordes of web-site designers displaced the original wave of engineering talent.
Where have all the flower{s | -children} gone?