Conference: Nov 13-15, 2017
Workshops: Nov 16-17, 2017
Presentation: Further Together: Curated Pairing Culture @Pivotal
Duration
Persona:
- CTO/CIO/Leadership
- General Software
Key Takeaways
- Learn the arguments and counter arguments for realizing a culture that embraces pair programming.
- Hear about techniques to improve the adoption of pair programming practices, including how to address challenges like remote developers.
- Learn about some of the enabling techniques that make pair programming work on distributed teams.
Abstract
The benefits of pair programming are well-known but enabling it is hard. It is clear that incorporating it into the workplace sustainably requires a fundamental shift in culture. After working at 2 startups who implemented different versions of pair programming, I came to Pivotal Labs with my own stories and preconceived notions. Pivotal Lab's engineers (and sometimes designers and product managers) pair program 8hours/day every workday and help enable other companies to practice it with us. It seems impossible but after spending a year fully immersed, the trends in having a sustainable pair programming culture have started to surface. Hear from someone who is a newfound believer in pair programming on the structure Pivotal Labs has put in place to enable it, war stories, and lessons learned.
Interview
Neha: The other motivation is to share what we negotiate for on the behalf of our client to give them the experience they want. So if they’re like, "we want to try to pair programming" or "we want to try test driven development" or "we want to see what extreme programming looks like", we say, "yes, we can do that with you but to be successful, we need these things from you". So what are we negotiating on behalf of our client to have a successful project, and what do we look out for and what are our red flags?
Part of what makes us successful is that we integrate our clients into our group, so it’s never "us versus them". It’s more "you are coming onto our team" and we want this to be successful for your happiness and ours (because making you successful makes us happy too!). So that’s one piece.
And then the other piece is kind of a little bit of a gotcha, which is: you can’t curate pair programming out of nowhere.
There is a lot of supporting structure around it. At Pivotal Labs we have maybe five or six components that work together in order to enable a pairing culture and so, I’ve sliced it in many different ways. I’ve taken the approach of it being like these puzzle pieces that fit together. What are those puzzle pieces and what does that look like on a day-to-day basis? And I’ve also examined it on three levels: a daily level, a weekly level and a project duration level. What does feedback look like for those three levels and how is that baked into our general practices?
Neha: Yes. And I have in the past talked about what it feels like when you have it and what it feels like when you don’t have it. This changes the dialogue to: “I am in this situation where things are not going well and maybe making this change will give me the positive result that I am looking for”. This talk should help people project what are their future roadblocks and what are the tools to address it.
Neha: Levelwise, it is across the board. It is a different role for every company; so it could either be a manager or an architect or a tech lead or just someone who can influence change.
Ultimately, I’m speaking to the person who is able to introduce and manage a project because for pair programming, the way I have seen it the most successful is that you have an isolated project and you are able to have those people working together for a prolonged period of time without being constantly taken away for other things.
Neha: That’s a great question. A lot of it is enabled by software: we use Screenhero, a tool that allows you to share your screen but also to have two independent mouse cursors that have your name on it. So you can see when I am moving the mouse and you can see it is attributed to me, and then if you are trying to move, I can see that you are trying to do that and give way so that you can work. And honestly, it’s just good tech, good audio.
After working a year for Pivotal Labs, I don’t feel that virtual pairing is as significantly different from pairing on a day-to-day basis. This is partly because of the way our pairing stations are set up: we have\ two screens side-by-side and we’re both facing forward. We aren’t facing each other unless we are having a discussion. And so I don’t usually needa visual queue. I am usually listening to the tone of voice and I am asking for a lot of feedback, like "how are you feeling?", "Do you want to drive?", "Do you want to write this test and then I will pass the test?" Or vice versa. One piece that suffers is getting to know someone for the first time and picking up on whether someone is distracted or getting tired. We prefer to onboard someone for 3 months to transfer context and let them get the hang of things before we release them but even having them the first few weeks help a lot.
Neha: I do. In the last two talks that I did, I have had a screen dedicated to some of the useful technology that we use, so Screenhero comes up. There is one for the keys that you type and they will actually show on the bottom right corner. So if you use shortcuts, you will see that people are actually pressing shortcuts instead of some magic where your key jumps or your cursor jumps.
Neha: One of my favorite things is to have a pairing retro when they start pair programming for the first time. Your biggest worry is going to be that anxiety around having to work with someone on the day-to-day level and having no idea what they are thinking because we all express our emotions in different ways. Confusion and frustration are expressed differently for each person. Happiness and contentment might be silence or it could be outwardly expressed, right?
So when people try it for the first time, the first week or the first few days, I encourage them to have a pairing retro. What went well? What didn’t go well? What was okay? What are some outstanding questions? And then what comes out of it are action items: how do I make this better next time? And if you do that on a daily level, it could be as formal as having a pairing retro the last five minutes of your day or it could be a little bit less formal, such as asking "hey, how do you think that went? How are you feeling?"
It’s all about trying to hear what their concerns were, whether that matched up to reality, and getting a sense for what their ideal pace is. And you can ask them in the moment, but it’s a lot to process and provide feedback on; hindsight is 20/20. It is much easier to ask them at the end of the day or maybe the next morning.
Similar Talks
.
Tracks
Monday Nov 7
-
Architectures You've Always Wondered About
You know the names. Now learn lessons from their architectures
-
Distributed Systems War Stories
“A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.” - Lamport.
-
Containers Everywhere
State of the art in Container deployment, management, scheduling
-
Art of Relevancy and Recommendations
Lessons on the adoption of practical, real-world machine learning practices. AI & Deep learning explored.
-
Next Generation Web Standards, Frameworks, and Techniques
JavaScript, HTML5, WASM, and more... innovations targetting the browser
-
Optimize You
Keeping life in balance is a challenge. Learn lifehacks, tips, & techniques for success.
Tuesday Nov 8
-
Next Generation Microservices
What will microservices look like in 3 years? What if we could start over?
-
Java: Are You Ready for This?
Real world lessons & prepping for JDK9. Reactive code in Java today, Performance/Optimization, Where Unsafe is heading, & JVM compile interface.
-
Big Data Meets the Cloud
Overviews and lessons learned from companies that have implemented their Big Data use-cases in the Cloud
-
Evolving DevOps
Lessons/stories on optimizing the deployment pipeline
-
Software Engineering Softskills
Great engineers do more than code. Learn their secrets and level up.
-
Modern CS in the Real World
Applied, practical, & real-world dive into industry adoption of modern CS ideas
Wednesday Nov 9
-
Architecting for Failure
Your system will fail. Take control before it takes you with it.
-
Stream Processing
Stream Processing, Near-Real Time Processing
-
Bare Metal Performance
Native languages, kernel bypass, tooling - make the most of your hardware
-
Culture as a Differentiator
The why and how for building successful engineering cultures
-
//TODO: Security <-- fix this
Building security from the start. Stories, lessons, and innovations advancing the field of software security.
-
UX Reimagined
Bots, virtual reality, voice, and new thought processes around design. The track explores the current art of the possible in UX and lessons from early adoption.
Conference for Professional Software Developers
