Forum:Time Management Strategies and Advice for Bioinformaticians

Question

[sviatoslav.kendall]

I am relatively early in my career (less than 5 years experience and all of it at academic institutions) but it seems to me that working on only one project for an extended period of time is a luxury reserved for beginners and maybe people leading the project. Its becoming increasingly clear to me that effective time management is a crucial skill for bioinformaticians but I haven't seen much discussion of it. Obviously the best strategies to employ will vary based on your work load, personality and other factors but I still think it would be very useful to read about what other people in this community do. Here are a few specific questions to get the ball rolling:

How do you allocate time for multiple, unrelated projects?

Personally, I like to split my days into pre/post-lunch blocks of time and set goals relating to a single project within each block of time. For example: I might aim to finish writing a shell script for Project A and run it before going to lunch then switch my focus after lunch to interpreting some results relating to Project B and deciding what to do next time I work on Project B.

What are some specific tools or techniques that you use to make swapping between projects faster/easier?

• I try to use complete paths in my scripts whenever possible because it makes it easier to remind myself where all the relevant files are
• I use draw.io to make flowcharts describing my workflows and save them in lab notebook

How do you manage expectations when it becomes clear that a project's timeline/deadlines are unrealistic or will not be met?

The only way I currently deal with this is blunt honesty framed around what can be done in time; "You can count on Part 1 of the analysis to be done by Friday but probably not much else".

Please consider posting additional questions as well as offering your answers to those already posted.

[Jean-Karim Heriche]

These should probably be three separate posts/questions, not because they're unrelated but to keep clearer threads.

Answer 1

[Ryan Dale]

I haven't seen any discussions like this either, would be great to see what others think. Here's some of what I've learned mostly from trial and error:

• Know your audience. Some folks I work with want to see all of the intermediate steps (i.e., ship early, ship often), while others prefer a definitive report just at the end. For the former case, you can work in smaller chunks, send them out for review by collaborators, and while you're waiting for comments you can work on other projects.

• Prioritize projects closest to manuscript submission. This is a pretty easy heuristic to justify and often has a clear winner though it'll depend on your particular mix of projects. This kind of prioritization also means exploratory work gets put on the back burner, but that's often the most time-consuming as well.

• Finish mini-projects as soon as they come in, otherwise you get a pile of small things that never get priority and there's no clear way of choosing which to work on or when to shelve a bigger project to work on them. My definition of "mini" used to be if I thought I could finish it in <3 hrs but now it's more like <1 hr.

• Batch together similar projects when possible to minimize cognitive overhead when switching tasks. For example, if multiple projects involve working on genomic intervals, do one in the morning and one in the afternoon.

• Similarly, if there's code you can write to solve a problem for one project and think it would be useful for another project, work on those projects together as you build the code. A nice side-effect of that is that your code is then more general and has a better chance of being generally useful to others.

• If possible, stop work on a project when there's still an obvious next step to finish. That way when you return to it, you can use that task as the warmup (loading the project back into your mental RAM), which in my experience ends up being more efficient than a cold start followed by figuring out what to work on next.

Answer 2

[WouterDeCoster]

I'm a huge fan of https://en.todoist.com, to keep track of my projects, things I have to do, mails I have to answer,... Syncs nicely between browser, email client, phone, desktop app,... I essentially organize my private and professional live with that, me, my goldfish and plants wouldn't survive without it.

I think it's also important to make sure you don't set your deadlines too tight, regarding the 90-90 rule in informatics:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.  (Tom Cargill)

Answer 3

[Jean-Karim Heriche]

Concerning expectation management, I think honesty is the best approach. The difficult part is to get a correct estimate for when you can deliver but because others may depend on your work, I think it's important to get this right. While this comes with experience, as a rule of thumb, you can estimate how long it's going to take you to reach your goal (factoring in time you're going to spend on other projects) then double this and use this to set your deadline. In my experience, there are always unexpected demands on your time and it's preferable to be realistic and account for them than always coming up with excuses.

In my experience, the main causes of disruption to time management are meetings. You often have little control over when they will happen and on how long they'll last. So a key time management skill is to organize your tasks so that meetings do not cause too much disruption to your work. If possible, I try to keep at least a day or two of the week without any meeting or seminar. I use those "free" days for tasks that require most concentration like programming/implementing a complex pipeline or algorithm or getting into a new math/statistics problem.

As you've already alluded to, a key to moving between projects is proper documentation, especially if you're going to have interruptions of more than a day or two. I try to document everything I did, in particular dead ends so that I don't spend time down them again, and record all command lines I run. I also occasionally make use of Rstudio projects. Another thing is to never code for single use, try to make your code as reusable as possible. And if you get a request for something trivial twice, then it's time to make a tool that your collaborators can use the next five times they need it, e.g. put a web interface in front of your script so that wet lab people can run it without you.

Answer 4

[andrew.j.skelton73]

I have multiple projects that I'm committed to at any one time, and everyone wants their "fair share". Proving what projects you've spent time on can be tricky, but I've found Toggl to be a fantastic habit to integrate into my work pattern. I highly recommend anyone to check it out and use it.

Answer 5

[5heikki]

I allocate time by maintaining task lists in Emacs Org mode. Every task has a state (TODO / IN-PROGRESS / WAITING / CANCELED / DONE), a scheduled start/close date, and a deadline. Additional notes can be attached to any task. Agenda view collects, sorts and displays this information in calendar. There's a Cron job for everything that can be automated. Swapping between projects is a matter of switching between Emacs buffers and/or byobu windows/panes. Code is well-commented and written with reusability in mind. Every remote login has a distinct prompt (and htop installed because it's so much better than top). I have "set up script" task IN-PROGESS in my ~/.org/other.org file. If somebody asks me how long something takes, I make an educated guess and multiply that by four for a final answer. I share my task lists as html files in intranet so boss and colleagues can see what I'm up to.

Answer 6

[LLTommy]

I have to say I don't feel Bioinformatics is any different than programming in this particular case. All the mentioned problems and methods to tackle these are simply the same problems you have with every software project. So if you look for input how to handle your project better, just search for software development methods and drop the bio in bioinfromatics in this case.

Having said that, Documentation of your code is important, for yourself as well as for other people. There is not too much documantation. A to do list is a nice start, but especially if you work with other people there are more advanced (projectmanagement) tools - like ticket systems etc. Also, there are multiple different ways to organize your team (e.g. scrum, agile software development... whatever, I just post a link , it is easier.

[Ryan Dale]

As long as by "software project" you mean "scientific software project" then I agree there's nothing specific about bioinformatics. But writing software for projects whose requirements change as they progress, whose outcome can't be known and where the output of one step will affect what next step is taken (otherwise it wouldn't be research!) seems to be an extra challenge of writing software and analysis code for research projects. That said, there's a lot to be learned from reading up on software development practices.