I worked for Camis from May to August 2024 for the second of two coop terms. My work involved developing software for park, campground, marina, and harbor employees to ensure Camis produced quality products for its clients.
I worked with my team to fix, maintain, and develop new features for Camis. As this term was a continuation from the previous four months, I tended to focus on contributing work rather than learning. There were still plenty of opportunities to learn and improve, which I took whenever I could.
Camis is a company that provides government operated parks, marinas, and harbors with various park management solutions. The company provides its journey and history on the company's "about" page.
The company develops fullstack software for its clients, whose staff use it internally or for customers using their resources. The overall solution that Camis provides includes multiple applications and services to meet a variety of needs.
Camis' values are similar to those followed on camp grounds. While describing careers at the company, Camis explains their values as shown below.
These values apply with both external and internal work relating to the company. Externally, we aim to achieve what our clients ask for to the best of our abilities, with the highest possible quality. Internally, it encourages everyone to provide their ideas and try new approaches, all while maintaining best practices in our development. Camis aims to foster positive social and professional environments for its employees.
On the social side, Camis has a "Culture Club" which arranges events for Camis employees. There were some virtual "game nights" that brought together employees from multiple locations to have fun. There have also been simpler events, such as providing treats for birthdays every month. While simple, making the effort to have such events fosters a positive attitude that feeds into the professional work environment.
During the summer term, some Camis employees started a patio garden. It's a somewhat simple activity as an amateur, but it also provides another opportunity for socialising with coworkers. At the start of the season, we planted tomatoes, basil, peppers, marigolds, and nasturtiums. We shared a weekly responsibility to keep the plants watered, and had small events to share what we grew with the rest of the office. One such event was making pesto with some basil (July 15, 2024), which we then shared with the office to enjoy.
Towards the end of the work term, there was an in-person "olympics" event. The activities included tent building (in which I competed with coops as a team) and rubber band shooting, among others.
There have been a few other instances of simple choices that improve Camis' work environment. The platform used for day-to-day communication includes social channels. The existence of this platform and these channels makes it much easier to socialise (and even plan smaller events with coworkers).
The aforementioned communication platform isn't just good for socialising. It is also an effective tool for collaboration. For example, reviewing work and pair programming are much easier to arrange (through an online call or in-person) when I can send a quick message to whoever I need. At times, I found that working in-person makes pair programming and troubleshooting issues much easier.
Camis structures their teams such that, even as a software developer, I am aware of the goings-on on a broader scope than I would have expected. While it is not thorough or in-depth knowledge, I find that being aware of other projects and work that my coworkers are involved in gives me a better understanding of how Camis functions as a whole.
Overall, I have been a part of the software development life cycle, participated in the scrum agile process, and collaborated with product development team members to develop new features.
With the software development life cycle, I have worked with various languages and technologies to create, fix, and maintain features in Camis' software. This includes languages such as C#, SQL, and Typescript, and tools like .NET 6 and Git. I also touched on WPF from time to time, when editing XAML files. The majority of these have been skills learned either on my own or on the job (be it a past or current position).
The agile process is a given for most software-based companies. At Camis, I used Jira and Confluence for ticket/task management and documentation respectively. We worked in two-week sprint cycles, aiming to meet a goal each sprint. We had to multitask a few larger projects, so the choice of focus would change each sprint as necessary.
My team focused on software used by client staff (e.g. park staff). This included working on bugs, issues, new features, and improvements.
I worked on two applications a majority of the time: Spirit and Sidekick. Spirit is a longer-standing application that manages anything that client staff would need, from selling products to managing bookings. Sidekick, on the other hand, is a mobile application meant to make on-site work easier, such as confirming that campers were at the appropriate (booked) campsite.
I really appreciated the effort Camis put to documentation. While agile development focuses less on documentation in favour of speed, more often than not there was a resource available to learn and proceed with a given task. If I reached out for help, I was often given direction to existing resources that I may have struggled to find.
Once I started working more on Sidekick, there was less existing documentation. It seems that the relative newness and different approach to developing the project was a primary cause. So, in the process of adding my work to Sidekick, I also spent some extra time documenting anything new I learned relating to it. Even if I didn't have a goal to provide further documentation this term, I likely would have recorded what I could about Sidekick anyways. Resources often come in handy, after all.
Skills that were necessary to perform well at Camis included clear communication, working on test coverage and unit testing, and reviewing changes to the code with the appropriate parties (including the user interface where necessary).
Communication is a constant requirement, and it is something that I learned through both previous work terms and group projects. Over time, I developed my own methods of keeping records of my work to make communication as easy and effective as possible.
Test coverage and unit testing go hand in hand, and they are a piece of knowledge I learned best in past coop positions where it was a requirement. I did have to learn new testing libraries (or at least refresh my memory), but once I had a decent understanding it wasn't too much trouble to add tests for the code I contributed to over the course of the work term.
Solution reviewing was somewhat new; it may have been a part of past work I've done, but with a different structure. Instead of checking the functionality of code, I would check in with the Product Owner, UX (User Experience) Designer, or Software Analyst on my team to verify the expected behaviour (also known as acceptance criteria). Once approved, I would then open a pull request on GitHub to check (and approve) the functionality of my code and merge it.
Set aside time to look at and review pull requests where my review is requested
I'm regularly reviewing pull requests and my understanding of Camis software improves over the course of my work term.
Previously, I wasn't added as a member of my team's review group. Once I was added, it became easier to contribute to the reviewing process. My review actually felt relevant, rather than being an "extra" review on a pull request.
It was a challenge to contribute well to the review process; I'm not an expert in Camis software, after all. Even with what I did learn about the software, I often felt like there were others that knew the code better than I did.
While I was primarily focused on getting my own work done, I took advantage of lulls in my own process (such as waiting for people to review my own pull requests) to review others' code. I believe this has increased the amount of time spent on reviewing, which was good. It also kept me from taking on too many tickets at once; I appreciated this, since my tickets would occasionally end up requiring more work than expected (or introduced new issues to correct).
I rarely reviewed pull requests to learn parts of Camis software, but I looked at past commits and merged pull requests to learn/understand some portions of the software. This even contributed to creating some documentation about Hot Chocolate object types and resolvers, which is linked below in my goal to continue documenting information for Camis.
Evaluate tickets on whether they're familiar or new. Take on any that are unfamiliar but I feel I can accomplish (with some help).
I am able to take on larger/more complex tickets and complete them largely unaided (about a month or two into my work term).
While I still hesitated to take on larger tickets, it wasn't too difficult once I got started. It seemed like I inadvertently took on complex tickets before; the system Camis uses to estimate tickets isn't always accurate, after all.
The part of a larger ticket that made me hesitate the most was my unfamiliarity with certain aspects of Camis software. Since I didn't know much about it, I had to first learn it before I could make the necessary changes. This is where reaching out for help to get even an overview was quite helpful, and members of my team had different niches of expertise around the work we did. I also had access to past commits and pull requests, which I have used as a reference and starting point for learning more about Camis software and improving upon it.
I picked up tickets a bit slower this term. This is because I tried to complete a ticket as thoroughly as I could before moving on to another one. Since I started doing that, I believe my quality of work improved. As previously mentioned, it also helped with performing other tasks that didn't directly involve coding.
Another reason I picked up tickets with less frequency was because I chose higher-complexity tickets. Since these tasks required more effort and attention, they naturally took more time. In early July, I picked up a few tickets in rapid succession. Upon noticing this, I tried to slow my pace to avoid picking up too many at once. However, they were lower-effort; each ticket could feasibly be completed within a day or less. That made it reasonable to be working on several at once (while awaiting feedback from others before marking the tickets as completed).
Keep documenting any work I find challenging and would have appreciated having an internal resource to help address it.
There is more documentation created that is helpful and will stay with Camis even after I leave.
I learned early in the term that documentation I previously created was used by my supervisor (a member of my team) for setting up his development environment. That was a case where I combined all the information and instruction I received into one document.
To improve the longevity and accessibility of my documentation, I moved most of it into my team's workspace on Confluence. I also re-created blog posts for better visibility for other developers in the company. I expect that these will be positive changes, and that more developers in Camis will be able to use my documentation in the long term.
As my knowledge became more specialised for working within Camis, it felt like it was becoming harder to determine what required documentation. My memory served me well for working efficiently, but I was less sure of what came from Camis documentation and what came from conversations with coworkers or independent investigation. I still did my best to update any issues or new information I encountered that had no existing documentation. (One such example is my documentation on Hot Chocolate object types and resolvers.)
I pivoted more towards documenting problems and potential solutions. This sometimes involved troubleshooting, but it also served as a method to make communication more effective for decision-making. For example, I picked up a ticket with a somewhat low estimate, but turned out to be more complex than anticipated. I created a document to share what the issues were, along with potential solutions and suggestions on how to move forwards (such as creating new tickets for what couldn't be completed at the time).
Working at Camis proved to be a wonderful work experience and learning opportunity. The collaboration within and between teams proved to be insightful. I was provided with a great environment to learn new skills and improve my existing abilities within the software development industry.