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.
