00:00:00
Ready for takeoff.
00:00:16
Good morning! I hope you all are having a great RubyConf. Are you guys having a good time?
00:00:21
Yeah.
00:00:24
It's been a great conference for me as well. My name is Kelly Ryan, and I'm here to talk about working together.
00:00:31
I transitioned from teaching in 2020 after doing a self-guided boot camp for about a year. I'm currently a junior developer at Power Home Remodeling, which is located near Philly. We install windows, roofs, and doors. I work on their ERP software.
00:00:38
Initially, I was hired as an engineer on the UX team, but now I do both backend and frontend feature work, working in Ruby and JavaScript.
00:00:44
Like many of you, I’m a career changer. I taught Latin and Greek for 13 years to high schoolers, ages 14 to 18, in a couple of different schools. I have an MA in Latin.
00:01:02
Because of my long career in education and extensive experience working with about a thousand teenagers and their parents, I have a unique passion and perspective on how people should work together to maximize learning and potential.
00:01:09
I don't have much social media presence, but my email and LinkedIn are above.
00:01:14
That picture is of me at yourVeteri, which is a large tomb complex in Italy. It looks like it should be where the hobbits live. It was amazing.
00:01:24
I decided to give this presentation for a few reasons. First, I'm really excited about learning and have a lot of experience helping people learn. The ubiquity of the pairing experience is significant. How many people here pair on a daily or weekly basis at their job?
00:01:38
Yeah.
00:01:40
And how many people have struggled at some point with pairing?
00:01:43
Yeah.
00:01:45
And how many people have had specific training in best pairing practices?
00:01:47
Oh, good! There are some people. That’s excellent.
00:01:50
There are many difficult things about pairing, especially if you're less experienced like I am. Maybe you've had trouble getting someone to pair with you, or perhaps during an interaction, you find yourself at a loss as to how to proceed.
00:01:56
At my workplace, we have many less experienced developers because we have an educational system where we take people from throughout the business and train them in-house. This means that many developers have less understanding of what is expected from junior developers and less experience in the world of tech altogether.
00:02:06
They need to pair daily and often for much of their day, so a clear idea of expectations is essential for them to be successful. The second reasoning is that it's worth the investment. The prevalence of the experience alone makes it worth it, but we all need help teaching and learning.
00:02:21
Our profession is about learning new skills, and according to a study on employer-provided training, 70% of professional learning can be done informally. For us, informal learning often means pairing.
00:02:34
Thus, good pairing practices are essential for moving our employees and our companies forward. Deliberate thought and training about best pairing practices are worth the investment.
00:02:44
Despite a few of you receiving specific training in pairing or collaboration, there is still a lack of sufficient training available. Lastly, I believe that small changes can lead to significant gains.
00:02:50
Practical advice can lead to behavioral changes that will make a real difference in people's experiences with pairing. This presentation is not here to provide a template for how you should be more empathetic or patient. It’s more about what you can do to enhance pairing experiences, whether you’re in a senior or junior developer role.
00:03:04
Additionally, the talk is structured so you can take away one or two points that you think will be most useful. There’s no need for you to implement all the suggestions I make, so please don’t feel overwhelmed by the number of tips.
00:03:17
Each point should stand on its own as valuable and, hopefully, easy to implement. Since this is a lecture, I’m going to be as direct as possible. There won’t be any fluff, just a decent lesson plan that conveys and reviews the information.
00:03:25
The talk will be divided into three parts: before, during, and after pairing. Before pairing, particularly, I think there are some ways you can set yourself up for success.
00:03:31
This section will focus on your role as a less experienced developer.
00:03:34
As I mentioned, during pairing, there are behaviors that can improve the experience for all developers. This section will focus more on you as a more experienced developer.
00:03:39
After pairing, we will look at things you can do to solidify your learning and build relationships. I will use 'junior' and 'senior' in a broader sense.
00:03:45
A junior developer is someone with less experience, which could pertain to years of experience, knowledge, domain ideas, or specific technologies. This means that, at times, a junior can perform the duties of a senior developer.
00:03:55
Hopefully, we are all a potential audience for this talk because we all play different roles at times. So, to summarize, a junior developer has less experience, while a senior developer has more.
00:04:06
As I move through this talk, I will shift my focus from junior to senior and back again, because we all play these roles.
00:04:11
When I first started coding, I expected everyone to be smarter and more intuitive than me, which was mostly true. However, I believed it meant I could provide very little information and that they would be able to solve my problem.
00:04:24
You might have had similar experiences when reaching out to less experienced peers. I would ping someone with specific questions like, 'Hey, do you have a minute? I have a question about users,' and often wouldn't get a response.
00:04:34
It was frustrating because I knew my question was simple and that they could answer it, but no one was responding. This was, of course, my fault.
00:04:41
I needed to frame my questions to provide potential helpers, i.e., more experienced developers, a clear understanding of my problem and whether they had the ability and time to help.
00:04:53
The point is that to set yourself up for a productive pairing session, you need to provide information to the person you are pairing with. This helps them help you in the best possible way.
00:05:02
By doing this, you're not only helping yourself but also your potential partner.
00:05:10
I would suggest being upfront about your expectations for the pairing session. There can be various reasons why you might want to pair. Oftentimes, when I was just starting and felt lost, I would create a plan for my pull request and then ask my lead developer to meet with me to review my intentions.
00:05:29
Before each pairing session, I would communicate what I wanted to do, which would help my lead understand the general parameters of our session. This way, he could estimate how long it would take and what was expected from him.
00:05:39
Potential reasons for pairing include debugging, general interest in the pull request for background knowledge, or just general assistance when blocked.
00:05:49
To gear towards getting help, I want to discuss ways to ask for help and structure your questions to provide background information to the more experienced developer so that you can have a productive session.
00:06:00
I want to take you through an example of a well-structured question and break it apart so that in the future you'll be better prepared to get help quickly and accurately.
00:06:09
If you have any takeaways from this talk, I believe this will be the most beneficial, as it helps you learn while also allowing others to see you as someone who asks good questions.
00:06:19
Some poorly structured questions include: 'I have a question, can you help?' or 'My user title PR isn't working and I'm stuck. Do you have time?' These are insufficiently precise, as they lead to more questions.
00:06:32
The fundamental questions need to be answered: What is the problem? What is the desired outcome or expected behavior?
00:06:39
My first tip would be to summarize your problem and write a brief version of what you want to happen versus what is actually happening.
00:06:50
For example, 'I need help on a PR that should change the default compensation amount for a user title. The compensation value is not changing.' This format gives the other developer clarity on the problem and the desired outcome.
00:07:06
At this point, you've given the more experienced developer a clear idea of the goal of your PR. However, providing context is also crucial.
00:07:18
My next suggestion is to expand on your issue with accessible context, code references, URLs, etc.
00:07:28
For example: 'I’ve tried changing the compensation amount and checked the career change page, but it’s not updating. I’ve pushed what I’ve done so far. Here's the story card.' Providing context gives the more experienced developer a broader view of your problem.
00:07:45
Context helps them see what you have done so far and what the goals of the PR are. If the story is clear, the goals can be gone over in more detail.
00:07:54
All of these questions become less necessary for simpler issues but are absolutely essential for larger PRs.
00:08:02
Pushing a PR that only changes one file might not be super useful, but if you're making larger changes, pushing your work even if it’s less than perfect can ease the process.
00:08:17
Senior developers appreciate the ability to toggle between pieces of your code and compare changes in a familiar format.
00:08:28
Lastly, it's sometimes helpful to supply outside information. This is particularly good for letting the experienced developer know the urgency of the problem.
00:08:38
For example, if a support ticket has been open for two weeks, it might be important to address it quickly.
00:08:47
In considering the structure of your questions, you might ask yourself if your question summarizes, contextualizes, and supplies outside information.
00:08:57
Once you have someone who agrees to help, the next suggestion is to look at your level of preparation. Preparation saves time and shows respect for others' time and effort, which encourages them to be willing to help again.
00:09:12
We’ve all had experiences where we started pairing with someone who wasn’t prepared. It’s best to prepare for an interaction as much as possible.
00:09:22
A simple plan could involve reading the story card together, reviewing the problem and expected behavior, showing the current behavior, and then looking at the relevant code.
00:09:33
This simple plan can help your partner understand the background and current situation. It doesn’t need to be complex; it just helps organize your approach.
00:09:41
My next point involves easing pain points during testing and reviewing. For example, when I work on an HR component, I often need to be logged in as two users in different states in two separate browsers.
00:09:54
Setting this up can take time and organization, so I should prepare to have it ready before meeting my partner, making the experience smoother for both parties.
00:10:06
Ensuring that all work is readily available is also crucial. Providing links in relevant files is essential, especially for more complex PRs.
00:10:15
Pushing your work to GitHub is extremely helpful as it allows developers to see your code and understand the changes you’ve made.
00:10:27
Providing links to the relevant code and marking correct functions will help make pairing go more smoothly.
00:10:38
So, some questions to consider are: Have I created a plan? Have I prepared my environment? Have I provided good context?
00:10:49
Once developers are set up and pairing, there are ways to communicate effectively which have been proven to improve performance, learning, and collaboration.
00:10:58
This section focuses on you as a more experienced developer. Again, more experienced staff is someone who understands more about a domain, technology, or idea.
00:11:08
The first suggestion is to teach and pair by asking questions. Question asking isn’t just good for junior developers; it’s also vital for senior developers.
00:11:20
It’s generally better to ask questions than to tell someone the answer. There are times when solutions need immediate attention, but on average, asking is best.
00:11:32
Asking questions increases engagement, encouraging the less experienced developer to share their knowledge of what they do and don't know.
00:11:42
Questions reveal gaps in knowledge. When developers ask good questions, they're addressing these gaps, allowing progress.
00:11:53
Even simple questions can clarify unclear points or reveal assumptions that may go unrecognized otherwise.
00:12:01
Next, creating a partnership is important. Rather than taking a top-down approach, engaging collaboratively will build both personal and professional relationships.
00:12:17
It’s easy to implement suggestions. For example, using first-person plural language like 'we' and conditional language can enhance collaboration.
00:12:30
Summarizing points made by your partner can also ensure clarity. You could rephrase their last statement and check for understanding.
00:12:41
If your partner’s ideas are unclear, encourage them to expand by asking for clarification, which can expose any wrong assumptions or knowledge gaps.
00:12:52
Moreover, suggesting rather than telling can improve your partnership. Gentle suggestions often receive better responses than direct orders.
00:13:05
In summary, the more you can share knowledge and direction—presenting it as provisional, revisable, and conditional—the better your partnership will be.
00:13:19
During pairing, ask yourself: Am I asking questions? Am I using conditional language? Am I summarizing what the other person is saying? Am I suggesting rather than telling?
00:13:32
After pairing, the first suggestion would be to reflect on what you’ve learned. Knowledge and skills are developed through direct experience and reflection.
00:13:44
I recommend telling your partner at the end of each pairing session at least one thing you learned from the interaction.
00:13:57
This reinforces your learning, as putting your thoughts into words makes them more memorable and relevant.
00:14:02
It doesn't have to be profound; it could be a new tool, method, way of thinking about a problem, or even a new vocabulary word. Every piece of feedback counts.
00:14:16
This not only shows your partner that you're engaged and listening but also makes them feel impactful.
00:14:27
Thanking someone who helped you is the right thing to do. Expressing gratitude with specific feedback solidifies the appreciation for the help received.
00:14:41
Sincere gratitude reflects your understanding of someone's work and time value and helps build stronger relationships. It’s a simple yet powerful way to give back.
00:14:55
In summary, have I provided specific positive feedback, and have I thanked my partner?
00:15:06
Next, I will briefly review the major takeaways from this talk. I have emphasized the essential nature of pairing. While many of us do it daily, few have received specific training in teaching or learning.
00:15:19
Small changes in our behavior can improve our learning and foster better personal and professional relationships.
00:15:30
Before pairing, I emphasized the importance of creating well-structured and well-documented questions. Doing this often allows you to answer your questions yourself.
00:15:42
Additionally, good pre-session preparation promotes quicker and better pairing sessions overall.
00:15:52
During pairing, I noted the benefits of using collaborative language, focusing on 'we' and 'us' while using conditional, revisable language. It’s also important to thoroughly explain the tools being used.
00:16:05
Lastly, I encourage you to reflect on learning by giving your partner feedback on what you’ve learned, as reflection on experience nurtures deeper learning.
00:16:17
Gratitude for the help and patience you’ve received fosters a positive, collaborative environment.
00:16:25
Thank you for your attention and for attending my talk. I challenge you to take one or two things from this talk and incorporate them into your next pairing experience.
00:16:41
I hope it helps you, and I wish you a wonderful time at RubyConf, filled with learning and a delightful holiday season.
00:16:53
Thanks to Valerie, Willard, Garrett, Airwood, and Gabrielle Ferreira for their support in this talk and for listening to me practice multiple times.
