I recently visited the University of Maryland
to give a colloquium
(slides here).
This was my first in-person colloquium as faculty because of COVID.
I had a great meeting with the grad students over lunch, and they asked several good
questions. I've thought over some of them a little more and wanted to fill out my answers.
I'll paraphrase two questions:
"How do you balance coding work with other research work?"
My answer was essentially, "All of my coding work is research work - I don't write
code that doesn't contribute to my research." That is broadly true, but not exclusively
so, and there are some exceptions.
All of the coding work I have done has been either to enable my research, support
someone else's research, enable my research career, or (in theory) make my life easier.
The research stuff is mostly obvious - my work on and with data reduction software
(see all the CASA-tagged blog posts here, all development on radio-astro-tools, etc),
pyspeckit, and most of astroquery. On the astroquery side, a lot of my research work
wasn't directly going to papers, but was instead to dig through the archives to see
if data were available, or if I needed to obtain new data. It was then useful
for supporting observing proposal writing.
The "enable my research career" component included a lot of side-work on things
that aren't directly research, but are research-adjacent. These projects
included building tools to deploy my papers to github (which was a bit
obsoleted by overleaf), automatically updating reference lists (it turns
out I often cite 5-10 arXiv papers in an article, but by publication time, I
need to update them to official journal article citations), assemble lists of
coauthors, add citation counts to the CV, writing this
blog, etc.
The exceptions are some of the 'pure service' coding. This necessarily had to
be the lowest priority most of the time, but this is still career-motivated.
Some of the contributions I've made to astropy & other open-source projects are
just to improve their code bases, either with bugfixes, added features, or
things to improve robustness. Most of my contributions were directly motivated
by need, of course - either there was something basic missing, or I was the
expert in that particular subtopic. A good example is the J-to-K equivalency;
it wasn't directly research-motivated, but was something I found myself needing
in day-to-day work.
The 'pure service' coding also entails maintaining projects. There is still a
selfish motivation here: if the code is maintained (if other people are using
iti and finding bugs), it is more likely to be functional when I need it next.
But, most of this work isn't triggered by my own needs, but by others.
The astropy Moore grant now funds some of this work, which helps ensure that
I'm motivated to continue the maintenance - but I was doing a lot of this work
as a postdoc long before I could be directly paid for it.
"How do you avoid being typecast as a coder?"
This question came from students who got to be known in their research
collaborations as "good at coding". My answer was basically, "learn to say
no", but there's more nuance to add.
First, there are some solid career paths to follow by being the science coder
in a group. Many observatory jobs, for example, would prioritize this coding
experience. There are a lot of positions in observatory jobs at places
like STSCI, NRAO, NOAO, etc. that value this sort of skill over many others.
So if you want to pursue one of these paths, or an industry path, because
you <i> enjoy </i> the coding, then great! Do it!
If you really enjoy the coding, you'll get to do a lot more of it in a job
focused on software development than in an R1 research job.
That said, if you are interested in pursuing an R1 faculty job, you need to
strike a more careful balance. It's fine if you're the coder in the group -
that can land you a coauthorship on a lot of papers, which is a good thing!
However, first and foremost, you need to publish your own (first-author)
papers, which means prioritizing your work over collaborative work. Ideally,
you'd just do both - that's what's expected of faculty members (faculty members
can't choose to prioritize teaching or research, really - they have to do well
at both, which often means just putting in more hours). But if you're faced
with the choice, a few first-author papers are more important than many
co-author papers.
The way I struck the balance was to focus entirely on research papers during my
grad school career, but still do a lot of software support work on the side - I
put in more time, but it was all stuff that was useful both for me and for
collaborators. Later, in my second postdoc, I started publishing code-only
papers; I would advise grad students to do this sooner, though. Since AAS
journals now accept code papers, if you want coding to be a big part of your
research portfolio, it's a good idea to have a refereed paper on a piece of
software. Note that some of the most highly-cited papers in astronomy are code
papers, like the DAOPHOT, SEXTRACTOR, and astropy papers.
Last bit of advice closing this out: Avoid GUI development. That way lays madness.
