Joudat Haroon

Co-op Work Term Report Summer 2024

StackC#, .NET, WPF, TypeScript, Angular, Git, Jira, Agile

Intro

This co-op term in the Summer of 2024 was a continuation of my previous term at Camis as a Software Developer. The job mostly remains the same, with it being a hybrid position and having a relaxed dress code. In the next few sections, I will be reflecting on my role and answer specific aspects of it. Do keep in mind, though, that this is supposed to be an 8-month term at the same place as last term, so some things will remain similar, but I will try to add new experiences wherever I can. I've also sprinkled in some photos from our very own Olympics event that took place in August.

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 still 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.

After working here for some time, I naturally became more familiarized with the tech stack. Most of the work is done in C#, which in my opinion, felt similar to languages like C, Java, and JavaScript. There were some new things I haven't seen before, such as how unit tests were written, some specific keywords I've never used before (like 'out'), and some finicky operators.

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.

Learning the fundamentals of debugging continued to be important tool for me all throughout, but with more time, I realized a bigger issue was that I was not properly able to classify the tasks, at least in terms of code. This means that I would get lost in trying to locate the code that I'm concerned with. I also initially thought that I would somehow "get it" as I kept working there, but this was the wrong perspective. Since then, I had to make sure to ask the developers helping me out about their thought processes, instead of them just telling me where the code exists, what to change, and to see if I can apply it on my own. With some time of doing this, I became better able to classify the various tasks (getting familiar with what kind of domain the features probably exist within) I took on, getting started on them without assistance (with some exceptions), and having my questions to the other developers evolve from "How do I begin to work on this?" to "Do you think my solution meets all the requirements?" and making adjustments where needed.

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.

In the previous term I mentioned that I was concerned about trying to ask questions during meetings where I would simply be asking about definitions of certain business terminology. This might be totally fine to others, but I would hate to break the flow of a productive conversation by butting in to ask simple questions. This kind of thought process can be sort of self-destructive, as not contributing means that I am not taking the responsibility of providing valuable insight, and this would sometimes have me tuned out. To break this cycle, I tried other ways to get familiar, by looking through and reading posts on Confluence, and if that doesn't fully answer the question, ask in the general squad chat on Slack, so that whoever has a bit of down time on their hands can take a moment to help me understand. Over some time, things just started clicking for me in terms of the various jargon being thrown around in meetings. This was partly inspired by observing the participation of the youngest full-time developer on the team, who made valuable contributions to these meetings, and have the concerns they brought up be taken seriously. They were also relatively new to the industry, and this made the problem seem a lot more approachable for me.

Job Description

This section largely remains the same, though in this term, we started on new initiatives. 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

I am very grateful for the opportunity of working with the folks at Payment Squad and Camis at large. I feel like I've become a more well-rounded developer as a result of my time and effort here. Notably, I've learned how to debug my code, write unit tests and making sure any new code is covered, engaging in back-and-forths with reviewers on my pull requests, performing demos on features I've worked on for internal stakeholders, providing feedback on every completed sprint, and making valuable contributions to meetings.

Company Website

Company LinkedIn