5 things the dev world has in common with the academic world (in my experience)

It's been roughly three years since I finished my PhD thesis on Finnish and Russian time adverbials (Available here, if you're curious) and decided to try switching careers into web development. One of the reasons I believed the switch was possible was the fact that the two fields, it seemed to me, had a lot in common. I felt that having worked as a doctoral student conducting quantitative research gave me good grounds for working as a developer, too.

Three years in, I'm happy to say I wasn't completely wrong. Here's a short collection of some of the things I have found similar between my two careers.

1. Learning to work with others

There's an old stereotype about researchers sitting alone in their ivory towers, working years on a problem before finally presenting their findings to the outside world. While, of course, far from accurate, the stereotype had some truth in the way I used to work or at least how I started as a young PhD candidate.

I had an idea about my research questions and how I wanted to find answers to them. I felt I was doing my own niche thing and becoming an expert in it and just wanted to gather data, analyze it, present my findings in one 700-page monograph and run away from any possible comments, feedback and questions people might have about it.

Of course, that is not the way the academic world operates. The sooner and more you get feedback, the better. The sooner you start co-writing articles and presentations, the better. And the more you take advantage of your opportunities to present your work, be it at small seminars or large conferences, the better.

Surprising or not, growing up as a researcher was pretty similar in this respect as growing up as developer has been. Starting out, I kind of expected myself to be able just to keep coding all day, every now and then publishing what I have done for the users of the software to start playing with. It did not take long for me to realize that I would have to show my code to others a lot more often than I originally anticipated. And just as in the research community, getting feedback often and early turned out to be extremely valuable.

Here's a straight up comparison:

2. Finding out about stuff you don't know

Researching is not called researching for no reason: you are constantly learning new stuff and you constantly need to find out about things. The same holds, to a surprising extent, true for development work. Starting out as a developer, I used to be constantly ashamed of having to look something up: not remembering, say, the difference between sessionStorage and localStorage, having not heard about some sql window function, googling for setting up reverse proxy in nginx... Growing up as a developer has not meant learning all that stuff by heart (although some learning has, hopefully, happened) but rather getting used to the fact that you can never know everything and being always ready to ask the potentially dumb-sounding question.

One thing I miss from the academic world is finding your answers from the pages of peer-reviewed journals and other publications. Sure, the dev world has stack overflow with its voting system (well, of course academia.stackexchange.com is a thing, too), but it just doesn't get up to the standards of reading a thoroughly written , thoroughly reviewed, revised-and-corrected presentation that cites sources and is further cited by others. Of course, there is the academic side of coding, but in my day-to-day job that is, unfortunately, not the way I get my information.

3. Supporting / following a school of thought or theory

As a young linguist I used to look up to the representatives of generative linguistics, the Chomskyans pursuing a genetically based universal grammar. Later on I began to question those assumptions and started to gain interest in usage-based (Bybee et al) approaches and construction grammar (Fillmore, Goldberg etc). That kind of progression is natural and expected in the academia: you hear and read about theories, correct and revise your assumptions, perhaps come back to your old assumptions, hear about new ones..

Funny enough, the same phenomenon exists in the dev world, too. You have your debates between functional programmers and OOP people, supporters of different frameworks and philosophies and, yes, even schools such as the London vs classicist schools in unit testing. Just as I was fascinated with radical new approaches and ideas in linguistics I am fascinated with what is happening in the dev world. Perhaps what I kind of miss from the academic world is the fact that there it is harder not to have a well thought-out position on the underlying assumptions of your day-to-day work: in the dev world, it feels like people often just code along without having made any conscious decisions about why they follow the principles they follow.

4. Keeping track of your time

To be honest, one of the things I used to envy developers (and any normal office workers) for, was their regular working times and steady, predictable rhythm in their work life. As a researcher, you have to be constantly applying for money and you are working in projects of predefined length. In my case, I had to write down how I spent my time: how many hours of teaching, how many hours of studying, how much research etc. You had 1623 hours per year that you were supposed to use and it was pretty much up to you to decide how you used those to balance your work and free time / holidays.

Becoming a developer has definitely made it easier to create a typical 8am-to-4pm / Monday-to-Friday type balance, which I do appreciate. However, working as a consultant, I definitely haven't escaped working in projects and tracking my time! A pleasant difference, though, is the fact that I am not the one writing applications and trying to find the money for the projects.

5. Tools

This last commonality might be something that is not true for many others switching from the academia to software development. Your typical academic - at least in the humanities - probably writes his/her stuff with MS Word, perhaps using tools like Mendeley, SPSS and Elan on the side. I started writing my research in Latex but later on moved to a format called Rmarkdown. The most important thing about those formats is the fact that you can right plain text files, which opens the doors to using a system usually only known in the dev world: version control. A year or two into my research I started committing all my research contributions into a git repository, started branches when I was trying new approaches and created GitHub issues representing problems I needed to solve.

Version control and plain-text-based formats is something I really think the academic world should borrow from the dev world and embrace. For researchers and for people reviewing your research having a good, diffable, version history and a format that compiles the same for everybody would be extremely valuable.

Oh, and I bet I was the only one at my faculty who wrote their entire thesis with Vim. In that sense, nothing has changed in my life: I start my day by opening a terminal, hit :wq at the end of the day and publish my changes to a remote repository before closing the lid of my laptop.