This week in the Topics in Open Source Development course, we were tasked with reading each other's code for the first assignment, evaluating it, and creating issues on GitHub to point out bugs, errors, or potential improvements. This is the essence of open source: collaborating and building with other developers. If I hadn't already completed my co-op work term, this experience might have felt quite different. Reading someone else’s code can feel strange at first, but with practice, it becomes second nature, and you quickly learn to distinguish between good and bad code.
How Was It Doing This Asynchronously?
I have to say, I really preferred the asynchronous approach to code reviews. This mirrors how it’s done in the workplace: you typically don't hop on a call with other developers, sharing your screen to point out issues or problems in their pull requests. Instead, everything is handled directly through GitHub, where comments, suggestions, and changes can be reviewed at each person's own pace.
Reviewing Someone Else's Code
As a Junior Software Engineer, I'm already quite familiar with code reviews—it's something I do regularly at my job. However, this was the first time I reviewed code written by my classmates. It was a really enjoyable experience, giving me a chance to see how others approach problems in ways that differ from my own. I didn’t encounter any major difficulties, but I did identify several issues. This week, my . I loved the concept; it’s a clever way to break down complex code into layman's terms. After trying out the program, and reading the code thoroughly, I found a few issues:
issue 1
One : When I tried running the command-line tool, an error was thrown, but it wasn't very descriptive. The issue was caused by a missing API key in the .env file. I recommended wrapping the initialization in a try/catch block to provide a clear and descriptive error message, so the user immediately understands what went wrong and why.
issue 3
in my partner's program: The -V flag was used to print the version information, but the requirement specified using -v or --version instead. I pointed this out as a nitpick, suggesting the flag should be lowercase. Additionally, the requirement mentioned displaying both the package's name and its version, but currently, only the version was shown.
issue 5
For the and a ! I quickly made a patch PR to fix this by removing the baseURL altogether. Additionally, he pointed out that I hadn't discussed any of the packages used in my program in the README.md file, so I went ahead and added that information.
The Aftermath
I was able to resolve all of my issues thanks to my partner's incredibly detailed and thorough feedback, complete with screenshots, explanations, and suggested fixes. It was genuinely enjoyable to address issues that others had caught—things I hadn’t noticed myself! It gave me a sense of collaboration and community, which is exactly how Open Source Development should feel. I really enjoyed this experience and am eagerly looking forward to more.
Conclusion
The level of collaboration and teamwork required for asynchronous development is incredible. It's not just the developer writing the code who must focus on code cleanliness, formatting, and clear comments; the person filing an issue also needs to provide as much detail as possible to describe the problem, reproduce it, and even suggest potential fixes. This course has been a great reassurance that I made the right career choice. If it's this enjoyable in just the second week, I can't wait to see what's in store for the weeks to come!
SOCIAL SHARE CARD GENERATOR