Words of Advice From One Intern to Another: Ashley Cyborski
Current team member and former intern Ashley Cyborski shares some words of advice with future interns.
Photo of Matt Carmichael sitting at table with other Palantiri
The transition from student to full-time programmer can be intimidating. The days of submitting buggy and poorly-tested code that is just good enough to get a passing grade are over. Every line of code is just as important as the last, and even the smallest mistakes could lead to catastrophic problems for your team and your client. But trust me, it's doable!
I was lucky enough to have an internship at Palantir the summer before becoming a full-time employee. The opportunity to dive into the professional side of development without having quite the expectations of a full-time employee is priceless in my opinion. It gives you a chance to focus more on the learning experience of being a developer, without stressing as much over productivity and results.
The most prominent takeaways from my time as an intern were learning and engaging in the process of collaborative programming with a team and also understanding the importance of code quality. In school a majority of the projects are done individually and you rarely have to rely on anyone else to get the job done. This is one of the biggest adjustments to make, as the workplace is the exact opposite. The members of your team need your code to be correct, verbose, and understandable in order to do their jobs. That being said, coding standards cannot be stressed enough in a team environment and doing things ‘your way’ is not going to cut it.
At Palantir, I was introduced to an extensive Github repository devoted to documenting our code standards and development process. Familiarizing myself with the workflow, documentation, and code style expectations seemed like a full time job in its own right. Every line of code is submitted in a pull request which is inspected by a senior engineer and tested against the standards that are laid out in the developer documentation.
Issues as seemingly trivial as the size of an indentation and documentation formatting are sent back to the programmer for revisions. Once the code has been through the critique and revision phase and is cleared by the engineer, the code is finally merged into the master branch and is ready to go into production. This level of attention to details that seem trivial at a glance, but are vital for code consistency and readability, is in place to ensure the best product for the client.
Once you get past the logistics of teamwork, and the code standards become second nature to you, it's all uphill from there. As I settle in and become more confident in my role I realize how exciting worklife is. The opportunity to work with people of all backgrounds and skillsets and to see a project come together from start to finish is what makes it all worthwhile.