It’s been nearly five months since I left my role as an Associate Lecturer at the University of St Andrews, and started my new career as a software developer at Dayshape. I spent the last ten years developing my skills as a computational astrophysicist: studying planet formation, astrobiology, and the search for intelligent life using a variety of semi-analytic and simulation techniques. Since February, I’ve been learning the ropes of a brand new industry, and it’s been a tremendously fun challenge.
I left academia for a variety of reasons, and I know there are many computer-literate academics out there contemplating their futures. Jumping out of the ivory tower can be quite a daunting experience. For many people, it’s their first time in the “real” world of work, and that makes the transition pretty scary. If you’re an academic thinking about moving into software development, here are some things I learned along the way that might help.
Learn To Use Version Control
Mortifying but true: I spent my first five years writing academic software without using any kind of version control. Each time I modified my code, I made a separate copy and stored it in a separate folder. I know, I’m a monster.
Not only will practising version control make you more employable, but it’ll make what you’re currently doing much easier to manage, and you’ll be more productive. I finally picked up Git around 2012, and immediately found it was worth the effort. In fact, I accidentally deleted my code about a week after starting to use it. Because I had a remote code repository, I was able to rescue it easily. That was months of work saved!
At Dayshape, we have around 20 developers working on various parts of the codebase – we simply couldn’t function without Git.
Think about what language you’re currently writing in
In academia, my first languages were Fortran and IDL. I occasionally broke out MATLAB in desperate circumstances. I picked up C++ and Python around the time I started using Git. It was a conscious decision on my part, a recognition that the languages I worked with at the time weren’t well used outside of the field. It’s no coincidence that all the interviews I had for software companies were on the back of my C++/Python expertise.
It’s worth considering what languages are currently in your armoury. You don’t need to precisely match the software requirements/tech stack of a company, but having a C-esque language and a scripting language is very helpful, and will cover a lot of bases. Some practical experience with databases is also good (brush up on your SQL!). I also started reading articles around agile software development practices to see what being a dev was actually like, and if I was missing anything I should learn about (I heartily recommend dev.to if you haven’t found it already).
Dayshape’ developers primarily use C#/.NET (and a little Java) for the backend of their products. I joined Dayshape having never written a line of C#, but I had 6 years’ C++ experience as a way in, and now C# is my bread and butter.
Your CV needs more work than you think
You might think the CV you wrote for academic jobs will be easily re-purposed for a broader job search, but it won’t. The biggest issue is that a lot of the things that academics prize aren’t that important to other employers. Having a complete list of publications can be a hindrance, not a help! The next biggest issue is that what employers value is probably already in your CV, but it’s wrapped up in terminology that they don’t readily understand. Ask people “on the outside” if your CV gets across what you want it to.
Remember: software companies want you because of your ability to learn, your problem solving skills, networking, time management, collaborative ability, adaptability and (ultimately) leadership potential.
Stroll out, don’t jump out
My decision to change careers came at a fortunate time. I had at least nine months left on my contract, so I had plenty of time to plan my departure and search for jobs. It takes time to get your skills to the right level, craft your CV, set up your LinkedIn and website (you don’t have a website?!?!). You’ll need to cultivate relationships with future employers (getting in touch with recruiters before submitting an application is really important). You’ll probably have to submit a lot of applications (in this respect, industry is just the same as academia).
All this means that you need to start the process of leaving earlier than you might think!
Never stop learning
Once you’re out of academia and into software development, you’ll soon see that software developers have very similar instincts to academic researchers. I don’t think it’s a coincidence that around 20% of the Dayshape dev team have PhDs. The team has a deep reverence for careful modelling and planning, a strong desire for self-improvement, and a real appetite for learning. New tools and concepts pop up all the time, and it’s crucial that software companies keep abreast of them. Choosing the right tool for the job is absolutely essential for high-performance software that clients want to use!
Personally, I found this atmosphere very reassuring as I finally left full-time education (after decades inside). I’m still surrounded by intelligent, funny people with fascinating points of view, with the massive plus that we’re not all competing for a single permanent post, as we would have been in academia. Instead, we’re all working towards the same goal – software that eliminates wasted effort, and makes people happier.
If you’re planning to escape academia and want to know more about Dayshape, let me know!