What Poetry Workshops Teach Us about Code Review

Talks

Andrew Ek

#software-development

What Poetry Workshops Teach Us about Code Review

by Andrew Ek

The video titled "What Poetry Workshops Teach Us about Code Review" features Andrew Ek speaking at RailsConf 2021. The talk explores how principles from poetry workshops can inform and enhance the process of code review in software development.

Key Points Discussed:

Background of the Speaker: Andrew Ek, a software developer and educator, shares his experience in teaching poetry and creative writing, emphasizing the feedback mechanisms in those environments.
Feedback Mechanisms in Writing: Traditional feedback in educational settings often relies on grades and generalized comments, which can lack actionable insights. Ek contrasts this with more collaborative practices seen in poetry workshops.
Peer Feedback in Workshops: Utilizing peer feedback promotes engagement among students, allowing them to act quickly on received feedback rather than waiting for the instructor's comments, thus creating a more dynamic environment.
Quality of Feedback: Ek discusses the varying quality of peer feedback and the importance of receiving insights at the right level of abstraction. Effective feedback should focus on understanding and emotional impact before diving into technical details.
Iterative Feedback: Recording performances enables students to review their work critically, enhancing the feedback process by allowing performers to observe their impact on the audience.
Code Review Process: Drawing parallels to code review, Ek mentions that, similar to poetry feedback, developers must consider the readability and understandability of code, as it may not be clear to others later.
Team Cohesion and Knowledge Sharing: Implementing a peer review system fosters a sense of shared ownership among team members, promotes questions, and encourages collaborative improvement rather than top-down criticism.
Practical Tips for Code Review:
- Establish a shared language and expectations among team members.
- Prefer smaller changes for more effective reviews.
- Balance feedback in code review to ensure fewer, more impactful comments.
- Regularly audit and reflect on the code review effectiveness.

Conclusions and Takeaways:

Emphasizing the importance of a collaborative feedback culture can improve both code quality and team dynamics.
Code reviews should aim to enhance understanding and readability of code, transforming them from mere defect-checking mechanisms to opportunities for mutual improvement and team engagement.
Pair programming is advocated as an effective method for live feedback and collaboration, complementing traditional review processes.

00:00:05.600 Hi everyone, my name is Andrew Ek. Welcome to my talk, "What I Learned about Code Review from Teaching 8th Grade Poetry." This is a presentation for RailsConf 2021.

00:00:12.360 First, a little about me. I'm the founder and Senior Partner at a company called Arid Software. We use Ruby, Elixir, JavaScript, and a few other technologies to build custom software for clients, primarily internal line of business applications. I'm based here in beautiful Lincoln, Nebraska, USA.

00:00:25.860 You can reach me at [email protected] or on social media under the username @textcatastrophe, but with an 'E' instead of an 'A.' There, I mainly post about my cats and share some funny things my wife says.

00:00:36.240 A bit more about my background: I am a software developer and have been in a senior role for several years. However, my formal training is in education. I taught English, math, and computer science at the middle school, high school, and college levels.

00:00:49.500 For a significant portion of my teaching career, I traveled around the state, teaching poetry, creative writing, and performance to young people. I had a long-term residency focused on spoken word poetry—poetry designed to be read aloud—at a high school here in Lincoln.

00:01:06.720 I was fortunate to work with several students who were eager to write. When I think back on my own writing experience, I mostly wrote independently, submitting essays or short stories for feedback. I'd receive them back with a lot of notes and a grade, but if I'm honest, I primarily focused on the grade.

00:01:19.159 If points were docked, I’d look at what they were for, and that was generally the extent of my engagement with the feedback. Most of it didn't help me grow as a writer; it simply contextualized my grade.

00:01:30.660 In college, it was similar, but we sometimes participated in peer workshops where we would give each other feedback. While I received some excellent, actionable insights, I also got feedback that was completely off-base, leading me to think it might have been better to receive no feedback at all.

00:01:42.660 So, when I became a teacher and initially followed the same feedback approach—justifying grades and providing rubrics—I thought about the experience of the poetry students who were primarily motivated by the desire to produce excellent work rather than to earn grades.

00:01:58.380 Since students would stand up and read their poems aloud, I would take notes and provide feedback. They diligently recorded my comments and then returned to their writing, but there were challenges.

00:02:13.560 First, our after-school sessions were only two hours long twice a week, which meant we didn't have time to get to everyone, much less provide multiple rounds of feedback. Consequently, I might not hear a student's work again for weeks or even months.

00:02:27.240 By that time, they often lost the context for my feedback or forgot what their previous piece of work was about, resulting in lost opportunities for improvement.

00:02:38.380 Researcher Dylan Wiliam notes that the best feedback is that which is acted upon by the receiver. In his literature, he highlights that feedback is only useful if the person receiving it can use it. If they cannot, or choose not to, the feedback is rendered ineffective.

00:02:50.160 Additionally, the primary predictor of feedback usage is whether the recipient trusts the person giving the feedback, which is independent of that person's expertise.

00:03:05.159 In the poetry residency, we found ourselves in a teacher-centric model. Students would read their work, I would provide feedback, and often, nothing would come of it. Although the students improved over time, the effectiveness of our feedback was questionable.

00:03:19.620 We noticed that many students were idle, simply waiting for their turn, which defeated the purpose of an engaging after-school club. So, I spoke with the teacher sponsoring the club about a new approach.

00:03:34.560 We decided to break students into small groups to provide each other feedback. This way, they could quickly act on it and perform again, creating a more dynamic and active environment.

00:03:49.680 While this change was beneficial, we found that the quality of feedback varied greatly. Some comments were useless while others were very insightful. We also encountered instances of feedback being at the wrong level of abstraction.

00:04:03.000 For example, if I wrote an essay with a fundamentally incorrect thesis, correcting my grammar was irrelevant. Instead, I needed to discard the flawed essay and start anew. Similarly, if someone didn’t understand the essence of my writing, providing suggestions on performance wouldn’t be helpful.

00:04:18.540 We began asking students focused questions: What works? What doesn't? The most effective feedback centered on whether the audience member understood the poem. Since they were hearing it for the first time, they couldn’t revisit the text to clarify points.

00:04:36.060 We also explored the development of emotional journeys within the poems. Even if emotions weren't intensely deep, students produced a mix of humorous, sad, and heartbreaking work.

00:04:51.540 Questions we focused on included: What emotions is the audience feeling? What thoughts arise in response? Only after establishing these basics did we move on to concerns about word choice or performance.

00:05:05.460 Through this approach, we noticed overall improvements in the feedback quality and student performance. It helped them contextualize feedback based on the audience's experience.

00:05:19.080 As a performer myself, I often found it challenging to determine whether my audience fully understood my meaning. Increasing clarity during performances was paramount.

00:05:32.460 We transitioned to recording performances with smartphones so students could review them later. They would provide feedback on their delivery and identify which gestures were effective or distracting.

00:05:50.220 This experience allowed poets to see themselves through the audience's eyes. They could articulate what worked and what didn’t, enhancing their overall skills.

00:06:07.500 Connecting this to software development, I realized that, as a developer, I am often clear about the problem I'm solving. However, when I, or someone else revisits the code after some time, the intent may not be as clear.

00:06:22.680 We can glean insights through comments and tests, but often developers focus excessively on writing code instead of contemplating the readability of that code.

00:06:37.320 Returning to my poetry students, we often got caught in a traditional feedback model where only a few students were able to present their work, leading to long feedback loops.

00:06:51.720 The delayed feedback adversely affected the writing process; students might lose sight, both of the context for their work and their motivations.

00:07:05.400 Under these new dynamics, we achieved more synchronous feedback cycles. Students could engage with each other in real-time, leading to more immediate improvements and growth.

00:07:21.540 In moments when students were particularly stuck, I could step in and provide assistance, but they were largely capable of elevating their own work through peer collaboration.

00:07:36.840 I began reflecting on how these principles could translate to code review. In my first developer job, time delays in code reviews often caused me to forget important details about my submissions.

00:07:52.140 Sometimes, by the time feedback came, the codebase would have changed so much that merging was impractical, resulting in decreased quality of work.

00:08:06.960 At my next job, where we worked within PCI regulations, we implemented strict code review policies, ensuring every change was signed off by at least one other developer.

00:08:22.740 In sensitive areas related to encryption or security, we required even more rigorous oversight to address vulnerabilities effectively.

00:08:37.139 Initially, our team lead managed these approvals, but he was extremely busy, leading to delays. We shifted towards a more democratic peer review system to enhance efficiency.

00:08:52.560 Throughout our evolution, we transformed from simply approving changes to engaging in dialogues about enhancing code quality and structure.

00:09:06.720 Conversations evolved from "This is good" or "This needs work" to asking questions like, "Is there a better name for this variable?" This collaborative atmosphere encouraged shared ownership of the code.

00:09:21.600 Initially, our focus was on catching defects and vulnerabilities, reflecting safety concerns. Over time, we embraced a more editorial approach, striving to create the best version of our work.

00:09:34.620 Our goal was for team members to understand the codebase thoroughly. We aimed to create code that was readable and made sense—much like poetry tells a story.

00:09:48.480 In our environment with 17 different microservices and six team members, keeping an accurate mental model of the codebase was challenging.

00:10:02.520 As developers, our understanding would diverge over time, requiring consistent review and dialogue to align our perceptions of the code.

00:10:15.300 This shared understanding allowed us to uplift our more junior engineers by inviting them to review code and share their perspectives.

00:10:28.740 This collaborative dynamic fostered rapid growth among team members, countering potential isolation caused by hierarchical structures.

00:10:43.740 By embracing shared accountability in the development process, we cultivated an environment where everyone felt empowered to contribute.

00:10:57.000 As I progressed in my career, a major takeaway has been the importance of pairing programming. It's essentially live code review, enhancing collaboration from the outset.

00:11:11.040 However, I recognize that 100% pairing isn’t feasible in many organizations, including my own, where we typically do it 40 to 50% of the time.

00:11:23.100 Despite this limitation, code reviews still serve as a vital tool for maintaining quality while facilitating collaboration among developers.

00:11:35.160 This leads to a healthy culture where developers feel responsible for their contributions while respecting the input of their peers.

00:11:49.320 In closing, I have several takeaways. The first involves establishing shared language and expectations among team members.

00:12:01.440 In my previous work, we established a clear vocabulary for services and functions, promoting efficient communication. Similarly, my poetry students benefited from a shared language relating to performance.

00:12:14.160 The next takeaway is the importance of opting for smaller, more manageable changes. Research indicates that the likelihood of catching defects diminishes as changes exceed roughly 200 lines of code.

00:12:27.120 Smaller changes allow developers to focus and respond in-depth as opposed to overwhelming them with a large volume of alterations to review.

00:12:41.760 Even when challenges arise—whether from management's perspectives on code review efficiency or developers' resistance to change—it's crucial to facilitate conversations and discussions.

00:12:55.560 Encouraging dialogues opens the door to understanding and fosters a collaborative environment where shared ownership and accountability thrive.

00:13:09.720 Ironically, having fewer comments in code reviews is often more beneficial. Having less frequent but impactful feedback allows developers to focus on core issues.

00:13:24.360 Initiatives like categorizing comments into significant, moderate, or minor issues help prioritize feedback, making the review process smoother.

00:13:39.000 Also, conducting regular audits of the code review process can shine light on what works and what doesn't—allowing teams to adapt effectively.

00:13:52.860 Reflecting on code reviews and seeking to improve the process is vital for sustaining their effectiveness and ensuring growth within teams.

00:14:06.180 Therefore, if you're not currently using code reviews as a means of sharing knowledge and promoting code quality, it may be worth considering.

00:14:17.740 If you are utilizing code reviews, think deeply about how you can improve and evolve this process to foster collaboration.

00:14:32.580 Thank you for joining me! I'm Andrew Ek, and I look forward to discussing these ideas further during the Q&A session.

RailsConf 2021