Not only is this about the tools that I used to complete my PhD, but I am optimistic that these tools/coping mechanisms will allow me to be a scientist that gets paid for doing science.

The tips & tricks:

Remote work: Working remotely accommodated the variability in my functioning levels, and allowed me to be as productive as possible without having to allocate most of my energy to getting to/working at a physical location or trying to conserve enough energy so that I could make it home on the bus (since I can’t drive anymore).

Ergonomics: Finding what triggered more discomfort and what allowed me to work for longer periods of time really helped make it possible for me to finish up.

Laptop of Science & a desktop, running Synergy to run one mouse and keyboard for both computers.

Monitor risers to prevent fatigue.

Kneeling chair to avoid obnoxious pressure points on hips, back and arms.

Wrist rests galore.

Kinesis Freestyle 2 keyboards, one for desk work with the dual machine setup, one for a reclining setup with just the Laptop of Science.)

Travel: Travel is dreadful. It involves a lot of discomfort while traveling, plus a lot of discomfort for weeks after. The thing that I am traveling for had better provide enough benefits to me that it is actually worth it because it is truly, truly unpleasant (of the crying and vomiting from pain variety). Remote attendance is vastly preferred.

Wheelchair service in airports/Redcap on trains. (Voice of Experience: When you are asked if you can get to places on your own, up stairs, etc., select “no” if the answer is “yes, but it will be exceptionally unpleasant and there may be crying, whimpering, or falling over”.)

Rest day after travel/accommodations really close to wherever you are supposed to be.

Electric blanket for hotel (as full body heat pad)\

Small travel blanket (for padding uncomfortable chair backs, etc.)

The technology:

Version control: Using version control (I used GitHub) allowed for a more efficient workflow between me & dissertation collaborators (mostly Ethan, but also Xiao Xiao), plus I was insulated against the effects of cognitive dysfunction through commit messages, issues, and the ability to revert commits.

Kubi: A teleconferencing robot that allowed me to turn my (remote) head and look at people when they were speaking through whatever teleconferencing system we were using. I cannot say enough good things about how much this made me feel more like a part of whatever was going on.

Web conferencing: We tended to use browser based options Google Hangouts or Firefox Hello for this, but Skype is another option as well, I just had some difficulty getting it to behave well on my laptop.

Live-streaming: For my defense, I wanted to make the presentation a demonstration of making a talk accessible, and also how easy this can be. Full details of the accommodations & accessibility statement that I used for my defense are available on the event announcement. I used Google Hangouts on Air to live-stream my defense, then close captioned the talk afterward with the editor available on YouTube. This was all straightforward and took very little time. Handouts were available in advance of the talk, and an accessibility statement was provided with my defense announcement.

For the last 5 years I’ve been actively involved in training efforts through Software Carpentry and Data Carpentry to train researchers in best practices for software development and data analysis. These are concepts that are fundamental to the research we do in my gropu and my commitment to open and reproducible research.

For those of you who aren’t familiar with Data Carpentry, we are a non-profit organization whose goal is to help teach scientists the skills they need to manage and analyze the increasingly large amounts of data that are being generated across the sciences. We do this through a combination of 2 day workshops at universities (if you’re interested in a workshop at your university request one here), and online resources including lesson material and forums. Data Carpentry is both similar to, and associated with, Software Carpentry, but with an emphasis on teaching material that is specific to particular scientific disciplines and focused on data management and analysis. We currently deliver courses for ecology/organismal biology and are in the process of developing material on genomics and geospatial data. The later in collaboration with awesome training group at NEON.

The support from the Moore Foundation will help us expand our efforts to cover new scientific domains, run far more workshops than we could have otherwise, and develop strategies for delivering this material in online workshops. I will also be leading the development of a semester long Data Carpentry course designed to make it easy to integrate these crucial skills into university classrooms. Check out the full proposal for more details.

I look forward to continuing my work with Data Carpentry and am excited about the opportunity for us to continue to enable data-intensive science by providing scientists the computational and data-oriented training they need to work with the large quantities of data we now have access to.

This is a guest post by Elita Baldridge (@elitabaldridge). She is a recently finished PhD in our group who has been navigating the development of a chronic illness during graduate school and beyond.

This is the second in a series of posts about my experiences completing a PhD with a chronic illness (Part 1, see also these two earlier, posts).

As I mentioned in the first post, having a chronic illness means that there can a lot of problems hiding behind the cheerful facade of graduate students you know. Here I describe some of the external challenges faced by people with chronic illness and disabilities that can be a much greater stumbling block than the condition itself.

Because I had such strong support from my family and my lab, I didn’t have to worry about the majority of these challenges. I didn’t have to worry about finances, losing health insurance, not being able to afford medical care, having to be on campus, able to work a regular schedule. Thus, I just had to deal with the physical challenges, and I could invest most of my energy into my research.

Finances/health insurance: Being able to afford medical care as well as paying for all of the regular expenses of being a PhD students can be extremely difficult. Although many PhD programs offer subsidized insurance, the long process of diagnosis, combined with extensive medical tests, plus the expense of treatment can leave massive amounts of medical debt. These issues can be magnified if a leave of absence is necessary, which typically eliminates both salary and insurance. Additionally, during a leave of absence, any student loans come out of deferment, making a leave of absence extremely challenging to take, and a chronic illness is unlikely to improve with a leave of absence with the added financial stress. I have a husband, who has health insurance for the both of us, and we were able to move in with my parents, and this was a situation that has been actually really great for everyone. This completely removed financial/health insurance worries from the picture, and there is always someone around for me just in case.

Advisor support: A good advisor is important for all graduate students, but it becomes especially important when dealing with a chronic illness. There are many stories of graduate students who have struggled way more than neccessary due to unsupportive advisors, or unsupportive university structures. (e.g., 1, 2, 3). The Weecology lab is awesome, and just made accommodations happen. In a later post, I’ll talk about some of the technological tools that made completing my PhD possible, but my favorite was the Kubi (https://revolverobotics.com/), which let me turn my own “head” when I was remoting in. Ethan also was my advocate at the university level, to make things happen so that I could work remotely to finish up.

Working: Chronic illness can result in many factors that make getting work done challenging, from the difficulty of getting to work, due to an inability to drive, chronic fatigue, medication effects, cognitive dysfunction, or being worn down by pain and discomfort. Even the physical environment of work can be challenging; for example, fluorescent lighting that triggers migraines. Getting to campus was taxing enough that by the time I got there, I was too worn out to get much done, and would have to leave early before I broke down. I also had to surrender my driver’s license, so I relied on public transportation (which caused a significant amount of “discomfort”) or I needed to get a ride from my husband (which caused slightly less “discomfort”). In addition, I have flares, so I’m good to work some days, but then am unable to function either physically or mentally some days. University campuses also tend to have some major accessibility problems. I was fortunate in that my office and the lab that I taught in were on the first floor, but when I returned for my defense I had to get to the second floor of a building with a broken elevator. Working remotely allowed me to set up my workspace so that I could work longer, and didn’t have to use up all my available energy going to campus to work.

Medical: Many chronic conditions require frequent medical care, through monitoring or trying out treatment options. My condition is chronic, but not progressive, and so I didn’t actually need a lot of medical care after I got my diagnosis. We’d figured out a treatment that worked before then, and I had a great doctor (USU Student Health Center is awesome, particularly Dr. Price). Thus, I didn’t need to spend a lot of time at doctor’s appointments, which for me would end up writing off an entire day, and then generally take the next day to recover from the appointment. Before my diagnosis, I was spending a lot of time at the doctor, experimenting with new medications, to see if they would have an effect, being poked more times than a pincushion, and waiting to see specialists.

Medication: Medications for chronic illness can have a lot of unpleasant side effects, including nausea, headaches, appetite loss, insomnia, fatigue, immune suppression, etc. Some of us end of taking medication to treat the side effects of the medication we are on to treat our condition. Most of the treatment options for fibromyalgia work by altering levels of neurotransmitters, and thus tend to be difficult to adjust to, have a long adjustment period, and make working while adjusting impossible. In addition, the beneficial effects generally wear off over time, leaving just the negatives, which happened with the first medication I was on. Because I didn’t have months to spend trying to find another medication that might work, and I was getting work done without medication, I saved that until after I was done with my PhD. I’ve spent the last two months dealing with adjusting to a fibromyalgia treatment I haven’t tried before, am minimally functional, and it seems as if this treatment option is worse than the fibromyalgia on its own. Because fibromyalgia is variable, I still have another two months to go to make sure that the medication is not effective, or whether I could be in a flare instead.

I am working on organizing an Inclusive Ecology Section within the Ecological Society of America. This section will provide resources and support for all ecologists, regardless of race, sex, physical or mental ability or difference, gender identity or expression, sexual orientation, ethnicity, socio-economic status, culture or subculture, national origin, parental status, politics, religion, or age. The Inclusive Ecology section will be a space for ecologists to learn about issues and problems facing ecologists from under-represented groups, share support and solutions about problems facing ecologists from under-represented groups, work to make ecology a safe and inclusive space for all ecologists, and recognize those who have made significant contributions toward working to make ecology more inclusive to all ecologists.

The first stage in creating a new section is to collect 50 ESA member signatures on petition. If you’d like to support the idea of this section please sign the petition here:

Most people aren’t familiar with the challenges of working on a PhD with a disability or chronic illness, and yet there’s a good chance that someone you know is in this situation and isn’t talking about it. This is the first in a series of posts about my experiences completing a PhD with a chronic illness, and about the things that we can do to support our colleagues and students so that they can have the greatest chance at success. Even with the best support in the world, it’s not always possible, but it’s a lot less likely without support.

A lack of support and accommodations is a major factor in people being unable to function effectively.

The biggest thing that keeps me from functioning effectively at this point (with accommodations) is my chronic illness itself. However, that’s the most disabling factor for me because I had the accommodations available to reduce the impact of my condition as much as possible.

Personal challenges

This is the sanitized, short version of some of my symptoms. I don’t particularly like to share these sorts of things because I want to be seen as a good ecologist, not as an inspiring story of an ecologist that has triumphed over terrible odds. An ecologist is a person, a story is a thing. However, I think that it’s important to understand that while your colleague may be cheerful and smiling and upbeat, they may also be hiding a lot, and being kind and providing accommodations is a small thing that can mean the world under the circumstances.

Cognitive dysfunction: This manifests itself in many ways, but when this is severe, I can’t actually think well enough to read anything more complicated than fairy tales, let alone think well enough to do research.

“Discomfort”: Pain is supposed to be a meaningful signal that something is wrong with the part of the body that hurts. However, with fibromyalgia, things hurt without damage occurring. Pain from fibromyalgia tends to be unresponsive to a wide variety of medications, and one of the best ways of managing the pain is through an exercise regime and visualization. I tend to use the word “discomfort” rather than “pain”, because pain is supposed to be a useful signal of damage, fibromyalgia pain is not useful, and calling it discomfort helps me to try ignore it more effectively.

The clothing thing: The majority of clothing does not work for me any more, because of the feeling of wearing an upset anthill.

The stinging nettle thing: Doing computer work while hands felt like I had been crushing stinging nettles with them.

The bucket thing: Keeping a bucket by my desk while I working, because I was throwing up because of discomfort. Also, avoiding eating before meetings on bad days, so I could make it through the meeting without throwing up into the bucket.

Mobility impairment: This depends on the day. Not a problem at a computer though, so that’s fine, unless on site and the mobility impairment access is garbage (i.e., mostly everywhere).

With sufficient support and accommodations, it is possible to do good science and get a PhD while living with a disability or chronic illness. Dealing with the illness itself is difficult enough, without also having to address barriers that are put in place by people and institutions not working to make things accessible. It’s not that difficult to make things more accessible, and making things more accessible for folks with chronic illness or disabilities also tends to be just good design that makes things more accessible to people without chronic illness or disabilities. Over the next couple of posts I’ll talk about things my lab and university have done to make things more accessible and therefore facilitate my PhD. I’ll also talk about practices that I’m now putting in place for things like seminars I give to make sure that they can reach as many scientists as possible, not just the able-bodied ones.

A few months ago Mick Watson wrote an awesome post about How to recruit a good bioinformatician. We’re in the process of hiring a scientific software engineer so I thought I’d use Mick’s post to illustrate why you should come work with us doing scientific software development and data-intensive research, and hopefully provide a concrete demonstration of the sort of things Mick suggests for appealing to talented computational folks.

Here are Mick’s original suggestions and why I think our position satisfies them.

1. Make sure they have something interesting to do

This is vital. Do you have a really cool research project? Do you have ideas, testable hypotheses, potential new discoveries? Is bioinformatics key to this process and do you recognise that only by integrating bioinformatics into your group will it be possible to realise your scientific vision, to answer those amazing questions?

Software and computational data analysis are core to everything our group does. Just check out our GitHub organization. We’re currently tackling challenging problems in: 1) automatically acquiring and combining heterogenous data; 2) combining large numbers of datasets into single research projects; 3) using machine learning and other computationally intensive modeling approaches to make predictions for ecological systems; and 4) trying to help improve computational and predictive approaches in science more broadly.

2. Make sure they have a good environment to work in

Bioinformatics is unique, I think, in that you can start the day not knowing how to do something, and by the end of the day, be able to do that thing competently. Most bioinformaticians are collaborative and open and willing to help one another. This is fantastic. So a new bioinformatician will want to know: what other bioinformatics groups are around? Is there a journal club? Is there a monthly regional bioinformatics meeting? Are there peers I can talk to, to gain and give help and support?

Or will I be alone in the basement with the servers?

Many members of my group have strong computational and/or machine learning backgrounds (at least for a bunch of scientists). We are also part of the new Informatics Institute at the University of Florida, which is being funded in part through UF’s “Big Data” preeminence initiative. The Informatics Institute brings together faculty, students, and postdocs from across campus with interests in computational science, and the preeminence initiative is recruiting mid-career folks in this area to move to UF (including myself). I’m also a Moore Investigator in Data Driven Discovery and actively involved in the Software Carpentry and Data Carpentry communities, providing strong connections to researchers and developers in all three of these groups. In short, the challenge won’t be finding people to interact with, it will be finding time to interact with all of the different folks you want to talk to.

Speaking of servers, the other type of environment bioinformaticians need is access to good compute resources. Does your institution have HPC? Is there a cluster with enough grunt to get most tasks done? Is there a sys/admin who understands Linux?

Or were you hoping to give them the laptop your student just handed back after having used it during their 4 year PhD? The one with WIndows 2000 on it?

The University of Florida has a brand new high performance computing platform – the HiPerGator. My lab has priority access to a large number of cores on this system. We also have experience working with, and resources to support, AWS and other cloud providers to address our resource needs.

4. Give them a development path

Bioinformaticians love opportunities to learn, both new technical skills and new scientific skills. They work best when they are embedded fully in the research process, are able to have input into study design, are involved throughout data generation and (of course) the data analysis. They want to be allowed to make the discoveries and write the papers. Is this going to be possible? Could you imagine, in your group, a bioinformatician writing a first author paper?

Technical and scientific development is strongly encouraged and supported for all members of our research group. You’ll have time and encouragement to learn new skills, support for travel to training/hackathons/conferences, and active engagement in both the scientific and software development aspects of the lab. Taking the lead on projects and writing first authored papers would be enthusiastically supported for anyone interested in doing so.

5. Pay them what they’re worth

This is perhaps the most controversial, but the laws of supply and demand are at play here. Whenever something is in short supply, the cost of that something goes up. Pay it. If you don’t, someone else will.

We’re doing our best. The position has a top starting salary of $70,000. Thanks to the low cost of living in Gainesville that’s equivalent to about $120,000 in Silicon Valley. We can’t compete with starting salaries for industry, but at least we’re on par with starting salaries for faculty.

6. Drop your standards

Especially true in academia. Does the job description/pay grade demand a PhD? You know what? I don’t have a PhD, and I’m doing OK (group leader for 11 years, over 60 publications, several million in grants won). Take a chance. A PhD isn’t everything

I don’t consider not requiring a PhD to be dropping my standards. We’re looking for the best person whether they have a PhD or not. If you’re good at computers and interested in science, I don’t know what more I could want.

7. Promote them

Got funds for an RA? Try and push it up to post-doc level and emphasize the possibility of being involved in research. Got funds for a post-doc? Try and push it up to a fellowship and offer semi-independence and a small research budget. Got money for a fellowship? Try and push it up to group leader level, and co-supervise a PhD student with them.

This position could have easily been budgeted as a postdoc, but I really wanted to promote the idea of more permanent software developer/engineer positions in academic science. This position is currently funded for 5 years as part of a Moore Foundation Investigator in Data Driven Discovery award. My goal is to make this a permanent position in my group by maintaining long-term funding beyond the 5 years. If I find someone good who wants to stick around I want the salary and responsibility to grow over time (and annual increases in salary are budgeted for the next 5 years).

So, hopefully I’ve done a decent job of satisfying Mick’s requirements. If any of this sounds interesting to you, feel free to leave a comment on this post, drop me an email, chat with me on Twitter, or just go ahead and apply.

My research group is hiring a Scientific Software Engineer to help develop software that facilitates science, contribute to research in data-intensive ecology, and improve scientific research and computing through training and modeling competitions.

We are actively involved in data-intensive computational research, open source software development, and open approaches to science. The engineer will work as part of a collaborative group, including undergraduates, graduate students and postdocs, using large amounts of ecological and environmental data to understand natural systems. They will develop and maintain open source software designed for working with large amounts of heterogeneous data, collaborate on research projects making predictions for ecological systems, and help develop web infrastructure for scientists to share, evaluate and improve predictions. In doing so they will actively interact with, and contribute to, related efforts from other initiatives and projects in these areas (e.g., rOpenSci, Dat, Software Carpentry, Data Carpentry, DataONE, NCEAS).

Are you a software developer who’s interested in science? Great! Are you a scientist with strong software skills? Awesome! If you have some experience with Python or R, Git, database management systems, web development, spatial data, and/or PostgreSQL/PostGIS, we’d be excited, but what we’re really interested in is someone who is good with computers, interested in science, enjoys working on a variety of projects, likes learning new tools as needed, and works well in a diverse team.

This position has guaranteed support for the next five years. My goal is for this to be a long-term position in our research group and a model for similar positions in other research groups.

If you’ve made it this far you might be interested in a few more details of the projects this position might be involved in. These include:

Developing, maintaining, and providing support for open source software for acquiring, cleaning, combining, and managing large numbers of heterogeneous datasets. This will include Python based development and maintenance of the EcoData Retriever software and the development of new software to automatically combine multiple datasets together for analysis.

Working in collaborative teams to conduct scientific research including the use of machine learning for making predictions and forecasts for ecological systems.

Developing, maintaining, and providing support for an open source system for publicly sharing ecological predictions and forecasts and automatically evaluating those predictions as new data is released. This system will be designed to allow researchers to collaborate and compete to improve predictions by uploading predictions to be compared to test data and/or by uploading code to make predictions.

Engaging with the broader community of projects involved in acquiring, cleaning, and combining heterogeneous datasets (e.g., rOpenSci, DataONE, dat), as well as those training scientists in the use of data and computation (e.g., Software Carpentry, Data Carpentry). This includes contributing to open source and participating in related conferences and hackathons.