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?
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....
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!
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?
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
... 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.
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.
- "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
1001 other jobs better than being a programmer
Amazon, The Dictionary of Corporate Bullshit
"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!
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.
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
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.
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.
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, Second Edition: Networking APIs: Sockets and XTI - ISBN 0-13-490012-X
1999 - UNIX Network Programming, Volume 2, Second Edition: Interprocess Communications - ISBN 0-13-081081-9
2003 - UNIX Network Programming Volume 1, Third Edition: The Sockets Networking API - ISBN 0-13-141155-1 (with Bill Fenner, and Andrew M. Rudoff)
2005 - Advanced Programming in the UNIX Environment, Second Edition - ISBN 0-321-52594-9 (with Stephen A. Rago)
2011 - TCP/IP Illustrated, Volume 1: The Protocols (2nd Edition) - ISBN 0-321-33631-3 (with Kevin R. Fall)
2013 - Advanced Programming in the UNIX Environment, Third Edition - ISBN 0-321-63773-9 (with Stephen A. Rago)
I'll have to go find the third edition. Rago was pretty good as well...
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