Found in 15 comments
by bipson
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.


Original thread
by Stwerner
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.

Original thread
by W0lf
I've gathered all the book titles in this thread and created Amazon affiliate links (if you don't mind. Otherwise you still have all the titles together :-) )

A Pattern Language, Alexander and Ishikawa and Silverstein

Advanced Programming in the Unix Environment , Stevens

Algorithmics: the Spirit of Computing, Harel

Applied Crytography, Wiley

Clean Code, Martin

Clean Coder, Martin

Code Complete, McConnel

Code: The Hidden Language of Computer Hardware and Software, Petzold

Coders at Work, Seibel

Compilers: Principles, Techniques, & Tools, Aho

Computer Systems: A Programmer's Perspective, O'Hallaron and Bryant

Data Flow Analysis: Theory and Practice, Khedker

Dependency Injection in .NET, Seemann

Domain Driven Design, Evans

Fundamentals of Wireless Communication, Tse and Viswanath

Genetic Programming: An Intrduction, Banzhaf

Head First Design Patterns, O'Reilly

Implementing Domain-Driven Design, Vernon

Intrduction to Algorithms, CLRS

Introduction to General Systems Thinking, Weinberg

Joy of Clojure, Fogus and Houser

Let over Lambda, Hoyte

Operating Systems: Design and Implementation, Tanenbaum

Parsing Techniques, Grune and Jacobs

Peopleware: Productive Projects and Teams, DeMarco and Lister

Programming Pearls, Bentley

Software Process Design: Out of the Tar Pit, McGraw-Hill

Software Runaways, Glass

Sorting and Searching, Knuth

Structure and Interpretation of Computer Programs, Abelson and Sussman

The Art of Unit Testing, Manning

The Art of Unix Programming, ESR

The Design of Design: Essays from a Computer Scientist, Brooks

The Effective Engineer, Lau

The Elements of Style, Strunk and White

The Healthy Programmer, Kutner

The Linux Programming Interface, Kerrisk

The Mythical Man-Month, Brooks

The Practice of Programming, Kernighan and Pike

The Pragmatic Programmer, Hunt and Thomas

The Psychology of Computer Programming, Weinberg

Transaction Processing: Concepts and Techniques, Gray and Reuter

Types and Programming Languages, Pierce

Understanding MySQL Internals, Pachev

Working Effectively with Legacy Code, Feathers

Zen of graphics programming, Abrash

Original thread
by jrs235
Peopleware: Productive Projects and Teams by Tom DeMarco and Tim Lister (
Original thread
by funkaster
"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.

Original thread
by kabouseng
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.








Original thread
by austinsharp
Regarding people skills, I always recommend Peopleware[1].


Original thread
by nickpsecurity
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. ;)

Original thread
by jrs235
Also Peopleware And Slack

Demarco is great!

Original thread
by csours
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:

Original thread
by DanielBMarkham
Disclaimer: my day job is helping companies continue to operate at scale the same as they did when there were only 5 of them. Turns out this is not a trivial thing to do.

Agile/XP practices are a good starting place in-between cowboy programming and micro-management hell -- as long as you don't take them as a recipe book. They're simply best practices that you can and should learn. Then prune/modify as necessary. There are really too many books to list separately. I'd advise joining a local Agile User's Group and noticing who has their shit in one sock. Then find out what they're doing. You can also bring in external coaches.

You need a couple of good books on the people part of things. I can guarantee you that the people part of things is where you'll screw up. "Drive" is really good. So is PeopleWare

For strategic stuff, especially in a growing company, you're going to have to master large work queues without having them eat you alive. If you'll allow me to self-promote, my Backlogs series is geared exactly towards this problem.

One observation: as you grow, it's not enough that you pay extremely careful attention to whom you hire. You also need to create an on-boarding system where new hires can learn and adopt the culture -- things like pair programming, how the build works, good coding etiquette, and so on. Setting the table for strategy to work is actually more important than whatever the strategy is.

Second observation: I imagine you're going to be swimming in business book recommendations. Business books are like dieting books: everybody has a few favorites. (I imagine this is because the material inside matches how they already feel). Better to identify specific areas, like Agile Requirements Modeling, and find books targeting those areas. Then look for practical advice. Otherwise you'll just have a ton of books that you'll spend hundreds of hours reading and not really have much to show for it at the end of the process.

Original thread
by aaronbrethorst
by dangero
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".

Original thread
by willismichael
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.


Original thread
by FourthProtocol
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.


Original thread

Found a good book? Subscribe to the weekly newsletter.