Ease At Work

Not long ago we had a study group on Kent Beck’s talk, Ease At Work. (The link is to the first part of a seven part series.) I found I got a lot of value out of listening to the entire talk. I jotted down a few highlights of the presentation:

Imagine an email discussion in which divergent opinions and viewpoints are respected. How often does this happen in technology (emacs vs. vi, windows vs. linux, etc.)?

Thinking about truly important ideas often produces discomfort.

When was the last time you felt comfortable in your own skin as a programmer? When was the last time you felt comfortable as a programmer at work?

Why do I have to turn off parts of myself to work here?

Can you expect ease and comfort at work?

The wizard can fix anything with magical ease.
The martyr sacrifices himself, his health and relationships, on the altar of technology.
The pendulum swing back and forth between the wizard/hero and the martyr takes a lot of energy.
An earthier description of this phenomenon: riding the genius / shithead rollercoaster.
This perspective does not match reality: most people are neither heroes nor idiots most days. To see oneself realistically, as neither great nor terrible, frees up a lot of energy to do productive work.

In this context, ease does NOT mean freedom from constraint or effort. Rather, it includes the following:

  • A sense that I belong here and it’s okay to be me
  • Confidence that it’s okay to have my skills and limitations
  • freedom from worry, pain, and agitation
  • readiness in performance, facility

What are the chances that a group of intelligent, creative, experienced people can’t come up with anything of value? How can we be ready and confident to meet the unknown?

The difference between fun and joy: Fun is just an enjoyable time-filler; truly joyful experiences are productive, valuable, and can change a person.

When one has confidence and works in a team, one behaves very differently than if one is assuming failure and is simply trying to make sure that someone else gets blamed.

To increase effectiveness as a programmer, become comfortable with potential AND limitation, i.e. become okay with changing the world (as technology can do) and with not being able to do this alone.

Part of Kent’s list for becoming more at ease (he recommends we each make our own):

  • act responsibly (working code, important work, public commitments, accountability)
  • make public information public (and keep private information private); disclose early
  • appropriately value feedback (positive and negative)

People usually need to hear something 13 times before they “get it.”

Making changes is easy; sustaining change is the hard part.

Because of their “wizardry”, programmers have had a sense of entitlement about money, freedom from social norms, etc. Kent noted, with emotion in his voice, that he hasn’t claimed the one thing he was entitled to: self-respect.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply