Soft Skills

Making software is a profoundly human activity. Successfully produced software is made:

• by teams.
• for people to use.

Interpersonal communication and mindset are increasingly important for developers.

An overlooked lesson from the Agile movement is:

Producing software products doesn't need or require projects or managers. Successfully produced software is laser-focused on People, Products, and Teams.

Another overlooked lesson is the growing demand for a mental shift. Successfully producing teams have adopted:

A state-of-mind over a set of PMO rules.

Producing software is a creative act more than a prescriptive act. Often developers must discover the right balance between generative thinking and evaluative thinking:

• What could the product do? and
• What should the product do?

We have learned that good things happen when we make a pact to:

Discover & adapt, rather than robotically design & implement.

Humility trumps ego. Make a practice of approaching your teammates and products with Beginner's Mind. Everyone aspires to mastery, but no one becomes the expert.

Practice listening.

"We have two ears and one mouth so that we can listen twice as much as we speak."
― Epictetus

Practice being a good teammate. Introspection helps. Ask how-can-I questions.
Ask How can I:

• be more helpful?
• become a better teacher?
• become unflappable?
• become non-judgmental?
• make people laugh?

“There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self.”
― Ernest Hemingway

Start Slackin

The infrastructure supporting the flow of communication has become an iteration zero concern. For software developers, a team chat application is becoming as fundamental as a GitHub repository.

Slack is a San Francisco based chat startup with a well-executed product that's rocketing in popularity. Slack's marketing pitch is

We’re on a mission to make your working life simpler, more pleasant and more productive.

Slack Chat Client

After a few months having used it with a few product teams, I'm convinced Slack is delivering on their pitch.

At the moment I'm using Slack with two product teams for different customers. In the past I have used other chat applications like:

• Colloquy (open-source for Mac OS X); and
• HipChat (by Atlassian).

Slack fills a niche by being less geek-centric than Colloquy and by being spiffier and more feature-rich than HipChat. Colloquy and HipChat remain fine products, but I've a growing preference for Slack.

Wildly Imagined Vintage Slack Poster

Using Slack, I like that:

• One can easily configure different client gigs and then switch between them on the handy left nav;
• One can easily create new team channels;
• One can easily toggle between team and private channels;
• Individual teammates may chat privately in the private channels; and



GitHub Commit Stream

• Developers reap the benefits from the information stream via GitHub, Heroku, and Jira integration.

Chat is a forum for knowledge sharing. It has the potential to build team camaraderie even when your teammates work from a remote location.

"Contextual conversation is likely to become the dominant social motif of the next generation of work-technology apps."
— Stowe Boyd, tweet @stoweboyd

REFERENCES

• Chat, Slack, and the Panoptic Telecommute, Scott Rosenberg, 13 Oct 2014.
• Contextual conversation: Work chat will dominate collaboration, Stowe Boyd, Gigaom Research, 30 June, 2014.
• Why these startups think chat apps are the next big thing in workplace collaboration, Jonathan Vanian, 1 Aug 2014.

Pair Programming in Perspective

Annual Mermaid Parade
Coney Island, 2012

I offered my 2¢ on this question from another developer:

Would you consider joining a company where pair programming is an essential part of software development?

One long-standing lesson from Extreme Programming is:

Programming in pairs improves quality. 

With qualifiers, few dispute this assertion.

Recently I've learned of mandates for pair programming which is mildly alarming. A team at BestBuy does pair programming ...all the time. This particular pair-programming-all-the-time initiative had the unintended consequence of chasing off one of the most test-driven, quality-focused craftsman I have pair programmed with, and learned from, in years past.

Let me state this:

Paired programming mandates are a bad idea.

Mandates in general are a bad idea. Producing software is a creative act. Mandates stifle and demoralize.

Pair programming is most helpful when on-boarding new team members, or when intentionally pairing an experienced developer with an inexperienced developer.

Software produced in pairs is typically superior, but not always the smoothest tack. Sometimes pairing is jarring to the soloist's creative flow. At times, pairing is downright inefficient.

It's common to achieve quality results on par with pairing by having peer reviews and team discussions. I'm an enthusiastic cheerleader for the Pull Request Workflow popular on GitHub and BitBucket (see Pull Requests for Teams). Pull Requests allow for collegial discussions that lead, more often than not, to quality improvements.

Mandates are a red-flag for team and organizational inflexibility. My answer to the developer's question "Would you consider joining a company where pair programming is an essential part of software development?" is a qualified no.

Two heads are usually better than one, but not always.

The development community has realized significant strides from XP and Agile, but shouldn't we be judicious about — and mindful of — how we apply what we've learned?

More ain't better, particularly when it's dictated over pragmatism or common sense.

Not every arrow in the quiver suits a situation.

REFERENCES

• Extreme Programming, Wikipedia.
• Paired Programming, Wikipedia.