Despite the nature of research, I find it challenging to stay up-to-date with new software engineering technology, tools, techniques, and practices. Now, there’s plenty of software development (or programming, really) in my research, but it’s almost always (a) very small scale software written to test some design or illustrate a proof of concept, and (b) written with my standard go-to languages such as C, Java, or Python. There’s no way around problem (a) – research code will always exist for this purpose. That’s why research code is distinctly not the same as production or industry code.
On the other hand, problem (b) can be addressed but with great risk. I was once told by Zack Butler at RIT that the best way to learn a new language is to solve one of your current problems or projects using it. This is obvious: experience is the best teacher. There is no technical reason why I use C, Java, or Python for my research code – it’s all about agility. I am more adept in these languages and can reach the end result much quicker. With artificial paper deadlines imposed by conference submission or advisor-mandated deadlines, this agility is very important. The risk in exploring a new language with each research project is loss of this agility and, in severe cases, failure, leading to a need to restart from scratch.
This doesn’t even address the problem of emerging technologies, techniques, or practices. The professional software community seems to be intensely focused on web development. The rate at which new frameworks spawn is astonishing, and it seems almost infeasible to stay up to date as a student with other priorities. How can I justify spending time learning the Meteor.JS or Ionic frameworks when I have research code to develop and papers to read and write? There’s simply not enough time in the day for everything.
This may be fine, though, depending on your outlook. If you are confident in your dedication to research and academia, you have no immediate need or obligation to be learning these new tools. However, if you think that you might want to one day go back to industry, becoming stale as a researcher can be worrisome. Personally, I find myself somewhere in the middle, with aspirations of ending up working in a professional research lab similar to PARC. Consequently, I find it important to stay up to date with everything in the field. It may not be ever be useful, but it does have one important benefit: it forces me to maintain an industry- and product-driven mindset about software.
My biggest fear when doing my Ph.D. is that I might forget what it means to write software professionally. Being engulfed in research code can make a skilled engineer rot (technically speaking). Completing my Ph.D. teaches me how to conduct research, so I have to teach (and re-teach) myself how to be a professional programmer. So how do I stay fresh while still meeting my research goals? The following set of tasks work for me:
These don’t consume a large part of my day. In fact, I do them every morning while drinking coffee at Starbucks. After I’m done, I move on to my professional research activities. With proper time management, it’s fairly easy to tackle each of these tasks every day. They keep me from becoming stale in a quickly evolving field, they force me to read and write large amounts of code (remember, experience is the best teacher), and they give me greatly needed context switch to pull me out of the research bubble and back into the real world. After all, the research I do will never end up being useful if its never made available for society to see and use. This highly optimistic mindset is what carries me through my Ph.D. career.