CST462 Service Learning Reflections

What went well?

My time volunteering as a developer for The Document Foundation was genuinely rewarding. The most valuable aspect was getting first hand exposure to a large, real world codebase, which is something that classroom projects can't replicate at scale. I had the opportunity to learn how to set up a professional development environment from scratch, navigate a complex project, and engage with an industry standard code review workflow through Gerrit. I also got experience with bug tracking tools and learned how to locating the right targets for code changes within a massive project structure. Altogether, the experience gave me a much clearer and more real sense of what day to day work as a software developer actually looks like.

What was the most impactful part?

The most impactful part of this experience was definitely working directly within a large codebase along with a real code review system. It pushed me out of my comfort zone in a productive way like becoming more comfortable operating in Git Bash rather than leaning on GUI based library browsers. That shift forced me to develop a more intuitive, command line approach to navigating and managing code, and I feel noticeably more proficient.

What challenges did you face?

Because so much of this was new territory, there was an adjustment period early on. Learning to perform effective bug tracing, understanding how to look up relevant code across a huge project, and meeting the project's documentation standards all required a huge amount of upfront reading and research. It felt somewhat overwhelming at times, but working through that learning curve ended up being what made the experience so valuable.

Advice for future Service Learning students

My suggestion would be don't rush. The most important thing you can do when starting out is to invest plenty of time in reading the documentation and making use of the resources available to you. Resist the urge to dive into complex contributions before you understand how the project is organized. Take the time to genuinely learn how to navigate the codebase. Once you are ready to contribute, work consistently on small, focused patches rather than trying to take on something ambitious all at once. Progress compounds, and steady incremental contributions are a better path to progression than overcommitting and getting stuck.

Comments

Post a Comment

Popular posts from this blog

CST334 Week 2

    This week has been a great introduction to how CPU process selection works in operating systems. We covered a range of scheduling algorithms, including FIFO (First In, First Out), LIFO (Last In, First Out), Shortest Job First (SJF), and Round Robin (RR). I learned how each algorithm has its own strategy for picking which process should run next, and how these choices affect system performance and metrics like response times.      I also learned to calculating those performance metrics such as response time, turnaround time, average arrival time, and average turnaround time. For Round Robin scheduling in particular, I learned how to calculate how long a process will stay in the system based on the time slice and the number of other processes in the queue. These exercises helped me understand the mechanics of how schedulers work and why the design choices made are so important.      One of the most interesting parts was comparing the pros and ...
Read more

CST334 Week 5

     This week I focused on concurrency and how it allows processes to run multiple threads in parallel, allowing tasks to be handled in the background while the main application continues. While I’ve previously worked with multithreading in Java, learning how the operating system manages concurrency gave me a better understanding of how multithreading works in the CPU. I learned that threads can share certain resources, such as virtual address space which makes communication between them efficient, but also introduces its own challenges.      One of the key concepts I learned was nondeterminism in multithreaded programs. Even if two threads call the same function, the order in which memory is accessed and modified can change which can lead to different outcomes every time the program runs. This unpredictability can cause bugs that are hard to reproduce and debug.      To address this, we use thread synchronization APIs like locks, or mutexes...
Read more

CST334 Week 6

       This week we continued concurrent programming and synchronization concepts and built on the ideas from last week. One of the first things I learned about was binder buffer coding, which was about how data can be shared and communicated between different parts of a system or between different threads. It's a used when dealing with message passing or structured data flow. Systems with modular or layered designs can make use of this to communicate with other parts of the system.    After  that, I learned about the concept of semaphores. Semaphores are a core component in concurrent programming as they act as signaling mechanisms used to control access to shared resources. The main idea of semaphores are integer variables protected by atomic operations like wait() and signal(). A semaphore can be used to limit the number of threads that access a resource such as a database connection pool or a bounded buffer to ensure that the variables remain safe ...
Read more