Lulu's World

July 28, 2026 — by Lulu Liu in Uncategorized

Image via Publication Coach

When I first enrolled in the UC Davis UWP 101V course, I assumed writing in Computer Science only meant comments scattered throughout my code explaining what a function does, and possibly a short paragraph or bullet points at the top of a file with my name and the date. I thought that formal writing was something I did for English and humanities classes, not something that had a place in the CS or Statistics disciplines. What I learned in this course changed my view. I discovered through three major projects, eight blog posts, and revisits of my past CS writing that writing in technical fields offers far more than a simple box to check after the work is completed.

The Blogs on Learning to Translate

The most consistent thread of writings I have completed through this course was the blog. Over the past seven blogs, I built what something that became a public-facing investigation into the topic of algorithmic bias and its intersections with AI, facial recognition, mathematical fairness theory, and music. Writing the blogs and researching related topics taught me aspects of my disciplines that simply coding or doing the mathematical works would never have done. My majors are full of precise and tedious knowledge that tends to stay within the discipline, and turning that knowledge into something a non-technical reader could comprehend and engage with without dumbing it down turned out to be more interesting than I expected. I am grateful that I got to discover this opportunity to share what I care about with the world through my own voice.

My second blog post on algorithmic bias introduced Joy Buolamwini’s Gender Shades research and Safiya Umoja Noble’s Algorithms of Oppression to readers who had likely never encountered either. My third blog post on the Fairness Impossibility Theorem had to explain a mathematical proof, the idea that no algorithm can satisfy all definitions of fairness, in plain language without eradicating what makes it meaningful. My sixth blog post on AI music connected that conversation to something more prevalent in recent days: We Are Charlie Kirk internet domination, GG EZ dance challenge that went viral, and the fan communities creating AI voice covers of kpop songs. Every post required me to find the right sources, the right amount of context, and the right conventions while being entertaining enough to score a public blog audience. That is a new skill I did not have before going into this course.

Image via Gender Shades

Screenshot via TikTok

Project 1: Analytic Narrative

My Analytic Narrative was a paper about learning to write a README file for my ECS 33 course. The assignment asked me to identify a piece of disciplinary writing, tell the story of how I learned to write it, and explain the conventions it followed. I chose my Project 1 README from the ECS course because it contained a detailed log of every interaction I had with agentic AI during the project, including what I asked, what it told me, and what I changed as a result. Before this project, I did not even know that READMEs can be considered a writing genre.

The feedback I received praised the sincerity of the reflection section and noted that the writing did a good job tracing my growth throughout the project. One reviewer suggested I could have provided more detailed instruction on how the README should be used by the intended audience. I think this is a fair point, and surely something I can focus on while I revise my paper. I would expand the section to more explicitly address the README’s functions as a public-facing document and what that means for new learners before they write a line on their own.

This project made me realize that the README is far more than a boring document, which is how I used to frame it. I have discovered more about it beyond what I already learned in the ECS course.

Project 2: How-To Guide

My How-To Guide was a beginner’s guide to writing a README file. I formatted the instructions to look like a VS Code coding window inside a Google Doc. The format was a rhetorical choice, and I wanted the guide to feel native to the coding environment. I used a dark background, Courier New font, and color-coded Markdown syntax to present the expected visual experience of actually writing a README in VS Code.

I received encouraging feedback. One reviewer said they did not know anything about READMEs before reading the guide and found it organized and well thought out. A major critique, though, was that the guide could benefit from more specific examples and direct links to READMEs, especially since it is targeted towards beginners. I agree it is true that a beginner might benefit more from a simpler classroom README rather than professional ones, so I plan on making this change when I edit this project.

I was very proud of the creative format I came up with, and it taught me something about genre awareness: that the form of a document itself can be a rhetorical argument. My guide about README files that looks like a README file at first glance is making a claim about its own subject before the reader reads the first line.

Project 3: Style Guide

My Style Guide was a summary of writing conventions in Computer Science and Statistics. I organized them around five features: content and methods, design and visuals, citation and attribution, specialized language, and tone and style. I provided examples from React’s README, NumPy’s source code, and a CDC NCHS Data Brief on Parkinson’s Disease Mortality alongside two background sources on technical writing in CS and STEM fields in general.

The feedback I received pointed out three major issues. First, my style guide was primarily text-based and needed more multimodal elements such as images, tables, or color-coded examples to match the assignment’s requirements and to show the visual communication conventions the guide describes. Missing this was completely on me and how I forgot to add the elements. Secondly, one reviewer caught an inconsistency in my statement: in how I mentioned six features in my intro paragraph but only ended up talking about five. This was also a careless mistake in forgetting to edit the beginning after cutting out one of the features. Lastly, I have not yet completed my references section. I will be finishing that. All these are fixable and specific, which makes my revision plan clear for this assignment. I am glad that my peers were keen enough to point out things I forgot about or did not notice.

This project taught me that writing a style guide forces you to make implicit knowledge explicit. I know many things I mentioned implicitly, such as how a statistical report’s tone would be different from a README’s, which also sounds different from inline comments. But explaining the “why” to my audience required a whole new level of analytical skills I had not applied in completing technical writings before.

What I Now Understand About Writing in My Field and What I Learned About Myself

I hope that my blogs and portfolios could achieve the purpose of giving my readers a new, purposeful point about STEM genres that they have not considered before. There are various types of writing in CS and Statistics. The README, the code comment, the statistical report, the blog post, and the style guide are all distinct genres with distinct audiences and purposes. Knowing how to write one does not imply how to transfer to the others, and a part of professionalism in these fields is composing a repertoire that lets people navigate these genres without starting from scratch.

Another thing that was confirmed is the importance of brevity in technical writing. The Data Brief I analyzed for the Style Guide communicated its key findings through five simple bullet points before a complete paragraph. The README examples define the entire library in one sentence. Code comments I examined explain how a function works within a few words. Too much flashy vocabulary is something technical writing discourages.

Lastly, I learned more about the importance of documentation, especially through looking at professional examples beyond the classroom examples that I mainly encountered. A codebase with no README is inaccessible, a statistical report without describing its methods is unverifiable, and a running code without noting the sources used does not resemble the coder’s skills. Writing is how technical work becomes usable, accountable, and legible.

I came into this course thinking that I was one of those lazy bums who writes only when required to. I am now leaving as someone more interested in writing, and I even considered continuing my blog. The blog pushed me further than any projects did, because it required me to consistently write for a possible group of actual audience who might be interested in what I have to express. I also learned to notice more aspects and details in technical writing. From now on, for my technical writing, I will think of more questions such as who the reader is, what do they need to know, what is the clearest way of communicating, and more. I think learning to ask myself these questions is what this course was about.