Debugging Teams

Wednesday November 18, 2015

cover of debugging teams

I read this book after listening to a podcast. It's been described as “How to Win Friends and Influence People for programmers”.

Debugging Teams is supposed to be a new, less software-developer-specific version of Team Geek. I haven't read Team Geek, but Debugging Teams still had pretty much that was focused on software-related things. I thought this was a good thing. Sure it could generalize.

The main thesis of the book is their “HRT”: humility, respect, and trust. These are all good things to have. As they say:

Here are some more quotes I pulled out as I was reading; some of them are themselves quotes.

“People are basically a giant pile of intermittent bugs.”

Shouldn’t people be allowed to work however they want? Actually, no. In this case we assert that you’re doing it wrong, and it is a big deal. Here’s why. Hiding Is Considered Harmful

Bus factor (noun): the number of people that need to get hit by a bus before your project is completely doomed.

we work best in tight feedback loops.

Software development is a team sport.

you are not your code. Say that over and over.

“Failure is an option.”

Write up “postmortems,” as they’re often called in our business. Take extra care to make sure the postmortem document isn’t just a useless list of apologies or excuses — that’s not its purpose. A proper postmortem should always contain an explanation of what was learned and what is going to change as a result of the learning experience. Then make sure you put it in an easy-to-find place and really follow through on the proposed changes. Remember that properly documenting failures also makes it easier for other people (present and future) to know what happened and avoid repeating history. Don’t erase your tracks — light them up like a runway for those who follow you!

The problem is that once you reach a local maximum on your team, you stop learning.

The more you are open to influence, the more you are able to influence; the more vulnerable you are, the stronger you appear.

A “strong culture” is one that is open to change that improves it, yet is resistant to radical change that harms it.

A good general rule around communication is to include as few people as necessary in synchronous communication (like meetings and phone calls), and to go for a broader audience in asynchronous communication (like email, issue trackers, and document comments).

We like our meetings like we like our sewage treatment plants: few, far between, and downwind.

We’ve seen some cultures where meeting attendance is equated with status, so nobody wanted to be left out. Not to put too fine a point on it, but that is patently insane.

If you’re trying to design something new, try to include no more than five people in your meeting

flat out ignore invitations to a meeting that has no agenda.

many engineers rush right into coding before designing the software they intend to write, and this usually ends very badly.

When many people first hear about IRC these days, they scoff at its primitive text-based environment because even the most modern of IRC clients tend to be less whizzy than outdated versions of iChat or Google Talk. Don’t be fooled by the outdated look and feel of IRC — its killer features are that it was designed for multiperson chat and it’s asynchronous; most clients keep an unlimited scroll-back record so that you can read back to see conversations among others that you missed. Slack is basically the modern-day version of IRC, and despite its whizzy integration of graphics, avatars, and emoji, at its heart it’s still a text-based messaging system like IRC. It may be tempting to try out fancy videoconferencing packages, shared whiteboard systems, and more, but these systems often tend to be ineffective and can eliminate the asynchronous advantage of text-based group chat. If you’re going to use something other than Slack or IRC, find something that is actually designed for group chat and isn’t just an instant messaging system with group chat bolted on.

Comments should be focused on why the code is doing what it’s doing, not what the code is doing.

infer what various symbols are and what invariants are true about them.

attempting to add and remove names from a source file is a never-ending exercise in insanity.

the overwhelming majority of effort that goes into a culture turns out to be communication.

saying no to all of the distractions is what keeps you focused.

the best leaders work to serve their team using the principles of humility, respect, and trust.

A boat without a captain is nothing more than a floating waiting room

Managers wind up acting like parents, and consequently employees react like children.

Traditional managers worry about how to get things done, while leaders worry about what things get done…(and trust their team to figure out how to do it).

A TL is typically responsible for the technical direction for all (or part) of a product, while a TLM is responsible for the technical direction for all (or part) of a product in addition to the careers and happiness of the people on the team.

“Above all, resist the urge to manage.”

you should strive to hire people who are smarter than you and can replace you.

“Hope is not a strategy.”

“A people hire other A people; B people hire C people.”

As an engineer, you likely developed an excellent sense of skepticism and cynicism, but this can be a liability when you’re trying to lead a team.

As a leader, your job is to inspire, but inspiration is a 24/7 job.

In many cases, knowing the right person is more valuable than knowing the right answer.

We strongly advise against using the compliment sandwich,

It’s the behaviors you want to filter out, not particular individuals.

Document all history: not just code history, but also design decisions, important bug fixes, and prior mistakes.

Streamline the barrier to entry for newcomers.

Attention and focus are the scarcest resources you have.

A strong culture based on HRT is irreplaceable, while technical contributions are definitely replaceable.

genius is such a commodity these days that it’s not acceptable to be an eccentric anymore.

it’s not worth compromising your culture for the short-term gains

there are only a few crazy people out there; the Internet just makes it seems like they all live next door.”

Most people work in dysfunctional corporate bureaucracies and need to employ certain manipulative techniques to get things done effectively.

It boils down to this: is your manager serving you? Or are you serving your manager? It should always be the former.

“It’s impossible to simply stop a bad habit; you need to replace it with a good habit.”

categorize all work as either “offensive” or “defensive.”

Every company has a gray-market favor economy that lives outside the org chart,

Every company has a “shadow” org chart that is unwritten but through which power and influence flow.

A good Three Bullets and a Call to Action email contains (at most) three bullet points detailing the issue at hand, and one — and only one — call to action.

Most industries are a lot smaller than you think, and people talk more than you think,

Friends come and go…enemies accumulate.

product laziness.

It’s really obvious (and infuriating) when a programmer could have made something friendly and easy for the end user but didn’t bother.

Most programmers vastly underestimate the importance of application speed (or latency, which sounds more scientific).

“Speed is a feature.”

An elegant design makes easy things easy and hard things possible.

the user’s data needs to be accessible

learn great patience.

there is no such thing as a temporary lapse of integrity.

Trust is your most sacred resource.

Humans are unpredictable and tricky to deal with no matter what the context.

And finally, “You and Your Research” by Richard Hamming seems like good reading they recommended.