Peopleware and books

I just started reading Peopleware, about how to create and maintain productive teams, with a focus on software development. I’ve only gotten through the first 3 chapters so far, but it’s freakin’ brilliant. I have no intention of becoming a manager, but it’s useful for a programmer to read in order to perhaps mitigate the worst of bad management. If nothing else, you can give it to your manager (if this makes them mad, quit now).

One awful and disturbing statement is at the end of Chapter 2:

The statistics about reading are particularly discouraging: The average software developer, for example, doesn’t even own a single book on the subject of his or her work, and hasn’t ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.

Where did they get that statistic? Can it possibly be true? I personally find it unbelievable, but then I’m the author of the Kernel Hacker’s Bookshelf series, so perhaps I am entirely out of touch.

17 thoughts on “Peopleware and books”

  1. We don’t know how they count, but I was hacking on Linux kernel since 1994 and I don’t own a single kernel book, not even Rubini/Kroah/Corbet LDD. What to say about Love et. al.! But I own a number of books in the fields where I do NOT work: Java, FPGA, IPv6, Patterson&Hennesy, Shimmel, etc. OK, I realize now that I used Shimmel when I maintained sparc(32) architecture. But it’s not a current case.

  2. I like Peopleware, but that sounds rather vaguely worded. What do they actually mean here, in a measurable sense? That the average number of books on an appropriate topic owned by software developers is less than one book?

    I am sceptical of this claim if it really is “the average number of books about anything to do with software development owned by a software developer is less than one book.” If nothing else, a substantial number of software developers take at least one formal course in it, and many of those courses set a textbook. (An alternative claim is that “software developers in the middle band of ability/effectiveness own on average less than one book…” but that seems like a weird measurement to make.)

    If it’s that software developers do not tend to own books about their specific area of expertise, I can more easily believe that: I do not know many developers of accounting systems who own books on “developing software for accounting systems” and many web programmers who do not own books on web development (they tend to use other resources). Operating systems has a large and good literature compared to many other fields of development.

  3. I’m doubtful. From personal experience, I don’t know any developers that don’t own a handful of O’Reilly books at the bare minimum. Even allowing for some selection bias, claiming that most don’t own and haven’t read any seems a bit of a stretch.

  4. Entirely plausible to me. Working in a company of a hundred or so developers, I find they can easily be divided into two groups. First, people who code for a living because they enjoy coding – such people generally have a strong drive to improve, which often includes reading books, developer blogs, and anything else that might catch their interest. Their reading material tends to include a) a handful of technical references, and b) a fair amount of more conceptual stuff like design patterns, things that give them ideas to think about.

    But there’s also the second group – those who simply code for a living. They’re not necessarily bad at the job, but to them, it’s just a job – they don’t have much interest in improving, except in so far as it might mean a pay rise. If they own technical books, they’re more likely to be tutorial in nature – how to code in Java, or how to use ASP.net – things they’ve had to learn to do the job.

    Obviously, the latter type don’t tend to participate much in open-source communities, so if you’ve not had much exposure to large development outfits, I’m not surprised you’re not familiar with such people.

  5. I own some books, but mostly bought a while back. For a lot of things, the web is better. Even for fairly obscure stuff – for algorithms, one can go to the web pages of academics working in the field, or conference proceedings, and get it from the horses mouth. It’s only when I suddenly need a map to some new area that I buy a book, and then I seem to end up just leafing through it and going back to google once I’ve figured out what I really need to know.

  6. I work in a large bank with an IT department of over 1500 people. Most developers have never read any books in their field other than direct how-to books (e.g. the perl cookbook) or the type of microsoft book that shows what button to click but doesn’t explain why. Many of my colleagues have zero reference books. The good developers do of course have stacks of books.

    I think the statement is entirely believable if read like “in-depth book” or “book explaining how and why thinks work”.

  7. For Free and Open Source Software in particular, dead tree documentation seems of limited value compared to the latest documentation off the Internet. You can’t grep dead trees, and they don’t automatically update when the software does.

  8. When I graduated from CS in 2004, the only book I’d accumulated I felt was worth a damn was an OpenGL reference. I hear they’re up to 3.0 now on OpenGL. I kinda think that books in general are a worthless resource in the field. Online documentation, on the other hand is rather helpful.

    My father had a ton of books, mainly business oriented language manuals accumulated over the years and I don’t think he really read them. For a lot of people I think the utter lack of enthusiasm for their job translates into a lack of enthusiasm for the field. When you work 50 or 60 hours on the job thinking about things because someone else is paying you to, you might be ready for something else at home. A hobby perhaps. Maybe read a book on investing so you can retire early?

  9. Sure, dead tree documentation of things that change quickly – like kernel APIS :) – are not terribly useful. Books about things that change slowly – such as good programming practice – are valuable to open source programmers as well as closed source.

    The general impression I’m getting, though, is that open source programmers tend to be more enthusiastic and thus more likely to own and read programming books. The two examples in this comment thread of coders who don’t give a damn and don’t read books are those in large development groups at big companies, and more likely closed source programmers.

  10. Hennesy and Patterson counts, dude. If you’re a serious kernel programmer, you have got to understand the basics of computer hardware design. I think the rest count as well.

    I wouldn’t interpret this as meaning you have to own a book on the Linux kernel; with all due respect for the hard work and excellent results of the various kernel book authors, Linux changes so quickly that the dead-tree references are immediately out of date. So is Documentation/, for that matter. :) I do own copies, but the most useful thing I’ve been able to get out of them is the high-level design of a subsystem as of a few years ago, which sometimes gives insight to the current architecture of the subsystem.

  11. Out of context, I would interpret that quote to mean that most software developers don’t own books on software development — the practice of developing software, as a distinct topic from programming / writing code / hacking. Which is to say, while most programmers own a book on their language of choice, they don’t own Mythical Man Month or Peopleware or whatever. That is entirely plausible, unless they’ve also been a manager at some point in time, or they got an actual Software Development degree instead of Computer Science.

  12. The general impression I’m getting, though, is that open source programmers tend to be more enthusiastic and thus more likely to own and read programming books.

    I think you’re wording it backwards – it’s not that open-source programmers tend to be more enthusiastic, it’s that the open-source community is made up of people who chose to participate in such a community. Someone for whom coding is just a job isn’t going to spend their spare time working without pay.

  13. programmer

    I think it’s plausible if you have a wide definition of programmer.

    Certainly the average *good* programmer has probably atleast a dozen books on various aspects of programming.

  14. In my copy of Peopleware, the second edition “featuring eight all-new chapters,” there is a section of notes at the end. On this particular point, they say, “The statistics on both ownership and reading come from private correspondence with the late Karl Karlstrom, then Senior Editor and Assistant Vice President of the College Division at Prentice-Hall, 1981.”

    So we’re talking data that, at best, is 27 years old…

  15. Peopleware

    I have read prob half of this book a wee while ago and was about to get back into it when I googled and found this page. It’s a great book but it does have a really dark view on project managers (at least I think so). alot of teh statements and “facts” also seem quite out of date. Not sure when the 1st edition was published but I don’t think teh 2nd edition has been updated enough to reflect modern thinking / modern systems. Thisnk like making statements such as Open plan is bad because of the amount of distractions created may not really apply these days, maybe people have a better tendency to block things out in teh work place or something else but it does seem a somewhat old fashioned statement and way of thinking.

    Anyway, its a great book and if you pick the stuff which may apply to you and maybe ignore / dismiss some of the more “older / unrealistic” stuff then its a very good read and gives you a great insight to a being a PM. I love the part at teh start that describes a developer’s role as to kill off a project as quickly as possible.

    Can highly recommend teh “fish” book as well if you liek peopleware. Fish book is a more upbeat way of making workplaces more exciting, lowering staff turnover etc…. http://notethat.blogspot.com/search/label/Head-ology

    Anyway, great comments, and the post has sparked a interest in finishing teh book :-)

  16. Generally people codes for such living because they enjoy coding – such people usually have a strong drive to improve, which often includes reading books, developer blogs, and anything else that might catch their interest. Working in a company of a hundred or so developers, I find they can easily be divided into two groups.

Comments are closed.