Slashdot Mirror
Ask Slashdot: What Should Every Programmer Read?
An anonymous reader writes "There's a blog post floating around right now listing articles every programmer should read. I'm curious what articles, books, etc., Slashdot readers would add to this list. Should The Art of Computer Programming, Design Patterns, or Structure and Interpretation
of Computer Programs be on the list? What about The Mythical Man-Month, or similar works that are about concepts relating to programming? Is there any code that every programmer should take a look at? Obviously, the nature of this question precludes articles about the nitty-gritty of particular languages, but I'm sure a lot of people would be interested in those, too. So if you can think of a few articles that every C++ programmer (or Perl, or Haskell, or whatever) should know, post those too."
It's rather out of date but "The Joy of C" was my first programming book and I attest its style to easing me in to the development mindset.
For example, here; http://www.catb.org/jargon/htm...
Clean Code by Robert C. Martin, Working Effectively with legacy code by Michael C. Feathers, Refactoring by Fowler, Design Patterns by the gang of four. If you are a C++ programmer, anything by Sutter or Meyers.
Je ne parle pas francais.
Everybody should RTFM.
Dear aunt, let's set so double the killer delete select all
No list is complete without Vernor Vinge's _True Names... and Other Dangers_. I don't care if it's a book, instead of an article, but still, it's required reading.
"Trust me - I know what I'm doing."
- Sledge Hammer
And "How to Write a KILLER LinkedIn Profile... And 18 Mistakes to Avoid", both by Brenda Bernstein.
An arbitrarily long strip of tape, divided into sections on which there appear symbols drawn from some finite alphabet. They should be able to work the rest out from that.
Code Complete is the #1 thing every programmer should read.
"Politics and the English Language", George Orwell.
Should be required reading for everyone not just programmers.
...you don't get to call yourself a "software engineer" or talk about others' software engineering practices.
"My life's work has been to prompt others... and be forgotten." --Cyrano de Bergerac
The little schemer series, (The Little Schemer, The Seasoned Schemer and The Reasoned Schemer) Daniel Friedman
Even if you never intent to use a lisp, it's worth reading.
http://www.amazon.com/The-Litt...
http://www.amazon.com/The-Seas...
http://www.amazon.com/The-Reas...
I have a copy of the first three volumes of TAoCP and have skimmed parts of it. I've occasionally opened it as a reference source (for example, on PRNGs), but I wouldn't claim to have "read" it. People who do are likely either hardcore computer scientists or bullshitters.
http://git-scm.com/documentati...
They're there for a reason.
The C Programming Language, so they learn how to properly document their work.
Paradigms, styles, approaches are different. There is no "central" body of things that can capture this. Even absolute classics like "Goto considered harmful" can be misleading and counter-productive to read unless the reader can supply the right context. That said, every programmer should always work to understand his or her craft better and broaden their view. That includes reading about insights other people have had into the process.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
http://www.joelonsoftware.com/articles/Unicode.html
Programmers maybe write reasonable code - but they often cannot express their ideas in ordinary language. Read the paper, George Orwell, 'Clean Code', Slashdot, whatever - and practice writing too. And talk to people. If they look puzzled, you're not communicating well, and need to get better. Use grammar. Write clean, accurate comments.
(Quick scan to make sure that this is clean... well, good enough...)
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
You never know when the Lannisters will turn on you.
Dilbert.
By seeing how it used to be.
www-smirc.stanford.edu/papers/chapter1.pdf
It won't hurt you to read about hardware, I promise!
http://www.ee.ryerson.ca/~elf/hack/realmen.html
Slashdot? Then no one will get any work done!
I'm gazing across my bookshelf full of O Reilly books, Knuth's series, TCP/IP Illustrated, and others... but the most important books are more mundane:
Godel Escher Bach: an Eternal Golden Braid, and Alice in Wonderland
Both of these books encompass the thinking and mindset which will make you a better programmer by planting the seed of logic, states, and recursion, and nourishing the hell out of it. It will massage the pathways to make someone actually want to be a programmer.
Can't think of anything else that 'every' programmer should read. All programmers are different, what would benefit someone who writes C for embedded systems might bore a WPF developer to pieces and not benefit him or her one bit. So might as well read something funny.
with a good commentary to explain the historical, cultural context needed to understand certain sections well.
Programming is a fun and rewarding way to earn a living. But it's not the most important thing.
I wish I'd read Roger Kaufman's book before I started programming. It would've helped a lot.
Here's a few pages to get a taste of the style: http://www.cs.utsa.edu/~wagner...
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
But how do they get "the right context" without knowing what to read?
By Robert Glass
Gack wrong title.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Study Slashdot Beta so you know what not to do.
Table-ized A.I.
code.
... the top 10 books/articles/whatever that every human being should read.
Now if only we could get some kind of agreement on what those "top 10" are.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Here's my two cents:
- Effective C++: 55 Specific Ways to Improve Your Programs
- Code Complete
- Design Patterns: Elements of Reusable Object-Oriented Software
"The best book on programming for the layman is Alice in Wonderland, but that's because it's the best book on anything for the layman."
- Alan Perlis, "Epigrams on Programming", ACM SIGPLAN Notices 17 (9), September 1982, pp. 7–13
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Code. Lots and lots of code. Code from diverse sources, understanding the problems, understanding the solutions. Programming books/articles offer nice ideas, philosophies, anecdotes, whatever, but nothing will improve programming skill more than experience. Reading code, IMO, and at least for me, increases that experience much more than writing it or reading the meta about programming.
while(1) attack(People.Sandy);
The Psychology of Computer Programming, by Weinberg. Its from 1971 but still relevant. It tackles the management aspect of working in a team, how to handle difficult people etc. Clean Code, a great book for those interested in adopting a better coding style. Are your routines longer than 5 lines? Wrestling With Bears , goes into details about how to mitigate risk, evaluate and prioritize requirements and keep your projects on track. Test Driven iOS Development. Cocoa Design Patterns (if your an iOS developer); it really helps to understand what is happening under the hood of the API. Software Engineering by Ian Sommerville, for those interested in design, architecture and large systems. Its a rather long and very traditional (not agile friendly), but its comprehensive and good. Someone already mentioned K&R, I'd add C++ by Bjarne Stroustrump. Agile and Iterative Development: A Manager's Guide. Its not really a "managers guide", but more of a "How can I be a good team player" with an introduction on XP/UP and Scrum kind of a guide. Highly recommented.
That's a good list of subject areas, and articles for technical areas, but if you're going to be an effective programmer, you need to venture out a bit. There are a couple of good books by Gerald Weinberg that will change the way you look at your profession. First is The Psychology of Computer Programming. It's a bit long in the tooth, but the lessons are still relevant. Same goes for Quality Software Management, Volume 1. Be warned, QSM, in particular, will make you dissatisfied with your managers.
Play it cool, play it cool, 50-50 fire and ice.
It will help you better understand your bosses concerns. And some day that's where you will be as technology laps you and you go from being a nerd to a person supporting a family where money means more than technology.
I intend to be a manager before I am 50. 10-15 years of not having to think out technical problems and I'll be making more money. It's win/win.
from cover to cover, then get back to me.
I'll wait.
There Ain't No Such Thing As Plain Text.
For the love of all that is holy, every person who ever writes a line of code anywhere, for any purpose, must read this! No exceptions!
There Ain't No Such Thing As Plain Text.
How about a book on Hindi so you can communicate with your boss and offshored co-workers at 2:00 AM in the morning, then train the H-1B who is going to be your replacement so you get a severance package?
Realistically, K&R's C book is a classic worth looking at. Defensive programming, and programming with security in mind are also important texts.
You gotta disconnect from the tech every once in a while.
I'm sure I'm not alone. This type of "article" seems to come up every other week.
What is a good read about programming?
If I want to get into programming, which language should I start with?
If I want to get my child into programming, where should I start?
Should schools push teaching programming?
Can I get a programming job with two semesters of classes done?
I've programmed for my whole life, can I learn a new language?
Isn't the rule of thumb for answers to headline questions to be "No"?
Seriously. Make a roulette wheel, spin it, then type the language it falls on followed by "tutorial" into google and start following directions.
This should be required reading for any programming putting software on the web. It details some 50 basic vulnerabilities that must be avoided. Its also a good starting point for the Q/A team and test planning.
"How to Win Friends and Influence People". Not for the advice; as a geek type you'll likely never be able to pull it off anyway. But in the spirit of knowing thy enemy; when the sales and marketing and pointy-haired businessmen try to manipulate you, you'll recognize the techniques and be able to put a source to them.
to superinflate the already universe-busting ego of the average computer programmer
Fun and will teach you to "think" like a programmer. Plus LISP! FTW!
I see some good suggestions on how to code well but it's important to know how to produce human interfaces that are understandable, effective and even fun.
For that, my favorite book is "The Design of Everyday Things." It's not about software design, it let's you see effective (and bad!) design all around you and will make you think about your own designs. The affordances, or clues, you provide on how things work without having to spell it out in documentation.
Good programming is just the start. Good problem solving is the goal.
Then I suggest every programmer read every single one of the posts on this site: http://prog21.dadgum.com/ . The author has a remarkably clear head about things and a very mature outlook on programming.
A fool and his hard drive are soon parted.
No need to worry, we'll get off your lawn...
You should read about dealing with people as well as programming. Read "Crucial Conversations"
Work? We are programmers. We abhor work.
"How to not fuck up"
It hasn't been written yet, but it needs to be written.
There are many that say 'how to do x'. But few/none that say 'How to not fuck up'.
/thread
I'll just leave this free and open source CS101 course here: NAND to Tetris.
No, in spite of what some jackasses say, it isn't just rewriting for its own sake. It is improving the structure in standardized ways so that you can add your new features much more safely. In interviews, I prefer people can name some standard refactorings before I ask them the typical questions about design patterns.
http://refactoring.com/
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
The best preparation for becoming a good programmer (or scientist or engineer) is to learn how to organize your thoughts and then address only what is necessary and sufficient to accomplish a given task.
I know no book that teaches clarity of thought better than Strunk & White's "The Elements of Style". Clear writing and great coding share a common wellspring.
The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully by Gerald M. Weinberg /. a long time ago, and I am glad I did.
It has a lot of little anecdotes that help you recall concepts of how to manage your own time. Things like Rudy's law of Rutabaga stick with me even though I haven't picked up the book in a while. I read this book based on someone's recommendation on
"Doctor's mistakes you bury, Engineer's mistakes you live with forever."
The UNIX Philosophy by Mike Gancarz is a great book. It is specifically applicable to understanding unix. But, it is broadly applicable for anyone developing software. Understanding how to build small reusable components that can be strung together well. It is also a short book, and thus a very easy read. So, it belongs on the list of books every program should read. You get a lot of bang for your buck.
My boss gave me this book when I started by my first job out of college. By far one of the best books on software development and construction out there. It is timeless and even though I no longer write code for a living, I refer back to it on many occasions still. You want a book to make a you a better programmer; you can't go wrong here.
Whereas other programming books are filled with conjecture and opinion ("I think this" or "I think that"), Steve McConnell went out and did the hard work of researching what actually works, then providing actual citations for everything he found. Following the guidelines and tactics in this book is like adding 10 years of experience to your programming skills. This book is a masterpiece in the field of programming.
http://www.amazon.ca/Code-Complete-Steve-McConnell/dp/0735619670
Spoiler, everybody dies
All the novels of Jacqueline Suzanne (one of the giants).
"Atlas Shrugged" by Ayn Rand.
And THIS.
"How To Win Friends and Influence People" By Dale Carnegie.
A classic, every programmer (and person) should read it.
"What every programmer should know about floating point math"
GEB
Fyodor Dostoyevsky - Crime and Punishment
So they feel guilty about their crappy code
Optimizing C++ was an eye-opener for me because it isn't just about how to optimize C++ but more about how things actually work (in the real world).
After a year i go back and realize what a horrible programmer i am. It happens every year. But i'm getting better. I also spend a lot of time reading other people's code. I've found that if you are writing "new" code you haven't already seen in action, you just might wind up killing somone someday.
This has always been one of my favorites.
https://www.thc.org/root/phun/...
Capital, Volume 1
Their own code
Revised report on the algorithmic language ALGOL 60
Basic CS courses @ a university should cover this stuff, at least in Europe.
Comment removed based on user account deletion
Won a Pulitzer in 1982, and git off my lawn.
One book I like to recomend to people is "The Design of Everyday things". It makes good observations about form following function, and what happens when this goes poorly. And gives examples of bad design choices. Its probably a must read for anyone doing user interface design.
I remember opening and closing The Art of Computer Programming. I was in a "fuck that shit" mood but to be honest this is a heavy book which will put you in the ranks of code monkey rather than innovator/creator. But maybe you've decided that you want to be the pass-all-thd-programming-test guy, the interview guy and the guy who wants to be part of the team. In this case, you can spend a lifetime reading books, bearing in mind that some of the books were written by guys or girls who didn't really make it. This is crucial. Read their bio, google them and ask yourself "do I really want to read anything from them, other than help me pass an exam or get through some Microsft style interview test." This is not right. Sadly anyone can write a book these days. However there are exceptions like the father of C++, Bjarne Stroustrup.
and browse the C2.com wiki (the first public wiki ever) to get some ideas of the philosophical conflicts surrounding software engineering. It's not neatly organized, but with some patience you'll find some interesting viewpoints and debates.
Don't read any books on programming, they're a waste of time and money. To become a good programmer, join an open source project and start developing in an open community. If you want to buy the books as a learning experience then I suggest grabbing an arduino ( or other uC ) and just writing a firmware, logging system and web interface for it.
"Thou shalt not make a machine in the likeness of a human mind."
http://www.joelonsoftware.com/...
Things you think are in the Constitution, but are not.
http://www.mit.edu/~xela/tao.h...
7 habits of highly effective people.
Never Eat alone
EMotional Intellegence 2.0
The Five Dysfunctions of a Team
What, were you thinking of programming books? bah, mostly worhtless for your career.
Understanding people? that is how you make it.
I used to be all about the programming books. I write solid, clean code. I use small methods, functions., etc. I wrote some really good code, did some amazing things with very limited memory.
None of that gets you dick in the long run.
Career and business wise, understanding how to deal with people, and how a good team works is the way to get ahead.
If I had read those books when I was twenty, I would have retired by 45. Instead I work endless hours to craft some high quality code when I could have written something mediocre and gone home on time.
Seriously no one would know or care.
The Kruger Dunning explains most post on
W. Ross Ashby's "An Introduction to Cybernetics", You have got to understand systems.
Jon Bentley's "Programming Pearls" and its sequel. Beautiful examples of doing it right.
And last but not least, Machiavelli's "The Prince". Because sooner or later, some a-hole is going to try to manage you.
Even absolute classics like "Goto considered harmful" can be misleading
Only thing worse than GOTO statement is COMEFROM statement. Event driven programming is basically COMEFROM functions.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Mark Twain wrote a scathing essay titled "Fenimore Cooper's Literary Offenses" which discusses "nineteen rules governing literary art in the domain of romantic fiction–some say twenty-two", and mentions 18 in detail. Of course it's all an excuse to bash another author's writing, but there is a germ of truth behind it. Think of variables as "characters" in the "tale" being told (perhaps a user story?). http://www.pbs.org/marktwain/l...
There is a wikipedia entry about it, in case you have interest:
http://en.wikipedia.org/wiki/T...
Uh, Linux geek since 1999.
See my sig line below: Buckminster's the man to read, you geeks.
Development is programmable; Discovery is not programmable. (Fuller)
- Hindi for Dummies
- How to Live like a Prince on a Pauper's Salary!
- Idiot's Guide To Self Medicating
- So You Want To Take Up Drinking!
- How To Impress No One And Irritate People
A fundamental book that teaches good programming habits, "Software Tools" also reveals many of the thought processes behind and the design of UNIX and its utilities. Interestingly, the code is in FORTRAN, but using a preprocessor similar to C's, which translates "RATFOR" (RATional FORtran) into the base language. The preprocessor is one of the Tools described in the book.
Nonsense. The Mythical Man-Month is mostly about team-building, project management and a bit about software architecture
In other words the mix of work for a programmer of every company I have been at.
You think you came to write code? Ha Ha! Let me acquaint you with Mr Process.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Everything Men Know About Women. They say Knott Mutch is the nom-de-plume for a Slashdot editor, but I'm not sure which one.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Was the Command Line by Neal Stephenson
I have plenty of common sense, I just choose to ignore it. -- Calvin
...he seemed to be the guru of efficient programming back in the day. The old x86 code may be well out of date but the principles of structure and efficiency are universal.
That's very timely---this week, I was researching what textbooks I should use for my CS courses (this is the time of year for semester-based schools to choose next semester's books), and I decided that the huge amount of work it took (there are a LOT of CS books out these days) should be amortized by sharing the results with many people. Except, I got curious, and repeated the process for every course. Here's my blog post from Monday listing what I decided were the best. I wrote the list in part to provoke debate, especially debate that might lead me to different choices for my courses, so please follow up with disagreements here!
http://casual-effects.blogspot.com/2014/05/a-computer-science-book-reading-list.html
#ifndef BOOKS_EVERY_PROGRAMMER_SHOULD_READ_H /* (The Blue Book) */,
#define BOOKS_EVERY_PROGRAMMER_SHOULD_READ_H
"The TAO of Programming", "Back to Basics: A Complete Guide to Traditional Skills - Abigail R. Gehring", "Paper: Bitcoin: A Peer-to-Peer Electronic Cash System - Satoshi Nakamoto",
"Murach's Mainframe COBOL - Mike Murach, Anne Prince and Raul Menendez", "Cosmos - Carl Sagan", "The Persian Expedition - Xenophon",
"Democracy in America - Alexis de Tocqueville", "Crucial Confrontations: Tools for talking about broken promises, violated expectations, and bad behavior -- Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler",
"The Curriculum - Stanley Bing", "Python the hard way",
"Dan Ariely: Predictably Irrational", "Are your lights on?", "A Brief History of Time - Stephen Hawking ",
"D is for Digital: What a well-informed person should know about computers and communications - Brian W. Kernighan",
"History of the Peloponnesian War - Thucydides", "PostScript Language Tutorial and Cookbook - Adobe Systems"
"Elements of Positional Evaluation - Heisman", "The origin of the species - Charles Darwin", "The Fourth Turning - William Strauss, Neil Howe", "The Art of War - Sun Tzu",
"The Practice of Programming", "The Elements of Programming Style", "A Random Walk Down Wall Street - Malkiel", "One Up On Wall Street - Peter Lynch", "The TeX book",
"Silent Spring - Rachel Carson", "LaTeX Beginner's Guide - Stefan Kottwitz", "The Art of Choosing", "Liespotting",
"Basic Physics: A Self-Teaching Guide", "The Art of Assembly Language - Randall Hyde", "1491 - Charles C. Mann",
"The IDA Pro Book: The Unofficial Guide to the World's Most Popular Disassembler - Chris Eagle", "The Unix Programming Environment", "http://plan9.bell-labs.com/plan9/*", "http://www.vitanuova.com/inferno/*",
"Learning CFEngine 3: Automated system administration for sites of any size - Diego Zamboni", "UNIX and Linux System Administration Handbook - R. Hein", "DevOps Troubleshooting: Linux Server Best Practices - Kyle Rankin", "The Unix Philosophy - Mike Gancarz",
"What Every Web Developer Should Know About HTTP - K. Scott Allen", "A Mathematician's Apology - G H Hardy", "Linux Device Drivers - Jonathan Corbet, Alessandro Rubini", "http://www.slashdot.org/*",
"http://rubyonrails.org/*", "paper: Reflections on Trusting Trust - Ken Thompson", "Computers, Chess, and Cognition", "paper: Fundamental Concepts in Programming Languages - Christopher Strachey",
"paper: An Axiomatic Basis for Computer Programming - C. A. R. Hoare", "Cryptonomicon", " Dreaming in Code", "Beautiful Code:*", "The future of the internet and how to stop it - Zittrain",
"The Devil's Dictionary", "I, Robot - Isaac Asimov", "1984 - George Orwell", "Tufte. The Visual Display of Quantitative Information",
"The Non-Designer's Design Book - Robin Williams", "The Wealth of Networks - Yochai Benkler", "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency - Tom DeMarco", "Why Popcorn Costs So Much at the Movies: And Other Pricing Puzzles - Richard B. McKenzie",
"Where Wizards Stay Up Late: The Origins Of The Internet", "Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing -- David Patterson, Armando ", "Practical Electronics for Inventors - Paul Scherz and Simon Monk", "How to Diagnose and Fix Everything Electronic - Michael Geier ", "Hard Drive: Bill Gates and the Making of the Microsoft Empire - James Wallace",
"Learning Web Design: A Beginner's Guide to HTML, CSS, JavaScript, and Web Graphics ", "Brave New World - Aldous Huxley", "Understanding Digital Signal Processing - Richard G. Lyons", "HBase: The Definitive Guide",
"The Joy of jQuery: A Beginner's Guide to the World's Most Popular Javascript Library ", "TCP/IP Illustrated Volume 1", "DNS And Bind", "Cisco Internet Routing Architectures",
"HTTP The Definitive Guide", "Foundations of IT Service Management with ITIL 2011 - Brady Orand, Julie Villarreal", "In S
Those that don't learn from history are doomed to repeat it. Look at node.js -- anybody who used cooperative "multitasking" back in the day knows shat a shitty hack it is. The node.js designers never learned that lesson (and then wonder why their single thread web server isn't web scale. Needs more callbacks!).
Numerical Recipes in C
... my upcoming book, "Quit Fucking Up Perfectly Good Software with Overly-'Designed', Non-User-Tested Bullshit, I'm Looking at You, Apple Mozilla Google Microsoft Adobe Slashdot and Certain People at My Company Who Shall Remain Nameless", in stores this fall.
So far it's just the cover and then 168 pages of the title being repeated but I think I'll get it wrapped up pretty soon.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Because that's the closest you'll get to a naked woman for a long time...
Word for word this short essay served to improve my coding more than any other document, and not just in C. Most of the essay is applicable to any language. Pike elegently and concisely explains the most important principles of good code style and software architecture. The sections "Programming with data" and "Function pointers" are particularly sailent. The section "Complexity", also known as "Rob's Rules", is outstanding and ought to be burned into the brain of every software developer. It's a free online classic and I'm surprised it hasn't been mentioned yet. http://www.lysator.liu.se/c/pi...
-73, de n1ywb
www.n1ywb.com
If you want to understand the system "under the hood", i recommend grabbing copies of any modern assembly programming books or references (i usually read off technical reference of CPU manufacturers - Intel, ARM etc..
the benefit of reading and understanding them is enormous. You start to understand how memory layout, alignments, registers, instructions and modern CPUs interact during a lifetime of a code. this is not only beneficial for performance people but for every programmer who has to write code; in general understanding them makes us a better programmer "because" we understand how it all interacts underneath (might take a while to grasp everything but a nobel pursuit nonetheless) and will write software to behave well. Even if you write the "high"est level code (think of most modern language such as Java, Scala etc..), you will then appreciate the fact that this is how vector arithmetic or memory alignment make things faster and that high level libraries do implement that in some form using some C library which then uses some assembly underneath. Understanding them takes time; but again, one thats worth a pursuit.
... The Design of Everyday Things.
And BOFH.
Hitchhiker's Guide to the Galaxy, Ender's Game, and Cryptonomicon
The part where he relates that Wordstar used the high bit of an ASCII byte to signify "last letter in a word" is a wonderful example of the confusion of concerns.
If we're just talking articles, not books:
The Rise of Worse is Better: http://dreamsongs.com/RiseOfWorseIsBetter.html
goto considered harmful: http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF
others have mentioned, and I second:
The Cathedral and the Bazaar: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
And for the lighter side:
Real Programmers Don't Use PASCAL: http://www.webcitation.org/659yh1oSh
BOFH: http://bofh.ntk.net/BOFH/0000/bastard01.php
I'll second C2, and offer an additional recommendation: dig deep.
Required reading for internet skeptics
Anyone developing software needs a clue about names, and about unicode and text encodings.
http://www.kalzumeus.com/2010/...
http://www.joelonsoftware.com/...
(Then learn lots, lots more about text encodings).
Also, whether or not they use SQL directly, about metacharacter attacks and SQL injection:
http://bobby-tables.com/
http://watchguard.com/infocent...
Mostly so if you ever go into management you'll have a clue, unlike the vast majority of managers. (Unfortunately after reading it you see just how much stupid stuff management does.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
The correct answer to this question is "A programmer should read a lot".
I apologize for the lack of a signature.
And learn the fundamentals!
http://www.amazon.com/Everyone-Turtleback-Library-Binding-Edition/dp/0613685725
Seriously, it puts everything into perspective.
//it is okay if x overflows
x++;
or
x++;
Programmers should read / investigate about how things work, specially human behaviour, economics and politics and pay special attention to problems (and why they happened across the longest period of time you mind can handle). That will be far more better than whatever recommendation.
http://www.quasarcr.com/
While a lot of programmers feel that software testing is both below them or not needed (the My code is perfect). This book should be required reading. Your code by definition is faulty unless it can pass the tests. And if the tests are bad, the code stays faulty forever.
Applied Cryptography by Bruce Schneier. Really any and all of his books.
+1 for, The C Programming Language, by K&R
(Brian W. Kernighan, Dennis M. Ritchie)
Because if you have never programmed in C (or assembler) then you really don't know how a computer works.
This is one of those questions that's going to keep being asked... Perhaps one day I'll be fast enough to get a first post on this that people actually read...
Link summary from last time:
General comments
I've noticed which book answers tend to fall a bunch of categories:
If you're going to ask someone "which book?" try limit the categories they should give you an answer for...
Zen and the Art of Motorcycle Maintenance
If you don't read it, you don't get it.
The Definitive C++ Book Guide and List
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
The pragmatic programmer and code complete
MouseClass extends ScrollClass, which extends TabClass, which extends SidebarClass, which extends PowerClass, w
by Tracy Kidder. A CS prof in school put it on the syllabus. Great account of a development project.
Karl Popper, "Objective Knowledge", in order to make you understand what the dangers of induction and inductive reasoning are.
John von Neumann & Oskar Morgenstern "Theory of Games and Economic Behavior", a brain-trainer that will leave you, after having read it, much more induced to first simulate, then code !
Peano, "Calcolo Geometrico", containing his famous axioms for Boolean algebra. There is a good translation from the year 2000 by Kannenberg, titled "Geometric Calculus"
Leslie Lamport, "Time, Clocks and the Ordering of Events in a Distributed System" -- you will never think the same again about synchronization and time-related problems....
And so on. All classics from the 20th century, giving the necessary background in computing and logics fundamentals that I so often miss in today's fresh graduates. The oldest text, by Peano is even from 1888, but still actual today !
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
If you are doing C++, you absolutely must read the Frequently Questioned Answers:
"C++ is a general-purpose programming language, not necessarily suitable for your special purpose."
It's a little (though not much) out of date, as it does not cover C++11. But the author has some comments on it, too.
Obviously I am going to be modded down, but hey. Truth is truth.
by Capers Jones.
Provides empirical evidence _why_ we need to write good code.
Here's an interview with the fella I just stumbled across yesterday:
http://www.informit.com/articles/article.aspx?p=1824791
-- Truth suffers from too much analysis.
This has got to be the most overrated book ever.
It's one man's hopelessly out-of-date, patronising, down-home, folksy BS in the form of boring, repetitive, unsubstantiated anecdotes.
I've never read so much waffle with so little actual content.
It's basically advise on how to butter people up so you can sell them stuff or manipulate them so you can sell more stuff.
Typical manipulative, overblown nonsense from a typical salesman-philosopher.
A 1930s Gareth Cheesman (UK reference).
Don't waste your time.
russoto: I didn't make it clear I agree with you! Just hate the book.
ok, this is more about what programmers should "do" than what they should "read". But for anyone involved in working as part of a team or dealing with either managers or subordinates (holy crap, I have just described everyone not working completely alone), I strongly recommend going to a few Toastmasters meetings.
No matter what programming language you use, development style, methodology, or approach, programmers today spend more time communicating with other people than they ever have done before.
Toastmasters - both in terms of giving speeches and also performing leadership tasks based on running the meetings, helps to improve communication and leadership skills (dramatically, in most cases).
If you are ok with being the anti-social loner who sits in the corner churning out code, and who thinks of communication with others as "one grunt for no, two for yes", then you need not bother. But for everyone else, it is a great place to go.
This is a list I think anyone should read if they really want to be a good programmer writing mostly critical system software that needs to be very fast and robust. A few of these are not directly applicable, but teach ways of thinking and analyzing programs that are very beneficial for writing correct code.
Aho et al.,Compilers: Principles, Techniques & Tools
Pierce, Types and Programming Languages
Winskel, The Formal Semantics of Programming Languages
Pierce et al., Software Foundations (online book)
Baier, Katoen, Principles of Model Checking
Cormen et al., Introduction to Algorithms
Sedgewick, Flajolet, An Introduction to the Analysis of Algorithms
Kreher, Stinson, Combinatorial Algorithms
Bird, Pearls of Functional Algorithms Design
I think all C++ programmers should read "The D Programming Language" by Andrei Alexandrescu, only then will they appreciate how truly awful C++ syntax is and discover a language that is just as powerful, but is also simple and elegant.
If every university simply taught this book, software development would be called software engineering. Written in 1996, and still we have not learned the lessons. Flawed. Wordy. Partially out of date. And yet, if you understand and apply the concepts in this book, you will design applications and systems of the standard that everyone actually expects software to be at (rather than where it is).
Don't be put off by the "C++" in the title. Most of the concepts are applicable to any language. It's about the engineering behind large scale software development.
ISBN-10: 0060589469
ISBN-13: 978-0060589462
If you want to read something different, try : Why’s (Poignant) Guide to Ruby
Yet the same people who complain about GOTO because they have to scroll around the source to see what'll happen have no problem with things like object-oriented programming, where it might be literally impossible to figure out what function (out of an unbound set) will actually be called until the code is run.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Apparently we don't actually care about security here. Writing Secure Code should be on every must-read list.
... for a perspective on security.
which dull book did you invest time in reading, and you now want other people to read so you can feel validated?
sag
Best overall book on programming.
Of course, finding any good Algebra book would help as well, along with an introduction to Abstract Algebra, which is a foundation of all programming languages, and many, many algorithms used for every coding project - even if the coders don't believe it.
Learn about Unix and the foundation of Linux from the comfort of your armchair, without all the hippy unicorn shit from Stallman et. al.
Learn about the force, Luke. pwd
By the time you're 35, you will be a manager. The mythical man month is the bible for this realm.
Also, why haven't I seen Knuth yet.
http://www.akkadia.org/drepper...
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Look around for things that deal with aspect that interest you, that expand on topics you do not know yet and that you can follow. I am _not_ against reading a lot. I am against elevating some texts to "high wisdom", as that can do more harm than good. This cannot be done without experimenting and looking around.
For example, for me, the algorithm books by Knuth are pretty worthless. I find them far too hard to read. On the other hand, the original papers referenced I usually understand much better.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Goto is not a problem in itself. In order to understand the issue, you have to know that at the time this article was written, most people used goto exclusively, and _that_ is a problem. Used competently, goto is just another tool in the box and it does have its uses.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Software Tools, by Kernighan and Plauger. Read and follow the examples and you will understand how to decompose a large problem into a set of small and useful solutions. I read this when I was learning C (even though the examples were in Ratfor in the version I had), and I always regarded it as the best book about programming that I ever read.
Indeed. All paradigms known so far have their serious problems, and I do not expect that to change. The important thing is to know more than one tool and more than one style, so you always have choices to make the code better. And "better" always means KISS, clarity, simplicity. There is no silver bullet, and there may never be one. But people that just know one tool, tend to think it solves everything best. It does not.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
They use cooperative multitasking in this day and age? How stupid can you get? Cooperative multitasking has its applications, but only in small, extremely high quality code, where you have special needs besides that.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I keep reading submissions like this. What should I read? What's THE MINIMUM I should learn? What do I really really HAVE TO do?
You're doing it wrong. You should read MORE than you really need to. If you like something, read more about it. If you don't, stop and do something else. CS is a vast field. Roam free.
This was the book that opened my eyes to defensive programming. It's pretty old now, but apparently there a newer version.
TFM?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Every programmer should read code. Bad code and good code. To learn how to do things and how to not do things.
You're welcome
Error-Free Software: Know-how and Know-why of Program Correctness by Robert L Baber, published by Wiley, ISBN 0 471 93016 4
http://www.amazon.com/Error-Fr...
This slim volume is by far the most readable and practical introduction to formal verification that I have seen.
Don't be put off by its somewhat overstated title.
I believe it is important for every professional programmer to have some understanding of how to construct a proof of correctness of code, even if they never use it professionally, as it will expand their understanding of programming. In my case, knowing what it would take to prove a program correct has changed the way I program, in ways that I hope improves the reliability of what I write.
I'll second the recommendation on Steve McConnell's Code Complete - I've used it as a college textbook in classes on SE I've taught. On a lighter note, I would recommend Tracy Kidder's The Soul of the New Machine. Somewhat dated, but gives a historical perspective on how/what it took to build a new machine and make it to market.
"Software is the difference between hardware and reality"
Programmers should sift through an old bug database.
“Common sense is not so common.” — Voltaire
Duh.
Need Mercedes parts ?
Not a book to read, but read about Unicode and learn that Characters are != Bytes.
Bytes are 8-bit machine values.
Characters are part of human languages. The old ASCII coding where a char is a byte is just one (primitive) method of encoding characters into bytes.
The important thing is that whenever you need to convert or store characters into bytes, you must use a function to convert chars to bytes. Conversely, when you need to convert bytes into characters, you need an inverse function to do so. Think of it like if you had to convert between bizarre languages like Klingon and Canadian, you would use a pair of translation functions between the two. You could not just access values from Klingon and assume they are valid values in Canadian.
The conversion from Chars to Bytes and vice versa takes an additional parameter that indicates which Character Encoding to use. There are several to pick from. US-ASCII, UTF8, UTF16, etc. But UTF8 is a very good default because it is very much like ASCII, but will properly convert characters in any human or alien language between Unicode and bytes. The functions that convert from Bytes to Characters on your system may very well offer a function that does not need a character encoding parameter (eg, UTF8) but will figure out which encoding the bytes represent and then decode them into characters for you.
It is difficult, I know. The notion that chars == bytes is deeply embedded. But it is easy to break. And once you do, it's really easy to understand that they are different and they must always be converted using a pair of functions. So for example, a function that compresses data would accept BYTES not characters and would return BYTES. A function that encodes data into Base64 would accept BYTES as input and would output CHARACTERS limited to the US-ASCII set of characters. But the characters could be embedded into anything that accepts character parameters, such as an email, output into a web page, etc. A function that parses JSON into a data structure accepts CHARACTERS as input, not bytes. An HTML output (or input) stream is characters, not bytes. A file on disk is bytes, not characters. But the byte stream can be passed through a reader that returns a character stream in order to read through the file as characters. Etc.
I'll see your senator, and I'll raise you two judges.
Although I don't believe that there is such a thing as a book that every programmer (or scientist or what have you) should know or have read, I think that apart from style guides on writing and programming well a good book or two on the mathematics relevant for the field the programmer works in primarily is quite valuable. It is much easier to comunicate your ideas about any abstract concept if you have a basic grasp of the mathematical and logical vocabulary. It's also invaluable in making your own assumptions clear to the point where you can see that maybe they do not conform to the reality of your (or someone else's) code. Any book on discrete math and something light on logic by e.g. Raymond Smullyan will do for a start. If a working programmer does not know the first thing about algebra than he will undoubtedly will run into trouble when dealing with things like user-defined operators or comparison functions.
1984 - Don't be evil. (Looking at you google)
http://www.catb.org/esr/writings/taoup/
http://insecure.org/stf/smashs...
The Visual Display of Quantitative Information
The Art of Computer Programming
The 2 best computer science books I've read in the last few years. Excellent writing, really teach you about how languages and databases get created, and how they fundamentally differ.
Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages
Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement
E. W. Dijkstra's essay:
EWD 1036
On the cruelty of really teaching computing science
This essay won't help you much with programming, but it provide clarity on why you should choose a different career.
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html
http://c2.com/cgi/wiki if you want the URL. One of the oldest URLs in my memory that still works.
It's not neatly organised, but I find I go to check one thing and two hours later I start closing the tabs I've opened that I know I'm not going to get around to reading.
It predates, predicted and helped evolve the whole Agile development movement, and all the conversations and insights that led to current best practices are still there.
Yet the same people who complain about GOTO because they have to scroll around the source to see what'll happen
That is of course a straw man. People don't complain about goto because they they to scroll around. Even in properly structured non-oo programming you have to scroll around to see subroutines. And that's fine.
The argument against goto is that it tends to produce buggy and unmaintainable code. Where maintenance isn't just scrolling around to understand what's going on, but making fixes and changes to the functionality.
Of course the oop approach is also complex, but it's complication derives from the actual complexity of the problem domain of writing event driven applications. Goto complexity (spaghetti programming) is accidental and unnecessary complexity.
i've done more harm to my own (and other people's) code by following advice taken from MSDN articles than by any another means.
microsoft have a way of breaking everything, and then writing about it is if they invented the solution.
except their solutions never work.
the number of times i have had to rewrite server code, socket code, locking code, threading code, all because the original was based on one of their samples.
there is no single "right" way to write code, but there are plenty of wrong ones, and microsoft have been the worst offenders, to date, in my experience.
at time of writing stackoverflow is my best reference, and otherwise plenty of RTFM.
I'm sure I'm not alone. This type of "article" seems to come up every other week.
If you see them every other week, you're visiting the wrong sites.
What is a good read about programming?
Source code! Lots and lots of source code...
If I want to get into programming, which language should I start with?
Brainfuck.
If I want to get my child into programming, where should I start?
First you'll need to get a child. In order to get that, you'll need to have sex! Which means that you'll have to get out of your moms basement.
In other words: Forget about it!
Should schools push teaching programming?
Should schools push teaching auto repair, cooking and sewing?
Can I get a programming job with two semesters of classes done?
No.
I've programmed for my whole life, can I learn a new language?
Depends on how stupid you are?
Isn't the rule of thumb for answers to headline questions to be "No"?
Only sometimes.
Seriously. Make a roulette wheel, spin it, then type the language it falls on followed by "tutorial" into google and start following directions.
Try that with "whitespace" or "malbolge" and all the directions are "U-turn! U-turn!".
The first thing I thought of when I saw this post was "import this" in Python, which prints out the Zen of Python:
"""
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
"""
Which is definitely relevant. Oh well.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
For sure...
Art of Assembly is a good book.
I concur. I've read three of Joel's books, which are comprised of the same essays you find online, but they all make for a great night curled up on the couch reading. Great storyteller Joel is, and the topics are always interesting.
Kernighan and Ritchie's "The C Programming Language". I think it is the best to understand programming. Knuth's Art of Computer Programming is a great plus, but it is not the basics. Also having an understanding of compilers is very beneficial. Dragon book is really recommended.
The algorithms and architectures found in code help you manage workflow and data. You'll need those same skills in other areas of your life so you can be effective. IMHO - the best book for figuring out how to handle time and mental energy is "Getting Things Done" (GTD) by David Allen. Here is the best summary I've found for condensing the book's 288 pages down into less than 4000 words.
-- "In a time of drastic change it is the learners who survive; the 'learned' find themselves fully equipped to live in
The problem with GOTO is that it makes it difficult to reason about the code, or make statements you can count on. (This largely goes away when GOTO is used in a disciplined fashion, but most of its real uses have different and more limited keywords in modern languages.) In OO programming, you can examine the member functions to make sure that they do the same thing, if in different ways. If you find they don't, that's a real problem.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Thing about cooperative multitasking is that it's safer than preemptive. Errors are going to lead to thread starvation, which is fairly obvious and may not harm the program except by making it take longer. In preemptive, errors can occasionally cause race conditions, in which execution goes subtly awry and you get the wrong answer without realizing it.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
"The Timeless Way of Building" by Christopher Alexander.
"The wisdom of the Patriarchs was that they *knew* they were fools." --Master Foo
and probably Tolkien, Douglas Adams, Heinlein
oh and probably read dilbert from the begining.
Read a book or paper about ethical engineering. The rest will fall in place.
http://en.m.wikipedia.org/wiki/Dunningâ"Kruger_effect
The problem with cooperative is that basically any piece of code can kill the whole thing by deadlocking it. Testing is not adequate to find that. On the other hand, calculations that give wrong results because of race-conditions are exceedingly rare. Race-conditions are a crash-, deadlock- and security-risk, but almost never a risk that causes wrong computation results. In addition, with preemptive you can split processing power into parts that do not have dependencies. With cooperative, that is impossible, everything always depends on everything else working.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
read everything you are interessted in. think about. may be you will be a better programmer after this, or may be you will be an author too or ... or you invite the next facebook and run around as a zombie, who sold his soul ...
> Thing about cooperative multitasking is that it's safer than preemptive.
The only time it's safer is when you control all the code running on the CPU. Blindly run anyone else's code, and you're asking for trouble!
...and get off my lawn
The Cat in The Hat by Dr Seuss ... to prepare programmers for the mayhem that is projects and Project Mangers.
http://lxr.linux.no/linux-old+...
Casteism