Moving from academic to practical code

Introduction

It shocks me to say that It’s now been 2 years since I graduated. The time that feels like only last summer’s memories, has whirled by. Leaving me with that confused feeling, similar to that of having to find that annoying zoom unmute button at short notice.

A common agreement is programming in academia isn’t the same as programming in industry. Whilst it's true that four years of programming theoretical questions, mainly involving console string interpellation, isn’t going to help you implement a Heroku hosted web application, there are some core fundamental skills and principles that do carry over.

With it now being over a year in this role. I can take some time to reflect on just how divergent my style of coding has become since summer 2018. My approach, attitude, thinking methodologies and even languages have all changed so quickly. I wanted to write about just a few ways I have changed.

Full specifications

In academia, a student will normally be provided with an exact description of the problem, the proposed solution, where to get marks, what to avoid, and hints for added complexity to get more marks. These specifications have been curated and refined over numerous years, reaching levels of detail from years of students asking all the questions necessary to leave little to the unknown.

Industry has taught me that specifications will vary in their level of comprehensiveness. Specifications can be ambiguous, key features will be mentioned in passing, and requested features will vary vastly in complexity. This isn’t necessarily a negative. It gives freedom to flex some creativity and introduce ideas, features and concepts that develop the proposal to a richer solution. However, it requires a degree of patience and organisation. Spending time to format all my questions and unknowns in emails or meetings. Especially to non-technical customers.

Taking pride in the code you write

Academic coding was always built to meet the needs of a single person. The reviewer. The code I was writing was written in a style that I knew the reviewer would see themselves as “good code”. The naming of variables, the order of functions and how code executes. This teaches good practice principles, but can often be forgotten as the submission is often never looked at again. Tests and maintainable code are never really considered in academia. The transition over to industry standard coding practices has taught me the code you write should first and foremost be code you know can be understood when returned too. Client responses and feedback is often spaced out, so the learning curve of finding yourself coming back to code a few weeks old and not recalling much is a common occurrence. Additionally, code I'm now writing tries to follow the defined convention practices. This is so other developers can understand the code I've written, and I can understand code they write too.

Differing coding purposes

A key difference between academic and industry software engineers is the lack of a “product” for customers. Academic code is often built to prove a point or showcase that something can be done. Often neglecting aspects of design, user experience and testing in favour of results and solutions. In contrast, in my industry my work as a software engineer is analysing purpose, accessibility, and ease of use. Academia is often focused on the “theoretics and science of programming” where in contrast industry my focus has been on utilising tools and frameworks to produce things to be used by a wider audience.

The transition has certainly had underlying similarities, which add an aura of familiarity to what my daily work revolves around. However, I found my focus changing since becoming a developer, with 40-60% of my time on new duties such as gathering and analysing requirements, testing, and prototyping. Something of which I was mainly told about rather than experience fully during my degree.

Working towards a common goal

Any university graduate can tell you a story of a group project, no matter the subject. With students not collaborating, missed deadlines and late-night scrambles a few hours before the deadline. I often wondered why is it that these team projects don’t work, whilst others achieve astronomical success. The pivotal point in the effectiveness of the team, was in working together towards a common goal. I haven’t been in my role long, but the huge point of the software engineering methodology is shared ownership. By building an effective team, who can work to each other’s strengths and weaknesses the process can combine into an efficient and effective machine. Reviewing and maintaining each other's code not only gives a deeper sense of ownership. It allows the team to have an understanding of all features of a system. Allowing for better planning and more effective collaboration.

The sizeable point of difference the software engineering methodology has to those group projects is shared ownership. Each member of our team feels responsible for an aspect of a system. Our work is intertwined with the help of a version control system merging our work together. This practise encourages responsibility and efficient collaboration as we all want to see the parts we developed working. Both in a sense individually and part of a wider scope. Often academic group projects were stagnated, with work being split up but only really brought together in a rush at the end. By taking on and learning effective working practises. I can now see how we help overcome that as a team. With continuous review of features encouraged and committing changes into the mainstream of work giving a sense of shared ownership. This brings about an opportunity to not only collaborate our individual work, but review and learn from others too.

I do see sense in the phrase that there are huge differences with the academic and industrial work. But there are practices every day that I find myself reflecting on that help me in performing my role. The fundamentals and the feedback given has no doubt led me to be the programmer I am today. But at no point does the learning ever end.