#acl SnyderLabGroup:read,write,delete,revert,admin All:read

= Expectations and responsibilities =

~-Attribution: this is based on the [[https://cpandar.github.io/labmanual/|SNEL lab manual]], which in turn is based on the [[https://github.com/alylab/labmanual|Aly lab manual]].-~


~-In the Meliora Spirit, we believe there is always room for improvement; these expectations and responsibilities are our current best idea, but if you have an idea for improvement please feel free to share it.-~

<<TableOfContents()>>

=== All lab members ===
 * Be driven, focused, and passionate about their work. 
 * Be collegial and supportive of everyone else on the team, and continually strive to maintain a collaborative and welcoming environment. 
 * Do not harm others personally or professionally.
 * Exercise independent thinking and judgement.
 * Take on responsibilities, and reliably fulfill commitments.
 * Be competent in required laboratory skills, especially animal handling.
 * Perform first-rate work with attention to detail. This includes maintaining comprehensive notes, back-ups of data and work, and well-documented code.
 * Actively communicate your progress and project directions so we're all on the same page (see [[#communication|General Policies: Communication]] section below)
 * Openly communicate your struggles and mistakes.
 * Maintain the highest standards of moral and ethical conduct and scientific integrity.
 * Follow all laws and regulations of agencies with jurisdiction over the lab.
 * Openly communicate with me when you have issues with others in the lab. If you're not comfortable communicating your issues with me directly, there are resources in the department (other faculty or staff) who can help.
 * Strive to stay current on the latest literature in our field.

=== "Opportunities for Improvement" ===

Hopefully everyone meets expectations and responsibilities at all times. Realistically however, we know that isn't always the case. When things go wrong, I like to call that an "opportunity for improvement". Sometimes, people's responsibilities might be in conflict, causing a dilemma that needs to be navigated. Other times, someone fails to meet expectations either through ignorance, neglect, or malice. Here are some guidelines for how these situations should be handled.

==== Conflicts ====

Navigating conflict is an important life and career skill. To develop this skill, I encourage people to '''first make a good-faith attempt to resolve conflicts directly in a mature and collegial fashion'''. We're all scientists here, and should be able to use reason and be persuaded by it. If a conflict cannot be resolved in this way, please bring matters to me (Adam) to mediate. If for some reason my mediation is not possible or appropriate, another faculty member in the department can be asked to mediate. Be prepared to compromise.

==== Failures ====

Failing to meet expectations or responsibilities will result in action to reduce future harms. Issues falling outside of the lab jurisdiction (e.g., violations of University, local, state or federal policy) will be referred to the appropriate agency. Examples of such violations include scientific misconduct, harassment/discrimination, and animal welfare concerns. For mild issues, additional coaching may be sufficient. For more serious issues, '''remediation may include removal of access to lab resources, or removal from the lab entirely'''. Examples of such serious violations include: misuse of laboratory resources, failure to observe safety procedures, and disrespectful/disruptive behavior.

=== Principal Investigator ===

My most important job is my role as a mentor to the trainees in my lab, and I take that role seriously.

As a mentor, I aim to ensure that my trainees are working on projects that align with their long-term goals and interests. I will, to the best of my ability, strive to keep roadblocks out of their way so they can focus on producing the highest quality research possible. Of course, one of my key roles is to secure funding so we can keep doing amazing research. I try to stay closely involved in research projects, but as a project matures, it's often most effective for me to help with higher-level strategizing and decision-making, thinking through results and implications, and working on communication/writing/packaging stories. Above all, my goal is to create an openly collaborative research environment where the research team is happy and productive while doing high-quality science. And as people begin to move on, I'm available to help them navigate their subsequent career choices. Some specific things I will strive to do:

 * Support you scientifically, financially, psychologically
 * Give you regular and timely feedback on your project ideas and progress, conference posters and talks, manuscripts, and grants
 * Be available on a regular basis through regular meetings (1:1s for grad students & postdocs), Slack, impromptu chats in lab, and email. (Availability will unfortunately fluctuate periodically with grants, travel, and teaching.)
 * Look for opportunities to further your career development - find talk opportunities (both local and more broadly), write recommendation letters, try to send you to conferences and courses (funds permitting)
 * Help you prepare for your next career step
 * Help make sure you maintain work-life balance, and always be open to any concerns about stress levels and anxiety

=== Post-Doctoral Fellows ===

Postdocs in the lab have of course gone through their PhD training, so they know how to take a project from its initial stages all the way to completion. The postdoc period is your opportunity to start proving yourself as a successful independent researcher. Postdocs in the lab should:

 * Serve as role models for the trainees around you in terms of drive, independence, high-level thinking, scholarship, collegiality, and collaboration.
 * Help mentor grad students and undergrads when they need it. I expect postdocs to really make everyone in the lab better.
 * Seek out opportunities to present - journal clubs, lab meetings, conferences. I will do my best to find local outlets (other institutions, other groups' lab meetings) so you can continue to develop your presentation skills.
 * To establish a track record of being competitive for funding, you'll want to start applying for grants (foundation fellowships, NRSA, K99).
 * You have a lot of training under your belt, but you're also still really close to all the technical aspects of projects. So I expect you to challenge me when you think I'm wrong, because you'll often see things that I don't. It's really critical to add your unique perspective to our research and help shape its direction.
 * By about year 3 of the post-doc, you should have some idea of what the next stage looks like for you, whether it's an academic job search, an industry position, etc. You'll want to be doing serious thinking about your career trajectory, and I will of course do my best to help you navigate the search.

=== PhD Students ===

PhD students are typically getting their core research training, often transitioning from being focused on coursework/studying to learning how to drive a research project. Some key roles and responsibilities:

 * Develop your dissertation research. Initially you'll work on a project that I or others in the lab have spent a lot of time thinking about. Eventually (by years 2 or 3), you'll become the expert and will be proposing your own directions. During that time you'll probably have to do your qualifying exams and thesis proposal (specifics vary by PhD program).
 * Help mentor undergrads and more junior grad students when they need it.
 * Constantly improve your presentation skills, by presenting at whatever venues we can find - journal clubs, departmental venues, other labs, and conferences.
 * Keep track of your deadlines and requirements - course registration, qualifying exams, thesis proposals and defenses, conference abstracts, fellowships, summer courses, etc.
 * Apply for grants. For US citizens/residents, it's a really good idea to apply for graduate fellowships (NSF GRFP, NIH NRSA, NDSEG). For international students, there are many applicable foundation fellowships. It builds a really strong resume and also frees up more funding for everything we do.
 * Start thinking through your career path and actively discussing it with me, so that together we can make sure you're taking the right steps and getting the training you'll need.

===  Undergraduate Students ===
<<Anchor(undergrads)>>

 * We will consider mentoring undergraduate research assistants if space and research opportunities are available. 
 * Undergraduates are initially admitted to the lab on a probationary basis for three months. By the end of the probationary period you must demonstrate competency on animal handling skills to continue working in the lab. There is a training checklist for these skills. A graduate student, postdoc, or lab manager will evaluate your performance on the checklist items. Be advised that training and certification to handle animals will take up the vast majority of your time during this period.
 * Because the bulk of the first year of undergraduate research mentorship is consumed with training, little research progress is expected during this interval. Since training undergraduates takes extensive time and effort on behalf of the lab with little returned in terms of research productivity for the first year, we request that students join only if they can commit to at least two years, and preferably more. Thus, '''our lab policy is to accept sophomores and exceptional freshmen only'''. Exceptional juniors with specifically detailed and scope-limited research proposals may apply and be considered on a per-case basis.
 * Initially most undergraduate students will assist more senior lab members on projects. As you gain more experience and expertise, we hope you'll take on more responsibility towards driving projects and setting direction.
 * Be in charge of setting your lab schedule, sticking to it, and communicating when any issues come up.
 * Make sure you complete your required trainings/certifications (e.g., lab safety, animal handling as applicable, etc).
 * Keep track of your deadlines - registration for course credit, applications for salary or travel funding, undergraduate conferences and symposium opportunities.
 * Pay attention to details. If you're working on a task, provide quality control and ask questions if something doesn't seem right. We expect high-quality output from every single person in the lab, regardless of the scale of the work, or the pace it gets done at.
 * Communicate. Provide regular updates, unprompted. Slack is great for this. As much as I'd like to be able to be on top of everything everyone is doing, without regular meetings, it's easy to overlook people's progress or roadblocks if they don't speak up.
 * Ask questions. Voice your confusion. Get comfortable not knowing things, and don't be afraid to look stupid - nobody's going to judge you for not knowing something.
 * Talk to everyone in the lab, not just your mentor. Get to know people and projects and expand your horizons! Everyone in our lab is willing to help if s/he has time.
 * If something goes wrong or breaks, speak up immediately. (Communicate!)
 * Attend lab meetings (schedule permitting). Start reading papers, even if they're over your head. Become an active participant. I expect the discussions in lab meeting to sometimes be hard to follow, but the people who get the most out of lab meetings are the people who speak up and ask questions.
 * Maintain a clean lab environment. This is especially important as you'll be in and out of the lab in spurts, and it's easy to leave a few things laying around, etc. - this then adds up to a lot of clutter and can make the workspaces unusable!
 * This is your opportunity to get to know what research is all about. We want to welcome you and have you develop into a colleague and valued member, and we want you to have fun.

=== Rotation Students ===

Our goal in the rotation is to determine if the lab is a great fit for you, and vice versa. Typically you will be paired with a grad student or postdoc, and your aim will be to advance a small piece of an existing project.

 * Read literature and become familiar with current topics in our field
 * Familiarize yourself with the experimental and computational techniques we use in our lab
 * Get a sense of which topics interest you
 * Get to know all the members of the lab and understand our culture
 * Determine good fellowship application topics / projects to write about

== Code of conduct ==

=== Essential policies ===

The lab and university are environments that must be free of harassment and discrimination. All lab members are expected to be familiar with and to abide by the [[https://www.rochester.edu/working/hr/policies/|policies]] of the University of Rochester (in particular [[https://www.rochester.edu/working/hr/policies/pdfpolicies/106.pdf|Policy 106]], which relates to harassment and discrimination). Your certification that you've read this lab manual is also affirmation that you will abide by these policies.

We are committed to maintaining an environment that is free of harassment. If you notice someone being harassed, or are harassed yourself, tell me immediately. Hopefully I am never the cause of your concern, but if so, please reach out to a trusted faculty or staff member in our department or look carefully at this page for more info on what to do.

=== Scientific Integrity and Research Conduct ===

Our lab is also committed to maintaining the highest standards of scientific integrity and research ethics. One portion of this mindset is that we do not tolerate research misconduct. To summarize that link, research misconduct can consist of:

 * Fabrication - making up data or results, and recording or reporting them.
 * Falsification - manipulating research materials, equipment, or processes, or changing or omitting data or results such that the research is not accurately represented in records or reports.
 * Plagiarism - appropriating another person's ideas, processes, results, or words without giving appropriate credit.

While research misconduct occurs for various reasons, often a driving factor is the pressure to produce results. Unfortunately the need to produce results is always there (it's part of the job), and is never an excuse fabrication, falsification, or plagiarism. If you're feeling severe pressure, reach out to me to talk about it. And always remember that the goal of our work is to arrive at new truths, while research misconduct is the antithesis of that goal.

I take a very hard line on research misconduct. If for some reason you are concerned that our work is not maintaining the highest standards of research conduct, please report this to me immediately. And if you are not comfortable discussing with me directly, please reach out to a trusted faculty or staff member that could serve as an intermediary to help resolve these issues, or to the university's Research Integrity Officer.

==== Reproducible Research ====

This section is currently quoted verbatim from [[https://github.com/alylab/labmanual|the Aly lab manual|target="_blank"]], because I agree with every word they said:

“If you gave someone else your raw data, they should be able to reproduce your results exactly. This is critical, because if they can’t reproduce your results, it suggests that one (or both) of you has made errors in the analysis, and the results can’t be trusted. Reproducible research is an essential part of science, and an expectation for all projects in the lab.
For results to be reproducible, the analysis pipeline must be organized and well documented. To meet these goals, you should take extensive notes on each step of your analysis pipeline. This means writing down how you did things every step of the way (and the order that you did things), from any pre-processing of the data, to running models, to statistical tests. It’s also worth mentioning that you should take detailed notes on your experimental design as well. Additionally, your code should also be commented, and commented clearly. We all know what it’s like to sit down, quickly write a bunch of code to run an analysis without taking time to comment it, and then having no idea what we did a few months down the road. Comment your code so that every step is understandable by an outsider. Finally, it is highly encouraged that you use some form of version control (e.g., Git in combination with [[https://github.com|GitHub]]) to keep track of what code changes you made and when you made them, as well as sharing code with others."

==== Animal Research ====

Much of our work to understand the brain and to develop new treatments for disorders of the nervous system will involve research with animals. We do this out of necessity, and we hold the welfare of our animal subjects in the highest regard. Accessing and working with laboratory animals requires comprehensive training with our [[https://www.urmc.rochester.edu/ucar.aspx|University Committee on Animal Resources (UCAR)]] and registration and orientation with the [[https://www.urmc.rochester.edu/animal-resource/services/dcm.aspx|Division of Comparative Medicine (DCM)]]. Further, it requires a commitment to treat all of our animals with the utmost respect, and a responsibility to carefully monitor their health and safety.

You must be on the animal protocol prior to working with animals. Detailed steps are on the lab wiki.

==== Authorship and Acknowledgement ====

In academic research, our primary currency is generally publications in journals and presentations at conferences. A critical aspect of these publications and presentations is appropriately allocating credit in the form of authorship and acknowledgement. 

We aim to ensure that anyone who has made a substantial intellectual contribution to a piece of work is allowed to participate in its dissemination via papers and presentations. Note that while authorship is a privilege, it also comes with responsibilities, such as helping to draft and revise any communication of the work (including providing critical, intellectual feedback). Anyone listed as an author on a manuscript is certifying that they agree with its content, can discuss the implications in depth, and are agreeing to be held accountable for their contribution to the content. Contributors who do not meet the criteria for authorship may instead be recognized via acknowledgements.

Because authorship is one of the cornerstones of the entire research endeavor, we take it extremely seriously. Here are some helpful guidelines:

 * Generally at the start of a project, the student or post-doc taking on a lead role can expect to be first author of the resulting publication. You can usually expect me to be last author. If the project is collaborative and another lab is the primary driver of the project, this may not be the case.
 * Once it starts to become clear that a publication or presentation is likely to result from the work, it is important to lay out the scope of the publication and proposed authorship. It is rarely too early to begin talking about authorship - this is critical to ensure all authors are on the same page. This plan (scope, authorship) will evolve over time, but documenting this and maintaining it is critical for setting expectations appropriately.
 * As a project evolves, and new researchers contribute, they may be added to the author list as appropriate (this is discussed with all involved parties).
 * Sometimes projects take longer than a person's time in the lab. In this case, projects may be transferred to others, and if so the new researcher may become the main driver (and first author) on the project. This is a conversation between all involved parties.
 * It is the responsibility of the person(s) driving the project (first author(s), and me) to make sure people's contributions are appropriately recognized. Whenever there is any question as to whether someone should be an author, we always err on the side of having a conversation with that person. It is never appropriate to assume someone will simply speak up to "claim" their authorship.
 * It is also the first author's (or authors') responsibility to ensure all co-authors have the opportunity to read drafts and provide critical feedback before dissemination/submission. For any sort of submission, all co-authors should have seen a draft and had a chance to contribute/comment a minimum of 2 weeks prior to the submission. As an example, if you're planning on submitting an abstract to a conference, everyone that could be considered an author must have seen a complete draft at least 2 weeks prior to the deadline (and any lingering authorship questions must be discussed in detail by that point). In rare cases, it is possible to put together a submission in a shorter time-frame, but only if every co-author is comfortable with the process. If we do not have permission from a co-author prior to submitting something, we simply cannot submit it.

=== Collaboration ===

We often collaborate closely with partners external to the lab (within or outside of U of R). Being able to collaborate with world leaders in various fields, who have substantial expertise that is often complimentary to our own, is a tremendous privilege. Two keys to successful collaboration are that we always show respect for our collaborators, and maintain communication so there are no misunderstandings. These are intellectual partnerships, and generally, even if a collaborator's role is mainly limited to experimental design and data collection, their expertise on the project is invaluable. 

==== Shared datasets ====

Building on the above, we have many projects with great researchers who share data collected in their labs. We do not share data beyond our lab without explicit permission from our collaborator. Datasets are also generally shared for a specific purpose, and any time we plan on using it in a manner that wasn't originally discussed (e.g., to test a different hypothesis), we communicate that with our partners and secure their permission.

=== (Social) Media ===

The messaging from the laboratory should be well-managed. In general, do not post information about laboratory business on social media or other sources. Do not comment to the media without express prior consent from me (Adam). If you have news, please let me know and we will coordinate University Public Relations. Feel free to share news that has already been posted through these channels.

==== Photos & videos ====

We want to create an environment where everyone is comfortable and we respect their privacy. Therefore photos and videos of other lab members can only be taken with their explicit knowledge and consent. Everyone has different degrees of comfort with pictures and videos, and we respect them equally.

Sometimes it is helpful to take pictures that include animals in the lab, e.g. to document procedures, experimental configurations, surgical techniques, etc. However, pictures of animals in experimental settings can make people uncomfortable, and in general there are a lot of sensitivities around animal research. Any existing pictures of animals in the lab are assumed to be kept 100% internal unless you have explicit permission from Adam for other uses, and do not make any new photos of animals without permission.

Occasionally you might want use pictures of other lab members in your presentations - check with them to make sure it's appropriate. Photos of animals in presentations are forbidden; make an illustration instead. You might want to share pictures of lab members for fun, e.g. on social media. Check with everyone involved to be sure that's OK. 

= General policies =

== Communication ==
<<Anchor(communication)>>

In my experience, one of the strongest predictors of whether people will do well in the lab is their ability to communicate effectively, both with me and with others. Often there are two key barriers:
Sometimes people worry that if they communicate questions or struggles, they will be seen as somehow inferior for not knowing something. In fact, that's rarely the case, and the opposite is a much bigger concern! People who don't communicate often get hung up on specific issues (that may be very challenging, and could really use outside perspective/discussion). Ultimately this leads to someone being much less productive than the person who's willing to ask questions. On the other hand, I've never once worried about somebody not knowing something - everyone in the lab is around because we believe in their talents. So the right decision is most often to just speak up! Try to overcome your imposter syndrome, and focus on working with your colleagues (me, other lab members) to find a solution to the problem.
A second issue is that we're often afraid of "bothering" more senior people (undergrads worry about bothering grad students, grad students worry about bothering postdocs, everybody worries about bothering the PI, etc). Fight that instinct. Bottom line - I much prefer that people in the lab speak up, and I have no problem telling people (gently) if they are in fact bothering me.

As a bare minimum, I expect graduate and postdoctoral researchers to:

 * Meet 1:1 every other week to discuss ongoing activities, set the meeting agenda beforehand, and follow-up with action items (see below). If for some reason we can't meet (one of us is out of town or extraordinarily busy), post a summary of recent activity and short-term plans.

 * Keep me updated when things aren't going to plan (examples: things are taking longer than anticipated, something is more complex than we thought, results don't match expectations, or something that seemed clear when we talked doesn't seem clear anymore). This stuff happens all the time, but updates are critical for helping set expectations and guiding decision-making.

 * Similarly, I expect undergraduate researchers to meet bi-weekly when possible or else post updates. Updates should describe your recent progress and your upcoming plans. Add a reminder to your personal calendar if helpful, and don't overthink it. This is all about maintaining communication and making sure your mentors and I can most effectively help you. 

In general, I do not expect you feel the need to respond to things on weekends or after hours. I do sometimes send emails or Slack messages during those times - that's just because I get to stuff when I get to it. Don't feel pressured to respond until you're back to work yourself! I only expect you to be responsive after hours during specific critical time periods (e.g., right before a submission deadline or leading up to a conference presentation). We should be able to anticipate those cases and agree upon a strategy in advance. If there's anything distressing about off-hours messages, just let me know, and I'll try not to bother you during those times.

== Hours ==

[Note: coronavirus pandemic of 2020 obviously affects the following policies]

You benefit a lot from being in lab: it's a good way to learn from others, build camaraderie amongst team members, and avoid falling into distractions that you might face at home or elsewhere. Academia generally offers more flexibility than many other jobs, but full-time researchers should still be working on research 40 hrs/week. Early graduate students will have classes and TA'ing that cut into these hours, of course, but I expect you to show up to the lab regularly when you don't have those obligations. 

To facilitate interaction, I encourage everyone to try to consistently be in lab 10:00 to 16:00 (and you should be using a 24 hr clock, btw). If you’re an early bird or a night owl, that’s ok, but try to overlap with others in the lab as much as possible. If we’re in a particularly busy period of experimentation, we may split rig access into two shifts: approximately 7:00 to 12:30 and 12:30 to 19:00. Surgeries (a few times a year) can mean long days for those involved; depending on the procedure, it may take up to twelve hours (eat a good breakfast!).

There's no concept of "face time" in the lab - I care much more that you're able to make consistent progress. But keep in mind that everyone benefits from a vibrant, interacting team.
Since a lot of the work we do involves setting up computational jobs that may run for several hours, it is often in your best interest to be able to login after hours, check the status on a run, make decisions about the next run, and get it going. Small, easy interventions in off hours can often save you hours or even days in a given week.

Undergrads work at least 10 hours/week in the lab. This is a minimum, because we devote a massive amount of time (between grad students, postdocs, and myself) to training and mentoring undergrad lab members. Anything less makes it impossible to make consistent progress, and thus isn't fair to the grad students/postdocs that take on mentorship roles. Again, 10 hours is really a minimum, and we expect that as you get more involved and engaged in a project, your time commitment will increase. The type of research we perform requires a lot of training; undergraduates are a net drain on our resources for the first calendar year after joining the lab, and become net contributors only after that point. For this reason, we prefer to engage undergraduates with at least two years remaining before graduation.

As mentioned above, all undergrads should set up a weekly schedule in the lab calendar so your mentors/colleagues can know when to expect you in the lab, and keep us posted when you need to deviate from that schedule. Occasionally it's possible to commit to fewer hours, if students have been working for a few semesters and are looking to transition away from the lab but hoping to finish up some work - talk to me about this.

== Office hours ==

If I'm in my office, my door is generally open and you're welcome to knock and come in. Sometimes I won't have time to talk and I'll let you know. If the door's closed, I might be on a call or trying to focus on something - in those cases, Slack is an easier way to see if I'm available.

== Meetings ==

=== One-on-one meetings ===

As a graduate student or postdoc, I expect we will have structured meetings at least every other week. (We might miss one on occasion if I am out of town or etc.) These structured meetings are critical to tracking both high-level and low-level progress on your projects, and ultimately your career. 

I leave the content of the meeting largely to your discretion. Sometimes it's helpful to discuss things that aren't specific to a project - classes, applications / rec letters, mental health, anything you want. This is how we make sure you have the time to discuss whatever you need to.

I expect you to post a meeting agenda to your Slack meetings channel the night before we meet. This is because:
 * You generally know the details of your efforts and any hangups much better than I do.
 * You should be thinking about the high-level direction of your projects.
 * If we don't start out with a plan for the meeting, we will likely spend all our time on one or a few issues, and miss critical pieces.
 * If I don't get to review an agenda beforehand, then we'll likely waste time in person, or I'll miss the opportunity to knock out easy things prior to our meeting that will help you move faster.

After our meeting, I would like you to post some notes on our discussion, as well as next steps / action items (for both of us), which we'll generally aim to complete prior to our next meeting.
We will of course generally have lots of opportunities for less formal interaction in the lab, but the weekly meeting is a key check-in to ensure you have time to address critical issues.

=== Lab meetings ===

We try to have lab meetings ~once/week, for ~1.5 hrs each. Content varies, but we typically cycle through journal clubbing papers of interest, lab members updating the group on their progress, and practicing presentations. It's also wonderful when people discover new things they think the rest of the lab might benefit from (technical tools, data visualization tips, version control strategies, project management approaches... anything heplful) - if you have something like this to share, let me know and we can easily carve out 5-10 minutes in the meeting to discuss.
I expect grad students and postdocs to present ~twice/semester. I strongly encourage undergrads to present project updates as well - it's great practice!

We typically adjust our lab meeting schedule every semester to accommodate people's classes as best as we can. Lab members are expected to attend all meetings, but of course it's understandable when things come up.

== Deadlines ==

If you have something with a deadline, you want to bring it up with your collaborators as soon as you find out what the deadline is. Don't be afraid to bug people - far, far worse is putting something off until the last minute, and forcing your collaborators to scramble.

If you need something incidental from me (paperwork, etc.), I'd appreciate a week's notice to be sure get it back to you.

If you need something more substantial from me (feedback on an abstract, a letter of recommendation) I need at least two weeks to make this happen.

For things that will need multiple back-and-forth interactions (fellowship applications, paper drafts, research statements, undergraduate and graduate theses), I need as much time as you can give me, and you'll need a significant amount of time to integrate any substantive feedback. A 3 week lead time is the minimum here, 3 months would be ideal. If you haven't heard from me on something in a week, ping me about it again. I am rarely bothered or annoyed when someone checks in to make sure I'm on top of something. And in any case, it's much better to bother me than to have an important deadline slip by!

== Presentations ==

Communicating our research is a critical piece of the endeavor - if we don't communicate our work, it may as well have never happened! So learning to deliver compelling presentations is an important piece of your training (and good presentation skills are invaluable even outside of academia). I highly encourage every student to get as much practice presenting as possible, whether it's within our lab meetings, journal clubs, events with other labs on campus, and external presentations/events.

When you present your work, you are representing not only yourself, but also your lab. If you're planning to give a presentation outside the lab, I expect you to give a practice presentation to our lab at least 2 weeks ahead of time (1 week in emergency situations, but that is really not enough time to integrate feedback and practice your revised presentation). If you're planning on giving a job talk, I'd recommend you give practice presentations at least a month ahead of time, because getting that right is an iterative process. You are responsible for ensuring this happens, including scheduling and coordinating with your fellow lab members.

We keep copies of previous presentations in the lab Box folder. I highly encourage our team to share presentation materials (you're welcome to anything from my own presentations). Check with other folks before using their materials.

== Coding ==

Learning to code well is a life-long process. Here are some best practices that we have learned over the years that you should follow (aka my “pet peeves”):
 
 * Don’t use “magic numbers”; all constants should be assigned to variables with informative names.
 * Use informative variable names with camelCase (first letter lower-case); consistent naming makes it easier to collaborate. So we use variable names like nNeurons, nTimePoints for the number of neurons and timepoints; variables like doNormalize or doFilter for booleans as to whether to normalize or filter, etc. Try to be consistent.
 * Define all variables at the top of your function or routine whenever possible.
 * Avoid loops as much as possible.
 * Write functional programs (i.e., write small functions and combine them into complex routines).
 * Plan ahead and make your program flexible. Your future self will thank you. For example, you might intend a function to operate on a vector, but what if a matrix was passed in? How about a string? Can/should your program handle that?

More details are in the lab Wiki. 
/* should eventually just make a subpage for a coding style guide -acs02sep2020 */

== Writing papers ==

We're just getting started on writing the first wave of papers in our lab. Below is how we're currently approaching this, and I'll update the lab manual as we refine our procedure. Note that this is really meant to provide a framework for inexperienced paper writers, but we can probably adapt to each person's style.
Our first step is determining the scope of the paper - what are the key points we want to make? Usually we're aiming to essentially create the paper's abstract. It may sound really backwards to write an abstract before the paper, but actually this is a really helpful way of boiling the project down into the essential points. If we have a compelling abstract, the rest of our job is simple - put together a clear story that backs up they key claims we make in the abstract. Of course, over the course of writing the paper, this abstract will be heavily revised (and maybe thrown away completely), but putting a useful framework in place is extremely helpful.
Once the paper's scope is worked out, our next key step is to put together a "Figure flow" - a list of the key points we'll make in each figure. Typically we'll have some plots/panels in mind also, which we can sketch out by hand. This expands on the story laid out in the abstract, and should concretely determine the points we're going to make and whether/how they fit together. We'll work closely together on the abstract and figure flow. Usually this is the result of repeated conversations and whiteboard sessions.
Next step is to develop each of those figures, which should really populate the Results section. You are always closer to the data than I am, so in this process, you'll put together rough drafts, we'll iterate many times to make sure they're conveying the overall point, and then we'll work on making them publication-quality. At the same time, you should be putting together the corresponding text for the Results section as well as the figure legends.
At the same time, we'll work together closely to write the Introduction. I will take a much more involved role here to help put this framework together. Concretely defining the questions we're asking, and relating them to previous literature, is critical for getting people on board with the story.

Other general points:
For most papers we write, the Intro and Results sections will be the stars - if these aren't compelling, people will have no interest in the Methods or Discussion. So we aim to hammer these out first. I find that Discussion sections can be pretty fun to write once other things are settled. 
In our lab we prefer to use [[https://www.latex-project.org|LaTeX]], and collaborate on [[https://www.overleaf.com|Overleaf]]. I typically perform edits in suggesting mode so that changes are tracked. When you are integrating my suggestions, do not simply go through accepting them! The way you will improve your writing is by taking the time to understand why I'm making each suggestion. (There is a real danger that when I send you a bunch of changes instead of handwritten comments, you could miss the opportunity to develop your own skills if you don't pay attention.) Second, I could be wrong! Just like everything else, it's perfectly reasonable to question my approach or disagree, and it's better to discuss so there's no confusion. In any case, simply going through and accepting suggestions is a huge mistake.
I expect people to write papers using the fewest, simplest, commonest English words possible. For most of our readers, English is a second language.
I strongly encourage you to write MATLAB code that produces figures at the intended publication size, with specified font sizes, line widths etc. I can show you how to do this if you need help. This saves a lot of time that would be spent editing in [[https://inkscape.org|Inkscape]].

Some good general resources for paper writing are below. There are plenty of more detailed guides on the web.
 * [[http://www.tulane.edu/~lamp/whiteside.pdf|Whitesides' Group: Writing a Paper]]. Whitesides, Advanced Materials 2004.
 * [[https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1005619|Ten simple rules for structuring papers]]. Mensh & Kording, PLoS Comp Bio 2017.
 * [[https://cbs.umn.edu/sites/cbs.umn.edu/files/public/downloads/Annotated_Nature_abstract.pdf|How to construct a Nature summary paragraph]]. Nature guide to authors. (Just an example of how to create concise and compelling summaries that get people interested in your work.)

== Recommendation letters ==

One of my key roles in furthering people's careers is writing recommendation letters. If you haven't been in a position to evaluate applications or hire people before, then you may not realize how important these letters are! To give you perspective - when you're evaluating applications, it's really hard to know how things like GPAs, coursework, writing, tests, etc. will translate into future success. This is a really "noisy" process, but evaluators tend to put a lot of weight on someone else's personal evaluation.

Given the importance of these letters, I write them honestly and I put a lot of time and thought into them. My goal is that by the end of your time in lab, I'll be able to describe your accomplishments in convincing detail, and talk about things like your independence, drive, communication abilities, scholarship, passion, collegiality, honesty and openness, reliability, critical thinking skills, and ability to "get the job done."

Because I do spend a lot of time on these, you've got to give me a head's up well in advance (at least 2 weeks as mentioned above). Also, send me a reminder or two to help me keep track.

It's really helpful if you can compile useful materials - essentially put together a short draft of the info you think the letter should contain. Don't worry at all about the language, I will absolutely not submit what you write. But it will help me be sure that I include all the information you need. Try to cover the main projects you participated in, places where you felt you made significant contributions, your particular strengths that may have contributed to your achievements, and ways in which you feel you've grown/benefitted from being in the lab. I usually can't spend too much time talking about specific experiences outside of the lab (because I can't speak to them first hand), but if there are a few particular points you think are helpful to highlight that don't directly relate to our lab, mention them and I will incorporate if I can.

This may seem like a tedious process, but it's invaluable. The letter will end up being an honest assessment of you from my perspective, but hearing your perspective is really helpful! Also, I might forget about specific projects or instances where you played a really key role, and this is your chance to make sure that those highlights get into the letter. (Note: it feels awkward to some people to highlight your own accomplishments. Don't worry about it! Everyone is much too humble when putting these together. This is not the time to be modest!)

== Purchasing ==

If you need something less than $200 for your research, talk to the lab manager and he/she will deal with it. For something more expensive, let me know. All travel must be approved by me in advance, and save your receipts.

== Grant funding ==

Our funding comes from various sources - my startup package, grants from the NIH, and private foundations. I will often ask you for help with grants, especially preparing figures, reviewing text, helping brainstorm, etc. When this happens, it's usually on a tight deadline - sorry in advance.

I keep copies of many (successful and failed… usually successful) submissions on our lab's Box folder. These are confidential and only for internal lab use. I'd encourage you to read through some of them to understand the funding process, to see how often I fail at stuff too, and to get a sense of our lab's long-term vision. Feel free to discuss any of this with me.

== Vacation / time off ==

'''If you feel sick, do not come to work'''. Try to have your in-person responsibilities covered by other lab members, especially with respect to animal care. Let myself (Adam) and the lab manager know you are sick.

Folks at different levels have different vacation policies, set by their programs. Just to head off any confusion - new grad students sometimes assume they're still on the undergraduate calendar (e.g., with spring & winter breaks that are set based on class schedules, etc). Actually no, and each program has different guidelines, so be sure to understand the ones for your program. In general, I’ve always considered a “break” in the academic calendar to mean more time for bench work. I expect each person to keep track of their time off. Give me (and lab techs) a head's up ''at least 2 weeks in advance'' of any vacation time, and '''put vacation times (or other time off) on the shared calendar so everyone is aware'''. '''''Make sure your responsibilities are covered, especially for animal care'''''. Taking a vacation right before a big deadline is generally a bad idea. If that can't be avoided, be sure you're planning way, way in advance, and that everything's under control so we're not scrambling at the last minute!

== Choosing projects ==

The best thing about academia is that we have the ability to chase after the questions we're interested in. The key factors that balance this intellectual freedom are time and funding: ultimately, I have to be able to commit quite a bit of time to advising every project, and I only have a finite amount of time and can't stretch myself too thin. Second, we can't do a bunch of work that doesn't have a plan in place to fund it (or else the lab will eventually shut down). While there's always room for exploratory work that makes up the basis of a grant application, we can't stray too far from our core competencies. 

For people new to the lab, typically it'll take you a while to become an expert in our field and have a deep understanding of the open questions. During this time, you will most likely be working on a well-defined project, where we have worked out a lot of the scope and planning in advance. We have several already-funded projects in this vein. As you become an expert, you'll have more freedom to think through new projects, but our goal in general is to closely align your project directions with our areas of expertise, interest, and funding.

== Intellectual property ==

All work in the lab falls under University policies on intellectual property. This is covered either in your employment agreement (postdocs/techs), in one of the agreements covering your graduate studies (PhDs/masters students), or in the volunteering paperwork you fill out (undergrads). In brief, all intellectual property we create is owned by the University. 

== Peer-reviewing manuscripts ==

Part of my job as a researcher is to peer review manuscripts - this is considered a piece of our service to our scientific field. I will often share these manuscripts ('''in strict confidence''') with interested lab members. Participating in peer review is optional, but I consider it a key part of your academic training. It helps you understand:
 * How to critically evaluate a manuscript
 * How to provide critical, constructive feedback
 * How manuscripts are perceived from reviewers' perspectives
 * How to effectively interact with reviewers to address criticisms

Again, it's important to remember that manuscripts under review and associated author/reviewer/editor interactions are strictly confidential, and may absolutely not be shared beyond those involved in the review.

If you agree to help with peer review, I’ll first meet with you to discuss the process and I’ll show you some examples of reviews that I’ve written in the past. Then, I'll ask you to critically and thoroughly read through the manuscript, and provide your take. Then we will meet again to discuss the paper before I submit the review. 

If you participate in reviews, you can/should add them to your CV. Consider registering with [[http://publons.com|Publons]] to keep track of your reviewing efforts.

== Info for new or prospective students ==

=== Technical areas ===

As mentioned above, we take graduate and undergraduate students from a broad range of backgrounds. Regardless of the project you're on, developing your technical skills will be crucial. Regarding programming, incoming graduate students should be experienced in MATLAB or Python (preferably both). Because so much of our work requires substantial computational power, students should be comfortable working on Linux servers. Regarding technical subjects, students will typically need to know or become comfortable with machine learning, calculus, differential equations, linear algebra, signal processing, dimensionality reduction, dynamical systems, and information theory. For experimental projects, students typically become proficient in large animal handling, aseptic surgery, behavioral training, electrophysiology, basic electronics, and basic mechanical and computer engineering.
No one comes in with expertise in all these areas. However, if you're looking at this list and none of these terms are at all familiar, it may be hard to get integrated into the lab.

{{{#!wiki comment
Need to come up with a good background reading list (and update the description of our interests). Should become a subpage or a separate page eventually... -acs02sep2020

=== Reading material ===

We think a lot about how the coordinated activity of populations of neurons represents information and drives behavior. We are especially focused on understanding large networks of neurons as coordinated, dynamical systems, and using deep learning methods to understand these dynamics. This paper list is not at all exhaustive, but it covers many of the concepts that people who have been in the lab for a while are expected to be familiar with. If you're really interested in the work we do, I'd recommend starting with the reviews below. 
[put a reading list here]
}}}

=== Notes for prospective grad students ===

In our case, graduate students joining the lab would first need to be accepted by one of the relevant graduate programs at the University of Rochester, either Brain and Cognitive Sciences or Neuroscience. It is not possible to join the lab without being first accepted to a graduate program. Apply in the Fall!
I am a mentor both for the Brain and Cognitive Sciences graduate program and the Neuroscience graduate program. Be advised that for Brain and Cognitive Sciences, students are typically admitted directly into a lab, whereas the Neuroscience program uses a rotation system. 
There's unfortunately a lot of randomness to joining a lab, because the timing has to be right (room in the lab, funding, open projects). Don't get discouraged if there aren't openings in my lab. Some things are out of our control.
Grad school is complex, and choosing a great mentor is critical for your career. Do your homework! 

=== Notes for prospective undergrads ===

 * First, check [[https://adams-lab.weebly.com|our lab home page]] to see if we are currently accepting new undergraduates. Space is unfortunately limited.
 * Read the [[#undergrads|expectations for undergrads]] above. If you don't think you can match those expectations, best to look for a different research experience.
 * When you contact me, be sure to include a CV, your undergrad and high school GPA, relevant courses you've taken, and some info about why you're specifically interested in our lab.
 * Make it clear what you're looking for. Are you looking to volunteer? Which semester? How long of a commitment (hours/week) do you expect to be able to put in? How many semesters do you think you can commit to research? When do you plan on graduating?
 * I get a lot of emails where people clearly copy and paste a form email to many professors, and I get it - finding a lab is hard. From my standpoint, I'm looking for people who are going to be passionate about and dedicated to our specific line of research. Anything you can do to show me that you've taken the time to think specifically about why our lab is a good fit will help make your note stand out.
 * Emails often slip by me when I'm particularly busy. Sorry. If you're really interested in the lab and haven't heard from me in a few weeks, it's OK to email again.
 * Mention to me that you read this far. That's a good sign. :)