OSD600 - Lab1

This is Lab1

1. How did you go about doing your code reviews? Do you prefer an async or sync approach? Why?

• I worked with Anh Chien Vu for lab 1. We used both async and sync approach. We talked in Slack direct message, and I also left my reviews of his code in Github Issues. I think I need both approaches. When I just want to ask him some simple questions, I prefer sync approach. When I want to leave reviews or something more organized tasks or documents, I prefer async(github issues) because it would be more efficient for him to understand(since I can make it more organized and easy to read using markdown).

2. What was it like testing and reviewing someone else's code? Did you run into any problems? Did anything surprise you?

• I tried to test his code and reviewed his project. However, I coudn't run the tool in a way that he described it in README.md, and I will do further tests and reviews after he fixs his code(It was Sep 11, now it is fixed, and I tested it again). I read his code, and it was very difficult for me since he used the libraries that I have never used or seen before, and reading others' code is always tough; as I need to study, google and use ChatGPT to understand his code and the libraries. Moreover, everybody has their own style in coding. In a sense, it's like a hand-writting. Somebody's code is easy to read for me, another's code is hard to read for me (I am not saying whether one is good or the other is bad).

• One thing that was surprising to me was, it looks like he was having the same problem that I am currently having, I think he was trying to make his code be run without node (for me, without python3). I guess he enabled it in his local machine, but it doesn't work on my machine. It was very interesting, we are having similar problem and I think many others would be having the same problem.

3. What was it like having someone test and review your code? Were you surprised by anything?

• It was great! It's like having someone check your typos. No matter how many times you check your typos, there is almost always some typos left that you miss or cannot find. However, if you have someone check your typos, they find them. I think it's because our brain kind of assumes there is no error so we don't take a close look at them when double checking them. From the reviews, I learned that there are a lot to improve and fix. In a metaphor, it's like having a third eye, you can see bugs, issues, or room for improvement that you couldn't find by yourself. I truely loved this experience.

4. What kind of issues came up in your testing and review? Discuss a few of them in detail.

• First, I found that Anh missed some of the details such as how to set .env file or the environment variable name. I think that he subconsciously assumed that others would know how to generate API_KEY or what the variable name should be. And also, there were some issues with settings. I think he made some settings on his machine locally, and forgot to tell others to set the same setting in their machine too. As a result, the tool didn't work. I guess that he made a symlink or script(or a $PATH variable setting) that makes his javascript file run without node commend. but it didn't work on my machine, since I don't have the same settings on my machine.

5. Provide links to issues you filed, and summarize what you found

• Anh's github Issues. I found that his README.md file was not detailed enough, which could cause people to be confused of how to install the tool and run it. That was the major issue. And also, I couldn't run the tool following his instruction (It was Sep 11, now some of them are fixed and I can run it in one of the two ways).

6. Provide links to issues that were filed on your repo, and what they were about

• my github Issues First, my README.md file also was not detailed, so that he was confused of how to use pipx or how to install poetry. Second, currently my tool is not complete at all, there are many features that I hadn't implemented such as not supporting multiple files input and there were some codes that are only for developers(checking some user inputs or arguments on cosole). Most of them were about enhancement and implementation.

7. Were you able to fix all your issues? What was that like?

• Yes, but most of them were not necessarily a bug. I hadn't implemented some of the features, and he reminded me of that. The issue was that my app didn't support multiple file inputs and I implemented the feature. There is still one issue that he suggested. but it's optional feature, so I am thinking of whether I am going to implementing it or not. I really liked the issues that someone else has given me. I could see my software from a different perspective when it comes to convenience and readability of documents. However, for some of the issues, I was like "Should I apply this issue to my software or not?", "is it better to take it or not?". One way or another, it was really helpful and a great opportunity for me to grow as a developer.

8. What did you learn through the process of doing the testing and reviewing?

• I learned how powerful collective intelligence is and that the more people work on a software, the more robust it can be and the less likely to have bugs it can be. As I've already mentioned above, it's like having more eyes and more brains to work on a software. I wasn't a huge fan of sharing my project or code. First, it's because I didn't want to be embarassed by the disasterous quality of my code; second, I didn't want other class mates to copy my code. However, from this experience, I learned that I can improve my programming knowledge and my coding skill much faster by sharing my code and reviewing others' code.