PLO 9: Developing Respectful Reciprocal Relationships Through Peer Technical Support
- Mingzhe Xue
- 2 days ago
- 6 min read

Among the MLIS Program Learning Outcomes, PLO 9: develop respectful, reciprocal relationships with professional and community groups, has become one of the most important to my professional development. This outcome matters to me because it shifted how I understand the value of technical knowledge in library and information work. Earlier in my program, I often thought of technical ability primarily as an individual strength: the ability to solve problems independently, learn unfamiliar systems quickly, and build workflows that function effectively. Over time, however, I came to understand that in information settings, technical skill only becomes professionally meaningful when it can be translated into forms that others can access, trust, and use. For my future interests in research support, digital scholarship, and technology-rich information environments, that realization has been fundamental. A strong information professional does not only know how to use tools, but they also know how to reduce barriers, support learning, and build relationships through knowledge-sharing.
My growth in this area became clearest during my work as an iSchool Peer Tech Advisor. In that role, I supported students who were navigating data analysis workflows, Python troubleshooting, and a range of technical problems across their coursework and projects. I also designed and delivered workshops on topics including HTML, D3.js, and P5.js/JavaScript, while preparing workshop materials and tutorial content to help students build practical technical confidence. Taken together, these experiences made me rethink what peer support actually means. At first, I saw the role as one of troubleshooting: identifying what was broken, explaining what to do, and moving on. Over time, I realized that the deeper work was relational. Students were not only dealing with code errors or unfamiliar software; they were often dealing with uncertainty, intimidation, and the feeling that technical work was somehow beyond them. Supporting them well required more than expertise. It required patience, attentiveness, and the ability to make technical learning feel possible.
Before becoming a Peer Tech Advisor, I already had a relatively strong technical background. That background was useful, but it also created a blind spot. When one is familiar with technical systems, it becomes easy to underestimate how fragmented or intimidating they appear to beginners. Many students did not know whether their problem was conceptual, environmental, or procedural. A single obstacle could involve software installation, file paths, browser behavior, code syntax, and assignment interpretation all at once. More importantly, students sometimes hesitated to ask questions because they worried their confusion would seem too basic. Through this role, I began to understand respectful relationship-building as the practice of meeting people where they are rather than where I assume they should be. Reciprocity, in turn, meant recognizing that support was not one-directional: every question, hesitation, or misunderstanding taught me something about how technical instruction should be designed.
One of the clearest artifacts demonstrating this growth is my HTML workshop. Rather than teaching HTML as an abstract coding topic, I framed it in terms of information work. The workshop explained that HTML matters because many libraries use web-based tools, because HTML underpins digital collections and cataloguing interfaces, and because basic web knowledge helps information professionals communicate more effectively with IT collaborators. That framing now seems especially important to me. It reflects an effort to respect learners as future professionals by connecting technical content to their actual academic and career contexts. Instead of asking students to learn code for its own sake, I tried to answer a more meaningful question: why does this matter for someone in the information field? That approach, I believe, is part of what PLO 9 asks of us. Respectful professional relationships are built when knowledge is offered in ways that acknowledge the learner’s goals, needs, and identity.
The structure of the HTML workshop also reflects how my orientation was changing. The slides moved from introduction and tools setup to core concepts, guided practice, Q&A, and follow-up resources. They emphasized clarity, accessibility, and manageable progression. For example, explaining semantic structure, headings, alt text, and basic markup through concrete examples. Looking back, the most important thing about this workshop was not that it covered foundational tags or browser behavior. It was that it attempted to create a learning environment in which technical knowledge felt organized and understandable. I was beginning to understand that community support often depends on reducing the emotional friction of learning, not only the intellectual difficulty.
A second major artifact is my D3.js workshop, which required an even more intentional form of scaffolding. D3 is conceptually demanding because it asks learners to think about data, the DOM, scales, SVG, and visual encoding simultaneously. In the workshop, I structured the material so that students would first encounter the high-level purpose of D3, then learn selection and binding, scales and axes, and finally apply those ideas to a real dataset through a guided exercise. The slides used bird observation records as a hands-on example and broke the process into a sequence: load the CSV, prepare the data, set up the SVG and scales, draw the chart, and interpret the result. This artifact is important because it shows that my role was not simply to demonstrate a sophisticated library. It was to build a path through complexity. In retrospect, this is where I most clearly learned that support is not the same as providing answers. Often, support means designing conditions in which others can arrive at understanding for themselves.
My P5.js / JavaScript workshop adds another dimension to this development. In those slides, P5.js is introduced as a free, beginner-friendly library for creative coding, one that makes programming more accessible through immediate visual feedback and playful experimentation. That framing reflected a growing sensitivity to the emotional side of technical learning. Many students are willing to try programming when the entry point feels exploratory rather than punitive. By teaching JavaScript fundamentals through visual and interactive examples, I was trying to create a different relationship to technical knowledge, one based on curiosity rather than fear. This, too, relates directly to PLO 9. Reciprocal relationships are not built only through formal collaboration; they are also built when one person actively reshapes knowledge so that it becomes more welcoming to others.
These artifacts also reveal a broader narrative of development across my program. Earlier on, I would have defined technical competence mainly in terms of precision and independence. Through the Peer Tech Advisor role, I came to define it differently: as the ability to translate, scaffold, and respond. I learned that successful support depends on recognizing variation in learner background, pacing explanations appropriately, and leaving room for uncertainty. The repeated inclusion of Q&A, wrap-up, next steps, and resource slides across my workshops reflects this shift. These components were not just routine presentation features. They signaled that learning was ongoing, that questions were legitimate, and that support did not end the moment a session concluded.
This work was not without challenges. One of the most persistent difficulties was the wide range of student backgrounds. Some participants had prior coding experience, while others were using a code editor for the first time. Designing workshops that were neither too overwhelming for beginners nor too slow for more advanced learners required constant adjustment. I also had to confront my own assumptions. There were moments when I realized I had explained something from the perspective of someone already familiar with the environment rather than from the perspective of someone encountering it for the first time. Those moments were humbling, but they were also some of the most important learning experiences I had. They pushed me away from a model of teaching rooted only in competence and toward one rooted in empathy and accessibility.
At the same time, these challenges also brought meaningful successes. I became more deliberate about sequencing content, designing hands-on exercises, and creating support materials that reduced confusion before it could accumulate. I also became more aware that relationship-building in technical environments often happens through seemingly small choices: the tone of explanation, the order of examples, whether questions are welcomed, whether relevance is clearly established, and whether learners leave with resources that allow them to continue independently. These are not peripheral considerations. They are part of what makes technical support feel respectful rather than transactional.
Looking ahead, I see this experience as directly connected to my future professional direction. In academic libraries, research support, and digital scholarship environments, much of the most valuable work takes place through consultation, instruction, collaborative problem-solving, and user-centered guidance. My time as a Peer Tech Advisor showed me that technical support can be a deeply relational form of information work. It can build confidence, reduce exclusion, and create learning cultures in which people feel more capable of participating. Going forward, I want to continue developing this capacity by improving my ability to design differentiated instruction, produce stronger asynchronous learning materials, and support a wider range of users beyond peer settings alone.
Overall, my development in PLO 9 has taught me that respectful reciprocal relationships are not secondary to professional practice; they are one of the conditions that make good professional practice possible. Through peer technical support, workshop design, and ongoing student assistance, I learned that technical knowledge becomes most meaningful when it is shared in ways that are attentive, enabling, and responsive. That is the understanding of professional relationship-building I will carry with me into the next stage of my career. Copyright and permissions note
This reflection and the workshop materials referenced in it, including the HTML, D3.js, and P5.js/JavaScript workshop slides, were created solely by Mingzhe Xue for educational and portfolio purposes. Copyright in these materials belongs to the author unless otherwise specified. Any third-party images, screenshots, platform names, logos, or linked learning resources referenced in the workshop materials remain the property of their original rights holders and are included only in ways consistent with citation, educational fair dealing, or permission requirements.


Comments