HN Books @HNBooksMonth

The best books of Hacker News.

Hacker News Comments on
Peopleware: Productive Projects and Teams

Tom DeMarco, Timothy Lister · 41 HN comments
HN Books has aggregated all Hacker News stories and comments that mention "Peopleware: Productive Projects and Teams" by Tom DeMarco, Timothy Lister.
View on Amazon [↗]
HN Books may receive an affiliate commission when you make purchases on sites after clicking through links on this page.
Amazon Summary
Demarco and Lister demonstrate that the major issues of software development are human, not technical. Their answers aren't easy--just incredibly successful. New second edition features eight all-new chapters. Softcover. Previous edition: c1987. DLC: Management.
HN Books Rankings
  • Ranked #19 all time · view

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this book.
There's even a whole book about this: (by one of the authors of Peopleware[1], which is also excellent).


Please, please, please pick up the book Peopleware if you haven’t read it. It’s a classic for a reason
(New-ish manager here.)

_Peopleware_ by Tom DeMarco and Timothy Lister is the best management resource I've encountered.

It also helped to keep careful track of things I really valued (and hated) about people I've worked for.

Just one example:

Depending on team size and culture it can concerning if your manager schedules a 1:1 meeting with you out of the blue and outside of your normal cadence. I had a manager that did this, on a Friday, with the meeting scheduled for Monday. Worrying about it would have bugged me over the weekend. Not a ton, but some. He followed the invite up with a Slack (team chat app) message explaining what the meeting was and what he wanted to talk about, turns out it was nothing to worry about. Him taking the time to clarify made a difference in my morale and it stuck with me.

Super small thing, but it matters.

my last weekend was ruined by a bad experience with Spectrum Cable and my supervisor on a Friday.
While I'm at it, 2nd best: _Managing Humans_ by Michael Lopp (aka Rands).

Not specific to scrum but I am reminded of a part from Peopleware:

"The most surprising part of the 1985 Jeffery-Lawrence study appeared at the very end, when they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others (see Table 5-3)."

  Table 5-3 Productivity by Estimation Approach (Full Result)
  Effort Estimate Prepared by   Average Productivity   Number of Projects
  Programmer alone                     8.0                    19
  Supervisor alone                     6.6                    23
  Promgrammer & supervisor             7.8                    16
  System analyst                       9.5                    21
  (no estimate)                       12.0                    24
This doesn't surprise me tbh. It's the same situation except you're not shackled by yesterday's commitments and free to act independently of them .
There's no source because it's a completely false claim. The "remote doesn't work" trope is perpetuated by Silicon Valley Culture[1][2]. Remote work is like security. You can't bolt it on and expect it to work. You can't half-ass it and expect it to work. The companies that do it correctly make it a foundation of their culture. I will cede the fact that remote work isn't for every individual, but I think even that can be overcome with the right company culture and support network.

1. 2.

I agree with you completely and suspect there is no evidence to corroborate the claim. I thought I would ask though.
I honestly think that even that is too binary. Clearly there are fully remote and no/minimal remote companies. But there are also a lot who (mostly) started with an onsite culture and as they've grown/acquired teams/etc. they've become more distributed and remote work-oriented organically. And they usually find it works better for some teams and roles than others.
I can't recall a time in the last 1-2 years when someone complained about it

Pick one (or more):

* they don't know the alternative

* they're afraid to speak up and sound un-cool

* they don't realize it's actually killing their ability to focus

* they do so privately and are ignored by the higher ups

Audio-visual distractions have proven to be detrimental to focused, "intellectual", work. Not by an article on Medium, but by actual research[1]. Time[2] and time again[3] and again[4], ad infinitum.

Open office is the anti-vaxx of today's tech world, where all known data is ignored in favor of superstition.





I second that observation. I wish the manager at my day job read ANYTHING, at the very least some informercial-laden industry publication.

In my case, I'd like him to read Fred Brooks' "The Mythical Man-Month", to make him understand how a programming system costs a lot more than a simple module.


In second place, I'd place "Peopleware", so he'd understand the importance of communications, and how the current office arrangement is losing the company a lot of money:


Amazon link to both:

Learn that everyone has value. No one is as exceptional as they think.

The guy coding a little slower but who customer success always talks to about problems. Great, he’s enabling communication between teams.

The girl who cleans up behind the “flash” programmer whose prototypes are awesome but doesn’t quite finish.[1] Great, she’s creating production code to be maintained by a team.

The list goes on. People provide value in ways that are not always apparent. I think Peopleware talks a bit about this although I may be mistaken, about the one team member who didn’t seem to fill a role but made everyone happy.[2] If the team wins everyone wins (hopefully in a good org).

The most exceptional teams have people filling roles. Every role is important and provides value. It’s why teams with a ton of exceptional people often implode, because they are all exceptional at only one thing and no one is filling the other roles. So all the members may appear exceptional, but the team is weak. It's a value systems problem.



This was the source cited the last time this quote was posted here:

"Peopleware" , a lot of insights and ideas how to build great teams. Great to read for developers, team leads and managers.

"The art of multiprocessor programming", excellent book on parallel programming theory with code explanations:

Got about 20 pages left in the Peopleware third edition. Excellent book even if you aren't a manager.
I read (not all of it, maybe 50% of it) "The art of multiprocessor programming" a couple of years ago and I agree, its an excellent book. I have a handful of books on the topic and I find this to be my favourite.
If you have the list of books to read on the topic I would be happy if you share it. My next book on the topic will be
The only ones I can think of off-hand are these two. The second one isn't really about parallel/concurrent/distributed programming per se, but rather about using Intels Threading Building Blocks - good book if that's what you want to do, but not very useful if not. The first book is interesting and covers a lot of ground (covering general techniques and algorithms as well as specific implementations with OpenMP, MPI and Java's facilities), but I liked Art of multiprocessor programming more, probably because it has a more beginner friendly teach everything from the very beginning approach.

Joel Spolsky has written a lot about open plan vs private offices (most of it inspired by Peopleware

> Not every programmer in the world wants to work in a private office. In fact quite a few would tell you unequivocally that they prefer the camaradarie and easy information sharing of an open space.

> Don't fall for it. They also want M&Ms for breakfast and a pony. Open space is fun but not productive.

See also:

Agreed, but limiting the human element (as opposed to 'drastically limiting') can lead to better productivity.

But most developers work better in offices with doors that shut (at least according to what I remember of Peopleware [], though that was published before IM was everywhere).

So I think acknowledging that you work better with quiet, and framing it as 'I want to be as effective as I can', is fine.

It can even open up a discussion on true effectiveness--if I am writing tons of great code because it is quiet, but you could have saved me 8 hours of code writing because of a library you know about or wrote, am I as effective as I could be (no). This is the quiet end of the spectrum.

The loud end is the bullpen with no headphones, where it can be very difficult to think.

There's a place for PMs. If you're willing to step into shoes other than your own, start by reading PeopleWare [1]. And then dig into the origins of self-managing Scrum and have a read through Takeuchi and Nonaka's paper[2].

When you're done, I'd love to hear your thoughts on PMs, and why we're still making the same mistakes we made, and wrote books about, 30 years ago.



peopleware goes into this a lot. i know it's an ancient classic that everyone has heard of, but it's actually still worth reading, imho (i found it much more relevant/useful/interesting than mythical man month - not sure why, it just clicked somehow).
Jan 25, 2013 · mbesto on Zen Writing Mode
I'll just leave this right here:
Just picked this one from the library. Around here, few people know it (Brazil).
Books that actually caused changes in my life:

Yes Man ( )

This book made me realize that I was defaulting to "no" in many aspects of my life. After this book I changed many things in my life, and ended up meeting and dating my future (now present) wife. Overall my life has been much improved by defaulting to "yes".

The Pleasures and Sorrows of Work ( )

Gave me insight into how there is a huge invisible fabric of society that we take for granted, and how I consistently underrated many categories of jobs. One change I made after reading this book is to respect the jobs that I took for granted, like the clerk at the checkout counter. I now give attention and respect to people that I used to treat like furniture before.

Books that would have changed my life had I read them sooner (and not have to learn their lessons the long/hard way.)

The Happiness Hypothesis ( )

The notion this book puts forward of the subconscious as a powerful but stubborn elephant and the conscious as its well-meaning but often impotent handler provides much insight into why people act against their own interests, and why they tell lies about themselves and their own actions. One of the things I had realized beforehand (through many years of struggling with social interaction) that the book also covers is how we all tell a story of our life in which we are the hero, and how we rationalize our actions to fit the story instead of adapting the story to fit the facts.

Peopleware ( )

The book covers why building software is primarily a people problem, not a technical problem. Again, I had already realized this, but it would have been nice to learn it sooner. Some stuff is outdated, but it's still one of the top books on building software in my opinion.

I'd second the 1st, 3rd and 4th of these. Peopleware is awesome - obviously - and The Happiness Hypothesis has had plenty of press.

However, don't underestimate Yes Man. It's by a comedian, but it's still a very powerful and interesting read.

It is especially shocking since a very compelling case was made (with actual evidence and everything!) for quiet and against open plan layouts back in 1987.

There are some great books which may help provide you with some structure on how to manage the team:

Peopleware: Productive Projects & Teams

Delivering Happiness: A Path to Profits, Passion, and Purpose

Rapid Development: Taming Wild Software Schedules

The Five Dysfunctions of a Team: A Leadership Fable

Fundamentally, cultivating a healthy team culture is the most important role you can play. Foster open, transparent communication, and avoid falling into the trap of micromanagement. Keep things happy, keep it real. All the best!

Thank you so much. I'll try to get my hands on these books!
Jul 02, 2012 · amm on Shall We Use Clojure?
> I've had first-hand experience of how technology choices affect companies and it can be very painful down the road.

I've had the same experience. A couple of years ago we decided to implement a rather large part of a project in JRuby (the other part was written in Java), because it seemed to be the right tool for the job: a scripting language that can interoperate with java libraries out of the box.

In retrospect it was a bad decision, because the interpreter error messages were (are?) cryptic (at least compared to what you get with Java) and IDE integration was really, really bad. Cross-language re-factoring was broken and we ended up unit testing almost every line of JRuby code to make sure we didn't introduce regressions when making changes to running systems.

There's a part in Peopleware ( where the authors describe that the choice of programming language has almost no impact on the success of a project. So why add additional risk when there's no proven benefit?

Edit: Also, people always argue that they can get things done much faster in "esoteric" languages, but forget about the time spent on maintenance, bug fixing, explaining code to new colleagues, ...

To add a few that span outside entrepreneurship, but are of course very valuable to entrepreneurs:

Inspired: How To Create Products Customers Love ( - The best if not only required reading for product management

Peopleware ( - Great read on managing and understanding people as it relates to organizations

Managing Humans ( - Obviously on management, you can read much on this, though the book does a great job of consolidating it

Great call on Inspired. Hands down the best Product book out there...haven't heard any others even in the conversation.
When I first landed this kind of role, I was given a copy of "Peopleware: Productive Projects and Teams ". In some circles it is considered a bit of a bible for this topic.

It's kind of an old book, but then the principles have remained the same. It also means this book isn't then laced with specific methodologies of the day or what not.

Downside is its a tad expensive on paperback, but reasonable on Kindle:

"During the 1960s, researchers at Cornell University conducted a series of tests on the effects of working with music. They polled a group of computer science students and divided the students into two groups, those who liked to have music in the background while they worked (studied) and those who did not.

Then they put half of each group together in a silent room, and the other half of each group in a different room equipped with earphones and a musical selection. Participants in both rooms were given a Fortran programming problem to work out from specification. To no one's surprise, participants in the two rooms performed about the same in speed and accuracy of programming. As any kid who does his arithmetic homework with the music on knows, the part of the brain required for arithmetic and related logic is unbothered by music—there's another brain center that listens to the music.

The Cornell experiment, however, contained a hidden wildcard. The specification required that an output data stream be formed through a series of manipulations on numbers in the input data stream. For example, participants had to shift each number two digits to the left and then divide by one hundred and so on, perhaps completing a dozen operations in total. Although the specification never said it, the net effect of all the operations was that each output number was necessarily equal to its input number. Some people realized this and others did not. Of those who figured it out, the overwhelming majority came from the quiet room.

Many of the everyday tasks performed by professional workers are done in the serial processing center of the left brain. Music will not interfere particularly with this work, since it's the brain's holistic right side that digests music. But not all of the work is centered in the left brain. There is that occasional breakthrough that makes you say "Ahah!" and steers you toward an ingenious bypass that may save months or years of work. The creative leap involves right-brain function. If the right brain, is busy listening to 1001 Strings on Muzak, the opportunity for a creative leap is lost.

The creativity penalty exacted by the environment is insidious. Since creativity is a sometime thing anyway, we often don't notice when there is less of it. People don't have a quota for creative thoughts. The effect of reduced creativity is cumulative over a long period. The organization is less effective, people grind out the work without a spark of excitement, and the best people leave."-Peopleware[]

I agree that silence is probably better than any sort of music for programming. Unfortunately, that's not the choice programmers often have to deal with. Usually, its a choice between music and the usual office distractions (other people's conversations, the noise of people moving around, etc.) In those cases any sort of music to block out background noise is a godsend. Having headphones on also signals to visitors that one is busy and that interruptions should be only for important things.
Headphones and white noise can serve the same purpose as silence.
Correct in my experience (I sometimes work with music, sometimes with silence). Deep insight needs silence: "You want to quiet the noise in your head to solidify that fragile germ of an idea" ->

The creativity part, the few eureka I had were when pausing long enough far from the screen, be it for a pee, a cigarette, or a bike ride. Same for my colleagues.
I can believe that. I listen to music (generally sans lyrics) only when I'm doing stuff that's relatively repetitive and un-taxing.

I don't think it makes me more productive, but it does make me happier.

So yea my hypothesis is that listening to music you like would release dopamine and make mundane work more bearable. It's also how psycho-stimulants like Adderall help ADHD people focus.
Would listening to music you like also release dopamine, and therefore make mundane work more bearable?
Many of the everyday tasks performed by professional workers are done in the serial processing center of the left brain. Music will not interfere particularly with this work, since it's the brain's holistic right side that digests music.

Makes me wonder if one of the subconscious motives for encouraging people to listen to music in cubicleville is to subtly keep them cowed and contented with doing the repetitive tasks they are assigned without thinking too much about how the process might be improved, without asking too many questions, and so on.

Peopleware was a beneficial book, but these stories need corroboration. I talked to one of the authors at a conference once, told him how much I loved one of their stories (that the Dutch East India Company, once the greatest corporation in the world, still exists with a mere 50 employees who do nothing but fill out paperwork) and asked him where they'd found it. "Did we say that?" he asked. Yes, absolutely, I said. "Oh," he replied. "Usually we only make stuff up for our talks, not our books."
Thanks for mentioning that. I scroll to the bottom of the book and got this for reference: "The Cornell experiment was never documented and has thus taken on the status of hearsay evidence except for those of us who were there. For a concurring view of the effect of music on concentration, see Jaynes, 1976, pp. 367-68."
"Concurring view" indeed, not an experimental study. What a weird thing for them to cite!
Also, make sure to read tons about how programmers feel about business guys / managers, and figure out how not to be like those people. There's tons of advice out there, and there may even be some good advice in the most offensive rants. Read those rants, feel the pain of those programmers, and see the opportunity to improve yourself so you don't inflict similar pain.

Some possibly helpful resources which you may have already seen: (right sidebar has a ton of articles)

I think this is SO much more valuable for a biz founder than learning to code. Understanding the development process and developers is critical. On the other hand, knowing how to code is merely useful.

(Note: I differentiate "knowing how to code" from being a coder. One means I made it through Python for Dummies; the other means I have a history of making software and understand the issues around it. That is far more than useful.)

Also, read Peopleware. It's an excellent book for anyone who has to manage technical teams.

Joel Spolsky mentions that every manager at Microsoft has to read it (I could be wrong on that, but a lot do read it apparently).

Assuming you don't go the year+ path of learning how to code (note the saw of a little knowledge being dangerous), you need to find a programmer who you ABSOLUTELY trust and respect, without reservation or hesitation. A co-founder, hired gun, whatever. You'll need him to vet your ideas, the people who do the actual work, the technical project management, etc.

Buy this book: and read/skim it. If you don't "get it", accept what it says as Revealed Truth and then if you have any talent for this game you'll understand more and more as you play it.

The Joel Test is also a good thing to pay attention to and follow:

May 05, 2010 · hga on The Immaturity of CMM
I focused mostly on the "Feet of clay: The CMM's fundamental misunderstanding of level 1 Organizations" section and I find a lot to disagree with.

The biggest issue, which I don't sense the author gets, is "repeatability". Level One companies are entirely dependent on "heroes" (or cowboys, take your pick :-) and their ability to follow their first success is not particularly predictable, except that it's likely to be poor. Look at Lotus, who's first product (the 1-2-3 spreadsheet etc.) was written by a team of 7 or so assembly language wizards for the first IBM-PC and that lost it's ability to develop software after that (1-2-3's mid-life kicker that saved the company (for a while) was an unauthorized project written by two programmer who left the company before the need for it was acknowledged).

I think we realize this less now because we're so much more leveraged and "powerful" today; a small team can do so much more and continue to do that if the company avoids Teamicide ( , READ IT!!!) and doesn't have to grow its team (much).

Microsoft, on the other hand, by the 1994 date of this essay was most certainly not a Level One company. I've long said the secret to their success in the period that includes that year was that they retained the ability to write software that basically worked (compare this to all their Windows Office competitors who lost in the transition to Windows 3.x: with the exception of WordPerfect, the others couldn't get past the "crashes too often" stage, and WordPerfect's release was a sad joke. Sure, it didn't crash, but it also would frequently move all your figures and tables to the bottom of your document.)

It's No Accident that Microsoft was run during that period by a seriously good hacker (anyone who can successfully rewrite an assembly BASIC interpreter (without benefit of a computer) during a transcontinental flight earns my respect.)

I too prefer Gerald Wienberg's approach to this, and CMM can obviously be fetishized and at best promises little more than "we can continue write mediocre software", but there's something there that's worthwhile that it's trying to achieve.

May 04, 2010 · rimantas on Real geeks die early
More than once I had a wish managers would have read this book:
When I was made a manager, I had the company buy cases of that book: one for each person in the department.
Jan 21, 2010 · earl on On Wages
There is some empirical evidence in a book called Peopleware.

I would paste some quotes but I lost my copy.

It seems to be out of print: . $95 second hand... Is it worth it?
Try bookfinder for used book search -

New for $55, used for $4-65, but several in the $28-35 range

It's been in and out of print on and off for years, I buy a few copies whenever it's back at the regular price. I've given away 6 copies now to various people.
You can get it from the publisher ~$46 ($39.95 + $6SH):

You might also try a local brick and mortar bookstore.

The 39.95 price includes shipping (UPS ground). Read it wrong the first time.
> Is it worth it?

Actually, I think so. Yes.

TimothyFitz (ebay) has it for $30

It's probably worth the $95 anyway.

As xsmasher said, you're citing Peopleware, by Demarco and Lister. If you didn't know that instantly, you need to read the rest of the book as well.

Pick it up, you won't be disappointed.

I'm really surprised nobody has mentioned Peopleware ( It's full of stuff about creating an environment that minimizes interruptions so you can get into the flow (or zone or whatever you want to call it).
It's by Tom DeMarco. The co-author of this:

I mentioned this in another comment, but the guys from Peopleware did exactly that:

The also conclude that small offices with 2-4 people and a door that can close is best.

Interestingly, 2-4 people per office on a small team == an open office plan.

Everyone says that Peopleware advocates private offices (e.g. 1 per person), but their main problem seems to be with cube farms.

You could read this research, or just have read Peopleware from, what, 15 years ago? DeMarco and Lister nail everything you've ever thought about working in an office.

If you haven't read this you should have! I think Joel just cribs articles directly from it some days ;)

Well, he has definitely read it.

Thanks for the link.

I know Joel has read it, Joel is one of the biggest blogging proponents of a lot of their philosophy. I only meant to be a bit tongue-in-cheek. I don't think Joel is trying to rip those guys off at all.
1. Peopleware:

2. Pragmatic Programmer:

How could I forget Peopleware? Good call! I've also been meaning to read Pragmatic Programmer, thanks for the reminder...
I highly recommend reading the book Peopleware by DeMarco and Lister. It devotes a chapter to the programmer's environment and speaks passionately about how important it is to get it right. They get into details about offices. They also say that if you can't get the environment right, you might as well stop there. Of course, "environment" also includes things like frivolous interruptions, etc. Anyway, it's an excellent read:

Joel Spolsky (another big fan of Peopleware) wrote on this when he had his office designed:

Apr 16, 2007 · bootload on Movable walls
'... I designed an office for Crabel Capital in Milwaukee - a whole floor mainly for the programmers ... We ended up using framed walls ...'

Glad someone takes these things into account. Not enough thought goes into developer workspaces apart from the fact that Demarco [0], Spolsky [1] and Graham [2] talk about relationship between superior workspaces and improved product.

The evidence is there but as soon as it comes to forking out the dollars there are excuses everywhere why it costs so much.


[0] Demarco, Lister, 'Peopleware, Part 2, The Office Environment, 0-932633-43-9'

[1] Joel Spolsky, "google search on 'the office'"

[2] Paul Graham, "Great Hackers, The Final Frontier"

(The office was finished early this year)

Here are some of the ideas I was working with specifically for making developer work spaces (This space is for a very fast growing but financially mature business - not a cash-strapped startup. My primary advice for a startup office space: buy DOORS for desks!. You can get doors at home depot for desks - hollow core nice wood without the door handles drilled out for just over $10 apiece. Put the doors on top of file cabinets, and voila, you have a nice looking desk at very low cost that can last for years if you like.):

From the hackers perspective:

+Each space had to have natural light and views, but be closable for privacy. The point here is to allow for staring into the distance when the subconscious is cranking on an idea, allow the space to be closed during moments of extreme focus, and to have the doors be a sign to others which mode the person is in at the time.

+Each space had to allow for a small conference of 2-3 people for easy and impromptu discussions.

+Each space had to have a lot of attention to detail and materials to make the spaces feel personal.

+There had to be a space for larger meeting outside of the formal business conference room. I turned the lunch-room into one of the key design spaces and put whiteboards all along one wall with data ports for easy discussions and to make having lunch more fun. (The company provides free lunch every day)

+The developer area had to be acoustically protected from the back office area, the customer relations area and the accounting area to avoid concentration disruptions.

+The space was in a classic old building with exposed wood beams and ceilings, so we used a raised floor system (with no sign to the user that it's raised) to have all the heating/cooling provided from the floor and allow for easy addition and movement of data and power ports.

+The server room was treated as a "jewel" with wall to wall glass for people (especially hackers) to appreciate the racks of technology at their fingertips. (Also, the servers had multiple power back up systems including generators, a fire suppression system that would not damage the equipment in case it was used, and its own cooling system to run at ideal temperatures with a lot of extra rack space to allow for easy growth.)

From Management's Perspective:

+The space had to be flexible to allow for reconfiguration and potentially moving out to another space in the future.

very cool ideas here ~ must take some time to think about them.

'buy DOORS for desks'

the old cheapscate amazon office ~

Nice link :) I guess my "door desk" is one step above Amazon as the filing cabinets look better (I use black ones that just happen to be exactly desk height) and don't cause injury on leg impact. They do cost more depending on how nice your file cabinets are. The alternative to filing cabinets are bolt on adjustable metal legs designed to hold doors - they cost about $15 apiece and look pretty good.

Another great door holder (maybe the best) is a bookshelf from office depot:

A good option: filing cabinet or shelves one side, legs the other.

I actually got the idea in 1989 when I was working for Paul Rudolph Architect in NYC. He was doing major high-rises all over SE Asia at the time and billing at $360+ per hour (staff of 7) but still worked on his door. He had designed a simple steel support structure that tilted the door for better drafting - analog drafting believe it or not. That was 1 year before I went from pencil drafting to Cad.

If it's evident in the job listing that they have read and practice what's in Peopleware (a classic, be sure to read it if you haven't already).

HN Books is an independent project and is not operated by Y Combinator or
~ [email protected]
;laksdfhjdhksalkfj more things ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.