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?
Nineteen Eighty-Four. Hey, you didn't specify computer programming....
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.
- "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.
"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.