SNEL Manual

Lab manual for the Systems Neural Engineering Lab.


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


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:

Expectations and responsibilities

All lab members should:

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:

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:

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:

Undergraduate Students

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.

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:

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:


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 is the communications backbone in our lab. Our workspace is

Shared Google Calendars

We have two primary shared calendars:

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


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


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.


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


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.


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


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:

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:

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.


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.


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:

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.


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!


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.

Other general points:

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

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!)


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:

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

[Updated 2019-03-18]

Review articles:

Details on the computational approaches we use:

Papers that heavily influence our thinking:


Notes for prospective grad students

Notes for prospective undergrads