My CA Technologies co-op experience can be best summed up as quite different from any other co-op I’ve done before. Heading into the term, I expected the role would be development focused, working on features for CA’s Gateway product. However, when CA accepted my four-month counter to their initial eight-month offer, the role changed considerably. Instead of doing any real software engineering, I spent the next three months migrating one of CA’s massive repositories from SVN to Git. Although this wasn’t what I signed up for, I’m now proficient in a powerful source control tool I can use for years to come.
Project: Moving to Git
For those unfamiliar, SVN and Git are version control systems used to track changes to files over time. In recent years, there has been a shift to Git for its more streamlined approach. However, moving a decade’s worth of data from SVN to Git is easier said than done. Throughout the term I had to come up with solutions to many of the problems resulting from migration. One example of this was that Git does not track empty directories nor does it support individual files that exceed 100 MB. This caused a lot of code compilation (i.e. builds) to fail, leaving it my responsibility to come up with fixes.
Learning New Paradigms
Speaking of builds, I also got to learn a lot about the Continuous Integration (CI) paradigm. Among other things, CI enables the compilation of source code after a developer submits changes to the codebase. This way, if the build fails it’s easy to track down the developer who submitted the breaking changes. But with Git, CI can be enabled to prevent breaking changes from being submitted in the first place. This was one of the motivating factors for moving to Git -- as developers often defer code fixes to meet other deadlines. Not only that, having developers submit code to an already broken (i.e. fails to compile) codebase makes it harder to distinguish subsequent breaking changes.
As far as workplace environment was concerned, I really enjoyed my time at CA. Everyone was friendly and willing to help. One of the directors of engineering even set up a monthly meeting encouraging the co-op students to share our questions and concerns. CA also took special care to ensure each co-op student had a “buddy”. My buddy was a senior software engineer and personally got me up to speed on what I needed to do.
Day to day life at CA was fun too. During the first week, the company held a three-hour bowling event to celebrate a major release. I found this a great opportunity to connect with my colleagues on a more personal level (although my arm was a little sore after bowling 150 times). CA also hosted biweekly “All Hands-On Deck” meetings where we would drink beer and listen to the latest news about the company. Beyond that, there was the odd day employees would bring their dogs to work, which made for a more relaxed work-environment. Lastly, the passion and kindliness of my coworkers always kept me in good spirits, even under times of stress.
As a side note, all development is primarily done in Java (no C/C++ here), which is partly why I opted for a four-month term. Nevertheless, CA was the first company I’ve worked for that offered the choice of Mac or PC. Better yet, because all workstations are laptops, employees are free to work the occasional day from home (I know remote methods such as RDP would work too, but it can be laggy at times due to VPN latency). This was hugely beneficial on the days I wasn’t feeling so well or had appointments to attend.
Overall, I would definitely recommend CA Technologies to other students. However, I would suggest taking an eight-month term for students wanting to do actual software engineering. This is because it will generally take co-op students three to four months to become familiar with codebase.