Making the transition into the professional world can be tough regardless of the field. One of the difficulties facing those programmers coming from the world of formal education is the differences in these environments. As a part-time student at the University of Illinois at Urbana-Champaign, my time at Prominic began with quite the adjustment period. In my experience, school has prepared me in many ways to be a software engineer. However, there were also some things that were undoubtedly different than I expected. Hopefully, by sharing my experiences with starting my career as a developer can help smooth the transition for others.
The schedule is different:
The majority of my last two years of college were project-based classes, meaning that every two weeks or so I had a minor project due. There are, of course, still projects that have deadlines outside of school, but the big difference is how much there generally is to do between these deadlines. The workload of one class in college has to be balanced, so that a student taking more than one class actually has time to complete all of their work, at least ideally. This means that although there is always work to be done, it is possible through good planning to get ahead of your work and have some free time. When the deadline is for a work project, however, the deadline has been set
When the deadline is for a work project, however, the deadline has been set with an eight-hour work day in mind. Assuming that a single class takes 10-15 hours of work a week, the amount of work that can be completed in a work environment over that same week is at least twice as much. This apparent increase of work can be daunting. Luckily, the same skills learned when planning out the work for a week of school can be applied on a day-to-day basis for work projects. Just as with school projects, it is also important to take the time to plan your code, at least to some degree before starting.
Due largely to the scale of most academic projects, an experienced programmer can usually tackle the problem set forth with no formal planning session and meet with reasonable success. It is important for the work environment, however, to make efforts to plan your projects, classes, methods, etc before you start writing them. Not only does this lead to a more efficient use of your time at work, but it allows people like project managers and fellow programmers to follow along with your progress much more easily. Lastly, take mental breaks when needed in order to stay effective throughout the day; in a work environment, you may be working for more consecutive hours than you are used to, so give yourself five minutes to collect your thoughts if and when you need to.
You didn’t learn this yesterday:
Projects for work arise out of a need that the company has as a whole, and may cover topics that you’ve never worked on before, as compared to the classroom setting, where a project is assigned as a way of cementing the concepts that you have learned over the past few weeks. This was a large adjustment for me since there is a very real chance that at the beginning of a project, you don’t know all of the required information to complete it.
One of the most useful skills that I have picked up on the job is to learn not from the academic material, but from published documentation and even the code itself when no useful documentation exists. Although the ability to read and understand new code was certainly nurtured at school, it was never the case that it was necessary to do so in order to be able to use a necessary library or driver. Documentation comes only when published by the original code’s authors and since things like notes and lecture slides/videos don’t exist, some ingenuity is occasionally required. After coming to the realization that I may not know how to solve a particular problem that I am faced with and that it’s not due to a lack of focus on my part, I was able to become much more effective on the job. Admitting the limits of your own knowledge and learning to just look things up is a crucial skill in order to save both time and effort as a programmer.
Grades don’t exist (Yay?)
As someone who has at times struggled with getting good grades in school, the idea of entering and arena where they don’t exist was a big plus. Strangely enough, I soon began to miss them as a form of motivation. While in school, I always knew what grade I needed to maintain a good overall grade in my class, which gave me some concrete motivation. Outside of the classroom, however, these incentives just don’t exist in as obvious of a fashion. The quality of the work you do is measured in more abstract terms, such as the reactions of your managers and the efficiency of your code. Getting used to this change can be discouraging, but ultimately I found that it has lead to me writing better code because I want to, instead of because of an obligation to a grade-based system. Moreover,
Moreover, as stressful as it occasionally was, the looming threat of failing a class has gone away, meaning that the obvious consequence of writing bad code or not meeting a deadline has changed, though there are of course still consequences to such actions. It is also worth noting that paychecks can easily fill the void left by grades as an encouragement with the right frame of mind. Not only does the compensation that you receive from your employer allow you to live from day to day, but I choose to see it as biweekly congratulations and encouragement. At the end of the day, it is more important than ever to be able to motivate yourself and be satisfied by the work that you do, independently of the recognition you receive.
Other people WILL be reading your code:
Even though all of my professors stressed the importance of writing clean, well-documented code so that others can read and understand it, it is not nearly as crucial for schoolwork as it is in the professional world. In a system that is comprised of managers, code reviewers and teams of programmers, writing code that requires its author’s in-person explanation in order to be understood is not acceptable. To this end, the best strategy is perhaps not a novel idea; write all of your documentation right before you write the accompanying code.
Although it may seem like the time spent on documentation could and should be better spent just writing code, but it is important to consider the time that you will have to take explaining the code that you wrote months ago to someone completely unfamiliar with it. As someone who has had to do this before, it is a frustrating endeavor for everyone involved. Moreover, the code that you write on a daily basis likely needs to stand the test of time and lend itself to an extension in the future without having to review every line of the relevant code. This is just another circumstance that does not arise in school where every project is turned in and forgotten about.
The importance of code style may also be highly important in the workplace, which can prove frustrating to those who have well-established code style of their own that doesn’t align itself with that of the company. Plugins for your coding environment (be it a full IDE or a simple text editor) can be a real lifesaver in this regard, at least until new habits are developed.
And away we go…
As I end my career as a student and transition into being a full-time developer for the foreseeable future, I believe it is important to take a catalog of the habits I learned while in school, and remind myself that the two “worlds” of writing code differ only at first glance. Though nowhere near perfect, it is my belief that if you come from a formal education in programming, everything you learned in the classroom and during your studies as a whole can be applied in one way or another to the world of professional programming. This is also one of the reasons that I am glad that I have had to opportunity over the last year and a half to work near full-time hours while going to school part-time. The more focused environment of the workplace has most definitely helped me with my schoolwork, and as outlined above, I have found many ways in which my time in the UIUC Engineering program has made me a better Software Engineer.