SNEL Manual

Lab manual for the Systems Neural Engineering Lab.

Welcome!

This is the Lab manual for the Systems Neural Engineering Lab at Emory University and the Georgia Institute of Technology. Our research is in the area of systems neuroscience and neuroengineering, and we're part of the GT/Emory Coulter Department of Biomedical Engineering, the Emory Department of Neurosurgery, and the Emory Neuromodulation Technology Innovation Center (ENTICe).

If you've just joined the lab - welcome! We're excited to have you as part of the team. You'll find the lab filled with smart, passionate people with broad interests at the intersection of neuroscience, engineering, and computational sciences. We really value diversity and openness in our lab, and hope to make it a friendly and productive environment.

If you are officially joining, take the time to read this manual through, then sign this form saying you've done so (and send to me via email).

Acknowledgement

Our lab manual borrows heavily from this one. I was inspired to put it together after reading Mariam Aly's great article, and via thoughtful discussions as part of the GT/Emory BME Dept's Committee on Diversity and Inclusion.

This lab manual is licensed under a Creative Commons Attribution - NonCommercial 4.0 International License. Feel free to borrow from it (and cite it!).

The lab manual is a work in progress. If you have ideas for improving it, please drop me (Chethan) a line!

General philosophy

The mission of our lab is to produce work that truly advances the fields of neuroengineering and neuroscience, develops novel strategies and devices to treat disorders of the nervous system, and never compromises in quality and scientific integrity. Concurrently, we aim provide rigorous academic training to scholars who will go on to have impactful careers (in academia, industry, or more broadly).

For new researchers, a helpful thing to keep in mind is that research is fundamentally different from most people's experiences in school. In most undergraduate classes (and many professional training environments), you're usually asked to solve problems with a known solution. You have a syllabus, a textbook, lecture notes, etc., and generally if you use the listed resources and do what you're told, you will succeed. In research, we're ultimately trying to expand the frontiers of human knowledge. Therefore, with research questions, if we (or anyone else) already knew the answer, we would not be studying the question. A great piece that describes this concept is the now classic "The importance of stupidity in scientific research". One key takeaway: don't worry when you don't know the answer to something. That's to be expected, and often times, nobody does! Once you're comfortable with that idea, you can focus on using all the resources around you to figure out the answer.

Here are some keys to being successful in our lab environment:

  • Collaboration: Our lab benefits greatly by being an intellectually diverse team. We bring in expertise from many disciplines, e.g., Electrical Engineering, Computer Science, Neuroscience, Biomedical Engineering, Physiology, Physics. No one in the lab (including myself) has the background necessary to tackle all the problems we're trying to solve. Therefore, the only way we can be successful is by fostering an openly collaborative and communicative environment. Ultimately, our group strongly selects for team members who are comfortable admitting what they don't know and learning new material as they go (both through independent research and discussion with colleagues).

  • Patience: As mentioned above - if we already knew the answer, we would not be studying the question. Similarly, if the work was easy, usually someone else would've done it already. From that standpoint, we fundamentally expect our experiments and approaches to fail more often than they succeed. So while we're always shooting for success, it's important to have thick skin and not get overly frustrated when things aren't working out. Just keep working diligently, keep thinking through the problem, and keep discussing it with your colleagues. It's also important to continually make honest evaluations on whether a problem is worth pushing on further, or when it's worth cutting our losses and moving on.

  • Accept the process: Don't hide or be afraid of contradictory results, mistakes, bugs, etc. We're going to make mistakes, and we'll find plenty of results that challenge our hypotheses, or that we don't initially know how to explain. So even if something is intimidating or embarassing, the only way forward is to face it head-on and openly, figure out solutions, and move on.

  • Caution: Science is about being extremely careful and thorough. Double and triple check every result. Be extremely skeptical about results, and think through every way they could be wrong before concluding that they're correct. Ask others to look at your results and think of ways they might be wrong. If we apply extremely high standards internally, then our work will easily pass external review.

  • Attention to detail: Our studies often involve complex systems and processes, with many points of failure that could doom an entire experiment or analysis. So careful attention to detail and quality control are crucial for making sure things keep moving forward.

  • Communication: Technical skills are important, but equally (if not more important) are communication skills. No one in our lab works in isolation (see first item above!) - at a minimum, you communicate frequently with your PI (me), and likely work closely with other lab members and collaborators. So without sustained effort from everyone to communicate, it's easy for things to go off track, for there to be misunderstandings or duplicated efforts, etc. (See a longer section below on my preferred methods of communication.)

  • Feedback: We want everyone in the lab to be comfortable giving and receiving direct, constructive criticism and feedback. It's extremely challenging to open up your thoughts and ideas to criticism, for fear that people will judge you personally. But if everyone is comfortable giving and receiving feedback that is never personal, it opens us up to different perspectives. Often this will reveal flaws in ideas that are hard to see when you're too close to them, and new solutions. Similarly, it's easy to get too attached to ideas because they're your own - we all have an instinct to go prove our ideas and show how clever we are. In our lab environment, that's not the goal! There's no "extra credit" for doing things on your own. It's much more important to find ways to solve the problem and get the job done, and the folks around you are wonderful resources to make that happen.

  • Positivity: Everyone on our team is working on a challenging set of problems. Being positive and supportive makes the endeavor more enjoyable for everyone. If you run into issues where it's difficult to be positive and supportive with your colleagues, take a break and come talk to me, we'll work something out.

  • Balance: Don't try to work 24/7, if for no other reason than you'll just find yourself staring at a screen without doing anything productive. Work smarter - I find it helpful to create focused blocks where I eliminate distractions. However you do it, make sure you take breaks to refresh your mind, and have a life outside of lab. There are obvious benefits for your mental health, but you'll also find yourself refreshed and productive when you do get back to work.

Expectations and responsibilities

All lab members should:

  • 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.
  • Exercise independent thinking and judgement.
  • Take on responsibilities, and reliably fulfill commitments.
  • Perform first-rate work with an extreme attention to detail.
  • Actively communicate your progress and project directions so we're all on the same page (see General Policies: Communications section below)
  • Openly communicate your struggles and mistakes.
  • Maintain the highest standards of moral and ethical conduct and scientific integrity.
  • 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 (Twitter is a surprisingly good resource for this - follow scientists whose work is relevant to you).

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 very 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, emotionally
  • 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 weekly 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

  • 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 unusuable!
  • 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 abide by Emory University's policies on discrimination and harassment, which you must read. Your certification that you've read this lab manual is also affirmation that you will abide by Emory's 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 the Office of Equity and Inclusion 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 the Aly lab manual, 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 GitHub) to keep track of what code changes you made and when you made them, as well as sharing code with others.

Reproducibility is related to replicability, which refers to whether your results can be obtained again with a different data set. That is, if someone ran your study again (with a different group of participants), do they get the same results? If someone ran a conceptually similar study, do they get the same results? Science grows and builds on replicable results – one-off findings don’t mean anything. Our goal is to produce research that is both reproducible and replicable."

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 IACUC and registration and orientation with DAR. 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. Emory's guidelines on authorship largely follow the International Committee of Medical Journal Editors (ICMJE) recommendations. As a serious researcher, it is important that you familiarize yourself with these guidelines.

While there are multiple ways of interpreting such guidelines, our lab in general favors inclusivity. 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, 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 layout 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. A key motto I learned from my mentors is to talk about authorship "early and often." 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 timeframe, 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 Emory/GT). 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 parters and secure their permission.

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 pictures of animals in the lab are assumed to be kept 100% internal unless you have explicit permission from me for other uses.

Occasionally you might want use pictures of other lab members in your presentations - check with them to make sure it's appropriate. You might also need a picture of an animal in a presentation - check with me to confirm this is OK. 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. As best as I can tell, there's no reason it would be appropriate to share pictures of our lab animals on social media.

Lab resources

Most of the resources below require access privileges, so if you don't already have them, ask me.

Slack

Slack is the communications backbone in our lab. Our workspace is https://snel.slack.com/.

Shared Google Calendars

We have two primary shared calendars:

  • SNEL-shared: for keeping track of general events (lab meetings, talks, conferences, when folks are out of town, etc).
  • SNEL-lab hours: to coordinate day-to-day schedules. Undergrads should list time periods they plan on being in lab every week (either setup recurring events for the semester, or post your hours at least a week in advance). Grad students/technicians/postdocs/staff should list time periods they don't plan on being in lab. This isn't to track "face time", but to make it easier to schedule face-to-face discussions, know when not to bother people on Slack, etc.

We have a few specialized or project-specific calendars (surgery, scheduling jobs on the cluster, task management / tracking certain projects, etc).

Basecamp

Basecamp is really helpful for task management (tracking progress on to-do lists, sharing results for specific tasks).

Gitlab

Gitlab is a server for hosting git repositories. Note that this is hosted on an internal lab server (not an external website), meaning you have to be on Emory's campus or logged in via the VPN to access it. All code for all systems in the lab is tracked on our Gitlab server.

Github

We have a Github organization for creating public-facing code repositories.

Wiki

Our lab wiki as a way for everyone in the lab to contribute to more specific documentation of lab practices, technical info, etc. (private, requires OSF account and access privileges)

Google drive

File sharing, collaborative editing, presentations, and archiving of abstracts/papers/theses/pictures, etc.

Listserv

Our Google Groups listserv is often a quick way to disseminate email announcements from other sources.

Computing resources

Much of our work uses sophisticated computational techniques, and we have a suite of powerful servers for this purpose. More often than not, if you are working on a computational task, it is easier to do it on one of our servers, or all of them in a cluster configuration. (You'll need a specific account to use these machines.)

General policies

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). I feel the same way about potentially bothering my own mentors and supervisors! Fight that instinct. Bottom line - I much prefer that people in the lab speak up, and I have no problem telling people if they are in fact bothering me (so far, this has never happened).

If these are sources of anxiety, I totally get it. However, if it's possible to overcome them, your time in lab will end up being much easier, and likely your productivity will increase quite a bit!

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

  • Meet 1:1 every 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 weekly summary and plans for the upcoming week.
  • Post ongoing progress/results in a relevant Slack channel (good for chat, not great for long-term tracking) or on Basecamp (great for being able to come back to later)
  • 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 post (at minimum) an update once/week in a Slack channel relevant to your project. Update should describe your progress over the past week and your plans for the coming week. 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.

Note this is a minimum, and I prefer more communication to less. For example, some folks will send a 2-3 line update in the morning outlining their high-level goals/plans and checking in. This is a really good strategy and never bothers me, even if I don't have time to respond. Often, this process will reveal areas where we aren't on the same page, and prevent larger misunderstandings. So if this works for you, awesome. I certainly recognize that different people have different communication styles.

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

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 between the hours of 10:30a to 4p. Beyond those hours, some folks might like to work early, others late, but having a minimum window ensures there's a time where people can count on interacting with each other.

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 involve 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.

As mentioned above, all undergrads should setup 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 once/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 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 expect 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. 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 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 responsibile for ensuring this happens, including scheduling and coordinating with your fellow lab members.

We keep copies of previous presentations in the lab Google Drive. 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.

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. Unfortunately, I have never enjoyed writing a Methods section (but maybe you will!).

  • So far we've had success with collaborative drafting and iterating in Google Docs. This is a rapid way to make progress. For folks who prefer Latex, Overleaf is a good option. 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.

Some good general resources for paper writing are below. There are plenty of more detailed guides on the web.

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."

Some key points:

  • 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, add an event to the lab shared calendar and have it send me a reminder email a week in advance, 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 the I include all the information you need. Mention how I know you, how long you've been in the lab, and what program(s) you're in. 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 pretty awkward 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!)

  • When applying for a lot of things (e.g., your grad school applications, multiple fellowships, academic job applications, etc) - create a Google (or etc) spreadsheet containing all the places you're applying to, deadlines, any links or other info you have, and I will update the spreadsheet as I submit each item.

Purchasing

Generally if you need to buy something that's less than ~$50, I prefer you order it to move quickly, and then just drop me a line to let me know you did. If something's more expensive, let me know and I'll get back to you soon. It is important to me that progress isn't stalled because we're waiting for parts or etc. In general, your time is the most valuable commodity in the lab.

We have multiple avenues for purchasing items (Emory Express for many vendors, Amazon, Newegg, Arrow, Digikey). Generally grad students and postdocs have access to our corporate card for purchasing from external vendors, or work with our admin (Colleen Spellen). If you purchase anything on our corporate card, please (please) send the receipt to Colleen as soon as you have it, and don't forget this step.

Grant Funding

Our funding comes from various sources - my startup package, grants from the NSF, NIH, DARPA, 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) submissions on our lab's Google Drive share. 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

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. I expect each person to keep track of their time off. Give me a head's up at least 2 weeks in advance of any vacation time, and put vacation times on the shared calendar so everyone is aware. 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!

Some resources to find more info on vacation (and other) policies:

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.

In general, because our lab spans computation and experimental approaches, and we have wonderful collaborators that share neurophysiological data from humans, nonhuman primates, and mice, there are many unique opportunities. It's easy to find a good match for your interests among our space of projects!

Intellectual property

All work in the lab falls under Emory's policies on intellectual property ( cached copy here - see Emory websites for official up-to-date policies ). 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).

A brief overview of the policies/process: First, all intellectual property we create is owned by Emory. Typically if we develop technology that is important to protect, we can work with Emory's Office of Technology Transfer to file protections (e.g., provisional and utility patents, software copyrights). If these patents are awarded and licensed, Emory shares a portion of the revenue with inventors (us).

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.

I'll first ask who is interested in reviewing. For those involved, I'll ask each of you to critically and thoroughly read-through the manuscript, and provide your take. You can follow my process (outlined below) or your own. There are plenty of great online resources for understanding the review process.

I typically start by reading through the abstract and intro to understand what questions are being asked, their importance, whether I buy the fundamental questions, and how they are going to go about testing them. This often requires reading through a couple of the cited manuscripts to put the work into context. Next, I'll go through the Results/Figures (often flipping back and forth between the Results and Methods) to understand what is being tested and how, determine if it's being rigorously tested, and whether or not I agree with the methodology and results. This is the most important step, for me. Then I'll read through the Discussion and flag any items that I might feel are unfounded or I have strong disagreements with. It usually takes me 4 or 5 read-throughs to feel comfortable providing a critique.

To construct a critique, I'll first try to write out 1 or 2 summary paragraphs describing what the authors did (if I can't create a good high-level summary of their main points, I have no business reviewing the paper). Most often I will follow that with a high-level evaluation of the strengths of the paper, and if I feel it is a particularly good fit for the journal (or not), I'll say so. Next, I create a two lists containing major and minor criticisms. For each major criticism, I find it important to layout how that relates to the central hypothesis, whether I feel it can be addressed, and if so how.

For group reviews, once everybody has taken the time to do the above, we'll all get together and discuss our independent evaluations. Getting independent evaluations helps us ensure we're looking at the work from different perspectives and being fair. After thorough discussion, I'll compile a review and submit back to the journal.

If you participate in reviews, you can/should add them to your CV.

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 typically must become 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 become typically proficient in rodent handling, surgery, behavioral training, electrophysiology, real-time systems, circuits, and embedded systems.

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.

Reading material

We think a lot about how the coordinated activity of populations of neurons represents information and drives behavior. Much of our work is focused on understanding large networks of neurons as coordinated, dynamical systems, and using deep learning methods to understand these dynamics. We also try to leverage these insights to build better brain-machine interfaces for people who are paralyzed.

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 review articles below. Note that many people have institutional access to papers (through your university library or etc) - I'd recommend learning how to setup a proxy if you haven't already. If you need one of the below papers, email me and I'll try to help.

[Updated 2023-05-26]

Review articles:

Brain-machine interfaces

Along with collaborators, I wrote two informative reviews at the intersection of brain-machine interfaces and systems neuroscience. The first review listed covers many of the concepts we think about in the lab.

  • Pandarinath C, Bensmaia SJ. (2021) The science and engineering behind sensitized, brain-controlled bionic hands. Physiological Reviews. Sep; 102:551-604. [link]

  • Pandarinath C, Ames KC, Russo AA, Farschian A, Miller LE, Dyer EL, Kao JC. (2018) Latent factors and dynamics in motor cortex and their application to brain-machine interfaces. Journal of Neuroscience, 38(44) 9390-9401 [pdf].

Computation through Dynamics

In the last 10-ish years, an emerging perspective is that certain brain areas act as dynamical systems to drive movements. This perspective underlies much of the work we do:

  • Vyas S, Golub MD, Sussillo D, Shenoy KV. (2020) Computation Through Neural Population Dynamics. Annual Review of Neuroscience, 43 249-275. [link]

  • Shenoy KV, Sahani M, Churchland MM (2013) Cortical control of arm movements: A dynamical systems perspective. Annual Review of Neuroscience. 36:337-359. [pdf].

Dimensionality reduction in neuroscience:

Much of the work we do relies on understanding how to analyze and interpret coordinated patterns of neural activity. John Cunningham and Byron Yu wrote a great overview of this topic a few years ago:

  • Cunningham JP, Yu BM (2014) Dimensionality reduction for large-scale neural recordings. Nature Neuroscience. Nov;17(11):1500-9. [pubmed].

Computational approaches we use:

We created LFADS, a deep learning method to uncover dynamics from single trial neural population activity. This paper goes over much of the theory and demonstrates application to a few different simulated systems.

  • Sussillo D, Jozefowicz R, Abbott LF, Pandarinath C. (2016) LFADS – Latent Factor Analysis via Dynamical Systems. arXiv:1608.06315, 22 Aug. [arXiv].

Then this paper is more explanatory, and shows how it can be applied to real neural data.

  • Pandarinath C, O’Shea DJ, Collins J, Jozefowicz R, Stavisky SD, Kao JC, Trautmann EM, Kaufman MT, Ryu SI, Hochberg LR, Henderson JM, Shenoy KV, Abbott LF, Sussillo D. (2018) Inferring single-trial neural population dynamics using sequential auto-encoders. Nature Methods, 15(10). [pubmed] [free access].

Brain-machine Interfaces

Here's some of our previous work on high-performing brain-machine interfaces for people who are paralyzed

  • Pandarinath C*, Nuyujukian P*, Blabe CH, Sorice BL, Saab J, Willett F, Hochberg LR, Shenoy KV**, Henderson JM**. (2017) High performance communication by people with tetraplegia using an intracortical brain-machine interface. eLife. Feb 21; 6. [Open access at eLife]

  • Gilja V, Pandarinath C, Blabe CH, Nuyujukian P, Simeral JD, Sarma AA, Sorice BL, Perge JA, Jarosiewicz B, Hochberg LR, Shenoy KV**, Henderson JM**. (2015) Clinical translation of a high performance neural prosthesis. Nature Medicine, Oct;21(10):1142-5. [DOI]

Scientific papers that heavily influence our thinking:

  • Driscoll L, Shenoy KV, Sussillo D. (2022) Flexible multitask computation in recurrent networks utilizes shared dynamical motifs. bioRxiv [link]. Shows how dynamical structure (fixed points) can be employed and adjusted by neural networks to flexibly perform a variety of computations.

  • Churchland MM, Cunningham JP, Kaufman MT, Foster JD, Nuyujukian P, Ryu SI, Shenoy KV. (2012) Neural population dynamics during reaching. Nature, Jul 5;487(7405):51-6. [pubmed]. Demonstrated that prominent rotational dynamics underlie population activity in M1 during reaching behavior.

  • Kaufman MT, Churchland MM, Ryu SI, Shenoy KV. (2014) Cortical activity in the null space: permitting preparation without movement. Nature Neuroscience, Mar;17(3):440-8. [pubmed]. Shows that low-D structure in M1 is organized into subspaces, and that activity related to movement preparation is orthogonal to activity that actually drives movement.

  • Sadtler PT, Quick KM, Golub MD, Chase SM, Ryu SI, Tyler-Kabara EC, Yu BM, Batista AP. (2014) Neural constraints on learning. Nature, Aug 28;512(7515):423-6. [pubmed]. Demonstration that the low-D structure we commonly observe in M1 relates to the constraints on the network's ability to generate patterns of activity.

  • Russo AA, Bittner SR, Perkins SM, Seely JS, London BM, Lara AH, Miri A, Marshall NJ, Kohn A, Jessell TM, Abbott LF, Cunningham JP, Churchland MM. (2018) Motor cortex embeds muscle-like commands in an untangled population response. Neuron, Feb; 97(4). [pubmed] Demonstrates that much of the neural activity in motor cortex does not correspond directly to task-related variables, but instead serves to "detangle" population dynamics.

Books:

  • Rieke F, Warland D, de Ruyter van Steveninck R, Bialek W. Spikes: Exploring the Neural Code (Computational Neuroscience) [amazon]. Classic book that provides computational/probabilistic frameworks for understanding how information is represented in the nervous system.

  • Dayan P, Abbott LF. Theoretical Neuroscience. Computational and Mathematical Modeling of Neural Systems. [website] [pdf]. The go-to textbook in computational and systems neuroscience.

  • Goodfellow I, Bengio Y, Courville A. Deep Learning. [website]. The best deep learning-related textbook I've seen so far.

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 Emory or Georgia Tech (Biomedical Engineering, Neuroscience, Machine Learning, Electrical Engineering, Computer Science, Bioengineering, etc). It is not possible to join the lab without being first accepted to a graduate program. Apply in the Fall!

  • It's hard to understand all the programs here. Some quick notes: BME is joint between GA Tech & Emory and is the most likely path to the lab. The Neuroscience PhD program is at Emory, and is one of the few programs around that does structured rotations. I have the most involvement with BME and Neuro, e.g., I read many of the applications. ML and BioE are interdisciplinary programs based at GA Tech. Each program will have a different curriculum, and which program is most appropriate really depends on the training you want, and what type of career you're looking for after.

  • 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! A helpful starting point is Ben Barres’s article, How to Pick a Graduate Advisor.

  • Here’s a page from the Shackman lab with great tips and resources on the grad school applications process.

Notes for prospective undergrads

  • Read the 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? Are you more interested in experimental or computational work?

  • 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. :)