I worked for
Camis from January to April 2024 for the first of two coop terms. My work
involved developing software for park employees to ensure Camis produced quality
products for its clients.
I worked with my team to learn and involve myself in the development process
effectively. Throughout my employment, I gained a better understanding of fullstack
development and the work involved in fixing, maintaining, and developing new
features.
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 are monthly virtual "game nights" that bring together employees from multiple countries to have fun. There have also been simpler events, such as providing treats for Valentine's Day and Pi Day. While simple, making the effort to have such events fosters a positive attitude that feeds into the professional work environment.
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).
When it comes to working, I found that learning and asking for help were always encouraged. It's sometimes a challenge to ask for help, but I quickly adjusted to reaching out while working at Camis. I do not believe I was ever discouraged from asking questions, only redirected to the appropriate people who could help me.
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 when I can send a quick message to whoever is necessary.
Camis allows employees to work with a hybrid format. I appreciate the choice. It allows me to continue to work and keep my coworkers healthy if I am feeling sick. For working in-person, I find that it makes pair programming 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. With this understanding, I think I was more patient whenever a teammate was less available to work with me on a given task.
So far, 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.
The agile scrum 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.
In late February, my team participated in the initial work behind understanding and planning out the general work for a new feature, event ticketing. The majority of it would be entirely separate from existing features. This involved other teams, including product owners and UX (user experience) designers. Our work was meant to be somewhat broad, while covering as much technical areas as possible that would be necessary to meet product requirements.
My team focused on software used by park staff. This included bugs, issues, new features, and improvements.
This meant working on two applications a majority of the time: Spirit and Sidekick. Spirit is a longer-standing application that manages anything that park 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, I rarely found myself without a resource to learn and proceed with a given task. Typically, if I couldn't start or complete something, it was more due to the complexity of the work and my lack of familiarity with job-specific technologies than a lack of resources. If I reached out for help, I was often given direction to existing resources that I may have struggled to find.
I have also been encouraged to document my own knowledge, which I hope contributes well to Camis. It was even my goal to provide documentation, since resources almost always come in handy. I include some examples of the documentation I wrote in that section.
Skills that were necessary to perform well at Camis included:
Communication is a constant requirement, and it is something that I learned through both previous work terms and group projects. I have also, over time, 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 to the code I contributed to over the course of this 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 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.
The structure of Camis seems to have helped me better understand the differences between each type of task I worked on.
For example, I better understand the difference between frontend and backend. While backend is defined as "server-side" and frontend as what the user sees, the definition wasn't always that clear to me in practical application scenarios. With the Sidekick project, the distinction between front and back end is much clearer and gave me a better understanding of how fullstack works in the "real world."
I also have a better understanding of the variety of projects and tasks within the company. Making changes to an application can either be a new feature, an improvement, or a fix for some bug or issue encountered in existing code. Previously, I had a general understanding of the difference between bug fixing and making changes. "Changes," however is a broad term, as it could be a fix or a new addition. While working at Camis, I believe I better learned the differences because each project is clearer about whether it's new, a change, or fixing some existing issue/bug than it has been in my previous jobs.
Learn what tools other team members use and configure/implement what I find to be useful for myself.
I am able to perform expected tasks as quickly/easily as possible by the end of the first month (around Feb. 1).
There are a few different tools that can make development work easier. For the most part, I used custom shortcuts, git stashes, and reference notes to improve my work speed.
Windows (in my case, Windows 11 on my provided work computer) provides a method to create custom shortcuts. I typically ran multiple C# projects simultaneously, sometimes from separate git repositories. Since navigating folders to find the specific files/solutions was somewhat time-consuming, I instead created shortcuts on my desktop. I hadn't done this before, but it was surprisingly effective at helping me work faster.
The initial environment setup process included setting up a custom powershell. This provided special commands made for Camis, which automated a majority of processes involved in developing and testing the software locally. I took some time to learn what commands were provided by the custom powershell, and it has definitely reduced the time taken on mundane or basic work for certain builds or tasks I run regularly in my development environment.
Unfortunately, I don't think I met the timeline I set for myself. Even during the month of February, I felt like I was learning new tools that have since become useful. However, when I reflected on this at the beginning of March, I did not think I fell too far behind my goal - perhaps only a week or two at most.
Camis' products are, admittedly, a very large project. Even now I am still encountering new sections that I have yet to fully engage with on a typical work day. Depending on which section of the project I am working on, I will continue to encounter work that requires unique setups or conditions to run correctly.
In my attempt at creating an efficient setup, I explored software that could provide custom command keys. Unfortunately, software I looked into wasn't trusted/allowed on my work computer, so I failed to implement anything of this type of tool.
On top of learning different commands and tools at my disposal, I also created reference files for myself. These helped me with remembering helpful commands (for powershell and git) and remember key details to include in my environment for specific setups.
For development environment setups, I took advantage of git stashes. By keeping the important local changes in a stash, all I had to do was "apply" them to make several edits at once.
Overall, it would likely have been easier if I used and explored shortcuts more on my own time before starting work here. However, I didn't do that, so I still consider what I have achieved to be rather successful in improving my overall efficiency at work. After all, tools and strategies can always be carried forwards into other situations and future employment.
Use Confluence, the current documentation platform, to create quick reference guides and notes for typical tasks. For example, coding conventions, best practices with git, a brief overview of certain environment setups, and so on that can be used as quick reminders (and possibly reference more in-depth sources).
I have created documentation that makes it faster to resolve environment-based issues or answer questions about technical expectations to improve overall team performance.
Creating documentation has helped me, but I'm not sure if it's helped others as much. I don't have any measures to track my coworkers' use of what I've created. I expanded beyond documenting the onboarding process and basic development steps. Some of this included development environment issues, or my review of larger pull requests from other developers.
As a personal reference for the development process used at Camis, my documentation has been a useful tool to remind myself of each step, such as what is needed for solution reviews and pull requests for a given task. Having notes on how to switch to different setups and handle any issues that might arise from that has definitely helped me. There are specific challenges to running each project within Camis, so having a reference to avoid missing any step in the setup process is beneficial.
I documented my reviews of other developers' pull requests rather than providing direct feedback because I wasn't always sure that what I noticed was a significant issue. By highlighting them in this manner, I used my documentation as a sort of confirmation with my team members on the existence, relevance, and severity of the issues I found. This meant that unimportant items or non-issues were filtered out, so I consider this approach successful.
While my team may not use as much of my documentation as I hoped they would, I still believe that what I created has been useful. I have certainly benefitted from it, and it leaves a record of my work that may be repurposed in the future by my team if they so choose.
Seeing as some of my notes are applicable outside of Camis, I have decided to include some of what I learned below. The observations may be specific to my experience at Camis, it is still knowledge that can be applied to any project that uses the same tools and/or a similar structure.
Understand how tasks are assigned to team members, and learn which type(s) of tasks I can take on over the course of my work term.
I consistently choose and work on tasks where I require minimal assistance to complete them. The time I take to complete tasks of similar weights should also decrease as the work term progresses. Additionally, I should be able to decently estimate the time it will take to complete a task and plan my time accordingly.
This is a goal I believe I have achieved, yet hope to improve upon. I am capable of gauging the complexity of tickets (or tasks) relatively well, and I can determine which tickets I can work on independently. An improvement would be reaching beyond what I currently know and continue to learn more about the details of each project.
Pair programming was a rather effective method for learning quickly. While it started of as guidance, pair programming was also a strong starting point to working independently on similar tasks in the future. I hope to use this more often as a learning method.
Generally, working on specific tasks and software has helped me learn and speed up my development process.
Sometimes, I've had to step away from work or give up a ticket. While there were people on my team that could have helped me, they also had their own work to do that made them unavailable to help me at the time. These challenges, in my opinion, were often because I lacked a crucial skill or piece of knowledge to be capable of working independently. If I encountered similar challenges at a less busy time, I reached out for help. This has enabled me to learn more, such as understanding Transact-SQL and how stored procedures work (both at Camis and in general).
I still feel like I perform the best on smaller tickets/tasks. I would like to build up to higher-effort work, but I have a limited amount of knowledge as a co-op software developer. I have learned plenty, but there is still more to learn, so I look forward to working at Camis for another four months.
When it comes to tickets that focus on sections of Camis software I previously worked on, I'm confident that my work speed has increased. There is less to learn, so it's easier to investigate and fix any issues or add new features.
At the end of January, my team participated in an activity to create "reference stories." The exercise allowed us to arrange previously completed tickets by their complexity and/or effort involved, and then assign point values accordingly. This reference has helped me better estimate the time I would spend on a ticket and gauge the complexity or effort involved in a ticket that doesn't yet have a value assigned to it.
Being capable of taking initiative is important; it means I am not idle or neglecting any work. With a combination of taking initiative and learning as I work, I can carry such knowledge forward and into future employment.
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.