As most of the regular readers know, I have moved from coding in a university to coding in a financial tech firm in central London. I used to think that I was a good programmer. However, industry has knocked some bad habits out of me that I didn’t even know I had. It’s not that academics are stupid, it’s that they have a different set of goals. An academic wants to find the answer to something and then write it up in a paper. The code can be awful, as long as it runs and finds the answer in a correct fashion they’ve done their job. Of course, there are some acceptions, there are academic departments that are looking into the speed of computations, however, most academics I know and worked with couldn’t care less about the code as long as it got there in the end. However, if you’re thinking of moving into industry here are 4 things that you’ll find challenging:

functions functions functions!

In academia, we did use functions. However, we only really used them to stop repeating a lot of code. This is because a problem in academia can generally be solved by one lengthy script. It usually doesn’t communicate with other scripts so conflicts are rare. However, in industry, you are usually coding a platform that can be used in a range of ways. In order for this platform to work, there has to be a whole range of files that talk to each other. Because of this, everything is coded in functions and classes. If not, there will be loads of conflicts. Furthermore, these functions have to be as multipurpose as possible to save you repeating functions with slight variances.

Speed

In academia, speed was not that important. In fact, I still talk to academics now who admit that they have to run their script for half a day before they get the result. Part of it is the problem that they are working on. This has become more of an issue with big data. However, a lot of it is down to not having the incentive to improve the speed. So what if it takes half a day to execute? This is different in industry. Before I was happy assigning multiple variables whenever I needed to. And whenever I needed data I just made a call to the database. However, my seniors in industry knocked this out of me. Multiple calls to the database? Consider that delay multiplied by every customer using the platform. That’s a lot of unnecessary strain on the server. Every person I met who has made the transfer from academia to industry has always sited this as one of the biggest shocks that they had to get used to. This makes sense. After all, just because a surgical academic publishes loads of papers, it doesn’t mean that you want him doing your surgery. Even listening to other members of the surgical team and the patient will affect the outcome of the surgery. I’d strongly stand by the statement that because someone coded something in an academic setting, it doesn’t mean they are a good choice for coding it in industry.

Clean Code 

In academia, I was mainly working on my own code. My supervisor was considered advanced because he wanted my code on Github. Most academics I know worked on a script and only told their supervisors when they had the results or were stuck. In industry, we have two-week sprints. The team gets together and the lead developer allocates a range of tasks to each developer and they work on them. I could spend a couple of days working on a function. Once the task is done I push it on Git, and the senior developer reviews it. If it’s up to scratch he will then allow it to be merged. Next week another developer may be using the function that I refined for one of his tasks. Because of this reusability, the code has to be clean, the documentation has to make sense, and all functions I end up coding have a doc string explaining the inputs and outputs. This was also a big culture shock for me.

Versatility 

In academia, the code is only run by a select group of people who have the same goal as you. Does a particular input crash the system? Just tell the team to put in sensible inputs. However, this doesn’t work in industry. Usually, your users are members of the public. They don’t have the same interests and sometimes their desires are opposite to what you want. They want to abuse your system for something that you didn’t intend it for. Therefore your testing is a job in itself. You have to develop robust code that can withstand a range of inputs. If the code breaks, you can guarantee that a user will also break it. A lot of time has been burned trying to protect a new function against all types of strange extreme inputs. Testing goes to a whole other level.