My name is Derek, and I’d like to cover productivity related to projects I worked on at Pivotal Labs. In particular, I’d like to speak about decision fatigue.

As software engineers, we continuously make decisions on the keyboard. We question architectural decisions in the software we work on. These decisions, as well as other the daily decisions may seem trivial, but they deplete our mental focus. As a result, we’re likely to either choose the option that requires the least amount of effort, only look at certain aspects of a decision in a limited way, or avoid making a choice entirely. This is decision fatigue.

Decision fatigue can manifest itself into copy-paste mistakes, bugs, additional technical debt, and spaghetti code.

How Do We Minimize Fatigue at Pivotal?

To answer this question, I’d like to describe a typical day at Pivotal Labs’ Tokyo office.

Breakfast

What should I eat for breakfast is a decision that we don’t have to make. Pivotal provides us a good breakfast, which is also an informal opportunity to chat with our teammates.

Morning Office Standup

There are prompt stand-ups at 9:06 a.m. where we discuss new members or guests who are visiting the office. We find out if anybody needs help with anything in the office. We also talk about interesting topics, news, and events in the area.

Project Standup

Each team meets to chat individually within their project groups on how things went the previous day and what the plan is for today.

This morning at stand-up, someone brought up a concern, mentioning that they had a hard time trying to determine where to put new parser and presenter objects they created. They asked if they can work through a solution as a team; not surprising, another engineer raised his hand and echoed the same concerns.

Project Organization

We had a short talk about project file organization.

Through a teams discussion, we agreed that there must be some sort of organization; we decided to do away with generic folder names that did not describe its contents.

A proposal was made to use three main top level folders instead of MVC: Application, Components, UI.

The Application folder contains things like the AppDelegate, plist, and launch screen, etc. The Components folder contains models and everything related to it, such as the parser used to handle the JSON parsing of the model. The UI folder contains ViewControllers and views used for each screen.

Pair Programming

Pair programming at Pivotal Labs is different from what I’ve experienced elsewhere. There are two monitors, each with its own keyboard and mouse so that both people can follow along and drive. Included are also a stack of index cards used for discussion and notation.

Styles

There are two primary styles we practice pair programming. The first is called “ping-pong” pairing, where both developers experience writing test and implementation code. The second is “driver-navigator”. Generally, the more experienced engineer is the navigator of the pair. They do not touch the keyboard and is focused only on teaching. This allows the driver, or the student in the pair, to be hands-on in writing code.

In action

In order to ensure shared understanding of the code base, it’s important for us to pair as much as possible. Pairing is a practice not exclusive to engineers. Designers and product managers also pair. This type of approach to pairing ensures that we’re sharing knowledge across the teams.

Lunch Time Tech Talk

Once a week, there is a tech talk on Tuesdays. Lunch is catered to the office, and someone does a talk on engineering, design, or product management topic. If nothing is scheduled, we’ll watch a video of a talk instead.

Back To Pairing

After lunch, we continue our pair programming session.

Impromptu Team Discussion

Sometimes, there is an impromptu technical discussion to tackle challenging problems. Today, someone mentioned that they noticed some of the differences in how Swift files were organized throughout the code base, and they thought that it’d be good to have a chat with the team about how to make these more consistent.

Swift File Organization

We met and discussed our Swift file organization, or what is the appropriate place for me to put this code within a file?

With any object that you create in Swift, depending on the complexity, the number of lines, or maybe the number of constants or properties, protocols, methods - it can be overwhelming.

Our team agreed that we should use Swift mark annotations. This could be used to help organize the code into sections, and pull out common parts of objects, protocol conformance, and private methods.

In our ViewController there are annotations added for properties, view elements, initialization, and lifecycle methods. This makes it easier to read.

In new ViewControllers, we can create a code snippet to help streamline the organization. I’ve created a ViewController boilerplate snippet that puts much of the code in its standardized place.

Protocol conformance can be difficult to read, especially if it’s not written in a friendly manner.

First, we called out the properties in the initialization and pull the conformance to the customer protocol into a separate extension along with a mark annotation.

Then, we pulled out the private methods, noting that we can mark the entire extension of this file private instead of having to mark each of these methods individually as file private.

Ping-pong

Like in pair programming, we play doubles ping-pong. This allows an informal team-building opportunity. Ping-pong helps us to clear our minds and helps us with a fresh perspective when we return to pairing.

Cross-Functional Pairing

Pairing isn’t limited to a discipline. Sometimes we do some cross-functional pairing in order to better align between disciplines.

Styling UI objects

We continue to pair and talk over how to apply consistent UI styles in the app. Our designer provided us with a style guide; we decided to focus on implementing those styles then building out the ability to reuse them.

For each style, the appropriate settings can be applied; and this could be the font size, the colors, backgrounds, foregrounds, border details, directly to that UI button that’s passed in. This type of approach can also be applied to any other type of UI object that you have, be it views, labels, segmented controls, etc.

Here, we added an extension on UIButton itself so we can apply these new UI button styles we’ve defined.

Retrospective (Retro)

We wrap up our work by holding a retrospective meeting (retro), a meeting that we hold every Friday at the end of the weekly cycle so that we can simply review and discuss our process.

We allow the core team members to speak, as it’s important to have them feel comfortable and to be honest about their thoughts even though the managers and stakeholders are present.

Retros are focused on how people felt about the last week. We start with a whiteboard that has three columns: a happy column acknowledging what’s working well, a “meh” column so we can identify things that need discussion, and then a sad column to denote what’s been painful.

Everyone will write their thoughts on the whiteboard, then we go through them one by one. We see our retros as a way for us to reflect for continuous improvement and as an important team-building exercise. They help us to create a culture that allows anyone to feel comfortable to ask a question or raise a concern. It also helps us to keep a pulse on recurring issues and solve problems before they become bigger.

Q & A

Q: How can one benefit from pair programming when working from a remote location? Derek: It is clearly a challenge to do pair programming in a remote fashion. I do know some people using Skype to do pair programming together, and it’s not an ideal situation - but it could be done.

Q: what you do when you have an odd number of developers? Derek: When we have an odd number of developers, one person is left on their own. Soloing can be good for certain tasks, such as research.