The transition from college to industry came with quite a few surprises and lessons. Reflecting back on own my experience, I want to share a few insights I’ve gained. Additionally I want to share habits I formed during my undergraduate that transitioned well, as well as those that required significant changes in order to assimilate successfully into industry.
Practice writing extensible code
A very common theme in college coding projects is that once you turn in your assignment it is considered finished as long as it passes a defined set of requirements. Only rarely will you be working with the assignment code again. One should recognize assignments that build upon each other, and spend time architecting and testing each assignment in order to have a solid foundation upon which to build. It will give you first hand experience of how much easier it is to work with modular and tested code. A “submit and forget” philosophy does not hold true in industry where projects must be maintainable, scalable, and usable by others into the foreseeable future.
Learn to communicate effectively
An important skillset that translates well into industry is the ability to effectively communicate. Those that are able to articulate their ideas will be given far greater influence over project specifications and implementation details. You must also be able to communicate your ideas to a non-technical audience. A good opportunity to practice this is taking a technical writing class. In my technical writing class I worked on a project team composed of both engineers and non-engineers developing a Facebook game for a real company. The company itself was very non-technical and had expectations that went beyond what could be expected given the time constraints and technical knowledge in my group. This gave me valuable experience justifying technical design specifications both among my team and to the company without a technical base.
Effective communication is essential in preventing project knowledge silos across engineering teams. You can lessen the time it takes to onboard an engineer onto a project If you are able to clearly explain the abstract overview of the frameworks and project implementation details. Clear design documents can go a long way towards onboarding an engineer onto a project by giving them a starting point to understand the intent of the code. You put yourself at risk of being the only one able to perform long-term maintenance on a project if you are unable to provide meaningful documentation.
Side projects matter
One of the best things I did while in college was work on a side project with a friend and classmate at Georgia Tech. We created an Artificial Intelligence Competition Framework that enabled the easy creation of new artificial intelligence challenges. The types of challenges created were based on the client implementing a single bot class, where the client would implement artificial intelligence logic to control the bot to compete in a game against other players. Working on this side project taught me more about scalability, testing, and software architecture than I learned in any class while in school. Not only did I learn many lessons from this project, it showed me that software engineering was something I was truly interested in, as I was working on a project that wasn’t required of me. Having a side project to talk about in interviews will not only show a potential employer your passion for the discipline, but your ability to take on a new project and the many challenges that it entails.
It’s a marathon, not a sprint
The transition into industry comes with the realization that there is always more work to do. Project roadmaps often stretch months and years into the future. The completion of one project entails immediate work on next feature, not free time until the next assignment. The completion of a project can often lead to a longer project roadmap as it opens additional possibilities. In addition, there are often co-worker and third party dependencies for your project that can hinder you from being able to complete the project in a single coding binge. Late night code binges can result in monolithic, hard to read code reviews if no one is available at 3 am to do your code reviews. Consistent, sustainable productivity is essential, as project requirements in industry are far more likely to change than college assignments.
This realization forced me to adapt my work habits that I had formed and utilized to great success in college. I often worked unnecessarily late into the night, often pulling intentional all nighters, to finish assignments far ahead of the due date so that I could guarantee myself several day stretches where I had absolutely no assignments to work on. This strategy does not translate well into industry. Working in long stretches Monday through Wednesday does not mean I can take the rest of the week off. Also I’ve found that my ability to function during all nighters has quickly deteriorated, where the toll on my body and cognitive function can last for several days. The lesson I’ve learned from this is that it’s a marathon, not a sprint.
I learned many of these lessons the hard way. Some of my early class projects were not written to be easily extensible. When the next assignments built upon the previous I was forced to rewrite far more code than had I architected it properly. When I first started at Wealthfront I attempted to work in a continuous sprint. I was quickly starting to feel burned out, and the switch to focusing on the longer picture not only helped with burn out, but made me more productive. I hope learning these lessons vicariously through my experiences will lead you to a successful and smooth transition into the workforce.