Please create an account to participate in the Slashdot moderation system


Forgot your password?

Ask Slashdot: What Should Every Programmer Read? 352

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."
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What Should Every Programmer Read?

Comments Filter:
  • The Joy of C (Score:4, Insightful)

    by Anonymous Coward on Wednesday May 14, 2014 @06:14PM (#47004117)
    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.
  • The story of Mel (Score:5, Interesting)

    by quietwalker ( 969769 ) <> on Wednesday May 14, 2014 @06:15PM (#47004129)

    For example, here; []

  • Books to read (Score:5, Informative)

    by Dionysus ( 12737 ) on Wednesday May 14, 2014 @06:15PM (#47004133) Homepage

    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.

    • by turgid ( 580780 )
      The winner of this thread.
    • Design Patterns by the gang of four.

      Beat me to it! I second this...

      • Re:Books to read (Score:5, Insightful)

        by AuMatar ( 183847 ) on Wednesday May 14, 2014 @06:37PM (#47004379)

        The problem with that book is that too many people read it the wrong way. Instead of using it as a language to describe design, they attempt to find ways to force their code into patterns or to add patterns because they think they should use them. The result is worse code than if they had never read it. This is especially true of those who read the book before they've seen enough code to understand design. It should be read, but only at the proper time and in the proper way.

        • by cfulton ( 543949 )
          Well yeah. But that is not a problem with the book exactly. The problem permeates the software development space in many other ways and the problem is...Many employers and many in the general public think that a weekend with the gang of four, Java in a nutshell and a complete lack of social skills are the definition of a complete programmer. Welders get more training and mentoring that the average programmer. Employers simply point to a goofy looking kid with bad motor skills and say get to it. Of cour
      • by narcc ( 412956 )

        I can't recommend reading it. That would be unethical.

        However, it is useful for leveling furniture and is an excellent source of kindling. So I guess it's not all bad.

    • by radtea ( 464814 )

      Excellent suggestions all. I would add:

      1) "Software Failure: Management Failure" by Stephen Flowers (somewhat dated, but an excellent collection of case studies of failed projects... technologies change but the lessons learned remain relevant.)

      2) "Rapid Development" by Myers. The chapter on estimation alone is worth the price.

    • by fermion ( 181285 )
      I would add an old book, Composite/Structured design. It is an old idea, but I have seen cases where people still have learned to keep data structures out of the code that operates on those data structures. If one is using a heavily OO development tool, this happens automatically. Of course, those who use such tool therefore never learn how to design so that the two are kept apart purposefully.

      Also if you are a C++ program, the original K&R C book is a good read of how to keep things simple.


    • If you're doing C++ everything by Meyers.

  • TFM (Score:5, Funny)

    by NIK282000 ( 737852 ) on Wednesday May 14, 2014 @06:16PM (#47004137) Homepage Journal

    Everybody should RTFM.

  • 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.

  • And "How to Write a KILLER LinkedIn Profile... And 18 Mistakes to Avoid", both by Brenda Bernstein.
  • by fuzzyfuzzyfungus ( 1223518 ) on Wednesday May 14, 2014 @06:17PM (#47004153) Journal
    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 (Score:4, Informative)

    by Anonymous Coward on Wednesday May 14, 2014 @06:17PM (#47004157)

    Code Complete is the #1 thing every programmer should read.

    • by gweihir ( 88907 )

      Never read it, and decided to better stay away after perusing reviews.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Code Complete 2nd Edition is the holy grail of programming books. Required reading for serious professionals.

  • by Troy Baer ( 1395 ) on Wednesday May 14, 2014 @06:19PM (#47004185) Homepage don't get to call yourself a "software engineer" or talk about others' software engineering practices.

    • by gweihir ( 88907 ) on Wednesday May 14, 2014 @06:26PM (#47004251)

      Nonsense. The Mythical Man-Month is mostly about team-building, project management and a bit about software architecture. It has almost no software engineering content. Sure, it is a highly valuable source, but not a software-engineering one.

    • No need. The "Mythical Man Month" is merely a series of special cases of the law of diminishing returns and/or The Planning Fallacy. []

      It's much more efficient to say: "Too many chiefs and not enough braves is bad, and it will always take longer than expected."

    • don't get to call yourself a "software engineer" or talk about others' software engineering practices.

      Excellent book, but the software engineer who is just writing code doesn't need it, in fact they might not want to if they don't have good managers. Now if you MANAGE a project or other software engineers, THEN you should read this book every few years.

      • by swilly ( 24960 )

        If you you do is write code, then you aren't a Software Engineer, you are a Programmer. An engineer is involved in requirements, specifications, design, and testing. On a good team, the experienced Software Engineers should also be consulted for process improvement, QA, and DevOps.

        • by narcc ( 412956 )

          Can we stop using the term "engineer"? It's not only meaningless, it does a serious disservice to actual engineers.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Yeah, it's the Bible of software engineering: everyone quotes it, but no one has read it.

  • by csumpi ( 2258986 ) on Wednesday May 14, 2014 @06:22PM (#47004201)
  • by Anonymous Coward on Wednesday May 14, 2014 @06:23PM (#47004209)

    They're there for a reason.

  • K&R (Score:4, Insightful)

    by ericloewe ( 2129490 ) on Wednesday May 14, 2014 @06:24PM (#47004215)

    The C Programming Language, so they learn how to properly document their work.

    • by dfsmith ( 960400 )

      K&R was an excellent introduction (short, expensive, valuable). However, I think I learned more about the why of C from reading Harbison & Steele, "C, A Reference Manual". It was a book for compiler implementers and programmers, and went into some of the design decisions, which really helped my comprehension.

  • by gweihir ( 88907 ) on Wednesday May 14, 2014 @06:24PM (#47004217)

    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.

  • Text Encoding (Score:2, Informative)

    by Anonymous Coward

  • 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...)
  • Dilbert. (Score:4, Insightful)

    by Anonymous Coward on Wednesday May 14, 2014 @06:25PM (#47004243)


  • by bugnuts ( 94678 ) on Wednesday May 14, 2014 @06:30PM (#47004299) Journal

    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.

    • by pla ( 258480 )
      This, a million times this.

      You can certainly find better books to help you learn a particular programming language. You can find better books about the history of programming. You can find better books on algorithmics that will make you a better programmer overall. You can even find better writing (although the skill that went into some chapters - "Crab Canon" in particular - simply blow me away), if you just want a good read overall.

      But if you don't read GEB and fall in love - you need to find a dif
  • It's simple (Score:4, Insightful)

    by viperidaenz ( 2515578 ) on Wednesday May 14, 2014 @06:39PM (#47004399)


  • by roc97007 ( 608802 ) on Wednesday May 14, 2014 @06:40PM (#47004413) Journal

    "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

  • Answer to title (Score:4, Insightful)

    by O('_')O_Bush ( 1162487 ) on Wednesday May 14, 2014 @06:47PM (#47004465)
    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.
  • 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 deve
  • 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.

  • You gotta disconnect from the tech every once in a while.

    • You gotta disconnect from the tech every once in a while.

      Yikes, How does reading about a litter of talking rabbits help you with that? Do they have a kindle version?

  • 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.
  • Dale Carnegie (Score:4, Insightful)

    by russotto ( 537200 ) on Wednesday May 14, 2014 @07:04PM (#47004593) Journal

    "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.

    • Re: (Score:3, Insightful)

      ...when the sales and marketing and pointy-haired businessmen try to manipulate you

      You have entirely missed the point of the book. It is not about manipulation. It's about being genuine and being persuasive. They are different things.

      I definitely agree that it is good to know when and how someone is trying to persuade you something, and it's a very valuable skill to increase your communication skills.

      "as a geek type you'll likely never be able to pull it off anyway"

      Resigning yourself to having
  • 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

  • by Beck_Neard ( 3612467 ) on Wednesday May 14, 2014 @07:08PM (#47004629)

    Then I suggest every programmer read every single one of the posts on this site: [] . The author has a remarkably clear head about things and a very mature outlook on programming.

  • by YrWrstNtmr ( 564987 ) on Wednesday May 14, 2014 @07:12PM (#47004669)
    "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'.
  • I'll just leave this free and open source CS101 course here: NAND to Tetris. []

  • by RandCraw ( 1047302 ) on Wednesday May 14, 2014 @07:17PM (#47004701)

    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.

  • by Hangtime ( 19526 ) on Wednesday May 14, 2014 @07:22PM (#47004737) Homepage

    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.

  • by Anonymous Coward on Wednesday May 14, 2014 @07:24PM (#47004745)

    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.

  • by jfdavis668 ( 1414919 ) on Wednesday May 14, 2014 @07:24PM (#47004747)
    Spoiler, everybody dies
    • Spoiler, everybody dies

      Including the reader... Or at least you wish you where dead for wasting all that time...

  • by NemoinSpace ( 1118137 ) on Wednesday May 14, 2014 @07:34PM (#47004803) Journal
    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.
    • by narcc ( 412956 )

      Here, here.

      Know who writes bad code? Everybody.

      Nothing is more instructive than a review of your own old work.

  • Every programmer should read Ecclesiastes. Vanity of vanities, saith the Preacher, vanity of vanities: all is vanity....

  • 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.
    • by geekoid ( 135745 )

      Worse. Advice. Ever.

      Hey, you don't need to learn about class, or environment, or understand memory to be a programmer! Just use VB.

      That the same mentality, stop it.

      Why you think OS = Good programming; is beyond me.

      • That is not the same logic, it's not even close. Joining a project with multiple developers who QC your code and assist you in module development is far from the crappy VB auto-completion. As for memory, I don't know where you got that either, as I mentioned to get a uC and write firmware for it, that is a crash course in pointers, memory and architecture, which you need to know to be a good programmer.
  • 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

  • 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?). []
  • There is a wikipedia entry about it, in case you have interest: []

    "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 pr
  • by sootman ( 158191 ) on Wednesday May 14, 2014 @09:43PM (#47005575) Homepage Journal

    ... 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.

  • 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 onlin
  • Anyone developing software needs a clue about names, and about unicode and text encodings. [] []

    (Then learn lots, lots more about text encodings).

    Also, whether or not they use SQL directly, about metacharacter attacks and SQL injection: [] []

  • by NotSoHeavyD3 ( 1400425 ) on Wednesday May 14, 2014 @11:29PM (#47006109)
    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.)
  • The correct answer to this question is "A programmer should read a lot".

  • by simishag ( 744368 ) on Thursday May 15, 2014 @12:55AM (#47006415)

    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.

  • by Sits ( 117492 ) on Thursday May 15, 2014 @01:05AM (#47006457) Homepage Journal

    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

    • A few people have volumes of Knuth's Art of Programming on their shelves (but it's harder to find people who have read all of them).
    • One of the consultants who taught at my University said that the Mythical Man Month and Peopleware were good. I've read these too and can also recommended them (although they are more about managing programmers rather than programming per se). The consultant also recommended Design Patterns (although he said not to read the book cover to cover but rather to just be aware of them so you could refer to them later).
    • I've heard the "Dragon Book" (Compilers: Principles, Techniques, and Tools I think is the 2nd edition) being talked of favourably.
    • Many people seem to recommend reading Godel, Escher, Bach (I'd say it's about mathematical thinking)...

    I've noticed which book answers tend to fall a bunch of categories:

    • Books that talk about software engineering/management/teams.
    • Books that talk about programming languages.
    • Books that talk about Computer Science.
    • Books that improve your mathematical thinking.
    • Books that programmers like but aren't programming/maths at all.

    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.

  • Try (Score:4, Informative)

    by Ghjnut ( 1843450 ) on Thursday May 15, 2014 @01:55AM (#47006621)
    The pragmatic programmer and code complete

I came, I saw, I deleted all your files.