Software Engineer's Social Playbook

A team is not a group of people that work together. A team is a group of people who trust each other. —Simon Sinek

Okay, you’ve survived day one, so what now? Well, now comes the tricky bit: working with other people. Weirdly, that’s a skill you won’t learn at any Bootcamp. But it’s the single most important factor in making your career a success, or… well, let’s not worry about “or”.

Instead, let’s talk about why the so-called “soft” skills are the hardest of all.

Social Capital

This is a crucial aspect of our professional dynamics. Think of it as your bank balance in the realm of collaboration. Acts of kindness, reliability, humility, and honesty contribute positively to this balance, while negativity and arrogance deplete it rapidly.

Beyond just being a decent person, social capital is instrumental in getting things done at work. When faced with a pressing issue and a tight deadline, having a reservoir of social capital allows you to ask a colleague for assistance. However, it's essential to recognize that if you haven't been supportive in the past, expecting help now might be challenging.

In essence, social capital is the key to having your ideas heard and your opinions valued. It shapes how you are perceived as a team player and influences others to lend a hand, even when it's not officially their responsibility. Trust is the currency here, and it's what keeps the collaborative engine running smoothly.

Managing your commitments

To build trust and accumulate social capital, I make it a priority to honor my commitments. In simple terms, if I commit to something, I ensure that I follow through.

Failing to do so erodes trust over time, and the subtle nature of this erosion makes it particularly dangerous. As Jerry Weinberg wisely said in "Secrets of Consulting", people don't explicitly inform you when they stop trusting you.

The greatest threat to my trustworthiness often stems not from being intentionally deceptive but from the common tendency to over-promise and under-deliver in a genuine effort to please. Saying "yes" feels good initially, but the challenge arises when I realize I've taken on more than I can handle. The subsequent need to retract promises not only disappoints others but may also leave them in a bind, as finding an alternative might now be too late.

Saying “no” is a superpower

Recognizing the power of saying "no" has been a game-changer for me. While making hasty promises might give a momentary boost to my social capital, the eventual inability to fulfill them results in a significant long-term loss. Conversely, declining now might slightly dent my capital in the short run, but it pays off in the long term by establishing me as a reliable commitment manager.

When someone seeks a commitment, it's crucial to understand that they prefer a genuine "yes" over a reluctant one. So, I carefully consider my response. It's perfectly acceptable to say, "Let me check my schedule and get back to you."

If, upon reflection, I realize that I can't be 95% confident about delivering on time, I opt for a diplomatic "I'd really like to help, but fitting this in with my existing commitments seems challenging." This not only communicates a respectful decline but also emphasizes the value I place on my commitments. It assures the other person that when I do commit, I do so with sincerity.

Finding your feet

Joining a new organization, division, or team is a guaranteed ticket to encountering different ways of doing things than what you're accustomed to. There will be a mix of written and unwritten rules, and inevitably, you might unintentionally break some.

That's all right. By adopting a listen-more-talk-less approach and closely observing how things operate—especially the nuances of how they unfold—you can navigate without getting into too much trouble.

However, friction is inevitable at times. How do I handle that?

Adapting to others' working styles is a challenge that requires time and patience. It involves being attuned to the dynamics and being tolerant of practices that might not align with my preferences.

Transitioning from solitary work to a team environment, especially a sizable one, exposes people to practices that might seem puzzling or even amusingly wrong. Coding standards, patterns, and practices vary widely, and even the placement of brackets and whitespace can spark debates in languages lacking a standard format.

As humorously noted in "Go Proverbs" gofmt's style is no one's favorite, yet it somehow becomes everyone's favorite.

Every team has its unique style, a house style, which you must grasp and adhere to. While you may not agree with every choice, it's likely that your team members share similar sentiments. The purpose of standardizing practices isn't necessarily perfection but to prevent unnecessary arguments over trivial matters.

Don’t rearrange the furniture

A codebase is akin to someone's home—they've been living there for a while, things are arranged to their liking, and they've grown accustomed to the setup. Introducing a new person who stumbles around, knocking over furniture, or breaking crockery, can be quite unsettling.

Just as you wouldn't appreciate a new roommate or partner criticizing your decor choices or rearranging things without consultation, the same principle applies when you're the guest in someone else's codebase or project. Instead of complaining, criticizing, questioning, or making unilateral changes, it's essential to recognize that things are the way they are for a reason, even if that reason is as simple as "we haven't addressed that yet."

Empathy plays a crucial role here. If something appears amiss, there's a possibility that others have thought it through more thoroughly, or they might be dealing with challenges unknown to you. What seems trivial to you might be part of a larger, more pressing battle. And if something appears unfinished, it might genuinely be a work in progress.

Making the right first impression

Instead of actively seeking out problems your colleagues might have overlooked, try asking them about the challenges they could use assistance with. A simple inquiry like, "Do you have any pending tasks that haven't been tackled recently? Taking those on would not only help you understand the codebase but also contribute something valuable." This approach is more likely to garner a positive, perhaps even enthusiastic, response.

By framing it this way, you immediately signal that your intention is not to highlight their shortcomings but rather to enhance their success. The message is clear: you're here to make them shine, not to add to their workload. Once you establish this mindset, you'll likely find a much warmer welcome.

Collaboration is your biggest challenge

The most significant challenges in the workplace aren't typically about build failures or the intricacies of the type system; they revolve around the complexities of working with other people. While it would be ideal if everyone were intelligent, kind, and competent, the reality is that you'll encounter a variety of personalities.

Even in teams where trust and camaraderie exist, conflicts and challenges are inevitable. Collaboration is inherently difficult—this is a well-known fact. Nobody is inherently a perfect collaborator; it's a skill that requires learning and practice to master. We're all on a journey, and throughout your career, you'll interact with individuals at every stage of collaborative proficiency, ranging from "zero" to "decent."

People Skills

While technical expertise takes the spotlight during the job application process, once you step into the workplace—be it physical or virtual—your tech skills become the baseline. The real determinant of your success or failure in this job? Your people skills.

Regrettably, not everyone grasps the importance of this, and you'll encounter a few individuals in every team or company who, despite their intelligence and experience, fall into the category of anti-social jerks. Apologies for that reality.

To contribute to addressing this issue, You need to make an effort to learn and exemplify how people should treat one another—whether at work or elsewhere—with respect, consideration, and kindness. Not everyone may reciprocate, but that's not the motivation behind these actions.

Listening

Listening is an interpersonal superpower often overlooked, and I've come to appreciate its significance. While many of us excel at talking—sometimes at great lengths—someone skilled in the art of listening is a rare gem.

It's easy to mistake thinking about what we'll say next for actual listening, eagerly waiting for the other person to stop talking so we can deliver our point. Even if we're somewhat attentive, it doesn't quite capture the essence of genuine listening.

When you truly listen to what someone is saying, instead of composing a mental response, there's a potential to learn something valuable. Additionally, if you can stay silent long enough, allowing them to articulate their thoughts, they often gain insights as well.

In the realm of experienced programmers, this practice is known as rubber-ducking. Simply explaining a problem in sufficient detail to someone else can trigger the insights needed for a solution. Oddly enough, rubber ducks seem to excel as listeners in this context compared to many humans.

What we, as conversational partners, bring to the table that bath toys can't is the ability to contribute to the discussion by articulating our understanding of what the speaker is conveying. Whether our interpretation is accurate or not, it proves helpful for the speaker to know how we're perceiving their words.

Don't make it about you

The sign of someone not really listening is when they jump in as soon as there's a pause, essentially saying, "Never mind that, here's what I think..."

I've noticed a common pitfall among poor listeners: the immediate attempt to relate the speaker's words to their own experiences. It's like saying, "The same thing happened to me once when I was on the way home. Now, I was wearing an onion on my belt, which was the style at the time..."

While the intention might be to show understanding by connecting to personal experiences, it often has the opposite effect. By interrupting the speaker's flow and making the conversation about them, the listener inadvertently undermines the act of genuine listening.

A better approach is to let the person express themselves at their own pace and in their own manner. If it seems they don't want to talk, there's no need to force it—just remain silent. If they feel the need to fill the silence, they will. Otherwise, being comfortably silent together is perfectly fine. Not every conversation requires constant talking.

Reflection

True listening, then, is not a passive process, but an active one.

I recall a time when I was talking with someone who seemed to ignore everything I said. “You are not listening to me!” I accused. “Oh, yes I am!” he said. He then repeated word for word what I had told him. He heard exactly. But he wasn’t listening. He didn’t understand the meanings I was trying to convey. —Robert Bolton, “People Skills”

Even if we’re showing all the signs of attending, the other person does not actually know that we’re listening unless we can show them that we’ve understood the importance of what they said.

The simplest way to do that is to reflect it, by stating the essence of what they said, but in our own words. That usually means identifying the feelings they’re trying to communicate

THEM: That code review comment really made me angry. It was like “You’re so dumb for making this mistake. ”YOU: You felt attacked. THEM: Exactly.

When the speaker hears that we have successfully grasped their point, they usually say something like “Right,” or “Exactly”. If not, they will correct us. Either way, they are reassured that we’re at least trying to understand.