CaseWare International is a global software provider for accounting firms, corporations, and governments. They have been building auditing software solutions for nearly 30 years that are used by over 400,000 users in 130 countries and in 16 spoken languages. As an organization they exercise three core values - community, excellence, and continuous innovation. To learn more about CaseWare, visit their website: https://www.caseware.com/ca/about.
I chose CaseWare for my first co-op placement because I had prior experience with the languages used (C#, Java, C++) and was interested in seeing Agile and Scrum methodologies in action.
Going into my co-op at CaseWare, I set goals to improve my oral presentations, documentation, knowledge of Agile, and knowledge of JavaScript.
During this co-op I wanted to improve my software demonstrations and learn to write professional documentation. By doing so, I hoped to improve my written and oral communication skills, as well as learn about presenting software.
Throughout my co-op, I documented and demonstrated several tasks I worked on during sprints. A couple examples I worked on are the ESLint test and Data Services getting started guide.
For the ESLint test I wrote, I made sure to document the configuration I used for it, as well as useful information and links to relevant documentations. For the getting started guide, I attended some of the Data Services team's meetings on the product to get a better understanding of it. I then worked with them in a Google Doc when writing it to get feedback and make improvements.
As part of my Software Engineering degree I have taken several Software Design courses and this co-op placement was a chance to put what I learned into practice, and extend my learning.
As a member of my squad, I took part in daily standup meetings and other Scrum ceremonies, including Sprint Planning/Review/Retrospective and Backlog Refinement. For some of our Backlog Refinements, we used planning poker to estimate stories.
Additionally, outside of my squad I attended sessions hosted by our Agile Practice Manager at CaseWare. These included Lean Coffees to discuss how Agile is being used in the company, Agile games to learn topics such as work in progress limits or Agile metrics like velocity. Some of the games we played were Spaceteam and FeatureBan.
In one of the last courses I took before going on co-op, CIS*2750, we touched on a little bit of JavaScript, but I wanted to learn more, especially since it is a widely used language.
In fact, JavaScript ended up being the primary language I used during my co-op. In particular, I wrote tests using Jasmine and Node.js for our development pipeline. As mentioned earlier, one of those tests was to integrate the ESLint code quality linter, but I also worked on others, such as sanity tests for repository file encodings or repository naming.
I found my demo, JavaScript, and documentation goals to be a success. There were many tasks I completed which helped me improve each of them, and they all were major components of my Map Gadget Capstone Project (mentioned in the Job Description below).
If I were to rank my goals by success, it would be as follows:
While I learned a lot about Agile, and would consider it a success, I didn't make the goal specific enough to give a measure of success. I also originally had a goal to improve communication and coordination but it was also very vague and partially covered by the demo and documentation goals. In future I will make sure my goals are specific and easy to measure when I am choosing them.
In my co-op I was a member of the Third Party Solutions squad. My job involved a mixture of developer support, code management, and product development.
One of my squad's primary responsibilities was to assist Distributors from around the world with developing products on CaseWare's platform.
One of the most common tasks was to manage the set of almost 200 repositories where each Distributor stored their product(s) code. When I was designated as on-call for the sprint, I would regularly check for incoming pull-requests, review them, and then merge or comment back to the requester.
Additionally, when Distributors wanted to release their product, I would set up pull-requests to move their code from develop to release and then from release to master.
Another common task when on-call would be to handle incoming JIRA tickets from Distributors. They could include questions, bugs, requests, etc. For the questions and bugs, I would research the issue and then either answer the question, direct them to documentation or sample code, or pass the ticket on to the relevant platform/product team for them to give a more direct answer.
Finally, we did product development with the aim of making it easy to use the CaseWare platform. Some of the development was to create sample code to help Distributors get started with the platform but we also created APIs/SDKs to make it easier to use the CaseWare platform.
One of the big projects I joined into was our Java Spring Microservice Framework. The end goal was to provide a Gradle/Maven dependency that Distributors could use to easily develop their own microservices that integrate with CaseWare Cloud. My part in the project involved some refactoring of existing code as well as creating several unit tests using JUnit and Mockito.
As a capstone for my co-op term, and one of the big measures of success for my goals, I was given a project to create a JavaScript gadget as sample code for creating gadgets and dashboards. The gadget would visualize overdue client requests for a firm on a bubble map; similar to this one for the United States.
My first step was to sit down with my Development Lead and break down the epic into individual stories. I then took the stories to a story splitting session hosted by my Agile Practice Manager, where she provided feedback and helped me refine the stories.
I then provided estimates for the stories and had some start being added to my squad's bi-weekly sprints for me to work on. At each Sprint Review, I demoed the current state of the gadget. Once I had completed all the stories, I held a meeting for my squad to demo the nearly complete gadget and obtain some feedback, which I worked on for the last few days of my co-op.
The implementation of the project itself included using a mixture of browser JavaScript, the Leaflet.js map library, and CaseWare's own JavaScript libraries. It also involved using the OpenCageData geocoding service, after completing some research into what services were available.
Alongside the gadget, I was also generating documentation to add to or improve the existing set. This included basic info on how to get started using the map as well as documentation on the various CaseWare APIs that I used in creating my gadget. Additionally, I reviewed and provided feedback on the existing documentation I went through, to find areas that could be improved or needed to be updated.
One of the more important pieces of knowledge I needed was knowledge of platform itself. I learned it through a combination of onboarding documentation, code samples we provide to Distributors, and API documentation (as well as first-hand experience using the APIs).
Another piece of information that helped with understanding terminology was basic knowledge of accounting/auditing. CaseWare provided this in a two-day Auditing/Accounting 101 session, and helped with understanding and communicating with Distributors and Clients.
For programming languages, the primary ones I used were Java and JavaScript. I had learned Java and some JavaScript previously in the Object-Oriented Programming and Software Systems Development and Integration classes, but also learned more as I worked with them.
For my first work term, I found the experience a little different then I expected. In terms of work, there was less programming than I thought there would be and more process required for creating JIRA tickets to track work. Learning JavaScript was one of my goals and definitely one of the major topics I learned about this work term. From learning based on ESLint's rules to writing Node.js and Jasmine tests, to creating the map gadget.
Another thing that I had not expected to learn going into the co-op was code management. Helping to manage almost 200 repositories as a member of my squad lead me to learn a lot about the need for standardization, from naming conventions to repository organization. Additionally, it made me more familiar with technologies such as git, NPM, and Gradle.
One of my favourite things about working at CaseWare was the variety of technologies I was exposed to, from Docker to Java Spring to various JavaScript libraries like Jasmine and Leaflet.js. There was also many, knowledgeable people working there who would host Lunch and Learns on topics like GraphQL, Kubernetes, and more. I took part in my own team's Lunch and Learn on our experience developing microservices, where I demoed a Docker Compose file I was working on to run a microservice with the ElasticSearch, FluentD, Kibana stack.
Altogether I found it a valuable experience to know what the industry is like from a firsthand perspective. I enjoyed my time at CaseWare and would be glad to return for my next co-op.