This is our lab manual, outlining how we work, collaborate, and grow as a team. It contains expectations, lab policies, and the lab’s principal investigator (PI)’s approach to mentorship and the PhD process. Please read it carefully before joining the lab and refer back to it regularly.

PhD Process and Career Planning

A PhD is not simply about completing program requirements, finishing coursework, or publishing papers. It is about becoming a critical, creative, and independent researcher, embedded in a network of collaborators. The true outcome of your PhD is not just a thesis or a list of publications—it is you: a rigorously trained professional capable of identifying real-world problems, generating original ideas, designing, testing, and validating solutions, and presenting your work with clarity and integrity. Just as important, you will build a professional network and grow into a leader, an effective communicator, and a collaborative team member—skills that are essential in any career path, whether in academia, industry, or entrepreneurship.

In my experience, this transformation looks different across academic systems. In Europe and some other regions, PhD students typically pursue focused, well-defined research questions. Progress is measured through clear milestones—the number and quality of publications, presentations, and committee approvals—and once those are met, the path to defense is usually straightforward. There, the emphasis is on depth and individual contribution. In the U.S. and similar systems, the PhD journey is more often embedded within broader, collaborative lab efforts that align with external funding priorities—whether from federal agencies, private foundations, or industry. Your work extends beyond a single dissertation: you may contribute tools, software, systems, or models as part of a team working toward long-term goals. Your progress is interwoven with the group’s; your contributions both depend on and advance the work of others. In this setting, the principal investigator (PI) is not only your thesis advisor but also functions as a lab leader—balancing team management, strategic planning, grant writing, and project execution.

There is no universal answer to when to graduate. While you must meet your program’s formal requirements, advisor expectations, and project commitments, the timing is ultimately strategic—and should align with your next career step. If you are pursuing academic jobs or postdocs, defending earlier may help you enter the market at the right time. If you’re exploring other directions, staying enrolled while finalizing applications, securing a postdoctoral position, or completing publications may be more advantageous. These decisions are not purely academic—they are also personal. Health, family, financial constraints, and immigration status can all be significant factors. Please share these considerations with me early. Understanding your trajectory helps me plan for project continuity, allocate lab resources, and support your transition. The same applies to internships and conference travel—communicate your interests and timelines in advance so we can coordinate responsibilities and project commitments accordingly.

Lab Roles and Structure

Our broader team includes undergraduates, master’s students, PhD students, postdocs, and research staff. While everyone reports to the PI, mentorship often flows through a layered structure: senior students and postdocs help onboard junior members, and some projects may have technical or domain leads. As you grow in the lab, you will contribute to more than one project and may take on more leadership or mentorship responsibilities. Respect and collaboration are expected across all roles and experience levels.

Mentorship and Meetings

The PhD process is intellectually demanding and, at times, personally challenging. If you’re feeling disconnected from your work, uncertain about your direction, or questioning your fit in the lab, please speak up. We can reassess, recalibrate, or pivot if needed.

Mentorship is tailored to your stage in the program. Junior researchers—undergraduates and master’s students—receive more frequent guidance. For PhD students, the frequency of one-on-one meetings evolves over time to support increasing independence. In Year 1, we’ll meet weekly to cover onboarding, foundational skills, and any research or career-related questions. In Year 2, meetings become biweekly. In Year 3, we’ll meet every three weeks. From Year 4 onward, monthly meetings are the norm—by then, you likely won’t want to meet more often anyway. These are individual meetings with me and do not include research team meetings, coursework, or office hours. If you ever need more time—whether for research, career planning, or anything else—just reach out and we’ll set something up.

Plan ahead for the support you need. If you’re requesting a recommendation letter from me or any other faculty member, please give at least three weeks’ notice. Include your most recent CV, a draft of what you’d like emphasized based on the opportunity, and relevant context. Take the lead; the more complete and organized your portfolio, the more effectively we can support you.

Keep a professional CV and an up-to-date NIH or NSF biosketch on hand, and be sure to share them with me. Fellowship and funding opportunities often come up on short notice, and it’s your responsibility to ensure your materials are current. Make sure to tweak and customize your CV based on the position or fellowship for which you are applying.

If you’re giving a presentation, please send your finalized slides at least one week in advance. For major milestones—such as your proposal, dissertation defense, or competitive fellowship applications—submit your materials at least one month ahead of time so I can provide thoughtful and timely feedback. Plan early and communicate early. It matters—for your work, your development, and your career.

Communication

Be respectful of others’ time, space, and focus. Respond to calendar invites, show up to meetings on time, and come prepared. Keep common BMI/lab areas and shared equipment clean.

During office hours, I often respond to emails quickly. However, I receive a high volume of email each day. So if you contact me with project updates and don’t hear back immediately—or even for up to a week—it’s not a negative sign. In most cases, it means you’re on track and managing your work well, while I may be focused on teaching, grant writing, reviews, or other responsibilities. If your message is time-sensitive, please follow up. If it’s urgent, include “URGENT” in the subject line. For important, time-bound issues and deadlines, send a reminder after 24 hours.

If we need to schedule a virtual call to discuss research, send me an email first. Please contact me by phone only in case of true emergencies, not for routine research updates. You are welcome to call me anytime—24/7—for personal emergencies involving safety, family, health, or immigration issues. For medical emergencies, always call 911 first. Emory’s LGS Student Affairs also offers excellent resources for counseling and emergency support.

Intellectual Property

The projects we contribute to belong to the lab, not to individuals. This may seem counterintuitive, but all projects are team efforts funded by grants that we, as a group—within and beyond our lab—have worked hard to secure. In many cases, multiple students, postdocs, faculty, and collaborators have contributed to the preliminary data, infrastructure, and hardware/software development behind a project. As you join, you’re building on work initiated by others—just as others will build on your work in the future. We all receive credit for our contributions through publications, presentations, and patents, but this is not a solo experience; the lab operates as a scientific enterprise, much like a startup.

From time to time, I may need to reassign tasks and/or onboard other people onto projects to meet deadlines and fulfill the commitments made in grant proposals. Please do not take it personally if I reassign part of a project or shift responsibilities; these decisions are often based on project/grant deadlines and funding obligations.

For the same reason, the intellectual property associated with lab projects is collectively owned by the team of contributors and managed under the discretion of the PI. As PI, I make these decisions based on a broad understanding of the project’s scope, funding context, and the full history of contributions. If you have any questions, concerns, or expectations regarding intellectual property, I encourage you to discuss them with me—either before joining the lab or as they arise. Open communication helps ensure that everyone feels their contributions are acknowledged and respected. Please also review Emory’s Copyright and Intellectual Property Policies.

Authorship

Publication of code or data must be coordinated with the PI. All GitHub repositories for active projects will be private by default and may be made public based on the requirements of the funding agency or the PI’s decision. Patent and licensing rights will be negotiated based on actual contributions.

Authorship in manuscripts reflects meaningful contributions to the research question, study design, implementation, analysis, or writing. We follow standard academic guidelines—such as those outlined by the ICMJE—and expect all co-authors to participate in manuscript development and approve the final version. Authorship decisions is discussed early in a project and revisited as roles evolve. Students and researchers will remain co-authors on publications where their contributions are essential to the final outcome, even after leaving the lab. If your contributions do not meet authorship criteria, they will be acknowledged appropriately. Transparency and fairness are essential throughout.

Expectations for Growth

Innovation is a key element of your future career. It emerges at the intersection of hard work, deep knowledge, exposure to challenges and new ideas, and conversations with your peers. But “you’re unlikely to discover something new without a lot of practice on old stuff”—a quote often attributed to Richard P. Feynman.

So, as a graduate student or postdoc, you should be reading at least one scientific paper per day or trying out new methods, tools, or software—whether within or beyond your research focus. This builds your technical and writing skills, as well as the depth and awareness you’ll need to publish and grow within and beyond your specific area.

Try to skim well-established textbooks—at least one per week. Use the library and borrow hard copies. Digital versions rarely stay in our minds like good old-fashioned physical copies. When reading textbooks, start by reviewing the table of contents, selecting chapters and sections that interest you, and digging deeper as needed.

Attend regular talks presented by labmates, as well as internal and external speakers. Listening to an hour-long talk from an expert is a simple yet valuable opportunity to familiarize yourself with a new field or expand your network.

Keep notes from meetings and presentations you attend, and the papers or books you read. Self-notes, especially handwritten ones, help track your development and remind you of the context in which a topic was discussed. Keep your notes organized in your cloud folder.

Share notes related to project updates and your thesis with me, and include a link to them in our one-on-one meeting calendar invites. All recurring meetings should have a single document that is updated each time we meet. Please take notes during the meeting—do not leave it until the end. Studies like Peterson & Peterson (1959) showed that after about 18 seconds, much of the unrehearsed (undocumented in our case) information is lost!

Your skills, interests, and research focus will evolve. So will the lab’s priorities, which are shaped by ongoing projects and available funding. Especially during the early years—such as during lab rotations—explore what you’re good at and what excites you. If you’d like to shift directions, let me know as soon as possible. I’ll support the transition if feasible, though such changes may take time due to existing project commitments.

Whether you’re aiming for academia or industry, start planning your career early. The conferences and workshops you attend, the skills you develop, and the internships you pursue should all align with your goals. In our one-on-one meetings, we’ll discuss your future path and what you need to do to get there. It’s up to you to take initiative and stay on top of your career plan.

Work-Life Balance, Leave and Vacation Policy

During regular work hours, I expect full availability and prompt email responses; however, I do not expect mentees to work on weekends or holidays as a general practice. So, if you receive an “unurgent” email over a holiday from me, feel free to wait until the next working day to respond.

However, as we have all experienced, in academia and research it’s not always possible to draw clear boundaries or fully unplug outside office hours. There may be times—such as grant application deadlines or critical project milestones—when work extends beyond office hours. These situations should be occasional and generally planned.

It’s your responsibility to manage your time effectively and maintain a realistic, healthy work-life balance. If you’re feeling overwhelmed, need to take a day (or more) off, or are facing personal challenges, please let me know.

For planned time off, please send me your request at least two weeks in advance so we can coordinate around project deliverables and deadlines. During high-stakes periods like grant submissions, we may ask to adjust your schedule accordingly. In cases of illness or emergency, just notify me as soon as possible.

If you are on a student visa, please ensure that you comply with Emory’s ISSS guidelines before planning any travel.

Use of AI and Large Language Models (LLMs)

The AI landscape is evolving rapidly, but in my view, the academic and professional world still demands hard skills in theory, research, engineering, critical thinking, problem-solving, and technical writing. If you graduate without mastering these areas, you’ll be outpaced by your peers.

LLMs (like ChatGPT, GitHub Copilot, and others) are helpful and time-saving for writing, coding, brainstorming, and summarizing. You are welcome to use them where appropriate. However, use them intentionally and with caution, and ensure you comply with all relevant training and research policies. For example, many professors, journals, and funding agencies require disclosure of LLM use. Depending on the context, I might ask you to deliver some tasks without the use of any LLMs. Please stay compliant.

LLMs should not replace your foundational skills—research design, scientific reasoning, problem-solving, coding, writing, critical thinking, or professional communication. These are essential to your future success, and no tool can substitute for them. You are training to become a Doctor of Philosophy—someone capable of independently designing and evaluating research, generating ideas, and executing them. If you outsource these core skills to an AI tool, you’re not learning what you need—and when everyone else has access to the same tools, you risk becoming replaceable in the job market. Note that AI is not a shortcut to expertise. Use it as an accelerator, not a substitute. Learn to critically evaluate their outputs and correct the hallucinations or errors they may produce. With or without use of AI, you are fully responsible for the work you deliver.

Technical Onboarding

When you join a project, the PI will share a cloud-hosted folder with you (on Google Drive or OneDrive). Use this folder to store all your reports, presentations, notes, and related documents. We host LaTeX documents, reports, and manuscripts on Overleaf, and codebases are exclusively hosted on GitHub.com under the lab organization.

Keep everything organized under relevant folders, and do not create duplicate or disorganized copies of codes, reports, or manuscripts. For each project, maintain a single slide deck that you update as we go. When providing progress updates, add them to that deck and refer to it in your email with hyperlinks. Do not send slide decks as offline email attachments. Always keep the master document online. We may pull them up and present them in meetings live. So keep them up to date and self-contained for presentation.

Cloud storage is not optional—it is mandatory lab practice. Send me your GitHub.com ID as soon as you join the lab. I, or the project PI, will create a private repository for you under the lab’s GitHub organization. Push your code to that repository daily, or several times a day as needed—even if the code is not complete.

If a code or document is on your laptop and not in the repository or shared cloud, it does not exist to others. When deciding whether to keep something local or push it to the cloud/GitHub, ask yourself: “How much time can I afford to lose if my computer crashes right now?” The answer shouldn’t be more than a few hours.

All results and code updates should be communicated by referring to your GitHub repository. When working on multiple projects, please ensure that you organize and push the code to the relevant repositories. We may reorganize or restructure GitHub repositories throughout a project as needed.

Do not email code or data. No data, especially if patient-related, should be pushed to GitHub. The only exception is small, fully de-identified public samples used strictly for demo purposes. Make sure to seek permission for sharing any such samples before posting them online.

No Protected Health Information (PHI) or other sensitive medical data should leave HIPAA-compliant storage, such as Emory’s OneDrive or the Emory BMI cluster. Google Drive is not currently HIPAA-compliant for Emory. No PHI data should be stored there or on your personal computers. All cloud work must follow institutional data security requirements.

If you are working on any PHI data on a local computer (with the PI’s prior written or electronic approval), make sure that the computer’s disk is encrypted (for example, using the macOS FileVault built-in disk encryption feature). Check how to encrypt your computer based on your operating system.

Do not share any datasets over email. Push them to the appropriate cloud folder and link them in your communication. Whether on the cluster or on the cloud, never overwrite the original data folder. Source and destination (result) folders should always be separated.

Please do not share private or identifiable human data—even with labmates, staff, or faculty—without prior coordination with the PI. The collection, storage, and sharing of human subjects data are subject to Institutional Review Board (IRB) approval and under the responsibility of the protocol PI. Only individuals who have been formally added to the approved IRB protocol may access or work with such data. As a lab practice, all human subjects data are organized on our cluster lab space under directories labeled with the corresponding IRB protocol numbers. Sharing data outside this scope, even unintentionally, can lead to serious ethical and legal violations. If you are unsure whether an activity or dataset you have access to falls under IRB restrictions, check with the PI before exploring the data.

All project documents and reports should live on Emory OneDrive, the BMI Google Workspace, or Overleaf. If you’re writing a paper or tech report, use Overleaf and keep it shared with the PI and your collaborators. Documents should stay online until you’re ready to submit them. Offline versions lead to confusion, incompatible copies, loss of updates, and inconsistencies.

When naming documents, avoid generic names like “Document,” “Final version,” or “My Fellowship copy v3,” etc. These are not searchable or meaningful for anyone a week from now. Use filenames that include your full name and the project or submission type. For example, “reza-sameni-ecg-digitization-google-fellowship-2025” or “reza-sameni-phd-proposal-2024”. Do not date files/codes manually in the cloud; contemporary cloud platforms track all changes and commit/change times automatically. Only use dated filenames when downloading files for external submissions or archiving, or when a file/folder is for a specific call, e.g., /R21-Blood-Pressure-NIBIB-June-2023/ or sameni-biosketch-ECG-Digitization-R01-June-2025.docx, which refer to specific grant submission cycles.

Coding Practices

Push code to GitHub regularly. Avoid hardcoded paths in your code. Do not write file paths like /Users/alex/data. Use relative paths or configuration files when developing portable code. Whenever needed, define file names and paths in a well-documented configuration file. Code must be reproducible by others in the lab and beyond. Your code should not be written in isolation—it should be usable by the next person who joins the project and should be readable in the future by yourself and others. That means clean structure, documentation, modular design, and no reliance on local setups or local libraries.

All data and code repositories must have a README file that includes the project title, contributors, setup and utilization procedures, a license file, contact emails, and citations to related publications. No need for over-documentation—just write it for your future self (in a week or months from now). We typically use the BSD 3-Clause License for our codebases, unless specified by the PI.

When submitting changes to shared/public repositories, open a pull request with a clear summary of what’s changed and why. Review others’ code constructively, and expect your own code to be reviewed the same way. Code reviews help everyone learn and optimize our codebases.

Systematic programming is part of being a researcher, not just a coder. To excel in your programming skills and software engineering practices, refer to Clean Code by Robert C. Martin for principles on readable, maintainable code, and Clean Architecture by the same author for structuring software in a scalable and testable way. These references are not just for software engineers—they’re valuable for scientific computing, big data, and biomedical informatics as well.

Cluster Usage

On the shared departmental cluster, we use SLURM for workload management and job scheduling. The BMI cluster is highly heterogeneous and serves many users, so responsible usage is essential and expected. Always request resources—CPUs, memory, GPUs, and time—based on a reasonable estimate of what your task actually requires, not based on the maximum available resources. Over-requesting wastes capacity and may delay others’ jobs; under-requesting can cause your job to fail or run out of memory, wasting your time and creating an unnecessary carbon footprint.

As advised by the BMI IT team, avoid running large jobs directly on the login node (oddjobs)—this is intended only for file transfers, code setup, and job submission. Use srun or sbatch to submit jobs, and monitor their status with squeue.

Before launching a large-scale or long-running job, test your scripts on a smaller scale to catch bugs and estimate runtimes. For long tasks involving many data files, use SLURM’s parallel job features and save results frequently so that you can resume if the task fails or is terminated/restarted by the admin. Use try/except (or equivalent error-handling) in your codes to ensure that failures on one record do not terminate the entire job.

Ensure your code logs both results and error messages in a readable format to help with debugging. SLURM allows you to direct error logs to text files for further debugging. Clean up temporary files after your jobs finish, and periodically review your storage usage. If you’re unsure how to request resources efficiently or interpret cluster logs, ask a labmate or consult the cluster documentation—it’s a shared departmental resource and we’re all responsible for keeping the system fair and efficient for everyone.

Conflict Resolution

Research is a team effort, and conflict can happen—whether about timelines, workload, communication styles, or credit. When it does, try to raise your concerns early and discuss them directly, constructively, and privately. If that’s not successful or appropriate, bring the issue to me. It is my responsibility to support and help mediate a resolution. For sensitive issues, the BMI Department Chair, the BMI Vice Chair for Training and Education, Emory’s Ombuds Office and other campus resources are available. It’s always okay to ask for help.

Code of Conduct

We are committed to maintaining an open, respectful, and inclusive environment for everyone in the Alphanumerics Lab, in alignment with Emory University’s policies on equity and nondiscrimination. This includes adherence to Title IX, which prohibits discrimination based on sex, as well as Emory’s Equal Opportunity and Discriminatory Harassment Policy, which prohibits discrimination and harassment based on race, color, religion, national origin, age, disability, and other protected characteristics.

All lab members are expected to use inclusive language, respect differing perspectives, provide and receive constructive feedback professionally, and act with empathy, integrity, and accountability. Harassment, discrimination, sexual misconduct, retaliation, or other disruptive behavior—whether in person, online, or in lab communications—is not acceptable. Consequences for violations may include informal conversations, formal warnings, removal from lab activities, or further action as appropriate.

Please note that Emory faculty are mandatory Title IX reporters. This means if a faculty member becomes aware of a situation that may involve a Title IX violation (e.g., sexual harassment, assault, or discrimination based on sex), they are legally required to notify Emory’s Title IX office. The intent of this policy is to ensure access to support, resources, and a fair process. Emory’s Title IX office maintains as much privacy as possible for both complainants and respondents—offering support without assumptions and protecting all parties involved.

Alleged violations may be reported confidentially to the lab PI or through official Emory channels, including the Office of Equity and Compliance and Title IX staff.

Our lab values transparency, collaboration, and mutual respect. The research journey includes both rewarding and challenging moments. We are committed to supporting one another and upholding the highest standards of scientific and professional conduct.

Welcome to the team! Feel free to reach out if you have any questions.

—Reza Sameni