- StackC#, .NET, WPF, TypeScript, Angular, Git, Jira, Agile
Intro
During the Winter of 2024, I had the opportunity to work at Camis as a Software Developer co-op. This position was hybrid, allowing me to experience both in-office collaboration and the flexibility of working from home. The flexible schedule and relaxed dress code provided a comfortable yet productive work environment. The next few sections will provide more details about my first work term experience at Camis.
Winter 2024 co-ops
Information about the Employer
Camis is a software solutions company headquartered in Guelph that started with the need to address the requirements of park management all the way back in 1980. They are partnered with national, provincial, and state parks all over Canada and the U.S. to provide reservations and management solutions with the use of software and hardware. In current times, they are working with over 725 government operated facilities. My supervisor is Ryan Ferguson, who is also the lead software developer of the team that I'm on. Besides his leadership role during team meetings and such, he has scheduled one-on-one meetings semi-frequently to allow for feedback to be addressed from either party.
Goals
I've noticed that my ability to solve problems often comes down to not fully understanding the technologies being used. Thus, I would like to have a more solid grasp over the tech stack.
I plan to take time after work or in between sprints to focus on specific elements of the tech stack, either through tutorials or mini projects. Accurately determining the story points for tasks during backlog planning will help me gauge my proficiency with the tech stack and codebase. Additionally, I've sought access to courses from one of my seniors and have been going through them to gain a better understanding of large-scale project structures. During PR reviews and when receiving help from other developers, I also make it a point to pick up best practices to further improve my skills.
Sometimes I get too absorbed with a problem and keep running into a metaphorical brick wall. I would like to recognize when I fall into this trap sooner and reach out to the team to maintain progress on the issue.
I plan to initially work on the problem independently. If I can't find a solution, I will then reach out to another developer. This approach allows me to better understand and communicate the exact problem, facilitating more effective troubleshooting with the team's help. Roadblocks are inevitable, so it's important to leverage the support of a reliable team to solve the issue and learn how to tackle similar problems in the future. However, it's crucial to balance seeking help and working independently. Reaching out too early can be disruptive, considering other developers' workloads. To create this balance, I've started using debugger tools in the IDE, which were not emphasized in my education. This helps me gain a comprehensive understanding of the code, improving my ability to explain the problem when I do seek help, and sometimes even solving the issue on my own.
I lack a lot of understanding when it comes to discussions that involve a lot of business terminology. The words themselves might be things I've heard of before, but when applied in this relatively new context, I have a hard time following the conversation.
I will review the resources available on Confluence to familiarize myself with business terms and their specific applications. If this approach doesn't fully address my needs, I will overcome my fear of disrupting productivity by asking questions about these terms during discussions. I don't mind appearing uninformed; my main concern is maintaining the flow of the conversation. By seeking clarification, I can build confidence in my future self to start speaking up and sharing my thoughts during meetings, In the past, a senior commended me for asking insightful questions, so I believe I'm already on the right track to achieving this goal in discussions. Additionally, I could start taking notes during meetings to help me stay focused and understand the conversation better, though I haven't needed it yet as using Confluence for understand terminology and asking for a technical breakdown of the task has been more than sufficient.
Job Description
Since I'm on the payment squad, my main tasks are typically in the space of online payments, integrated/non-integrated payments, reconciliation, and financial reporting. The specific kinds of work are either adding/removing features, maintenance, or bug fixes.
The required tasks are selected per sprint (agile), and the squad's members self-assign tasks in a first-come-first-serve basis. If someone does feel that they should be the one assigned to a specific task, there's never any conflict that arises and these sorts of issues get resolved almost immediately through basic, direct communication.
There are also regularly scheduled meetings, and a few extras on a few occasions that must be attended. The common ones are standup, where the developers on the team briefly describe their progress on their assigned task and any potential blockers they might have, while the managers and the analyst will chime in only if their responsibilities are relevant to the current sprint.
The next common meeting that occurs is backlog estimation, where developers and the analyst will go through a list of tasks that are not part of any sprint (based on priority by the product manager usually) and estimate the 'story points' of each task or until the allocated time for the meeting ends. This approach contrasts with, say, to assign one member of the team as the designated estimator. When these approaches are juxtaposed, we can quickly understand that having one person estimating tasks could introduce a lot more inaccuracy (due to biases, skillset, etc.) rather than having the task-completing members all participate in estimation. This allows members of the squad to calibrate with each other, and helps converge on a more accurate result.
The final common set of meetings have to do with the ending and beginning of sprints. Sprint planning is where a greater goal of the sprint is set by the product manager and tasks are pulled into the sprint, which will be the tasks that developers start working on for the duration of the sprint (2 weeks). Sprint review takes place at the end of a sprint and is a meeting with the squad and internal stakeholders where the tasks that were completed are showcased to said stakeholders for feedback. Sprint retrospectives take place after reviews, where members in the squad provide feedback and constructive criticism on how the sprint went.
Conclusion
The Winter term was great! At the beginning I struggled with a lot of things, but with constant communication with Ryan and the other developers, I feel that I'm finally starting to understand the various facets of the Camis software, as well as firsthand experiencing an Agile environment.
Viewing the solar eclipse - April 8th, 2024