Chaos, Order, and Code

I’ve noticed I go through a certain set of phases each time I move into a new job or get a promotion:

1. Disorientation: I’m too new to have a clear picture of what it takes to be successful in the job. I complete the tasks, but feel aimless, as I don’t know which actions are truly impacting my success, or even what success looks like.
2. Chaos: I gain a clear picture of all the skills I must master to be truly effective in my job, but I don’t know how to prioritize the learning. As a result, my approaches to mastering those skills are scattered and chaotic, making it difficult to see my progress. This is the frustration stage.
3. Planning: I reach the point where I have sufficient information to make a plan. I analyze the skills I must master, prioritize them, and estimate how long it would take to master each skill. I begin to feel in control.
4. Order: With plan in hand, I attack each skill gap ferociously. I steadily gain confidence as I watch the dominos fall. I am calm and focused.
5. Knocking on the Door of Mastery: I master enough of the skills that my progress becomes apparent to others. Others start celebrating my successes, but I’m still not satisfied.
6. Mastery: The dominos have fallen. I have attained a level of mastery that meets my own standards. The difference is small but noticeable to others. The difference is everything to me.
7. Thumb Twiddling: Having mastered the skills, I wonder what to do now that my list is complete.

Both Coding Bootcamp and the first months of my job felt chaotic. I had too little time to stop, reflect and plan.

Yesterday evening I finally found the time to plan. I laid out every skill I needed to learn, ranked them by importance and by my current skill level, and made a graph showing the intersections between skill level and importance level. (Geeky, yes, I know, but that’s been established).

Other developers often try to be helpful by suggesting obscure tools and languages you should learn. They mean well, but if you try to follow everyone’s advice, you end up with DADD (Developer ADD). Sorting out what is truly important is a very difficult task. The graph helped me visualize the top priorities, which means I can finally stop chasing after every stick another developer throws.

It is such a relief to have a plan again.

Pairing with Intent

Why did you pair program today?

No, I’m not asking why you pair program in general. Anyone can list the benefits. I’m asking “Why did you pair program today?”

The articles I’ve read all claim that when pair programming is done right, participants will reap a host of benefits, including:

• Increased Discipline (Less goofing off)
• Better Code (2 brains are better than one)
• Resilient Flow (One pair handles an interruption while the other maintains the flow)
• Improved Morale (More enjoyable than programming alone)
• Collective Code Ownership (Less finger pointing, more shared trophies)
• Mentoring (Natural way to share knowledge)
• Team Cohesion (Definitely will know each other. Hopefully will like each other.)
• Fewer Interruptions (People know you’re busy because you’re thinking out loud)

I’m not disputing the accuracy of the list. YES, these benefits result from effective pair programming.

The mistake is in the assumption that all pair programming sessions will produce all of the benefits.

I assure you that is not the case. In reality, each session delivers a small subset of these benefits. The benefits produced depend on several things:

1) The participants’ relative skill levels

2) Their personalities and relationship with each other

3) The goal of the pair programming session.

Let’s look a few of the team roles and how they benefit most from pairing:

The Junior Developer

• Benefits most when:
  • working on an issue just above his/her current level of knowledge
  • paired with a person who excels in mentoring others
  • NOT paired with the most senior team members (the gap in knowledge becomes frustrating for both)
  • given solo time to fight through simple issues on his/her own (builds confidence)

The Senior Developer

• Benefits most when:
  • working with someone who has domain-specific knowledge
• Provides most benefit when:
  • Working on complex or critically important issues
  • Paired with a developer who is only slightly less experienced
  • Paired with the express intent to mentor

The Mid-Level Developer:

• Benefits most when:
  • Paired with a Senior Dev on a complex issue
  • Paired with another mid-level dev on a standard-complexity issue
• Provides most benefit when:
  • Paired with a Junior Dev with the express intent to mentor
  • Paired with another mid-level dev on a standard-complexity issue

The Shy Dev

• Benefits most when:
  • Paired with someone who forces him/her to socialize

The Introverted Dev

• Benefits most when:
  • Encouraged to pair, but given the freedom to work alone to get a break from socializing

The Extroverted Dev 

• Insufficient data for analysis.

Pairing is an incredibly effective tool, but it is just that: a tool. No tool is right for every job, and not having a pair can be better than having the wrong pair.

It’s time we start asking ourselves: What am I trying to accomplish with this pairing session? What pair will benefit most from tackling this specific issue? Would pairing be helpful or wasteful on this particular issue with this particular pair?

Learning On the Job

Today a friend who is about to start his first job as a Junior Developer asked me a great question:

“Do you still find the time to study outside of work or has on the job learning become way more valuable?”

Here’s what I told him:

I definitely learn a lot of things at work that I would not learn outside of work, but I also spend quite a bit of time filling in the gaps outside of work.

---

For example, sitting with a developer who is awesome with Git shows me some new Git features I never would have learned on my own, but it also tells me, “Okay, apparently there’s still a lot I need to learn in that area”, so Iend up studying it at home.

---

Basically, I’m exposed to a lot more things and get a better idea of what I need to learn, but then I have to put in outside time to learn them. (Which is a little hard because my outside time is so limited).

Overall, I think the best learning experiences are a mix of being taught and teaching oneself.

When I’m paired with someone who likes to teach, I think I learn as much or more than I do alone. When I’m paired with someone who doesn’t stop to explain, I end up wishing I could spend the time teaching myself.

In an ideal world, I’d have plenty of time for both types of learning. For now, I’m soaking up everything I can from my peers, and trying to squeeze self-teaching into the tiny slivers of time left after work and family take their share.

Pairing Effectively with a Junior Developer

Pairing a junior developer with a more senior developer is an excellent way to get the junior person up to speed quickly. It can also have unexpected benefits for the senior developer, since the junior team member will often question things that a senior team member would not think to question.

“Why does Bicycle inherit from Grapefruit?”

“Um, I don’t know. It’s been that way since before I got here. At first I thought there must be a reason, but I didn’t want to ask, and then I guess I just got used to it. Yeah, we should probably change that.”

It’s easy to forget, however, that pair programming–especially with a junior team member–is a demanding task that requires a unique set of skills. The greatest programmer on the planet could be utterly incapable of mentoring a junior developer.

A great mentor needs:

• Patience: He must be able to wait for a person to solve the problem, even when he could have solved it himself in a fraction of the time.
• Excellent communication skills: He must be able to explain what he does and why. He must also be able to ask questions that provoke thought while boosting, rather than undermining, the learner’s confidence.
• Awareness of body language: He must pick up on the clues that say, “I get it,” or “I’m lost”, or “I’m thinking. Now is not a good time to interrupt.”
• Belief in the value of teaching: He must believe that teaching the junior team member is a valuable use of his time–that it is worth reducing his capacity in other areas so that the new team member can learn. He must find satisfaction in seeing the junior team member make a great leap in understanding, even if that leap of understanding was at the expense of short-term productivity.

The best mentors:

• Meet the learner on their level, without judgment. Rather than assuming a certain level of knowledge, they quietly assess the learner’s current knowledge and make a plan to move them forward from there. If the learner turns out to know more or less than expected in a certain area, they quickly adjust.
• Let the learner drive, but never forget to navigate: They start by telling the learner explicitly what to type. Next, they hint at what should be typed without saying it explicitly. Later, they simply ask Socratic questions to get the learner thinking in the right direction. As the learner progresses, they give less and less guidance, but they are always ready to step back in when the learner gets lost. Even when the learner is completely lost, they do not take over the keyboard–they simply get more and more explicit in their instructions until the learner is back on steady ground.
• Gently praise and reassure: Learning something new is taxing on the ego. Hearing an occasional “Good job” or “That’s okay. You’re doing fine,” reduces frustration and keeps the learner motivated.

Mentoring is a complex skill. Anyone can learn to mentor, but it comes more naturally to some than to others. Some developers will see the value in mentoring a new team member, and others would rather be responsible for only themselves.

When a new developer joins the team, it’s critical to pair them not with the best developer, but with the best mentor.