HN Books @HNBooksMonth

The best books of Hacker News.

Hacker News Comments on
Peopleware: Productive Projects and Teams

Tom DeMarco, Tim Lister · 22 HN comments
HN Books has aggregated all Hacker News stories and comments that mention "Peopleware: Productive Projects and Teams" by Tom DeMarco, Tim 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
Few books in computing have had as profound an influence on software management as Peopleware . The unique insight of this longtime best seller is that the major issues of software development are human, not technical. They’re not easy issues; but solve them, and you’ll maximize your chances of success. “ Peopleware has long been one of my two favorite books on software engineering. Its underlying strength is its base of immense real experience, much of it quantified. Many, many varied projects have been reflected on and distilled; but what we are given is not just lifeless distillate, but vivid examples from which we share the authors’ inductions. Their premise is right: most software project problems are sociological, not technological. The insights on team jelling and work environment have changed my thinking and teaching. The third edition adds strength to strength.” ― Frederick P. Brooks, Jr., Kenan Professor of Computer Science, University of North Carolina at Chapel Hill, Author of The Mythical Man-Month and The Design of Design “ Peopleware is the one book that everyone who runs a software team needs to read and reread once a year. In the quarter century since the first edition appeared, it has become more important, not less, to think about the social and human issues in software develop¿ment. This is the only way we’re going to make more humane, productive workplaces. Buy it, read it, and keep a stock on hand in the office supply closet.” ―Joel Spolsky, Co-founder, Stack Overflow “When a book about a field as volatile as software design and use extends to a third edition, you can be sure that the authors write of deep principle, of the fundamental causes for what we readers experience, and not of the surface that everyone recognizes. And to bring people, actual human beings, into the mix! How excellent. How rare. The authors have made this third edition, with its additions, entirely terrific.” ―Lee Devin and Rob Austin, Co-authors of The Soul of Design and Artful Making For this third edition, the authors have added six new chapters and updated the text throughout, bringing it in line with today’s development environments and challenges. For example, the book now discusses pathologies of leadership that hadn’t previously been judged to be pathological; an evolving culture of meetings; hybrid teams made up of people from seemingly incompatible generations; and a growing awareness that some of our most common tools are more like anchors than propellers. Anyone who needs to manage a software project or software organization will find invaluable advice throughout the book.
HN Books Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this book.
> I don't mean to say that people shouldn't do a good job at work or that they shouldn't try to continuously improve. But I think that an environment and a mentality of continuous competition between individuals is not necessarily beneficial. For one it can cause tensions, frustration, anger, alienation at an individual level, but I think in the long run it can actually harm the company itself.

IIRC, the authors of Peopleware [1] (fantastic book, btw) agree with you. They identified some pay for performance ideas for knowledge workers as "teamkillers" (e.g. tempting management ideas that end up destroying the social fabric that makes an effective team stronger than the sum of its parts).

Thanks for the recommendation, I'll check it out.
"Peopleware" is a great one --
Highly recommended. 100% agree with the "emotional part" and "engineers hate wasting time... DUE TO YOU" haha. A mind changer to me.
Agreed, Peopleware is great. Very good for engineering leadership specifically.
+100 for peopleware.
IMHO, the best one.
Excellent book! Adding Managing Humans to that.

I concur! Just finished MH and really enjoyed it.
Going beyond an article, 'Peopleware' is a fantastic book for engineering folks transitioning to management - it's not new but the fundamentals stand the test of time.

It's the book I started out with 15 years ago and I have suggested to many others.

Peopleware: Productive Projects and Teams (3rd Edition)

Agreed. I can’t recommend Peopleware enough. It is common sense, humane reasoning applied to software teams.

Sadly, I read Peopleware long before I ever became a manager, and it made me very attuned to being treated badly and being given ineffective tools or support (e.g. crappy open plan seating arrangements instead of private offices).

Peopleware will open your mind to the obviousness of productivity-first thinking and accomodating basic, inescapable human needs. Which can make you reflexively sad when you see how much of our industry steamrolls these ideas in favor of idiotic open plan disasters, hazing-focused interview barriers to entry, unrealistic mandates for Agile-style estimation and work tracking, etc.

Peopleware: Productive Projects and Teams (

It talks about what makes a good team, how powerful they can be, and also gives some insight on team dysfunction.

The classic book ‘Peopleware: Productive Projects and Teams’ covers office layout from productivity perspective:
Everybody arguing for open office plans and stating that they or "some people" thrive in such environments should finally come around to read Peopleware [1].

Although they might base some statements on assumptions I do not fully agree with all the time, and before reading I was had not decided if I was strictly for or against open office plans, their conclusion is spot on: open plans do not foster collaboration or communication. They may cause a constant buzz and seem productive, but nobody will be smart, creative or productive in that environment, compared to a silent, uninterrupted workplace.

All you multitaskers and procrastinators (including me): You are lying to yourself.


I might add: I honestly do think we thinkers, developers, programmers, researchers, etc. do not talk enough and communication and exchange is important.

That being said, the open office plan is not the solution to that, it will kill every possibility of focus, and make the lives of people seeking it miserable - because there needs to be communication, but it should not interrupt everyone especially if not actively participating.

I made the transition from engineer to managing a team of around 12 at Groupon. So I made the transition with a smaller team than you are - forgive me if some of this isn't as useful for your situation.

What worked for me:

- One on Ones. Nothing I've done has had as much of an impact as weekly one-on-one meetings with everybody on my team. I tend to follow the format outlined on Rands In Repose: (This is an incredible blog for engineering management. I would highly recommend reading everything he has written.)

- Read everything you can find on the topic and about leadership in general and start figuring out how you can incorporate the lessons from those books into your situation and context. This is a brand new skill set that you need to approach with the same effort that you had been approaching engineering.

Some suggestions:

Rands in Repose:

Radical Candor:

Extreme Ownership:

Becoming a Technical Leader:


- Finally, one piece of advice I got when I first transitioned into management was that "first-time managers usually fall into the trap of becoming the manager they wish they had. What you really need to do is figure out how to be the manager that each person on your team wishes they had, and become that manager." Easier said than done, obviously, but I've always found it useful to return to it whenever I am struggling.

>"Finally, one piece of advice I got when I first transitioned into management was that "first-time managers usually fall into the trap of becoming the manager they wish they had. What you really need to do is figure out how to be the manager that each person on your team wishes they had, and become that manager."

That is a very salient point. Managing a team of multiple people of different backgrounds, experience levels, quirks, communication styles, pet peeves, etc. is an exercise in adaptation.

As a Director, there are certain things you need your team to adapt to in order to keep your team on track with your strategy and process. How you go about getting them to do that is all about you adapting to them to get them excited, help them overcome hurdles, break down communication barriers, and build your relationship so they know you have their backs and you know you can rely on them.

It sounds easy in principle, but it is incredibly difficult in reality, particularly for those who may be stronger on the technical side than the communication side.

And P.S., you won't always be successful, so start planning for when (not if) you will fail in that regard. That means making sure your team knows that you are always open to their candid feedback so you can do a better job of supporting them.

On a final note, I'm quite partial to this illustration that nicely sums up your role in relation to your team [1]. In another sense, some see an org chart with them at the top and their team beneath them. I see it as an inverse pyramid with the leader at the bottom supporting each and every one of their team members because your success is wholly dependent on their success at that level.


> What you really need to do is figure out how to be the manager that each person on your team wishes they had, and become that manager.

Manager of a software development team here. Great advice. Thanks!

"Peopleware: Productive Projects and Teams"[1]. Even if you're not in a management track, it's a great read to learn and better understand how to structure teams for a happy, productive and successful path.


Edit: add Amazon link.


Peopleware: Productive Projects and Teams (3rd Edition)

Well I don't have a MBA :D, but I do have a masters degree of a similar orientation (Masters in engineering management). I can only recommend the ones I have read and found of value:

[1] Crossing the chasm (Marketing related)

[2] Peopleware (HR related)

[3] How to win friends and influence people (HR related)

[4] The Goal (Business related)

[5] Critical chain (Project management related)

[6] Who moved my cheese (Change management related)

and any of the lean / agile businessy books for ex.

[7] The lean startup

These might not be viewed as traditional MBA material, but my course featured some of these along with more traditional academic books on subjects like financial management, people management, operations etc. I can provide these textbooks to you as well if you like.

*Amazon links just for convenience, no affiliation.








Amazon links for the lazy:

"The Mythical Man Month" -

"Peopleware: Productive Projects and Team" -

"The Pragmatic Programmer" -

"Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams" -

"Joy Inc: How We Built a Workplace People Love" -

"A Lapsed Anarchist's Approach to Being a Better Leader" -

"Becoming a Technical Leader: An Organic Problem-Solving Approach" -

"Code Complete" -

Thanks for the shortened URLs. Question: I always obtain those by hitting "Share" and then copying the link. Is there a better way?
Regarding people skills, I always recommend Peopleware[1].


A great example of a group of people gelling into a team with its own culture in a way that enhances its work. I ran across this example in the book PeopleWare:

It had a lot more wisdom in it on teams, interruptions, flow, and so on. I recommend anyone that enjoyed this story to get it as it has many more with recommendations. Of course, my version was an older one so the new one might be better or worse. I'm sure it will be Good at the least. ;)

Putting aside all the ad-hominem and everything-is-terrible, I think I learned a lot from following the references Tef makes in this talk.

Some references (sorry for the formatting, if this becomes a thing I'll do the wiki and the logo):


Blub Paradox:

Perl and 9/11:


Waterfall (same pdf, linking from 2 sources):

Conway's law:

Unrelated, Pournelle's Iron Law of Bureaucracy (I just like this law):

X-Y Problem:

Atwood, Don't Learn to Code:

Wason selection task:


Amazon Links, no referral:

TL;DR: this, and this guy really does not like Jeff Atwood.
He doesn't like PG or Joel Spolsky either!
Links to the books Drive:

and Peopleware:

for those who are worried about clicking url shortners

DanielBMarkham has been on this site for a long time and is pretty well known, so I would trust him not to put shady links.

I also heartily agree with him that lots of business books are best digested as summaries - look them up on wikipedia, for instance. The fundamental problem is that many have a simple idea, but you can't sell a 10 page book. So it gets fluffed up with lots of case studies and extra material until it's long enough to sell as a book.

Try "Peopleware" from DeMarco and Lister:
3rd edition is out! Great news! Time to re-read.

Now instead of looking for my second edition, I'll spend tonight debating if I should get paper, or Kindle version, or both. :)

Speaking of influential books, Peopleware and Mythical Man-month are the most influential software books for me.

Agreed. The Mythical Man-Month by Fred Brooks is another great book. It is famous for Brooks's law: "adding people to a late project makes it later".

But for me, even better with that book was one page at the end of chapter one, entitled The Joys of the Craft. There, Brooks described what's so great about programming. I really loved that part, and wrote a blog post about it:

Yes! This one should be required reading for anyone managing people or projects. It's a bit like "The Design of Everyday Things" - it isn't necessarily the material in the book, but rather the patterns of questioning and thoughtfulness produced by the book that will stick with you. Peopleware is beyond being a "software" book - it's really about how to create an environment where professionals can thrive.
Peopleware has some good information on quantitative value of private offices vs alternatives:

Their discovery was that people who had closed door offices were more productive. In general people with less interruptions got more done.

The book is somewhat dated, so this may have changed since, but one of the interesting things they found was that there weren't really any studies showing that open offices helped productivity for software teams. It was purely a cost saving measure by execs wrapped up in wrapping of "being collaborative".

The individuals may have been more productive; did they measure the output of the teams?

I don't think anyone disputes that people are more productive without distraction. That's not what open plans are for though: collaboration helps everyone orient around the right thing, so all that individual productivity isn't wasted pursuing the wrong stuff.

That's a good point and I'd definitely like to see some quantitative studies on that.
Haven't read it, but the source I've always heard cited in claims that less distraction leads to real productivity gains (3x) is Peopleware
Oct 22, 2013 · willismichael on Coworking Spaces
I use headphones in my current open workspace, but I find that there are certain things that I work on that are really better in silence. From Peopleware [1]:

"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 an 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 Cornless experiment, however, contained a hidden wild card. The specification required that an output data stream be formed through a series of manipulations on numbers in the input data stream... 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."

I don't think there's a problem with listening to music some of the time. My concern is that by constantly having the headphones on to mitigate audible distractions, I'll miss insights that would directly impact the quality of the work that I do.


I never bother with cookie-cutter interviews. With the exception of the first, every time I've had one I ended up being made an offer, and turning the job down. First, I found obscure technical questions from interviewers a bit sadistic. Almost as though the interviewer is trying to tell you how good she is. When I accepted an offer after such an interview I only lasted three months, because the interviewer felt threatened by me.

If, conversely, a candidate asked me the questions edw519 listed above, you'd pretty much be guaranteed a job. I don't care how well or badly you program. I don't care whether you know Boost or not. I want to know whether you'll fit in here. Ever read Peopleware [1]? There's a great example in there on why you should value the programmer that seems to deliver nothing of value, and yet makes the team gel.

If you don't know why this line of C++ code compiles with Visual Studio 6, but produces the wrong result, hey, that's ok. Are you giving me the impression that you like programming? That you will try and find an answer yourself before coming to ask for my help? If I ask you a question that you can't answer, do you bullshit, or do you say "Hey, I don't know, but I'll find out and email you the answer tomorrow."

The character is far more important to me than your ability as a programmer. The former is a fit, or it isn't. The latter I can work with. Because it's a long game.


"If, conversely, a candidate asked me the questions edw519 listed above, you'd pretty much be guaranteed a job."

I'm confused. Is it normal for an interviewee to ask the interviewer a tricky technical question at some point of a job interview now? Am I reading this correctly?

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.