My new book Practical Remote Pair Programming is available for pre-order. Learn how to be a better (remote) pair programmer: How to use pair programming efficiently Techniques and styles for pair programming Pair-programming with distributed…
Tests should tell a story, and not be some complicated array of technical terms that almost nobody understands. This is our focus during the next #RemotePairProgramming session with Bastien David.
We call our tests paragraphs and our test class a story. Because we feel in a flow, we could go on writing tests that tell a story for a few hours and still discover what it an easy to understand story by the end user: the programmer.
Emily Bache and I have a remote pair programming session. The focus in working on the Approval Tests with Lift Kata that Emily created. We use Approval Tests to check each step in the progress of the implementation. Fast feedback and continuous communication are a good recipe for a quality pairing session.
About approval tests with lift kata. The code already has a starting point which is very useful for getting to work fast. There is a printer that can print the lift status in ASCII art format. We start from this minimal start-up and add approval tests in a TDD approach with small steps and incremental thinking. We add production code step by step as we add the tests.
A short excerpt from the full video where Adi https://twitter.com/adibolb and Stefan https://www.linkedin.com/in/stefankanev/?originalSubdomain=bg work on an iOS small app that interacts with GitHub and uses GraphQL https://graphql.org/learn/ Check the code here https://github.com/skanev/pull-request-explorer
This is a remote pair programming codecast with Wassel Alazhar on an interesting problem called Good Friends.
After implementing a bit of the problem, we discuss about what we have done. We observe a lot of duplication and we debrief.
Before getting into remote pair programming, let’s see what pair programming is.
Pair programming is when two programmers write code on the same requirements / problem. There are two roles: driver and navigator. The driver has the keyboard and writes the code. The driver focuses on short term implementation. The navigator looks at long term strategic decisions and double checks the driver’s implementation details.
In many cases pair programming is a lot more efficient, the code being clearer, nicer and with fewer defects. Nevertheless pair programming can be tiring, especially when doing it for the first time.
As a rule of thumb, you don’t need to pair the whole day, because it’s tiring, difficult and sometimes inefficient. Choose more complex, difficult or areas less known when doing pair programming.
Not everyone is at the office all the time. Sometimes we work from home, or we are in another office. So it’s a good idea to use this useful tool of pair programming also when you are not next to the other programmer. We call that remote pair programming.
This is a remote pair programming codecast with Wassel Alazhar on an interesting problem called Good Friends.
We pick a problem not at all known by me and we figure it out with #TDD on first view. Interesting to see how you need to analyze before rushing to write tests
This is a remote pair programming codecast with Amitai Schleier on Legacy Code, the Trivia kata.
We are refactoring some legacy code in Perl and VI. Adi doesn’t know almost anything about Perl, but he knows the problem and the approach. Amitai knows Perl so he is primarily driving, while Adi is navigating.
This is a remote pair programming codecast with Ferdinando Santacroce on the topic of Elastic Pair Programming.
When you are in a team when people know each other well and they are at the same level, having the role of driver and navigator might not be the best option because the navigator gets bored about the role. In this situation I find both the developers to share keyboard and mice so both can edit the code at anytime, to figure the solution of the problem. So we both can change the code at anytime.
After episode 7 when we added the minimum amount of tests needed to start refactoring legacy code, you can see how we gradually improve the code in small steps.
During episode 7 of #RemotePairProgramming series Tom Oram is pairing with me on some legacy code. We apply legacy code techniques to improve testability and clarify the code. After that the next episode will be about improving the legacy code, but with a safety net.
Episode 6 of this #RemotePairProgramming series is about Evolutionary Design with Selection Pressure. My coding pairing partner this episode is Julian Ghionoiu