The PI should:
- Enviroment
- Provide a safe, supportive, congenial environment
- Provide a lab where students can learn bioinformatics science
- Provide rules, best practices, and guidance
- Communication
- Respond promptly to requests by students
- Host weekly lab meetings
- Attend weekly subgroup meetings
- Have regular, standing meetings with graduates (undergrads maybe too)
- Be available to students for additional one-on-one meetings
- Be as open and transparent as possible in all forms of communication
- Praise the student when appropriate
- Promote/defend the student in public settings
- Science
- Create the study
- Design experiments with students
- Interpret experiments with students
- Critique the science when appropriate
- Write papers with students
- Help students with posters and slides
Students should:
- Communication
- Ask questions frequently
- Respond quickly to requests
- Go to lab meetings
- Host subgroup meetings (graduates)
- Have regular, standing meetings with the PI
- Science
- Choose a project that interests them (when possible)
- Take part in designing experiments
- Conduct experiments
- Proactively report on progress
- Follow best practices
- Write initial drafts of documents
- Make posters and slide decks for presentation
- Programming
- Use GitHub regularly
- Work in a Unix command-line interface
- Program in Python and possibly other languages
Most scientists are do-gooders who want to be useful. In a molecular biology lab, you can be useful immediately: there are dishes to wash, solutions to prepare, and instrumments you can use with a couple hours of training. There are no such tasks in this lab. In order to be useful in this lab, you need to be at least an intermediate level programmer. If you joined the lab with little programming experience, your first priority is to become a decent programmer. Start with MCB185. How do you know when your skills are advanced enough? Pass the exam https://github.com/KorfLab/exam
Thoughts on the problems of being a scientist in academia.
There is a saying when it comes to race cars: "fast, cheap, reliable: pick two". There is a recognition that you can't have everything.
In Science, we don't say that. The sentiment is more like "intelligent, creative, self-motivated, hard-working, independent, collaborative, disciplined, flexible, reliable, accountable, personable: choose (all) eleven".
- Intelligent - you can solve the problems that are in front of you
- Creative - you can find new problems to solve
- Self-motivated - nobody has to tell you to show up for work
- Hard-working - you work many hours
- Independent - you don't need others to succeed
- Collaborative - you recognize success requires others, and welcome them
- Disciplined - you can behave precisely as required
- Flexible - you make room for difficulties
- Reliable - people can count on you to show up or deliver on time
- Accountable - you take credit for your failures
- Personable - you are likable as a person and co-worker
It's unfair to be expected to be good at everything, and yet many scientists beat themselves up because they aren't. Give yourself the breathing room you would give to others. You don't have to be an A+ or even A- in all of these. But try not to have an F in any of them.
How hard does one need to work? Partly, that depends on your future plans.
Back when I was in graduate school, everyone had the same goal: become a professor. That's a little unrealistic. There aren't that many jobs for professors. The probability of becoming a professor at a Tier 1 research university is less than playing in the NBA. All the professors you know right now worked really hard as graduate students, and even harder as post-docs because they had to. It wasn't possible to become a professor unless you were working some evenings and weekends because that's what everyone else on your path was doing. Is that still true today? Probably. Is it unhealthy for future professors to work 50-60 hours per week? Probably. Is this a form of academic hazing? Probably. Ultimately, if you have designs on becoming a professor, you might need to work 50-60 hours per week because your competition is doing just that. On the plus side, being a professor is a pretty great job most of the time and I have a hard time imagining myself doing something else.
What if you want to be a staff scientist job in an industry setting? If the company is well-established, you might end up in a 40 hour work week with HR telling you not allowed to work more. However, in a start-up you might be working harder than you would trying to become a professor.
Your RER is a measure of how well you are playing the Bioinformatics Researcher Game in the Korf Lab. This is a kind of self-assessment. If you want a high RER, you should do the following:
- Be more proactive than reactive or non-active
- Be interactive and collaborative with other members of the lab
- Follow best practices in your computer environment
When there is a scheduled meeting:
- I sometimes forget and don't show up -2
- I sometimes arrrive late -1
- I arrive on time +0
- I arrive ahead of time +1
When in a Zoom meeting:
- I usually have my camera off -1
- I turn my camera on when I'm interacting +0
- I usually have my camera on +1
People are talking about something and the topic is so unfamiliar that they might as well be speaking a foreign language.
- I ignore it, it's probably not important to me -2
- I don't say anything, planning to look it up later -1
- I don't say anything, planning to ask someone later +0
- I interrupt to ask for clarification +1
People are talking about something slightly unfamiliar but I don't understand.
- I don't ask a question because I don't want to appear stupid -3
- I don't ask a question because I don't want to bother others -3
- I don't ask a question because I'm shy -3
- I don't ask a question because I plan to look it up later -2
- I don't ask a question because I plan to ask someone later -1
- I privately text somone else in the meeting +0
- I interrupt immediately +1
- I wait for a pause and then ask my question +1
People are talking about something I am familiar with and I suspect they are wrong about something.
- I don't ask for clarification because I want them to appear stupid -4
- I don't ask for clarification because they are senior to me -3
- I don't ask for clarification because I'm afraid I might be wrong -2
- I don't ask for clarification because I plan to discuss it privately -1
- I privately text someone else in the meeting +0
- I immediately ask for clarification +1
- I wait for a pause and then ask for clarification +1
People are talking about something I am familar with and I suspect that others might be getting lost.
- I don't interrupt, they will catch up eventually -1
- I don't interrupt, I'll chat with them later +0
- I interrupt, asking for clarification +1
- I interrupt, offering clarification +2
- I interrupt, asking a question I already know the answer to +2
I schedule individual meetings with Ian:
- Never -2
- Only when he asks me -1
- Only when I'm stuck +0
- Before I need help +1
I use Slack to chat with Ian:
- Never -2
- Only when he starts a conversation -1
- Only when I'm stuck +0
- Before I need help +1
I would describe my computer as:
- A total mess -2
- Chaos, but I know where everything is -1
- A balance of chaos and order +0
- A church +1
If someone were to steal my computer, the result would be:
- Catastrophic loss of productivity -2
- A week of pain to recover -1
- A couple days of pain to recover +0
- Not much of a problem +1
I am comfortable with the Unix CLI:
- What's that? -1
- Somewhat, but I still double-click +0
- Yes +1
echo "scale=812; 4*a(1)" | bc -l | tail -1 | awk '{print substr($1, 60, 6)}' | echo $(xxd -r -p)+2
General practices: +1 for each of the following (except as noted)
- I use R-Studio
- I use Jupyter Notebook
- I program in a Unix/Linux enviroment
- I program in a VM
- I also program in an unusal OS or hardware
- I have installed software with conda
- I have run jobs on the cluster
- I have run slurm jobs on the cluster
- I commit to GitHub X days per week (+1 for each day)
- I have reported a bug to a developer
- I have fixed a bug reported by a user
- I have fixed someone else's code and commited the change
- I have opened a GitHub issue
- I have closed a GitHub issue
- I have made a pull request
- I have accepted a pull request
My policy on unit tests:
- What's that? -2
- I've seen them, but never used them -1
- I'm interested, tell me more +0
- I have created some +1
- I use them regularly +2
My policy on functional tests:
- What's that -2
- I've seen them, but never used them -1
- I'm interested, tell me more +0
- I have crated some +1
- I use them regularly +2
Documentation: +1 for each
- The beauty of my code is somewhat self-documenting
- My programs have Unix-standard usage statements
- My programs have Unix man pages
- I write API docs
- I write tutorials
- I write books