ISBN: 9781449302443
Buy on O'Reilly
Found in 7 comments on Hacker News
ekke · 2018-05-22 · Original thread
In that section, would like to add recommendations for:

- "Being Geek: The Software Developer's Career Handbook"

- "Team Geek: A Software Developer's Guide to Working Well with Others" -- Software engineering teamwork a-b-c. I'd love to work on teams where everyone has read this one.

[edit: 2nd edition of "Team Geek" is titled "Debugging Teams"; having read both, no difference which you get]

kashyapc · 2018-04-11 · Original thread
This reminds me of the following, from the book Team Geek[1], chapter "Offensive" Versus "Defensive" Work:

[...] After this bad experience, Ben began to categorize all work as either “offensive” or “defensive.” Offensive work is typically effort toward new user-visible features—shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the sexiness of a product (e.g., improved UI, speed, or interoperability). Defensive work is effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migra- tion, or improved emergency monitoring). Defensive activities make the product more maintainable, stable, and reliable. And yet, despite the fact that they’re absolutely critical, you get no political credit for doing them. If you spend all your time on them, people perceive your product as holding still. And to make wordplay on an old maxim: “Perception is nine-tenths of the law.”

We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.


foz · 2015-06-21 · Original thread
As a manager, 1-1s should not just be considered status reports. They are a way for you to build trust and communication with your staff, and to give them a chance to talk about anything: problems, work on personal development, or feedback about you as their manager.

1-1s are probably your most valuable tool. Often, you will discover problems and info you would have otherwise not known - "our lead developer seems depressed and was talking about quitting", "did you hear about that other project that started? It's in direct conflict with our plans...", "there's a conference coming up, we should present at it", and so forth.

An effective manager should, in my opinion, spend 50% or more of his time with his team. Working on the same topics, talking to them, helping to plan, fixing problems, finding resources, and doing 1-1s. It's no surprise that teams with the most problems often have a manager who is just not around enough.

For new managers, I always suggest the following resources as a great starting point:

- "Team Geek": - "Managing Humans": - Manager Tools podcast:

webmaven · 2014-06-24 · Original thread
From a technical perspective, I have found 'The Mature Optimization Handbook' invaluable: (HN discussion here:

'Team Geek' is a great primer on technical leadership:

Another recommended book is 'Shipping Greatness':

Assuming you're already familiar with 'The Lean Startup', there has been a series of excellent 'sequels' on many more specific disciplines that you will likely find useful:

A recent addition (that I am still digesting) on Agile processes beyond Scrum is 'Unblock!': (Posted to HN a few days ago:

DavidHogue · 2013-09-06 · Original thread
They also have a few other talks on youtube about similar topics and a book now:
harper · 2013-07-29 · Original thread
Surprised that this isn't in the thread already.

Brian Fitzpatrick and Ben Collins-Sussman from Google have done a bunch of great talks about exactly this: How Open Source Projects Survive Poisonous People (

They also wrote a book about the topic:

All of their advice comes from their experience running the subversion project. It is also good general advice for dealing with humans/engineers/etc.

radicalbyte · 2013-01-17 · Original thread
Replace "geek" with "highly sought after, intelligent and talented employees" and you'll be closer to the truth.

The reason developers are "hard" to manage is that they're in demand, so they don't have to put up with bad or abusive management.

That said.. I'd recommend reading Team Geek ( if you have any ambition to move into a management or leadership role.

Fresh book recommendations delivered straight to your inbox every Thursday.