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.

Raising Products

Sunrise to sunset, products have a time-honored cycle. In the realm of software development, I prefer Products over Projects.

Product life-cycle

Who are the best people to raise a software product? As a contractor in dozens of IT departments, I've found IT to be the most ill-staffed and culturally stifling place for raising software products.

IT is where What's Possible goes to die.

For user-centric software developers, having the human activity of making software under the yoke of an IT department is like a fish in outer space.

Wrong environment. Wrong vibe.

What should be the goals and purposes of product development are frequently at odds with the raison d'etre of IT. By popular definition, IT deals with all things electronic.

Information Technology - Often the name of the part of an enterprise that deals with all things electronic. Free On-Line Dictionary of Computing

All things electronic is hardly a human activity. Successful software involves people. The most successful software focuses on human pains and gains.

People unfamiliar with the nuts & bolts of software development imagine it's an engineering process, but it's a profoundly human activity.
― Alan Cooper

The product-focused team is rooted in the common cause of serving people by relieving pains or offering gains. In Product vs. IT Mindset, Marty Cagan chose the words Mercenaries and Missionaries to distinguish the IT Mindset from the Product Mindset.

In an IT mindset organization, product and tech are mercenaries. There is little to no product passion. They are there to build whatever. In a product organization, product and tech are missionaries. They have joined the organization because they care about the mission and helping customers solve real problems.
― Marty Cagan

IT programmers tend to make marginally consequential changes to existing applications. The applications built and supported by IT serve people in other departments ― users that frequently harbor contempt for IT. IT programmers derisively refer to these users as The Business.

Because there is a death of product passion in IT, programmers tend to gold plate dubious features behind the guise of some perceived benefit to The Business. If The Business doesn't use the feature, no one loses their job or their life-savings.

Contrast the IT mindset to a product-centric developer's mindset in a startup. Product-centric developers know the existential narrative is:

Deliver value or die.

For software startups, continuous innovation and connecting with customers are dual imperatives. On the other hand, IT departments focus on support and execution over innovation.

"A business that isn’t investing in tomorrow, is a business that’s already in the process of dying.”
― Reid Hoffman

IT departments are better equipped to handle knowns than unknowns. IT is ladened with processes, governance, and gratuitous ceremony.

"Every time another execution process is added, corporate innovation dies a little more.”
― Steve Blank

The product mindset is that the product is paramount so all but the most pragmatic of processes falls by the wayside. Products have an inception and an end of life. IT tends to fund ongoing projects, rather than products with a beginning, middle, and end.

Delivery teams deliver software products - not projects - that run from inception to retirement.
― Jez Humble

Product-minded behemoths like Apple, Amazon, and Google demonstrate that people-pleasing products are not limited to startups.

My philosophy is that everything starts with a great product. So, you know, I obviously believed in listening to customers, but customers can't tell you about the next breakthrough that's going to happen next year that's going to change the whole industry. So you have to listen very carefully. But then you have to go and sort of stow away -- you have to go hide away with people that really understand the technology, but also really care about the customers, and dream up this next breakthrough. And that's my perspective, that everything starts with a great product.
― Steve Jobs

To raise my killer product, I'm determined to partner with people steeped in a product mindset, then rally them around our product to change the world.

REFERENCES

• DevOps and the "Product-Centric" Approach, DevOpsGuys, 13 December 2013.
• Nuke & Pave Information Technology, by Bob MacNeal, 23 March 2009.
• Product vs. IT Mindset, by Marty Cagan, Silicon Valley Product Group, 14 October 14 2014.

Say Why to Estimates

Agile estimation surfaces a clash of cultures. Broadly speaking the Agile community consists of makers & managers.

The clash between makers & managers distills to motivation:

• Why & What —motivates makers
• When & How Much —motivates managers

Makers make. Managers manage.

Estimates are a wild-assed-guess at How Much. A quote is exactly How Much.

If you suggest to a manager that there is a distinct and important difference between an estimate and a quote, she won't get it. Still, I prefer a gentle reminder — particularly with newly forming teams. If nothing else, such a reminder has the potential to lead to a better understanding of the Terms & Conditions between managers and makers.

Reminder: There's a difference between an estimate and a quote.

Because of the cognitive disconnect managers have about estimates, few seasoned makers take estimates seriously.

Some makers will sandbag an estimate by suggesting an inflated number. Other makers will confidently declare a random number, for example,

Just say three.

"Just say three" is my estimation mantra. Just say three is an artifact of the absurd notion that some tracking tool needs a number attached to a story. Makers, as they're eager to get back to the joy of making, will use "Just say three" to fulfill the immediate desires of the tracking tool jockey.

I suggest managers consider the necessity of the prevailing agile estimation pattern. Estimates, when so frequently treated as quotes, extract a cost in maker trust & product quality.

Say Why to Estimates.

Every team should attempt the Why conversations about process artifacts like estimates. Estimation is not a sacred cow.

REFERENCES

• Quotation vs Estimate, Estimates.info.

The Learning Team

A Learning Organization seems so obviously desirable as to be ubiquitous yet most of us will never experience one.

Learning Organization
A term for an organization that fosters ongoing learning among its members. Because learning is ongoing, the organization continuously transforms itself.

If we can't fix our inept organization, perhaps we can influence our team.

All politics is local.
― Tip O'Neill

All politics is local means that our success is tied to our ability to understand and influence our constituents.

My constituents are my teammates.

We owe ourselves the courtesy of modeling the kind of behavior we want to see in our teammates. We owe ourselves the courtesy of striving to be good learners and aspiring to be good teachers.

“You cannot force commitment, what you can do…You nudge a little here, inspire a little there, and provide a role model. Your primary influence is the environment you create.”
― Peter Senge

Fun teams cultivate learning. The rest suffered from varying degrees of toxicity. I resolve to choose fun. I urge you to join me.

People unfamiliar with the nuts & bolts of software development imagine it's an engineering process, but it's a profoundly human activity.
― Alan Cooper

A Learning Team

The closest I've been to a learning organization has been flashes of a learning team practiced by me and my teammates.

If your teammate responds to a question by affirming, "That's a good question", all indicators point to a learning team.

A well-tended and searchable wiki  ― thanks Ward ― that has up-to-date on-boarding instructions, and frequently used command sequences, is one sign of a learning team. On the other hand, admonishing a teammate to "look it up on the wiki" is a red flag your teammate is missing a teaching opportunity. Such opportunities occur whenever a teammate asks a question.

Missed teaching opportunities occur whenever a teammate stops asking or regrets asking.

A few red flags that you're falling short of a learning team are:

1. Defensive Postures
2. Shaming Mechanisms
3. Cynicism

Defensive Postures:

We often recognize defensive postures in ourselves and in our teammates. Defensiveness is a burden and a buzz-kill. Excise it.

“It is not the absence of defensiveness that characterizes learning teams but the way defensiveness is faced”
― Peter Senge

Your teammate doesn't want a knife in the back. He wants to you have his back. When your teammate is defensive, she's probably not pro-active.

Shaming Mechanisms:

Sometimes the original idea for a practice, or the spirit of an idea, gets lost over time.

Practices should never devolve into a mechanism for shaming.

Examples of sound practices that have gone toxic:

• Continuous integration is a highly recommended, ongoing health-check, BUT never shame a teammate for breaking the build, or for failed functional tests. I suffered through an immature team that handed around a stuffed Build Monkey to anyone who broke the build. I deep-sixed the monkey.
• Test-First is a valuable learning tool, as is Test-Driven. Both play a role in ensuring quality. BUT avoid shaming a teammate for not adopting them as a matter of course. If one or the other is an agreed upon team practice, then reward good behavior rather than shaming people for slip-ups or for regressing under pressure.
• Estimation and burn-down charts, once handy tools to make wild-ass-guesses at story sizes and to make progress visible, have become blunt instruments for flogging in the hands of command-and-control managers. NEVER use a tool or a process to hurt people.

Process alone is usually innocent. It is converting ideals into expectations that can be toxic. For more on shaming, see Say No To Brogrammers.

Cynicism:

Cynicism grows from the loam of unmet expectations. One tip:

Don't romanticize your teammate's abilities to be a "craftsman" ― particularly if he must measure up to a poorly articulated definition of craftsmanship.

By avoiding romanticizing the notion that developers are craftsman, you'll be better equipped to avoid the psychological baggage of unmet expectations.

“In combating cynicism, it helps to know its source. Scratch the surface of most cynics and you find a frustrated idealist – someone who made the mistake of converting his ideals into expectations.”
― Peter Senge

Cynicism grows from trying to change too much. Forget about the larger broken organization for now. Remember all politics is local.

Get to root causes. If it's something the team can fix, fix it before it devours all optimism.

Lastly, try modeling vulnerability rather than oozing cynicism. Your teammates will appreciate it.

Getting to the Learning Team

A learning team, like a happy family, requires practice and vigilance. A learning team gets sustenance from people expressing ideas and opinions with reckless abandon.

Remember everyone has a different take. The spectrum might range from Michelangelo to Cowboy Coder.

To voice an opinion or posit an idea we need to feel comfortable speaking up and we need to be practiced at listening. A learning team starts by modeling listening, practicing Beginner's Mind, and aspiring to teach.

"In the beginner's mind there are many possibilities, but in the expert's mind there are few"
― Shunryu Suzuki

Learning frequently calls upon us to step out into the vast unfamiliar. Learning can make us uncomfortable because it means exposing our weaknesses. But humility goes a long way toward learning. Practice humility.

The place I'd start to cultivate a learning team is a distributed source control system that supports the Pull Request Workflow.

Pull Request Workflow:

If you use no other means to get to a learning team, try the Pull Request Workflow on GitHub and Bitbucket. The PR Workflow encourages you and your teammates to:

• publicly view proposed code changes,
• publicly offer options or discuss alternatives, and
• approve all changes ― shared responsibility.

Two outcomes of the PR workflow are:

1. Quality - Under the assumption that two-plus heads are better than one, quality invariably improves from peer-reviewed code; and
2. Learning - Newbies can view other's code before it's merged and benefit from the public dialogue about how the code might be improved. Old hand's are given the golden opportunity to learn and the golden opportunity to teach. Double gold. Be respectful. No one loses.

See Pull Requests for Teams for more details.

An ideal teammate teaches you something and wants to learn from you. Seek or grow a learning team. Resolve to choose fun.

REFERENCES

• Beginner's Mind, Dumb Luck & Agility, Bobtuse, 20 April 2009.
• Pull Requests for Teams, Bobtuse, 28 August 2013.
• Say No To Brogrammers, Bobtuse, 26 May 2012.
• TDD is dead. Long live testing. David Heinemeier Hansson, 23 April 2014.
• The Fifth Discipline: The Art & Practice of The Learning Organization, Peter Senge, 2006.

ACKNOWLEDGEMENT

Hat tip to Chris Bartling for introducing me to aspects of the learning environment and for nudging me into the vast unfamiliar of open source.

Naming Conventions

On my last three software teams I have had a teammate named "Bob". What are the odds of a Bob having a teammate named Bob? I can understand a Horatio or a Cuthbert, but not another software guy named Bob.

Bob is a rare name. Ask any SETI scientist. Okay so maybe the software world has a notorious Uncle Bob, but I suspect Uncle Bob is a actually a closet Robert (see Robert Cecil Martin).

Before my software gig, I probably encountered two or three Bobs in my lifetime, one of whom was my father. It's pure dumb luck that I'm not a Bob Jr. Being branded Bob Jr. would be worse than having a Microsoft operating system named after you.

But there's a solution to this madness. The next time I encounter another Bob, I'll diffuse any confusion by pulling a Steve Jobs, who when he encountered a designer named Steve on the iPhone team, declared,

"Guess what, you’re Margaret from now on”. ⁽¹⁾
― Steve Jobs

Move Deliberately & Build Things

Bell Labs technicians preparing the
Telstar communications satellite for
launch in 1962.

Describing the post World War II golden age of innovation in the US, Jon Gertner posits that the Bell Laboratories' motto might well have been:

Move Deliberately & Build Things.

And build they did. Bell Labs was the most prolific innovation factory of the 20th century.

Reviewing The Idea Factory, Gertner's book about Bell Laboratories innovations, Walter Isaacson suggests that the first intercontinental phone call between New York and San Francisco, master-minded at Bell Laboratories, ushered in the novel model of the collaborative industrial organization — an organization that deliberately seeks and models cross-functional, cross-disciplinary teams.

The problem was one that required not just engineering skill but advances in pure science. They needed, among other things, to create a repeater or amplifier for the electric signals so that they would not attenuate after a few miles. Thus was the seed planted for a new collaborative industrial organization — teaming up theoreticians, experimentalists, material scientists, metallurgists, engineers and even telephone pole climbers — that eventually became Bell Labs.
― Walter Isaacson

Isaacson asks,

What causes innovation? Why does it happen, and how might we nurture it?

In The Idea Factory Gertner offers insights into how an engineered organizational structure, and an intentional physical layout led to and sustained decades of unprecedented innovation if the US until the monopolistic breakup of the Bell System in 1982.

Contrary to the popular notion of a lone genius conjuring culture-changing inventions in the isolation of a garage workshop, Bell Labs inventions grew incrementally from teams of people with diverse expertise and temperaments. It grew incrementally from people learning from and extending the discoveries and inventions of their colleagues and historic predecessors.

If I have seen further than others, it is by standing upon the shoulders of giants. ― Isaac Newton (1642 – 1727)

One of the many triumphs of Bell Labs was to connect us through digital machines shrinking our collective cultural & communication sphere. And connect us they did.

Conveying break-through scientific theory into useful consumer products is incremental and deliberate. The product development path was rarely direct, rather setbacks and diversions were not only expected but redoubled resolve ― resolve to drive toward better and cheaper products.

REFERENCES

• Inventing the Future, a book review of Jon Gertner's The Idea Factory, by Walter Isaacson, New York Times, April 6, 2012.
• The Idea Factory: Bell Labs and the Great Age of American Innovation, by Jon Gertner.
• True Innovation by Jon Gertner, New York Times Opinion, February 25, 2012.

Open or Closed

A closed door shields us from our shortcomings, but robs us of humanity's greatest currency ― sharing ideas.

Richard Hamming left many insights about learning to learn from his career as mathematician. Hamming retrospectively concluded that his cloistered colleagues had made less impact.

Bell Laboratories, where Hamming worked from 1946 to 1976, capitalized on the physical proximity of brain power combined with a floor-plan that co-mingled multiple-disciplinary thinkers and doers.

Bell Laboratories

"Traveling the hall’s length without encountering a number of acquaintances, problems, diversions and ideas was almost impossible. A physicist on his way to lunch in the cafeteria was like a magnet rolling past iron filings."
― Jon Gertner

The mixing of disciplines at Bell Laboratories, attributed to Bell Laboratories President (1951-59) Mervin Kelly, orchestrated harmony and tension that incited change. It was the frequency of change that sped up the flurry of innovation.

"If you're going to have progress, there has to be change. Change does not mean progress, but progress requires change."
― Richard Hamming

Traveling the halls of Bell Laboratories, Hamming observed the difference between those whose doors were open and those whose doors were shut.

I cannot prove to you whether the open door causes the open mind or whether the open mind causes the open door.
― Richard Hamming

An open door is an apt metaphor for an open mind. Hamming argued for diversity of input.

"You have to get wide cleave of what's going on."

He observed,

"Those who work with the door shut don't know what to work on. They're not connected with reality."

A closed door leads to fewer interruptions, and fewer interruptions allow one concentrated time to knock off problem-solving tasks. What if it's the wrong problem?

"The guys with their doors closed were often very well able, very gifted,but they seemed to work always on slightly the wrong problem."
― Richard Hamming

Learning is our imperative. The door is our metaphor. Today we have many channels vying for our attention or what Linda Stone calls Continuous Partial Attention. Paradoxically we must be both open and selective.

Being Open and Selective is a discipline of that demands daily exercise and vigilance.


REFERENCES

• True Innovation, by Jon Gertner, New York Times Opinion, February 25, 2012
• You and Your Research, lecture by Richard Hamming recorded June 6, 1995. This lecture was from the capstone course "The Art of Doing Science and Engineering: Learning to Learn" for graduate students at the Naval Postgraduate School.