ShakaCode | ShakaCode Blog | Rails On Maui Blog | Rails | ReactJs | JavaScript | Webpack | Productivity |

Working well with others (Debugging Teams book)


I’d recommend anyone to read the Debugging Teams book.

From my opinion working well with others it’s critical for any team (not only for software teams). Embracing and learning empathy or trust are much better skills than learning the next new fad language/technology. Here I’m sharing some notes that may encourage you to read the whole book.

“Being a successful programmer isn’t just about learning the latest languages or writing the fastest code. Professional coders almost always work in teams, and it turns out that one’s team directly affects that individual’s productivity and happiness more than many people would like to admit.”

“Software development is a team sport. And in order to succeed on an engineering team—or in any other creative collaboration—you need to reorganize your behaviors around the core principles of humility, respect, and trust.”

“But even if you are a genius, it turns out that that’s not enough. Geniuses still make mistakes, and having brilliant ideas and elite programming skills doesn’t guarantee that your software will be a hit. What’s going to make or break your career is how well you collaborate with others.”

In order to reach collaborative nirvana, you first need to learn and embrace what we call the “three pillars” of social skills. These three principles aren’t just about “greasing the wheels of relationships; they’re the foundation on which all healthy interaction and collaboration are based.

You are not the center of the universe. You’re neither omniscient nor infallible. You’re open to self-improvement.
You genuinely care about others you work with. You treat them as human beings, and appreciate their abilities and accomplishments.
You believe others are competent and will do the right thing, and you’re OK with letting them drive when appropriate.

“Criticism is almost never personal in a professional software engineering environment—it’s usually just part of the process of making a better product. The trick is to make sure you (and those around you) understand the difference between constructive criticism of someone’s creative output and flat-out assaults against someone’s character. The latter is useless—it’s petty and nearly impossible to act on. The former is always helpful and gives guidance on how to improve. And most importantly, it’s imbued with respect: the person giving the constructive criticism genuinely cares about the other person and wants her to improve herself or her work. Learn to respect your peers and give constructive criticism politely. If you truly respect someone, you’ll be motivated to choose tactful, helpful phrasing—a skill acquired with much practice.”

“In the open source world, projects that are built on HRT and focused on writing clean, elegant, maintainable code will attract engineers who are interested in—surprise, surprise—working with people they respect and trust, and writing clean, elegant, maintainable code.”

“at the end of a busy day of “management” you’ll usually find yourself thinking, “I didn’t do a damned thing today.” It’s the equivalent of spending years counting the number of apples you picked each day, and changing to a job picking bananas, only to say to yourself at the end of each day, “I didn’t pick any apples,” handily ignoring the giant pile of bananas sitting next to you. Quantifying management work is more difficult than counting widgets you turned out, and you don’t have to take credit for your team’s work; however, making it possible for them to be happy and productive is a big measure of your job. Just don’t fall into the trap of counting apples when you’re picking bananas

“The best leaders we’ve worked with have all been amateur psychologists, looking in on their team members’ welfare from time to time, making sure they get recognition for what they do, and trying to make certain they are happy with their work.”

“Dan claims you can increase intrinsic motivation by giving people three things: autonomy, mastery, and purpose"

“Google is great at this; it has a deliberate policy of not pre announcing features for any product. When new features roll out they’re often a delightful surprise. It also prevents internal death marches to meet unrealistic advertised launch dates. The software is released when it’s actually ready and usable.”


A couple more:

“Even if you know you’re the wisest person in the discussion, don’t wave it in people’s faces.”

“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.”