Sunday, November 10, 2013

I just released a new episode of This Agile Life, Episode 23 - Overloading Yoga Positions.

In this show we discuss:

  • What does role overloading mean?
    • Swarming / the ‘Whole Team Approach’.
    • Does it have a positive or negative connotation?
  • The positive and the negative of the definition.
    • Negative: When one person tries to become a super hero by doing everything.
    • Negative: Filling in when a team is understaffed.
    • Negative: When people try to do too much and end up doing nothing well.
    • Positive: People swarming to get work done as a team.
    • Positive: People pushing their comfort level to expand their skills and add facets to their skill profile.
  • Revisiting the concept of the T-Shaped Person
  • Risk vs. Reward when role overloading
    • Potential for errors vs. making forward progress.
    • It’s better to make small amounts of progress rather than no progress.
    • It’s better to make small amounts of progress rather than creating additional work in progress.
  • Can metrics be used to help manage and assess the success of role overloading?
  • Mob programming.  http://mobprogramming.org
  • A game to demonstrate the benefits of role overloading.
Thanks to Jason Tice and Dr. Lee McCauley for co-hosting this episode.

Sunday, November 03, 2013


I originally published this article on DevX on Oct. 12, 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.

Sunday, May 12, 2013

I just did an interview for Trevor Page, a fellow podcaster, to tell him about my story as a self taught programmer.  Please checkout the write up and the podcast interview over at:
http://howtoprogramwithjava.com/self-taught-programmer-to-success-story/
Trevor is doing a lot of good work with his blog, podcast, ebook and instructional videos.  Take a few minutes to check it out.

Friday, March 08, 2013


Savvis, A CenturyLink Company, is starting a new Agile forum in St. Louis, MO. The first meeting of the "St. Louis Agile LINC Forum" will be held on the evening of Thursday, April 11 from 6:00pm to 8:00pm.  Savvis is hosting the meeting at their St. Louis office located at #1 Savvis Parkway, Town and Country, MO 63017.

Those interested in attending should RSVP to jim.haftarczyk@savvis.com. The following are the details for the upcoming event.  I hope to see you there.

The event will have three presenters who will delve into a variety of topics including:

  • The Agile Transformation, presented by Gint Grabauskas, will inspire and motivate IT professionals considering the transition from the Waterfall SDLC to the Agile SDLC. He will discuss gaining support, organizing the Agile office, and unleashing the IT potential using Agile. 
  • The Role of a Developer in Agile, presented by George Hack, will cover how developers function in an Agile methodology. He will discuss how the environment and activities are different than a traditional waterfall approach. In addition, he will touch on the skill set differences for the Agile developer working in a collaborative environment. 
  • Testing in Agile, presented by Parvez Yusufji, will discuss how very different QA is between Agile and Waterfall. This will include examining the mentality of Agile testing, the tools, and the daily activities. Parvez will focus on the cornerstone of Agile testing – automation.

The interactive forum, moderated by Deanna Miller, will provide an opportunity for you to network and collaborate with IT professionals interested in Agile. Food and prizes will be provided courtesy of Savvis. Whether you are contemplating a transformation or you are well experienced in the Agile methodology, this forum is a unique opportunity in St. Louis for IT Professionals to share their experiences.

Monday, December 31, 2012

I recently wrote an article titled "The Seven Secrets of Pair Programming".  The article was published on DevX.  Check it out over at DevX.
Subscribe to RSS Feed Follow me on Twitter!