Forem: Peter Vera

Inclusivity - Let's have lunch!

Peter Vera — Mon, 17 May 2021 23:21:43 +0000

This is an adaptation of a document I wrote in 2018, while working at Google on the Assistant on Android Auto team. Each day I’d make sure everyone on the team got an easy, low pressure invitation to have lunch with their teammates. I wrote this to explain why I did that and solicit feedback for improving the process. I wanted to share it here in hopes that other people would find it helpful. I left it mostly intact, but cut out the references to Google/Auto-specific stuff.

Preface

I love team lunches, I think they’re important for team cohesion and psychological comfort. I love lunch so much I try to organize some form of team lunch daily.

A new team mate of ours recently told me that he had been speaking with friends on other teams and was surprised to find out that our team’s lunch standard wasn’t part of some Google-wide mandate, and was instead just part of our team’s culture. This document is an attempt to explain the reason I organize lunches, and to ask for input about how it could go more smoothly.

Motivation: Friends work more effectively

A couple of years ago I worked over at Intuit. I was on a feature team that was heavily reliant on a front end infrastructure team. We weren’t really sure where our effort stood in terms of their priorities, and we didn’t really have visibility into their process, which would have allowed us to find out.

Independently, my team was in a bit of a crunch time. To fight off the stress, I started mixing cocktails for my team every Friday. One Friday I was particularly proud of my concoction and I wanted to show my handiwork off, so I invited some of the nearby teams, including the infrastructure team. Drinking and joking while we coded quickly turned us from acquaintances into friends, and suddenly our teams were comfortable reaching across cubes for input and requirements and feature requests and bug reports. We became a cohesive effort, it gave them a chance to get a more intimate understanding of our project, and gave us a window into their workflows.

There is something to be said for working with people you feel comfortable with. I can’t really provide any sort of academic rigor for its benefits, but I would bet that anyone reading this goes to the people they consider friends for help with work before they go to the people they don’t. Being friends with your team makes engineering easier.

Motivation: Team lunch is easy social support

My former Intuit coworkers will tell you that my one fear leaving to join Google was being socially isolated. My former IBM coworkers will tell you that my one fear leaving to join Intuit was being socially isolated. I’ve been in bad social situations, joining a new team, having lunch alone, and not knowing whether that was going to be the way it was for the rest of my career.

I’ve joined teams where I went weeks before I knew anyone well enough socially to break through the anxiety and try to have lunch with them. I’ve been on teams where it never made it to that point.

It’s painfully easy to not subject people to this. It’s practically unavoidable to fall into social cliques that look exclusive from the outside, but team lunches offer the crucial benefit that by definition they’re open to everyone on the team. It’s an easy way to make sure people don’t feel completely alone on a team.

Problem Statement

In an ideal world, my lunch efforts would adhere to the following standards:

Everybody feels that they are invited to lunch, not just nominally, but like they are legitimately welcome
Nobody feels pressured to attend lunch
Everyone who wants to attend is able to

It’s clear that some of these standards are partially at odds with one another. They might actually be legitimately impossible. My implementation is the closest thing I’ve found that adheres to these standards.

Implementation

Timing

I start lunch at 11:30. It’s early enough that the lines are short in the nearby cafeterias, and the larger tables aren’t occupied yet. Early on, I tried a later lunch, but frequently it meant people would take their lunch alone or in small groups, not knowing whether they’d be invited to a larger lunch. 11:30 is early enough and consistent enough to avoid that problem.

Inviting the team

I send a lunch invitation to our team’s off-topic group chat. Every day I also personally invite the people who consistently attend lunch, as well as the people who have specifically asked that I gather them daily. I’m certain it would be more welcoming if I could personally invite everyone every day, but there are a lot of us, and it’s unsustainable.

Thursdays and Fridays we have an actual calendar slot booked for team lunches. Those days I do personally walk around our cube area and invite each team mate personally. I’m of the opinion that this cadence of 3 days of mass invitation and 2 days of direct invitation provides the right balance that allows people to continue to feel invited, without being forced to reject my invitations daily.

There are people who never come, and that’s OK. I do my best to invite them every time, it’s really easy to stop entirely because you expect them to decline, and before long they don’t feel invited anymore. I try to avoid expressing disappointment when people opt out; I want them to feel as comfortable as possible saying “no.” Everyone has to at some point and I don’t want to introduce any unnecessary stress if avoidable.

Weaknesses

These are the weaknesses I see in this scheme. I don’t have a good way to address them. Please ping me if you have any suggestions, I’d love to improve.

Not everyone sees the group chat invitation

Not everyone is checking their group chats all the time, so it’s easy to miss. I try to give a few minutes for people to see it before heading out. I hope the minorly disruptive group forming is enough of a signal for the people who want to have lunch to recognize what’s happening.

There’s no stress-free way to opt out entirely

It makes sense to me that the perception is that asking me to never invite you to lunch would be damaging to your social reputation with me or the rest of the team, and feeling that you have to reject my invitations regularly is also unpleasant. I want everyone to be as comfortable as possible, so I’m personally totally open to the concept. In an ideal world people would recognize that there are tons of reasons to never want to attend a team lunch.

11:30 is pretty early

Some people have late breakfasts and 11:30 is too early for them to be considering more food. It’s harder to find tables later, and varying the time would result in more people getting confused or skipping lunch when they’d otherwise prefer to join in. That being said, I’m open to varying the time, but I don’t have a handle on a good system for choosing and coordinating time.

Epilogue

I fill this pretty strange niche in my team. Most of my motivation for writing this was to tell them why I organize lunch the way I do, and to level set that I recognize it’s distinctly non-ideal. I hope the takeaway from this document is that I want to know if there are better ways to approach this that I haven’t recognized yet. Do you feel invited? Can you think of anything that would make you feel more invited? Do you feel pressured? Is there anything I can do to lessen the pressure? Is there anything getting in the way of you joining if you want to? I welcome the feedback!

And if you’d like to have lunch, let me know!

Out of all of the documents I’ve produced in my career, this is the one I’m most proud of. It’s stuck with me longer than every technical design, architecture overview, and system investigation I’ve ever produced. People aren’t machines you can use to exchange a salary for engineering. Company and team culture are important for the wellbeing of the people who get things done.

I look back fondly on the time I spent with the Auto team, some of them are still some of my closest friends, 2 years and a company transition later. When I left, I got a lot of messages about the impact I had to team culture, but the reality is that I didn’t have any special magic that allowed me to affect team culture the way I did. The lunch process grew organically out of wanting to make friends and wanting everyone to be included. It could have been anyone, I just stumbled into it. If you’re up for it, you can make strides for your team’s culture too.

Why you should use pure components

Peter Vera — Fri, 27 Mar 2020 02:31:32 +0000

I've seen a number of articles explaining what pure components are and tutorials about how to write them. I haven't seen as many good justifications for why you should consider structuring your components as pure components first. I'm hoping to make a good case for them.

Impure Components Tend To Inhibit Use Cases

If you bundle a components state and behavior with its presentation layer, you risk obstructing important use cases.

As an example, let's say this minimal React toggle that maintains its own state is part of the component library your team uses:

// Bear with me here.
const Toggle = (props) => {
  const [isOn, setIsOn] = React.useState(props.initialState);

  const handleToggle = () => {
    setIsOn(!isOn);
    props.onToggle(isOn);
  };
  return (<button onClick={handleToggle}>{`${isOn ? "on" : "off"}`}</button>);
}

What are the features of this toggle?

You can set an initial states
It maintains its own state
It informs you when the state changes

Then, let's say you're working on a UI that's going to let your user toggle a setting that might be costly. Your design team wants to make sure people aren't going to turn it on by mistake, so they want you to insert a confirmation before actually making the switch to the on state.

This toggle implementation actually won't support this use case. There isn't a place to insert a dialog confirmation before switching the state of the toggle to on.

That toggle might be a little too contrived, so let's take a look at a real world component that was designed before declarative UIs caught on: dijit/form/ValidationTextBox from version 1.10 of the Dojo Toolkit.

It's your standard text box, with some functionality that performs validation and displays valid states. I've copied some of its relevant parameter documentation here:

Parameter	Type	Description
required	boolean	User is required to enter data into this field.
invalidMessage	string	The message to display if value is invalid.
missingMessage	string	The message to display if value is empty and the field is required.
pattern	string	This defines the regular expression used to validate the input.

You can see that they've tried to supply functionality to support a simple required prop to test if the text box contains a value, and a pattern prop to validate the text box's value with regular expressions.

Now, what sorts of use cases do these props not support?

Validation based on external values, e.g., is this value already present in a list of values you've entered prior?
Server-side validation, e.g. is this username taken?

In order to support #1, ValidationTextBox also allows you to override the validator function in a subclass, but if you look into the source you'll find that the output of validator is used synchronously, meaning asynchronous validation, as in #2, might be impossible. As an aside, overriding validator means the required and pattern props will be ignored unless you explicitly use them in your custom validator.

Instead, imagine it exposed the property isValid, which would trigger valid or invalid styling. I'd bet you could deliver the equivalent functionality in less time than it would take you to even understand the current API, and could support those additional use cases.

You Can Ship Those Behaviors On Top Anyway

Let's say you are convinced and rewrite your toggle component to be pure.

const PureToggle = (props) => {
  return (<button onClick={() => props.handleClick()}>
    {`${props.isOn ? "on" : "off"}`}
  </button>);
}

But you don't want to throw away your hard work and you really want your consumers to not have to write those behaviors themselves. That's fine! You can also release those behaviors, in many forms including...

Pure functions

const toggle = (previousState) => {
  return !previousState;
}

Hooks

const useToggle = (initialState = false) => {
  const [isOn, setIsOn] = useState(initialState);
  return [isOn, () => {
/
    const nextValue = toggle(isOn);
    setIsOn(nextValue);
    return nextValue
  }];
};

Or Even A Higher Order Component!

const ToggleComponentWithBehavior = (props) => {
  const [isOn, doToggle] = useToggle(props.initialState);
  return (<PureToggle
    isOn={isOn}
    handleClick={() => {
      const nextValue = doToggle();
      props.onToggle(nextValue);
    }
  }/>);
};

You might have noticed, but that higher order component actually exposes the exact same API as the original, behavior-coupled toggle implementation. If that's your ideal API, you can still ship it, and shipping the pure version will support the use cases you've missed.

Takeaways

Now you might be thinking "OK, but I'm not writing a component library, I'm writing a product. The components I write have specific-case behavior so this doesn't apply to me." The underlying concept that I'm trying to convey is that separating your presentation from your behavior gives you more flexibility. That can still be beneficial when your components are only ever used once. When your behavior has to change in a way you didn't initially architect your component to support, your presentation layer can be in the best possible situation to be able to handle those changes.