Six Strategies to Kill Creatively Without Dying in the Process

0

By

May 10th, 2013

Fourworlds Aggregated Timeline on Dipity.

 

This Dipity timeline aggregates the last five years of creative output from all my online repositories. They add up to dozens of songs and comics, hundreds of videos, and thousands of blog posts and images. Although I’m a tiny little fish in the vast Internet ocean, it’s been very satisfying to exercise creativity, develop new skills and archive a steady stream of work to share with friends, family and social networks. Along the way I stumbled upon a number of strategies that allow me to keep producing fresh work, even through stretches of burn-out and periods of creative ennui. If you’ve got a creative itch, these may help you find relief:

1. Break down large projects into iterations. This boils down to publishing your work as a continuous series of drafts, rather than as a single finished product. You can do this with just about any modality, including music, video, images and of course, text. And just because you title something “Part 1” doesn’t mean you’re obligated to follow up with “Part 2.”

2. Look for the creative sparks hidden in your daily routine. I’ve found inspiration in traffic, kitchen mishaps and social networking. The point is that you can find grist for your creative mill in practically any situation if you’re open to the moment.

3. Try new tools and mediums. I think a lot of people don’t write, draw, record music, etc. because they compare themselves to “professionals” and feel unworthy. That’s rubbish. If you can’t draw a straight line to save your life, for instance, you can create visual works by using a free comic creation site. You can create music by mashing up loops using a free tool like Sony’s Acid Xpress or GarageBand.  If there’s a particular medium or tool you tend to use exclusively, consider trying something new. Creativity is a collaboration between the artist and the medium. When you channel your creativity through new forms, exciting and unexpected work will emerge.  One of the most satisfying aspects of the last five years has been playing around with new formats such as comics and machinima.

4. Keep a recording device with you at all times. I’ve lost countless ideas by failing to jot them down when inspiration struck. Since no one is ever separated from their phone these days, you can always leave yourself a voice mail or snap a photo. I really love Evernote, a free information capturing application that runs on Mac, PC, iOS and Android.

5. Share your work. Dump all of your work to media sharing sites such as Flickr, Youtube and Issuu. Then selectively post files and links to your social networks. Start a blog; you can get on Tumblr with just a click. Even if only a handful of people follow your work, the magic alchemy of an audience is a powerful motivator to create new work and keep pushing it forward.

6. Show your process. Part of the joy of sharing is helping other people actualize their own creative work. You can do this through listing the tools you’ve used to create a work, or by occasional tutorial posts or case studies.

There you have it! If you give the strategies a try, please let me know how they work for you.

Women & Engineering

0

By

April 30th, 2013

I went to my first Women & Engineering panel recently and wasn’t quite what I thought it would be. To be honest, I don’t know quite what I was expecting. Everyone was open and supportive, even the women not on stage were often offering advice on the issue at hand. Here are some of the takeaways I got from the discussions:

How to be an engineer in the work force:

Having an engineering background helps out much more than just having a degree in an engineering related field. In becoming an engineer, you are taught analytical thinking and root cause analysis, basically taught how to think in a manner that is both effective and logical (something an old roommate and I used to joke about as having “man brains” as that is something so different than how stereotypically women supposedly think). You are trained to constantly check assumptions and make data driven decisions, letting the facts both of the present and probabilities into the future guide how you handle situations around you.

Breaking the “Guy Culture”:

No matter how open the company or group of guys, women will always be treated differently simply because we aren’t guys. One panelist told a story of how she was going to a plant where the inspection would take them to the dregs of the facility. When everyone looked at her, wondering what her situation would be on this visit, her boss very simply stated “Don’t worry about her, she always wears sensible shoes.” She commented that, to her, this was an evaluation of who she was simply by how she dressed, not the fact that she dressed appropriately for factory visits as a part of her job.

Being the only woman in the room is not all disadvantages. Being both a woman and an engineer leads to having a different perspective on problems, and life in general. While both women and men have the same aptitudes for solving complex problems, it is more likely that they will come at it from different approaches and come to different solutions simply by not being the same gender. And I have never seen a situation where only having one approach to come at a problem is a good thing.

Encouraging future women engineers:

Unsurprisingly, getting more women into engineering was discussed and once again the answer came back to our youth. Girls perform equally with boys in math up until about 4th grade, where for little reason, they typically start falling behind. Some commented that this was due to lack of female technical role models, some commented that since this is seen as acceptable, nothing is really being done to curb this. One panelist talked about how she worked with her son’s FIRST robotics team. While the team had some girls on it, they were always few and were not long lasted on the team because of the culture they were in: surrounded by geeky guys. Initially she had not been asked to help the team but volunteered herself in an effort to both help her son and to catch girls early. The team’s coach asked why her son hadn’t said his mother could help, and her son replied “but you asked if any of our dads could help.” This is the other side of the coin, where girls don’t assume that they can grow up to be engineers because their parents don’t assume women are engineers.

How to have a life:

While I don’t believe wanting to have a life outside of work and partake in activities not directly related to your chosen profession is something that is particularly feminine in nature, it just tends to come up more as people still cling to the idea that the home is still the “woman’s world.” Rule one was to make commitments and stick to them. No matter how hard you might try, you can’t make every kid’s soccer game and pick up every extra project at work, and that’s ok. One of the things that can help you the most is having a supportive partner, and be honest with both them and yourself. I don’t know how many times my husband has looked at me and told me I was being psychotic and emotional, and there was nothing I could do but smile because I knew he was right.

I really valued the connections I made there and the fact that there are more meetups planned for the Women & Engineering alums. I also really value that all the discussions were in how to help: help us not feel so alone, help men not feel insecure that a woman is “invading their space,” help girls realize they can grow up to be engineers, and help everyone figure out that the fact that we are women and engineers is really no big deal.

Company meetings don’t have to be “Bloody Stupid”

1

By

March 1st, 2013

On Monday, February 18, Asynchrony held our company meeting.  As well as being our first company meeting in the new office, we were able for the first time to bring in guest speakers. We chose two great voices in the Agile world, James Shore and Arlo Belshee, to help remind us of Agile values and to inspire us to keep striving for technical excellence.

Arlo Belshee being Bloody Stupid, James Shore is not Fooled

James and Arlo started off the day with “Bloody Stupid Johnson Teaches Agile,” a farcical send-up on how Agile is tried and fails when the commitment isn’t there to really change the culture.  We were reminded about all of the roles that can pop up as an organization tries to be Agile, from the consultant who promises the world, the Agile religious zealot who only knows how to tell people when they aren’t Agile, and the “certification trainer” who offers something really enticing and easy, but without much real benefit.

After Bob Elfanbaum and the sales team openly presented our financials and sales pipeline to all employees (as has been our custom since starting the company), Arlo and James spoke on “Virtuoso Technique,” the value of reaching a level of skill in your craft that lets you do the right things without even thinking about it, so you can concentrate on the problem at hand.  Quality is a constant conversation at Asynchrony, and an area we never feel we have totally mastered, so it was a good reminder on how practice is required to really make these skills second nature.

Arlo and James emphasize Virtuosity

At this point, the group split into two, as James and Arlo had a session to dig deeper into the Virtuoso Technique concepts by guiding developers through refactoring in their own project code bases.  Our own Stephanie Greytak and Jason Tice led another group in a presentation called “Everyday Agile Values,” where values inherent in Agile ideals were illustrated through exercises and games.

Ron and Mark experience Everyday Agile Values

After lunch, Asynchrony had a time of employee recognition, where those who were new to the company were asked to stand one at a time (35 since last October, so this took a while!) so that other Asynchronites could put names with faces.  We also renewed our tradition of giving out company-logoed jackets to those who had been with the company for five years (temporarily on hiatus as we got jackets with our new logo), and bobble heads for those who have been around for ten, a duplicate of which will be displayed in the case in our lobby.

So many five year jackets!

This was also the time that Bob Elfanbaum, our general manager, introduced the Asynchrony Culture Committee concept. As our company grows and the management team gets more and more occupied with everyday operations, it’s important to us to hold on to the culture that makes people want to work at our company and that allows us to do amazing things for our customers. This grass roots team will help keep us on track by advising changes and roles in the company to help us continue to promote an open, accepting environment of empowerment, creativity, achievement, and learning.

James Shore standing up for what he believes in…Context!

Arlo also gave a short but inspirational talk on how brain chemistry affects the learning process. It was useful for even our most experienced developers to understand the chemical reactions that allow us to learn, and how we need practice to retain what we learn.

After a lively “Agile Caucus,” where James and Arlo represented the various goals we fight for on our software projects, we broke into teams and played an Agile project simulation that helped emphasize how the engineering and planning disciplines of Agile can help make teams successful in their development goals.

We concluded with an Open Spaces discussion where employees were encouraged to propose topics that they were passionate about discussing concerning Agile and life in Asynchrony.  I saw talks on developing leadership, various development practices, and how culture should really be retained to be successful (should it be leadership doing it, or the employees?).

Kenny masters the Agile Adoption game

Asynchrony for so many years has worked not because of what management does but what our employees do to make us great. This company meeting was an effort to show support for our employees and inspire them to continue to emphasize discipline and quality, and to come up with the new ideas that will keep us successful.  We hope hearing Arlo and James helped to solidify the reasons we do what we do the way we do it, and that many of our employees had the chance to talk to them and each other to take a little something away they can use in the future. We sent out a survey about the meeting and will be reviewing the feedback to see how we can do something even better next time.

Thanks to Matt Sebek for the great photos!

Game Night!

2

By

February 18th, 2013

2013-02-15 18.49.42

I’ve been thinking about having a company game night for quite a while, and I decided to just jump out there, even at the risk of looking silly.  I sent a message out to the company with what I was thinking, with the caveat that if we got at least ten people interested we’d go ahead and have it.

The response was fantastic.  People stopped me in the hall and on the way into work, or dropped by my office to say that they were in.  I set a date, had my talented brother put together a great-looking sign that I posted around the office, and waited for the day to come.

My hope was that there were people in the office who love playing board games, but can’t find a big enough crowd of people to play with them, and so would be willing to come in.  My inspiration was the first JoCo Cruise Crazy in 2010, where a room was set aside for nearly round-the-clock board game activities.  I thought this would be a great way for people in the office to get their “game fix” and spend time with each other outside of work.

2013-02-15 18.55.59

Last Friday night, we had our first Asynchrony Game Night.  There was a great crowd there; employees brought their families and friends along and got the gaming started right away.

2013-02-15 18.50.13

I saw Carcassonne (and got to play for the first time), lots of Ticket to Ride, Settlers of Catan, Clue, Set, The Logo Game, Smash Up, Forbidden Island, Zombie Dice, some game about beans that Amos was really excited about, and others.

Then there was the raucous group that went into the Adult section (our Zanzibar conference room) and played Cards Against Humanity.  Yes, we have all of your names, and some pretty incriminating hidden camera footage.

2013-02-15 18.50.41

I didn’t get an exact count, but we consumed 17 pizzas (ordered using a new group pizza ordering algorithm that I thought of that worked pretty darn well, I must say), so I’m guessing we had at least 30-40 people there.  Most of the crowd had cleared out between 9 and 10, but there were a hardy few of us who closed out the night playing Rock Band on the big screen in Downtown North (I got my “Love Shack” fix in, so I’m happy).

Thanks to everyone who came!  I had several people stop by to tell me what a great time they had.  We will definitely do this again!

I’d Rather Be Coding: Gathering Metrics

0

By

February 17th, 2013

For a long time, I’ve been wanting to write a series of posts about those little activities that are a critical part of Agile and Lean, but somehow seem to slip by the wayside even on the most competent teams.  This series is entitled “I’d Rather Be Coding,” and recognizes that the team is trying to do their best but sometimes needs a reminder about what is important.

 

The fact that so few development teams want to gather metrics on what they are doing has always baffled me.  Aren’t these people the same ones who calculate the most profitable ways to get gold on World of Warcraft, destroy others at fantasy sports with their predictive algorithms, and optimize their route to work through careful tracking and Monte Carlo simulations?  Why wouldn’t they want to analyze every facet of how they perform as a team, to make sure they always make the best choices and don’t waste time and effort?

The simple answer is that they’d “rather be coding.”  Gathering metrics takes thought and effort, and ultimately they’ve got deadlines and customer priorities to think about.  Does the customer really want them to spend time on metrics, anyway? Wouldn’t they be angry if they were crunching numbers instead of adding that next new feature?

The essential problem is this:

  1. No team is perfect.  There is always room to improve.
  2. Improvement brings greater productivity, fewer errors, and/or more predictability (all aspects highly valued by the customer).
  3. Without baselines and measurements, there is no way to know whether or not improvement has actually taken place.

 

Without metrics, even the best team who really wants to improve is left with “gut feelings” and “well, nothing bad has happened yet” to determine whether or not a change in their process, tools, or methods has actually added value.  I would maintain that this is the real waste of time. If your team is feeling pain, and then makes a change to deal with that pain but doesn’t measure anything before and after the change to evaluate it, then they are effectively just trying out different rain dances every time one they are using doesn’t bring rain.

Deep down, teams know this. However, there are several “fear factors” involved with metrics:

  • How do we know what we are measuring is the right thing?  What if we spend a lot of time gathering a measurement and it doesn’t tell us the right information?
  • What if we start getting evaluated by the measurements we create?
  • What if the measurement tells us something we don’t want to hear?

 

It’s important for teams to follow a process when a measurement is constructed, to make sure that it is not just a waste of time.  There are several important questions that need to be answered every time the team decides to gather a metric:

What question are we trying to answer with this measurement? Decide what it is you need to know. Is it whether your quality is slipping? Is it a concern for how long features take to develop? Is it an observed slow response time by the customer?  It’s helpful to relate the problem back to a risk to your project, which usually comes down to either time (deadline being met) or money (budget being exceeded).  Getting down to the root cause of the issue helps clarify what needs to be observed.

How will this measurement be gathered? How is it that the team will start to gather this data?  Will it need to be done manually, or is there a tool that can do it for you?  This is also the time to determine whether or not the measurement is actually worth doing; if you need to spend two weeks building a tracking system to be able to effectively obtain the data, perhaps the benefit of having it is not great enough to overcome that investment.  In that case, try to find a simpler method that gathers a lower fidelity of data that can still be useful.

How will the gathered data be stored? It’s not enough to gather the data; in almost every case, what you care about is the trend of data, the way it changes, not the information on a particular day.  How will you reliably store this information so that you can access it later when you want to analyze it?  Hopefully, you have a tool that takes care of this for you, but if you don’t, even putting it up on a chart on the wall that everyone can see can add value.

How will the data answer your question? You should have an understanding before you start of how and when you will analyze the data to answer the original question.  For a trend, determine what trend direction is “good” or “bad.” Decide when the data will be reviewed, and by whom (again, maybe it’s an automated process that does this review). Should action be taken when the data hits a certain “bad” level (call a meeting, send an email, break a build)?  Should you have times when you evaluate whether or not the measurement still makes sense to gather?

How do we know these decisions are being acted on? It’s not enough to make the decisions, you need to follow up to make sure the actions decided on are being executed.  Ask someone outside the project to hold you accountable.  Announce what you’re doing to a group of peers who will expect to see results.  Make it a defined part of your agenda at meetings and demos.  Otherwise, you really are wasting your time.

(Coincidentally, these are the same questions that CMMI would have you ask yourselves in the Measurement and Analysis process area.  So, it’s not just coming from me.)

Getting good measurements isn’t easy.  You need to work to plan the measurement, you need to work to take the measurement, you need to work to analyze and report the results.  However, without measurements, your team is truly “flying blind,” and without thought put into measurements, you’re just relying on “blind faith.” Take the time to perform metrics the way you take time to design your code, and the sight that it brings you will pay dividends.

An Agile Response to an Urgent Business Shift

0

By

September 17th, 2012

by Myles Bogner, Ph.D. and Steve Kanter

We had a small Agile software development team in one location.  Within this environment, we operated with the following tools:

  • A Kanban board drawn on a whiteboard with post-it notes that were physically date-stamped as items moved through the queue
  • Company provided git repository for source control
  • Metrics gathered manually from the post-it notes and entered into Excel
  • Daily reporting by taking a photograph of the Kanban board for transcription into emails

We received a new business paradigm that included the following requirements:

  1. Software features in the development queue may change daily and possibly hourly
  2. Ability to, at any moment, permanently record a snapshot that communicates the following three pieces of information:
    1. Release-ready features
    2. Current priorities
    3. Features currently in development

As we began to operate with these new expectations, we soon realized our current tool set for fulfilling these requirements was extremely difficult, tedious, and time consuming.  The developers were continually interrupted and our limited quality assurance resources were pulled away from testing.  Our limited personnel needed to be focused on their jobs.  The team was stressed, and our relationship with our project sponsor was becoming increasingly strained.

Additionally, enormous changes to the development team were scheduled for implementation the following month.  These included:

  1. Tripling the size of the development staff
  2. Changing from a single location and company to a team spread worldwide working for multiple organizations
  3. Product roll-out

We knew that if we did not quickly address these problems and upcoming organizational changes, we would possibly be at a breaking point.

We needed to rapidly create a simple automated solution using readily-available tools.  We devised, implemented, and employed a process that automatically captures the required information and formats it into multiple presentation needs.

Business Need Solution
Story tracking and a code repository with link to stories GitHub (github.com)
Visually re-prioritize features collaboratively with customer Huboard electronic Kanban (huboard.com) linked to GitHub
On-demand automated raw data capture Publicly available code from https://gist.github.com/2369729, modified to add additional data fields (ruby_to_csv.rb)
Automated status capture Custom Excel macro parses raw data to create daily Kanban state worksheets
Automated customer report generation Custom Excel macro that outputs wiki-ready text
Metrics Custom Excel pivot tables
Distributed team support Huboard and Github online versions

Now each day, or optionally multiple times a day, with minimal personnel involvement to kick off automated processes, the following occurs:

  • The project sponsor logs into Huboard to see the state of development and prioritize the team as desired
  • Developers utilize the popular GitHub environment for distributed collaboration and as a source code repository
  • As needed, the project manager or quality assurance engineer executes ruby_to_csv to capture the state of the Kanban board;  this <datestamp>_issues.csv file is uploaded to a repository for distributed team access and historical record
  • Quality assurance executes the Excel macros which parse the data and prepare:

○ Point-in-time Kanban status worksheet showing queues

○ Wiki-ready text for a customer status report

  • Quality assurance optionally generates Excel pivot tables that leverage the point-in-time status worksheets to display desired metrics such as cycle times

This straight-forward solution saves a tremendous amount of time, approximately three hours each day:

  • The time quality assurance spent to capture and record metrics fell by two hours
  • Project management time to pull together reports was reduced by one half hour
  • Developers no longer are being regularly interrupted to field status questions saving at least a half hour

This solution has improved morale as all team members now focus on their primary responsibilities.  Our project sponsor is happier as there is up to the minute status enabling prioritization on the fly.  The team has valuable metrics for review and to facilitate improvement.  Most importantly, the team has a better synergy and rapport with our sponsor.

Lean Six Cobra Kai

0

By

September 5th, 2012

“This Agile Life” podcast just published episode 3, titled “Lead Six Cobra Kai”. The hosts for this episode were our own, Amos King, Andrew Radford, and John Sextro. Rocking the audio, as always, is the one and only, Dr. Lee McCauley.

Please have a listen and share it, email it, Facebook it, Tweet it, Digg it (oh wait, isn’t Digg dead) with all your friends and even your enemies.  You won’t be sorry.  You can pickup the feed on iTunes at http://itunes.apple.com/us/podcast/this-agile-life/id549367028?mt=2# and on Feedburner at http://feeds.feedburner.com/thisagilelife/podcast

You can find out more about the podcast, including the show notes, on our website http://thisagilelife.com. While their, please let us know if you have discussion items you’d like us to add to our discussion backlog and share your feedback on the podcast with us.

If you’re into iOS and Objective-C you should checkout the latest episode of iOhYes. You can find the latest episode and links to subscribe to the feed at http://iOhYesPodcast.com.

7 Habits of Highly Effective Pair Programmers

1

By

June 22nd, 2012

Through my various experiences as a Developer, Technical Lead, Test Driven Development Mentor and Agile Coach, I have paired with more than 100 different Developers over the course of 10 years.  As you can imagine, I’ve seen just about everything, the worst of the worst and the best of the best.  Most of the people I have paired with were proficient programmers and nice people.  However, pair programming can be tough, even for the best developers, and can be downright daunting if you haven’t done it before, are introverted or unsure of yourself.  For those of you that want to improve your pair programming fu, I offer you my 7 Habits of Highly Effective Pair Programmers.

Proficiency

Proficiency with the language and proficiency with the IDE are paramount to working as an effective pair partner.  When you program with a pair partner you have nowhere to hide.  All of your skills and abilities, along with your fears and shortcomings, will be on display for everyone on the team to see.  This often scares people away from pair programming.  To overcome these fears you must first accept that there will always be someone out there that knows more than you do.  Second, you should work to improve yourself in the areas where you feel weak or unsure.  Block out 30 to 60 minutes per day for self improvement for a few weeks.  You’ll be surprised by the results.

Finally, you must master your IDE.  There’s nothing more frustrating than watching your pair partner wade through a series of dropdown menus to perform “Extract Method” when Ctrl+Alt+M is quick and easy to remember.  Almost all modern IDEs have a wide range of shortcut keys for the most commonly used actions and commands.  Find a reference card for your IDE on the internet and highlight the ones you think will be most useful to you.  Then memorize the shortcuts and start using them everyday.  Your pair partner will appreciate your mastery of the IDE and you will improve your efficiency.

Communication

In any relationship, communication is key.  When you are pairing you are essentially in a very intense, but short, relationship.  You are two people working collaboratively towards a shared goal.  You must communicate well.  Before you dive into a task spend a few minutes discussing the task and identifying an approach to implement a solution.  You can write some given/when/then statements or actually use Cucumber or another Behavior Driven Development tool to document and clearly define your success criteria.  Doing so will ensure that you and your pair partner agree on what to do and how to do it.

When it’s your turn at the keyboard keep your pair partner informed.  You need to verbalize your thought process to let your pair partner know where you are heading and why.  I try to use a verbal stream of consciousness to let my pair partner know what I am thinking and what I am doing to keep me from wondering off course and let my pair partner know where that course is leading.  I also try to ask my pair partner questions to help keep my pair partner engaged and to solicit feedback and advice.  For instance, after passing a test, I will often say, “What do you think?” and offer the keyboard.  This is chance for my pair partner to improve, refactor or write another failing test.

Self Confidence

When you are confident in yourself and your abilities you feel comfortable offering and receiving constructive criticism.  Having this self confidence allows you to focus on making the criticism that you give constructive rather than using the opportunity to belittle your pair partner in order to inflate your own ego.  Self awareness of your strengths and weaknesses, coupled with a confidence that you “can do this” allows you to relax and focus on your work rather than on your shortcomings.  Additionally, you will be able to open yourself up to constructive criticism and you will have the perspective necessary to determine if the criticism is relevant and actionable.

With self confidence you will find that you are more willingly to ask questions and try out new ideas.  Your self confidence can inspire better communication on the team by setting the example that you are willing to admit that you don’t know everything and are willing to ask for and accept help.  When you’re self confident you don’t worry about what others are thinking about you or your productivity so you are more willing to take chances and try innovative solutions.  Doesn’t this sound like someone that you would like on your team?

Self Control

When we were children we learned the basics of self control.  We learned to take turns, to finish our homework before playing outside and to go to bed at our bedtime.  But sometimes our self control lapses when we are bored, tired or frustrated.  Let’s face it, our world is full of distractions: email, smart phone, internet, mobile gaming, social networks, hallway conversations, the list goes on and on.  The discipline of software development requires a significant amount of mental effort and focus.  So anything that distracts your attention can be a potential productivity killer.

The high functioning teams that I have witnessed leverage their “team norms” or “ground rules” to help them reduce the number of potential distractions.  For instance, one team made a rule that they would only use their cell phones outside their team area (see the example “ground rules” later for more ideas).  You can also leverage good agile principles to stay focused.  Use spikes to investigate new ideas and techniques.  Add a “time allowance” to your spike story to keep you from going down an endless “rabbit hole”.  When you’re working on an agile team you’re responsible for you and for everyone else on the team.  That’s what we mean by the “whole team approach”.  If you’re having trouble focusing you should be able to rely on your pair partner and your team to help get you back on task.  Just the same, if you notice that someone else is having a hard time staying focused you need to be willing to step up and help them get back on track.  Remember, you will succeed or fail as a team.

Patience

I think by now we have clearly established that writing code with a pair partner is much different than hacking by yourself all day.  Your patience, or lack thereof, doesn’t usually affect others when you’re working alone.  If you’ve spent your whole career as a solo “keyboard jockey”, pair programming will put your patience to the test.  As a pair partner you won’t always have control of the keyboard and mouse and it is considered bad form to rip the mouse out of your partners hands.  Some people have a hard time with this and have to use extreme measures, such as sitting on their hands, to keep themselves from grabbing for the keyboard or mouse.  So when you get the urge to grab, take a deep breath exercise your self control and then use your best manners to ask, “May I?”

Once you get control of the keyboard and mouse, you should be willing to relinquish control without a fight.  Liberal keyboard passing helps keep both pair partners engaged and motivated.  Some of the best athletes in team sports are the ones willing to sacrifice a small personal victory and make a pass to a teammate in order to achieve a larger team “goal”.

Manners

Manners in the workplace seem to have gone the way of chivalry, yet manners are a crucial part of human interaction.  Programmers often forget this because they don’t have to thank their shell script for grep’ing through a log file or ask politely for their laptop to launch their favorite IDE.  However, when pairing, good manners are expected and poor manners are not easily forgiven.

I find it useful to start off a new pairing session by setting a few simple ground rules. If you prefer to formalize these ground rules you can work with your team to create a set of team ground rules for pairing.  Some groups like the formality of a team set of rules while others prefer to play it loose and make the rules up as they go.  Whichever way you go, just remember that it is necessary to have a shared understanding of how you will work together as a pair before starting to avoid confusion and hurt feelings.  You might be surprised to learn the things that distract or bother your co-workers.

Here’s a few example ground rules:

  • Pass the keyboard liberally.
  • Allow the person on the keyboard to complete a block of code before asking a question or making a comment.
  • Don’t read email, talk on or play with your cell phone or other distracting behavior while actively working.
  • Don’t touch the screen.

That addresses the technical aspects of the pairing session.  Don’t forget to use general good manners otherwise.  The following is a list of ways to improve your manners:

  • Rather than grabbing at the keyboard or mouse, ask, “May I?”
  • Instead of sighing or huffing, keep quiet until your partner finishes his thought and then offer your suggestions for improvement or refactoring.
  • If you get into a heated debate or discussion, ask a third party to intervene to help resolve the situation or propose a short break and then use that time to evaluate the importance of the discussion to determine your next steps.
  • Rather than gobbling down your afternoon snack, offer to share.
  • Instead of just quietly parting ways at the end of the pairing session, thank your pair partner.

If you work to improve your manners I think you will find that you will have more enjoyable pairing sessions and will become one of the most sought after people to pair with on the team.

Hygiene

This should really go without saying.  It really should.  Unfortunately, I have to say it, because too many people ignore the use of basic hygiene in the office, and it’s better that you hear it from me now, than suffer the embarrassment it could cause later.  So consider this a quick “Health Class for Programmers”.

Here is a simple list of things you can do to improve your hygiene.  You should shower every morning, brush your teeth and use deodorant.  Throughout the day you need to be mindful of your breath.  Some people are very sensitive to coffee breath and onion breath.  If you like to drink coffee and/or eat onions or garlic (or other strong smelling foods) consider following those  up with a mint or breath freshening gum.  If you smoke, you should always wash your hands and freshen your breath before returning to your workspace.  If you cough or sneeze, be sure to cover your cough/sneeze using the inside of your elbow as a shield and sound muffler.  Always keep hand sanitizer nearby to keep your hands clean and sanitary throughout the day.

If you work in a bullpen or agile room, it’s important to remember to clean up after yourself.  Throw away your empty soda cans, disposable water bottles, snack bags, gum wrappers, etc. Its not fair to the pair that will come behind you to have to clean up after you before they can get started working.  Try to keep some disposable cleaning wipes on hand.  These work great to sanitize the workspace to help keep everyone healthy and to keep the cruft from building up on the mice, keyboards and desktops.

Let me close by telling you that I have probably violated every principle of every habit in this article and this is part of what has made it possible for me to compile these habits.  But thanks to my years of experience and with help from my teammates and coaches I have gained a level of self awareness that allows me to make the necessary adjustments to become a more effective pair programmer.  By no means have I completed this journey, but I am a better pair programmer today than I was yesterday.  It is for this reason that I define success, not as the attainment of a static goal, but rather as the continual attainment of small goals on a path toward perfection, with the full awareness that my journey as a pair programmer will end well before achieving perfection.