Chemaclass - pair-programming

Effective Pair Programming

2024-03-28T00:00:00+00:00

What is pair programming? Two people working together on the same problem, at the same time.

It is not about one person showing off their skills in front of another, nor one person afraid of making mistakes due to an impostor syndrome.

Each person will have a role:

Navigator: he will pay attention to the bigger picture; eg: architecture, relation between collaborators, object design, etc.
Driver: she will pay attention to the small details; eg: naming, code conventions, writing syntax, object design, etc.

The pair could, and should, switch roles occasionally; eg: every X commits pushed, every 10 mins, … up to them.

Pair programming should not be considered a practice only for “seniors” to juniors, but regardless of the team members’ experience level.

It is about the collaboration flow, the quality communication, the absence of feeling judged, and the idea of welcoming vulnerability with your peers, knowing they will support and help you.

It is about constantly challenging each other, seeking the most pragmatic solution while keeping it simple. Always looking for quick feedback when speaking to each other, but also on the solution you agreed to implement and its direction.

It is about the short, quick, and immediate feedback loop while talking to your partner, who reviews your code on the fly. You can guide as a navigator or help the driver validate their ideas in a broader picture.

It is about the constant sharing of knowledge atmosphere by default, reducing bus-factors and silo-knowledge areas to the maximum. Increasing the focus by having two minds working on the same task simultaneously.

It is about team cohesion and sharpening the feeling that we belong. When we understand each other’s strengths and weaknesses, we will realize how much we can help each other grow.

How can you practice pair programming? #

Pair programming can be done in different ways:

You can start and finish a task with pairing. You can time-box it to 30, 60, 90 minutes. Either way, it is recommended to have pauses in the middle - Pomodoro.
You can start the task together and stop when one of your peers feels confident enough to continue alone.

It is up to the team, and the task in context, to decide when and how to apply pairing to get the best out of it.

This does not mean you must constantly work “no matter what” in pair. This is not about creating rules; on the contrary, it is about embracing this practice to the point you feel confident to choose when and how to use it to get the best out of it.

Pair programming might become one of the best tools in your team toolbox for daily interactions. Not because you read it somewhere but because of the benefits you and your team will find.

Common Patterns #

Different strategies for effective pairing #

Driver-Navigator: One person is driving the code (with the keyboard), focusing on the detail aspect of the task itself. The other is a navigator (no keyboard), having a more abstract picture of the task in mind.
Ping-Pong: Frequent switching driver-navigator roles in small interactions, e.g., every N minutes, every N commits, etc.
Backseat driver: The navigator engages actively with the driver.
Tourist guide: The navigator passively learns with the driver.

Anti-patterns while pairing #

The silent partner: The navigator is not participating, and they are being silent.
The solo act: The driver ignores all inputs from the navigator.
Distracted pair: The pair does not focus on the problem to solve.
The Dictator: One person is telling what to do, ignoring the input from the other.
Philosophical pair: The pair is bikeshedding into irrelevant topics.
The code war: The pair does not reach an agreement and starts an unnecessary war, which wastes time and effort.

Want more? Check this out: Learning Through KATAS

The takeaway #

Pairing is not a rule to enforce, it is a tool to reach for. Use it when the task is complex, the knowledge is siloed, or the stakes are high. Skip it when the work is trivial. The goal is never “always pair”, it is better software and a stronger team. Pick one real task this week, pair on it, and switch roles often. The benefits show up faster than you expect.

Pull Requests vs Pair Programming

2021-04-01T00:00:00+00:00

Let’s talk about the benefits of Pull Requests and Pair Programming, and my thoughts on these after some years of experience with them.

Pull Requests #

A Pull Request (PR) is basically a way of showing your suggested code changes such that they are easily comparable with the existing source code. This is part of a workflow that helps developers to share knowledge about the changes that are being done within the system.

A Pull Request is the moment where you ask your peers to review and check out your code changes.

Usually, it’s also used:

For discussions about code style.
To spot potential bugs.
For architectural or design discussions once the solution is done.

Pull Requests aren’t the best tool for everything #

The main problem with these topics above is that PR’s are usually ready when the feature/bug is already being worked on and in the last stage of its development process. It [a PR] is an “already changed proposal [I have already worked on this change, here’s the code] to be merged into the current system [someone please look it over]”.

The concept of “Draft PR” exists to make explicit that a PR is not ready to be merged, so it’s still a “work in progress thing”, but that’s another topic.

Pull Requests are, indeed, one of the best tools that we have in our industry to share knowledge about the changes that we are doing in the system, but sometimes they might be misused, as for example:

Discussions about code style. Code style shouldn’t be discussed in a PR. There should be already a CI running a code style checker, that’s all. If you want to talk about code style, request a change in your code style checker, but not in a random PR.
Spot bugs. Bugs and desired behavior should be covered by automated tests. The developer is the first responsible person for this topic.
Architectural or design discussions. Once a particular solution is developed and ready for review, it is usually really hard to “rollback” that idea and rewrite it again. Because “why would you do that? For some subjective opinion? It’s done already. And it seems to work just fine.”

Having an extra person looking at the changes that we have done for “designing decisions” might be beneficial, but we could have addressed “potential disagreements” in a sooner stage.

What should the purpose of a Pull Request be? #

Sharing knowledge about the proposed changes with the team.
Ensuring the team aligns and agrees across the multiples changes that are getting submitted every day in order to keep a healthy direction for the project. Yes, this might include double-checking the outcome design, but… What if that is now too late? How could we solve all those issues?

Pair Programming #

The concept of “Pair Programming” can be understood from different points of view. Pair thinking and pair programming, driver-navigator roles concepts, or pure live coding from one side. Actually, this is way easier than it looks like at first instance:

Either you watch and help the other person to write code,
Or you type while getting another pair of eyes watching and helping you.

Pair Programming helps the team to work together.

Pair programming is the joy of working with an extra brain and another pair of eyes, where the key is to build a context where you two share the same goal in order to find the best possible solution. All of this while learning from each other every single second. Pair Programming is not about developing the best solution at the very beginning. It’s about making it work, sharing ideas, and finding a better solution together. After that, you can refactor and clean the code.

Pair Programming is a continuous code review #

Pull Requests are an asynchronous way to share code changes, while Pair Programming is totally synchronous because it happens at the same time.

That said, Pull Requests and Pair Programming aren’t mutually exclusive, they can coexist. They are tools, and we should wisely choose them in order to achieve our objectives.

The most common fear that I saw while encouraging to do Pair Programming is that some people are shy and they don’t like to have other eyes around them while they are coding because of:

Fear that they don’t know what to code or where to start.
Fear that others will laugh at their solutions.
Fear to not succeed in public.
Fear to not be able to develop the expected solution for multiple reasons: misunderstanding the task or lack of knowledge.
Fear to change your mind in front of others.
Fear to discuss and make decisions loud.
Fear of disagreeing with others.

After several years of experience on this topic #

The pattern which rejects Pair Programing is basically “fear”, and being out of your comfort zone. And this is due to the misunderstanding of the roots of the actual Pair Programming concept.

Pair Programming is not “to show off in front of your colleagues” or “to be screwed by your peers”, but to be transparent (showing your skills as they really are) and improve as a team lifting up each other.

Programming is an iterative process that needs a continuous refactoring of our way of thinking in order to achieve better solutions, day by day. Therefore, programming with another person next to you (with a different way of thinking) will help the team to get the best from each other while discarding the waste or bad habits if necessary.

Pair Programming doesn’t need to be always set for everything. As a tool, it’s flexible, and we can choose how, when and for what reason.

A personal rule of thumb, before starting tasks that might involve touching multiple modules or complex business rules, think about a quick Pair Thinking/Programming with another more experienced colleague in that field.

Everything depends on a particular context and people: the developers, the pairs, the tasks, the mood.

Still uncomfortable with Pair Programming? #

If you still feel uncomfortable having another person next to you while you write code, it might be because you aren’t particularly happy with your own code, or the process that you follow in order to achieve some result. My favorite way to work on this is by exercising on your own and working on improving your skills as a software developer.

Create and play around with your own pet projects.
Work on code katas on your own and with others.

Practice makes the master.

Keep pull requests, add pair programming #

Don’t get me wrong, Pull Requests are great. Keep doing them.
Team collaboration is essential. Pair Programming aims for this.
Pair Programming encourages the team to proactively work together.
Don’t be afraid of coding while having eyes around you. Ask questions when something is unclear. Ask for help when you don’t know how to solve something.

It’s totally ok not knowing everything. The most important thing is to know how to work together.

Sharing Your Git Patches

2020-12-01T00:00:00+00:00

Discover another way of sharing suggestions with your development team.

Imagine this situation #

You are reviewing a Pull Request (PR), and you see some minor improvements or suggestions that you would like to share with the author. You might write some comments, and usually, that would be sufficient.

Imagine that in order to transmit your “whole idea” you would need to change some files because just communicating the full picture will end up in a huge comment which might be not as clear as it could be.

What possibilities are there apart from just comments in a PR? #

Well, there are multiple options. The key is to be aware of them and use them wisely depending on the priority of the task and the changes themselves:

As already mentioned, writing a comment as feedback is a good idea by default, but not the only one.
We can always do some pair-thinking, talk at any time. Communication is always good in order to clarify the possible uncertainty.
Sharing your git patches is another good option.

Git diff to the rescue! #

What if you (as a reviewer) could share your idea without any single commit or comment in the PR, but sharing your changes directly with the author?

Well, that’s actually possible and really easy. As you already know, the git diff command gives you the differences between any two branches.

git diff origin develop > ../my-origin-develop.patch

What we are doing here is redirecting the output of the diff command into a file (aka: patch), so we can share that output with any other peer-team.

What now? #

Well, having that patch file, it’s pretty easy to apply those changes in your local machine without doing any commit:

git apply ../my-origin-develop.patch

Applying this patch will simply change your local system in the same way the patch was created.

“How to” by steps #

Let’s divide the responsibilities into two: the creator of the patch and its user:

The patch creator: the person who will create the patch #

# Checkout that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Do your suggestions and changes in the targeted branch
# Generate the patch file using the diff command
$ ~/myProject git:(the-branch) ➜ git diff > ../your-diff.patch
# Share the patch file with the author of the PR

The patch user: the person who will see the patch #

# Ensure you are in that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Apply the patch file
$ ~/myProject git:(the-branch) ➜ git apply ../your-diff.patch

References #

Official documentation for “git apply”

Extreme Programming Explained

2020-03-05T00:00:00+00:00

Definition #

Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.

Values #

The five values of XP are communication, simplicity, feedback, courage, and respect and are described in more detail below.

Communication #

Software development is inherently a team sport that relies on communication to transfer knowledge from one team member to everyone else on the team. XP stresses the importance of the appropriate kind of communication: face to face discussion with the aid of a white board or other drawing mechanism.

Simplicity #

Simplicity means “what is the simplest thing that will work?” The purpose of this is to avoid waste and do only absolutely necessary things such as keep the design of the system as simple as possible so that it is easier to maintain, support, and revise. Simplicity also means address only the requirements that you know about; don’t try to predict the future.

Feedback #

Through constant feedback about their previous efforts, teams can identify areas for improvement and revise their practices. Feedback also supports simple design. Your team builds something, gathers feedback on your design and implementation, and then adjust your product going forward.

Courage #

Kent Beck defined courage as “effective action in the face of fear”. This definition shows a preference for action based on other principles so that the results aren’t harmful to the team. You need courage…

to raise organizational issues that reduce your team’s effectiveness.
to stop doing something that doesn’t work and try something else.
to accept and act on feedback, even when it’s difficult to accept.

Respect #

The members of your team need to respect each other in order to communicate with each other, provide and accept feedback that honors your relationship, and to work together to identify simple designs and solutions.

Principles #

Humanity #

Human beings are the ones developing software. It is a fact. The book mentions 5 points that are needed for developers to become good: basic safety, accomplishment, belonging, growth, and intimacy.

The magic of great teams is that after the team members develop trust they find that they are free to be more themselves as a result of their work together.

Economics #

Software costs. Someone or multiple people paid or invested in it.

Make sure what you are doing has business value, meets business goals, and serves business needs. For example, solving the highest priority business need first maximizes the value of the project.

The earlier software makes money, the sooner the development is valuable.

Mutual Benefit #

Mutual benefit in XP is about activities benefitting all concerned. This principle is about finding practices that benefit me now, me later, and the customers as well.

The book brings up 3 points how XP mutually deals with communication-with-the-future problems:

I write automated tests that help me design and implement better today. I leave these tests for future programmers to use as well. This practice benefits me now and maintainers down the road.
I carefully refactor to remove accidental complexity, giving me both satisfaction and fewer defects and making the code easier to understand for those who encounter it later.
I choose names from a coherent and explicit set of metaphors which speeds my development and makes the code clearer to new programmers.

Self-Similarity #

This principle is about copying the structure of one solution into a new context.

For example, the basic structure of development is that you write a failing test and then make it work. This structure operates at all different scales. Take into account, this principle is a good start, but it may not always work.

Improvement #

Do your best today but strive to do better tomorrow, strive to have a deeper understanding tomorrow. XP shines in this aspect, it is about always improving.

Put improvement to work by not waiting for perfection. Find a starting place, get started, and improve from there.

Diversity #

Teams need to bring in people from different backgrounds, with different experiences, attitudes, etc. In order for the team to have different ways of thinking and solving a problem.

The principle of diversity suggests that the programmers should work together on the problem and both opinions should be valued.

Reflection #

Good teams reflect after action, regularly. They think about why and how they are working.

Why did we succeed? What should we continue doing?
Why did we fail? What can we do better or differently?

Reflect and strive to improve. Even if everything seems perfect, know that there is always room for improvement and throw in the question:

Why do things seem perfect? What are we doing well? What can we do better in order to succeed even more?

Flow #

Flow in software development is delivering a steady flow of valuable software by engaging in all the activities of development simultaneously. Don’t deliver software in big portions. Deploy smaller increments of value more frequently.

Opportunity #

Learn to see problems as opportunities for learning and improving.

Part of being extreme is consciously choosing to transform each problem into an opportunity: an opportunity for personal growth, deepening relationships, and improved software.

Redundancy #

The difficult problems in software development should be solved in multiple ways.

The cost of the redundancy is more than paid for by the savings from not having a disaster.

Failure #

Sometimes it is extremely difficult to implement something, we don’t know which way or approach to take, try the ideas you have, even if they fail! Failure isn’t a waste, rather a learning experience.

Be aware of falling into the trap of discussing or thinking forever and not getting things done.

When you don’t know what to do though, risking failure can be the shortest, surest road to success.

Quality #

Projects don’t go faster by lowering the quality. Actually it’s often the other way around (if not always). It results in later and less predictable delivery, especially due to the amount of time spent on fixing bugs for example.

Pushing quality higher often results in faster delivery.

A concern for quality is no excuse for inaction. If you don’t know a clean way to do a job that has to be done, do it the best way you can. If you know a clean way but it would take too long, do the job as well as you have time for now. Resolve to finish doing it the clean way later.

Baby Steps #

Take baby steps. Making big changes in big steps is dangerous. People and teams can take many small steps so they appear to be moving forward rapidly.

Baby steps acknowledge that the overhead of small steps is much less than when a team wastefully recoils from aborted big changes.

Accepted Responsibility #

Responsibility cannot be assigned; it can only be accepted. If someone tries to give you responsibility, only you can decide if you are responsible or if you aren’t.

Practices #

While it is possible to do these practices in isolation, many teams have found some practices reinforce the others and should be done in conjunction to fully eliminate the risks you often face in software development.

Sit Together #

Since communication is one of the five values of XP, have your team sit together in the same space without barriers to communication, such as cubicle walls.

Whole Team #

Include on the team people with all the skills and perspectives necessary for the project to succeed.

Informative Workspace #

Set up your team space to facilitate face to face communication, allow people to have some privacy when they need it, and make the work of the team transparent to each other and to interested parties outside the team.

Energized Work #

You are most effective at software development and all knowledge work when you are focused and free from distractions.

Pair Programming #

Pair Programming means all production software is developed by two people sitting at the same machine. The idea behind this practice is that two brains and four eyes are better than one brain and two eyes. You effectively get a continuous code review and quicker response to nagging problems that may stop one person dead in their tracks.

Teams that have used pair programming have found that it improves quality and does not actually take twice as long because they are able to work through problems quicker, and they stay more focused on the task at hand, thereby creating less code to accomplish the same thing.

Pair programmers:

Keep each other on task.
Brainstorm refinements to the system.
Clarify ideas.
Take initiative when their partner is stuck, thus lowering frustration.
Hold each other accountable to the team’s practices.

Pair programming is a dialog between two people simultaneously programming (and analyzing and designing and testing) and trying to program better.

Though, if you need privacy and time to work on an idea, go ahead and do it. We need both companionship and privacy. Make sure to rotate pairs frequently and take frequent breaks, pairing can be tiring, but surely is rewarding.

Stories #

Describe what the product should do in terms meaningful to customers and users. These stories are intended to be short descriptions of things users want to be able to do with the product that can be used for planning and serve as reminders for more detailed conversations when the team gets around to realizing that particular story.

Give the stories a short title and a description. Write them on cards and put them on a wall that is often being passed.

In XP stories are estimated extremely early, which gets the team thinking about how to get the largest return from the tiny investment.

Weekly Cycle #

The Weekly Cycle is synonymous to an iteration. In the case of XP, the team meets on the first day of the week to reflect on progress to date, the customer picks the stories they would like delivered in that week, and the team determines how they will approach those stories.

The intent behind the time boxed delivery period is to produce something to show to the customer for feedback.

Ten-Minute Build #

The goal with the Ten-Minute Build is to automatically build the whole system and run all of the tests in ten minutes.

Continuous Integration #

Continuous Integration is a practice where code changes are immediately tested when they are added to a larger code base. The benefit of this practice is you can catch and fix integration issues sooner.

This practice requires some extra discipline and is highly dependent on Ten Minute Build and Test First Development.

Test-First Programming #

Write a failing automated test before changing any code.

The book mentions 4 problem Test-First Programming addresses at once:

Scope creep: It’s easy to get carried away programming and put in code “just in case.” By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding. If you really want to put that other code in, write another test after you’ve made this one work.
Coupling and cohesion: If it’s hard to write a test, it’s a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test.
Trust: It’s hard to trust the author of code that doesn’t work. By writing clean code that works and demonstrating your intentions with automated tests, you give your teammates a reason to trust you.
Rhythm: It’s easy to get lost for hours when you are coding. When programming test-first, it’s clearer what to do next: either write another test or make the broken test work. Soon this develops into a natural and efficient rhythm: test, code, refactor, test, code, refactor.

Incremental Design #

Invest in the design of the system every day.

You do a little bit of work up front to understand the proper breadth-wise perspective of the system design, and then dive into the details of a particular aspect of that design when you deliver specific features.

This approach reduces the cost of changes and allows you to make design decisions when necessary based on the most current information available.

Roles #

Although XP specifies particular practices for your team to follow, it doesn’t really establish specific roles for the people on your team.

Depending on which source you read, there is either no guidance, or there is a description of how roles typically found in more traditional projects behave on XP projects.

The Customer #

The Customer role is responsible for making all of the business decisions regarding the project including:

The XP Customer is assumed to be a single person, however experience has shown that one person cannot adequately provide all of the business related information about a project.

The Developer #

Because XP does not have much need for role definition, everyone on the team (with the exception of the customer and a couple of secondary roles listed below) is labeled a developer. Developers are responsible for realizing the stories identified by the Customer.

The Tracker #

The main purpose of this role is to keep track of relevant metrics that the team feels necessary to track their progress and to identify areas for improvement.

The Coach #

This is usually an outside consultant (or someone from elsewhere in your organization) who has used XP before and is included in your team to help mentor the other team members on the XP Practices and to help your team maintain your self-discipline.

Chemaclass - pair-programming

Effective Pair Programming

How can you practice pair programming? #

Common Patterns #

Different strategies for effective pairing #

Anti-patterns while pairing #

The takeaway #

Pull Requests vs Pair Programming

Pull Requests #

Pull Requests aren’t the best tool for everything #

What should the purpose of a Pull Request be? #

Pair Programming #

Pair Programming is a continuous code review #

After several years of experience on this topic #

Still uncomfortable with Pair Programming? #

Keep pull requests, add pair programming #

Sharing Your Git Patches

Imagine this situation #

What possibilities are there apart from just comments in a PR? #

Git diff to the rescue! #

What now? #

“How to” by steps #

The patch creator: the person who will create the patch #

The patch user: the person who will see the patch #

References #

Extreme Programming Explained

Definition #

Values #

Communication #

Simplicity #

Feedback #

Courage #

Respect #

Principles #

Humanity #

Economics #

Mutual Benefit #

Self-Similarity #

Improvement #

Diversity #

Reflection #

Flow #

Opportunity #

Redundancy #

Failure #

Quality #

Baby Steps #

Accepted Responsibility #

Practices #

Sit Together #

Whole Team #

Informative Workspace #

Energized Work #

Pair Programming #

Stories #

Weekly Cycle #

Ten-Minute Build #

Continuous Integration #

Test-First Programming #

Incremental Design #

Roles #

The Customer #

The Developer #

The Tracker #

The Coach #

What is XP? (in 2 min) #

Tech Talk by kent Beck: XP 20 years later #