By Prof. Milan Amrut Joshi — Researcher in TDA, Optimization & Machine Learning
╔══════════════════════════════════════════════════════════════╗
║ ║
║ "The PhD is not about proving you're smart. ║
║ It's about proving you can keep going ║
║ when everything is confusing." ║
║ ║
║ — Every PhD survivor, ever ║
║ ║
╚══════════════════════════════════════════════════════════════╝
Let me be honest with you.
When I started my PhD, I had no idea what I was doing. I didn't know how to structure a paper. I didn't know what "Reviewer 2" meant (oh, I learned). I didn't know that getting rejected wasn't the end of the world — it was just Tuesday. I didn't know that the hardest part of a PhD isn't the research itself; it's everything around the research that nobody teaches you.
Over the years, across 15+ publications in SCI, SCIE, and Scopus-indexed journals, a Best Paper Award at ICIVC-2021, and more rejection letters than I care to count, I've accumulated a set of lessons, templates, workflows, and hard-won wisdom that I wish someone had handed me on Day 1.
This repository is that handbook.
It's not a textbook. It's not some sanitized "guide to academic excellence." It's the real, practical, sometimes messy truth about how research actually works — written by someone who has been through it and is still going through it.
Whether you're a first-year PhD student staring at a blank LaTeX document, a postdoc trying to survive the publish-or-perish treadmill, or a seasoned researcher who just wants better templates — there's something here for you.
If this repo helps even one person feel less lost in academia, it was worth making.
Star it. Fork it. Share it with your lab. Add your own tips. Let's build the resource we all needed but never had.
- Why This Exists
- 📝 How to Write a Research Paper
- 📬 How to Respond to Reviewers
- 🎤 How to Give a Great Research Talk
- 🏆 How I Got My Best Paper Award
- 📐 LaTeX Templates
- ✅ Checklists
- 🔄 Research Methodology Flowcharts
- 🛠️ Essential Tools for Researchers
- 📚 Recommended Books
- 🎯 Journal Selection Guide
- 💡 PhD Life Tips
- 🤝 Contributing
- 📖 Citation
This is the core skill of academia, and yet almost nobody teaches it properly. Here's everything I've learned from writing 15+ papers.
The research gap is the foundation of your entire paper. Without a clear gap, you don't have a contribution — you have a homework assignment.
How to find a gap:
| Method | What to do | Pro tip |
|---|---|---|
| Survey papers | Read the "Future Directions" section of 3-5 recent survey papers in your field | These are literally experts telling you what hasn't been done yet |
| Limitation mining | In every paper you read, highlight the "Limitations" and "Future Work" sections | Keep a running document of these — your next paper is hiding in there |
| Method transfer | Take a technique from Field A and apply it to a problem in Field B | My TDA work came from applying topological methods to ML problems |
| Failure analysis | Find a well-known method that fails in certain cases, then fix it | "Method X works great except when Y" is a paper waiting to happen |
| Dataset gap | Find domains where existing methods haven't been tested | New datasets + existing methods = surprisingly publishable |
| Scale it up | Take something that works on small problems and make it work at scale | Optimization and efficiency improvements are always needed |
Personal note: My best research ideas came not from reading more papers, but from asking "Why does this method fail here?" while doing experiments. Failures are gifts if you pay attention.
The Gap Validation Test: Before you write a single word, answer these three questions:
- What exists? (Current state of the art)
- What's missing? (The gap — be specific)
- Why does it matter? (The "so what?" factor)
If you can't answer all three clearly in 2-3 sentences each, your gap isn't sharp enough yet.
Most research papers follow the IMRaD structure. Here's what actually goes in each section:
┌─────────────────────────────────────────────────────┐
│ TITLE │
│ (Specific, Informative, <15 words) │
├─────────────────────────────────────────────────────┤
│ ABSTRACT │
│ (Self-contained, 150-250 words) │
├─────────────────────────────────────────────────────┤
│ INTRODUCTION │
│ • What's the problem? │
│ • Why does it matter? │
│ • What has been done before? (Brief) │
│ • What's still missing? (THE GAP) │
│ • What do you propose? (Your contribution) │
│ • How is the paper organized? │
├─────────────────────────────────────────────────────┤
│ RELATED WORK / LITERATURE REVIEW │
│ • Organized by themes, NOT chronologically │
│ • Show how your work fits into the landscape │
│ • End with what's missing (reinforces YOUR gap) │
├─────────────────────────────────────────────────────┤
│ METHODOLOGY │
│ • Problem formulation (math, definitions) │
│ • Your proposed approach (step by step) │
│ • Algorithm/framework diagram │
│ • Theoretical analysis (if applicable) │
├─────────────────────────────────────────────────────┤
│ EXPERIMENTS & RESULTS │
│ • Datasets description │
│ • Experimental setup & baselines │
│ • Results tables & figures │
│ • Ablation studies │
│ • Statistical significance │
├─────────────────────────────────────────────────────┤
│ DISCUSSION │
│ • What do the results mean? │
│ • Why does your method work (or not)? │
│ • Limitations (be honest) │
│ • Broader implications │
├─────────────────────────────────────────────────────┤
│ CONCLUSION │
│ • Summary of contributions (not results!) │
│ • Future directions │
│ • Final takeaway │
├─────────────────────────────────────────────────────┤
│ REFERENCES │
│ (Formatted per journal style, 30-60 refs typical) │
└─────────────────────────────────────────────────────┘
Pro tip: Write the sections in this order: Methodology -> Results -> Introduction -> Related Work -> Discussion -> Conclusion -> Abstract -> Title. Yes, write the abstract last. You can't summarize something you haven't written yet.
The abstract is the most important paragraph you'll write. 80% of people who see your paper will only read the abstract. Here's a battle-tested template:
[CONTEXT - 1 sentence]
<Topic/Field> is important because <reason>.
[PROBLEM - 1-2 sentences]
However, existing methods <limitation>. This makes it challenging to <specific problem>.
[APPROACH - 2-3 sentences]
In this paper, we propose <method name>, a <type of method> that <key innovation>.
Our approach <how it works at a high level>. Unlike previous methods, <key differentiator>.
[RESULTS - 2-3 sentences]
Experiments on <datasets/benchmarks> demonstrate that <method name> achieves
<specific metric improvement> compared to state-of-the-art methods.
Specifically, <highlight 1-2 key numbers>.
[IMPACT - 1 sentence]
These results suggest that <broader implication / future direction>.
Abstract quality checklist:
- Can someone outside your subfield understand it?
- Does it contain at least one specific number/result?
- Is it self-contained (no references, no abbreviations without definitions)?
- Is it within the word limit (usually 150-250 words)?
- Does it make the reader want to read the full paper?
Don't just read papers randomly. Be strategic.
The Snowball Method:
Start Paper (seminal work in your area)
│
├── Forward snowball: Who cited this paper?
│ └── Find recent papers building on this work
│
└── Backward snowball: What does this paper cite?
└── Find foundational works you might have missed
My literature review workflow:
- Google Scholar — Start with 5-10 keywords. Sort by date for recent work, by citations for seminal work.
- Connected Papers (connectedpapers.com) — Paste a key paper's URL. Get a visual graph of related papers. This tool is gold.
- Semantic Scholar — Better than Google Scholar for finding the most relevant papers, not just the most cited.
- arXiv — For cutting-edge preprints (especially in ML/AI). Check weekly.
- Reference tracking — When you find a great paper, look at its references AND who cited it.
How many papers should you read?
| Paper type | References expected |
|---|---|
| Workshop paper | 10-20 |
| Conference paper | 20-40 |
| Journal paper | 40-80 |
| Survey paper | 100-300+ |
Honest truth: You don't need to read every paper cover-to-cover. For most papers: read the abstract, skim the introduction, look at the figures and tables, read the conclusion. Deep-read only the 10-15 papers most relevant to your work.
This is where your actual contribution lives. Make it crystal clear.
Rules for a good methodology section:
- Start with problem formulation. Define your inputs, outputs, objective function. Use math notation consistently.
- Use a framework diagram. A single clear figure explaining your pipeline is worth 1000 words.
- Be reproducible. Someone should be able to reimplement your method from this section alone.
- Number your equations. Only number the ones you reference later.
- Explain your design choices. Don't just say "we use ReLU activation" — say why you chose ReLU over alternatives.
Common methodology mistakes:
- Writing it like a tutorial instead of a research paper
- Not defining notation before using it
- Missing crucial implementation details
- Over-complicating the explanation (if a reviewer can't follow it, that's YOUR problem)
Your results section should tell a story, not just dump numbers.
Table formatting rules:
- Bold the best result in each column
- Include standard deviations or confidence intervals
- Always include at least 2-3 baseline methods for comparison
- Use consistent decimal places (e.g., always 2 decimal places for accuracy)
Figure guidelines:
- Every figure should be understandable without reading the paper text
- Use colorblind-friendly palettes (viridis, cividis)
- Label axes clearly with units
- Use vector graphics (PDF/SVG) for plots, not raster (PNG/JPG)
What makes results convincing:
| Element | Why it matters |
|---|---|
| Ablation study | Shows each component of your method contributes |
| Statistical tests | Proves improvements aren't just noise |
| Multiple datasets | Shows generalizability |
| Failure cases | Shows honesty and self-awareness |
| Runtime comparison | Practical applicability matters |
After reviewing dozens of papers (and making most of these mistakes myself), here are the killers:
- Overclaiming. "Our method is the best" vs. "Our method outperforms baselines on X dataset under Y conditions." Be precise.
- Weak baselines. Comparing against outdated methods to look good. Reviewers will catch this every time.
- No ablation study. If you have a multi-component method and don't show what each component contributes, expect Reviewer 2 to demand it.
- Copy-paste literature review. Listing papers like "A did X. B did Y. C did Z." Instead, synthesize: "Approaches to X can be categorized into three families..."
- Ignoring related work. If a reviewer finds a relevant paper you didn't cite, they'll assume you didn't do your homework.
- Poor writing quality. Grammar issues, typos, and unclear sentences signal carelessness. Use Grammarly + have a colleague proofread.
- Figures that need a magnifying glass. If text in your figures is smaller than the paper body text, it's too small.
Here's honestly how I write a paper, start to finish:
Week 1-2: Run experiments. Get messy. Try things. Break things.
Keep a lab notebook (I use Notion) of what worked and what didn't.
Week 3: Results are promising? Start organizing.
Create all figures and tables first.
The paper's story should emerge from your results.
Week 4: Write Methodology and Results sections.
(These are the easiest because you already did the work)
Week 5: Write Introduction and Related Work.
(Now you know what your contribution is, so you can frame it)
Week 6: Write Discussion, Conclusion, Abstract.
First complete draft exists.
Week 7: Let it sit for 2-3 days. Don't look at it.
Fresh eyes catch mistakes tired eyes miss.
Week 8: Revise. Cut 20% of the text. Tighten every sentence.
Send to co-authors for feedback.
Week 9: Incorporate feedback. Final proofread.
Format for target journal/conference.
Week 10: Submit. Celebrate. Start dreading the reviews.
Key insight: I write the paper around my figures and tables. If I can tell the full story just by looking at the figures in order, the paper structure is right.
This is the part of academic publishing that strikes genuine fear into the hearts of researchers. Let's make it less terrifying.
Your response letter should have this structure:
Dear Editor and Reviewers,
We sincerely thank the reviewers for their constructive feedback, which has
significantly improved our manuscript. We have carefully addressed all comments
and made substantial revisions to the paper.
Below, we provide point-by-point responses to each reviewer's comments.
Original comments are in [BOLD], our responses are in regular text, and
changes made to the manuscript are highlighted in [BLUE].
================================================================
REVIEWER 1
================================================================
[Comment 1]: <Original reviewer comment, quoted verbatim>
Response: <Your detailed response>
Changes made: <Exact text added/modified in the paper, with page/line numbers>
----------------------------------------------------------------
[Comment 2]: <Next comment>
...
================================================================
REVIEWER 2
================================================================
...
Here's a LaTeX template for your response letter:
\documentclass[11pt]{article}
\usepackage[margin=1in]{geometry}
\usepackage{xcolor}
\usepackage{enumitem}
\definecolor{reviewercolor}{RGB}{0, 0, 180}
\definecolor{responsecolor}{RGB}{0, 100, 0}
\definecolor{changecolor}{RGB}{180, 0, 0}
\newcommand{\reviewer}[1]{\textbf{\textcolor{reviewercolor}{Reviewer Comment: }} \textit{#1}}
\newcommand{\response}[1]{\textbf{\textcolor{responsecolor}{Our Response: }} #1}
\newcommand{\change}[1]{\textbf{\textcolor{changecolor}{Changes Made: }} #1}
\begin{document}
\begin{center}
\Large\textbf{Response to Reviewers}\\[0.5em]
\large Manuscript ID: XXXX-XXXX\\
\large Paper Title: Your Paper Title Here
\end{center}
\vspace{1em}
Dear Editor and Reviewers,
We sincerely thank the reviewers for their insightful comments...
\section*{Reviewer 1}
\reviewer{The motivation for using TDA features is not clearly explained
in Section 2. Why should persistent homology be preferred over traditional
feature extraction methods?}
\response{We thank the reviewer for this important observation. We have
expanded Section 2 to include a detailed comparison of TDA features
with traditional methods, emphasizing that persistent homology captures
multi-scale topological features that are invariant to continuous
deformations...}
\change{Added paragraphs 2-3 in Section 2.1 (page 4, lines 12-28).
Added Table 2 comparing feature extraction approaches.}
\end{document}You can find the full template at templates/reviewer_response.tex.
Let's be real — sometimes reviews are unfair. Here's how to handle it:
Step 1: Feel your feelings. Read the review. Get angry. Complain to your advisor/friends. Close the laptop. Walk away for at least 24 hours. Never respond while emotional.
Step 2: Re-read with fresh eyes. 90% of the time, even harsh reviews contain at least one valid point buried under the rudeness. Find it.
Step 3: Categorize each comment:
| Category | What it means | How to respond |
|---|---|---|
| Valid and important | They found a real issue | Fix it. Thank them genuinely. |
| Valid but minor | Typo, formatting, small clarification | Fix it quickly. |
| Misunderstanding | They didn't get what you wrote | That's YOUR fault. Rewrite for clarity. |
| Unreasonable | Asking you to rewrite a different paper | Politely explain scope. Stand your ground. |
| Factually wrong | They made an error in their critique | Correct them politely with evidence. |
Step 4: Respond professionally, always. Even when Reviewer 2 is clearly wrong. Even when they clearly didn't read your paper. The editor is watching, and your professionalism matters.
Ah, Reviewer 2. The legendary figure of academic folklore. The one who asks you to compare against a method that doesn't exist. The one who says "this is trivial" and "this needs more explanation" in the same review.
The 5 Stages of Receiving Reviewer 2's Comments
================================================
1. DENIAL → "There's no way they actually read my paper."
2. ANGER → "WHO REVIEWS A PAPER LIKE THIS?!"
3. BARGAINING → "Maybe if I just address points 1 and 3..."
4. DEPRESSION → "My research is worthless. I should quit."
5. ACCEPTANCE → "Okay, some of these points are actually fair."
"Let me fix this and resubmit."
Real talk: In my experience, about 70% of "Reviewer 2" comments — even the harsh ones — contain actionable feedback that genuinely improves the paper. The remaining 30%? You respond to them professionally, make reasonable changes, and write a clear explanation of your position.
Golden phrases for reviewer responses:
- "We thank the reviewer for this insightful observation..."
- "This is an excellent point that has helped us strengthen our paper..."
- "We appreciate the reviewer raising this concern. We would like to respectfully clarify..."
- "Following the reviewer's suggestion, we have conducted additional experiments..."
- "We agree that this point needed further elaboration. We have revised Section X to..."
Phrases to NEVER use:
- "The reviewer is wrong." (Even if they are)
- "We disagree." (Too blunt — use "We would like to respectfully offer an alternative perspective...")
- "This is out of scope." (Instead: "While this is a fascinating direction, it falls outside the scope of the current work. We have added it to Future Work in Section 6.")
- "As clearly stated in the paper..." (This sounds condescending)
This is the hardest judgment call in academic publishing.
Should I make this change?
┌───────────────────┐
│ Is the reviewer's │
│ point technically │
│ correct? │
└────────┬──────────┘
┌────┴────┐
YES NO
│ │
┌───────┴──┐ ┌──┴────────────┐
│ Does it │ │ Can you prove │
│ improve │ │ them wrong │
│ the paper?│ │ with evidence? │
└─────┬─────┘ └──────┬────────┘
┌───┴───┐ ┌────┴────┐
YES NO YES NO
│ │ │ │
┌───┴───┐ ┌┴────┐ ┌┴─────┐ ┌┴──────────┐
│ DO IT │ │Make │ │Push │ │ Make a │
│ gladly│ │small│ │back │ │ compromise │
│ │ │tweak│ │with │ │ and │
└───────┘ │move │ │proof │ │ explain │
│ on │ └──────┘ └────────────┘
└─────┘
Rule of thumb: If implementing the change takes less time than arguing about it, just do it.
You've written the paper. Now you have to talk about it. In front of people. Who will ask questions. Fun.
The cardinal rule: One idea per slide.
| DO | DON'T |
|---|---|
| Large fonts (24pt minimum) | Walls of text |
| Key figures and diagrams | Full paragraphs from your paper |
| Bullet points (max 5 per slide) | Tables with 47 rows |
| Consistent color scheme | Rainbow explosion of colors |
| Speaker notes for yourself | Reading slides verbatim |
| Build-up animations for complex ideas | Gratuitous slide transitions |
| Slide numbers | Unlabeled axes on plots |
My slide structure for a 15-minute conference talk:
Slide 1: Title slide (title, authors, affiliations)
Slides 2-3: Motivation — Why should the audience care?
Slide 4: Problem statement — What are we solving?
Slide 5: Key insight — The "aha!" moment
Slides 6-8: Method overview — How your approach works
Slides 9-11: Results — The goods (key figures and tables only)
Slide 12: Comparison — How you beat the baselines
Slide 13: Conclusion — 3 bullet points max
Slide 14: Future work / Open questions
Slide 15: Thank you + contact info + QR code to paper
Guy Kawasaki's famous 10-20-30 rule (10 slides, 20 minutes, 30pt font), adapted:
| Talk type | Slides | Time | Min font size |
|---|---|---|---|
| Conference short talk | 8-12 | 10-15 min | 24pt |
| Conference regular talk | 15-20 | 20-25 min | 22pt |
| Invited seminar | 30-45 | 45-60 min | 20pt |
| Thesis defense | 40-60 | 30-45 min + Q&A | 20pt |
| Lab meeting / group talk | 10-30 | 15-45 min | 20pt |
The golden ratio of talk preparation: 1 hour of preparation per 1 minute of talk. A 15-minute conference talk? That's 15 hours of preparation if you want it to be great.
Q&A is where good talks become great talks (or where panic sets in).
Before the Q&A:
- Prepare 3-5 "backup slides" with additional results, proofs, or details that didn't fit in the talk
- Anticipate the 3 most likely questions and prepare concise answers
- Have your paper open on a tablet/phone for quick reference
During the Q&A:
| Situation | What to do |
|---|---|
| You know the answer | Answer concisely. Don't ramble. |
| You partially know | Answer what you can, acknowledge what you can't |
| You don't know | "That's a great question. I haven't explored that specifically, but my intuition is..." or simply "I don't know, but I'd love to discuss it afterward." |
| Hostile question | Stay calm. "Thank you for the challenging question." Address the substance, not the tone. |
| Unclear question | "Could you clarify what you mean by X?" (This is perfectly acceptable) |
| The questioner is giving a speech | Wait politely, then ask "What's your specific question?" |
Important: "I don't know" is a perfectly valid answer. It's honest, and it's far better than making something up in front of 200 people.
| Aspect | Conference Talk | Thesis Defense |
|---|---|---|
| Audience | Peers who chose your session | Your committee (they MUST be there) |
| Goal | Spark interest, get citations | Prove mastery of your field |
| Depth | Surface-level, highlight key results | Deep dive, show you understand everything |
| Q&A | 2-5 minutes, polite questions | 30-60+ minutes, probing questions |
| Preparation | Practice 5-10 times | Practice 15-20 times |
| Stress level | Moderate (low stakes) | Maximum (career milestone) |
| Dress code | Smart casual | Slightly more formal |
Storytime. My first conference talk was at a small workshop. I had 15 minutes. I prepared 35 slides. I spoke so fast that I finished my 35 slides in 12 minutes, skipping half of them. During Q&A, someone asked a basic question about my baseline method and I blanked completely. I stood there, mouth open, for what felt like eternity (probably 5 seconds). I mumbled something incoherent and the session chair mercifully moved on.
I went back to my hotel room and seriously considered a career change.
But here's what I learned:
- Fewer slides, more depth. 15 slides for 15 minutes, not 35.
- Practice out loud. Reading slides silently is NOT practice. Stand up, talk to a wall if you have to.
- Time yourself. Practice with a timer, every single time.
- Know your baselines cold. If you compare against Method X, you better be able to explain Method X.
- Nobody remembers your bad talk as much as you do. I've never had someone say "Hey, weren't you the person who bombed that talk in 2019?" It only lives in your head.
My talks got much better after that. Failure is a teacher, not a sentence.
At ICIVC-2021 (International Conference on Image and Vision Computing) in Oman, I received the Best Paper Award for my work on TDA-based feature extraction. Here's the real story — not the polished version, but the messy truth.
Month 1-2: Had a vague idea about using persistent homology for feature
extraction in image classification. Couldn't get it to work.
Considered abandoning it twice.
Month 3: Breakthrough! Changed the filtration approach and suddenly
the features were meaningful. Ran initial experiments.
Results were... okay. Not great. Kept pushing.
Month 4: Deep-dived into parameter tuning. Tried 200+ configurations.
Found the sweet spot. Results started looking strong.
Month 5: Started writing. Struggled with explaining TDA concepts to a
computer vision audience. Rewrote the introduction 6 times.
Month 6: First complete draft. Sent to co-authors. Got feedback that
the methodology section was "incomprehensible." Rewrote it.
Month 7: Submitted to my top-choice journal.
Rejected. Desk rejection, actually. "Not suitable for this venue."
Devastating.
Month 8: Regrouped. Revised the framing. Submitted to ICIVC-2021.
Nervous wait begins.
Month 9: Accepted! Prepared the camera-ready version.
Worked on the presentation slides.
Month 10: Presented at the conference. Won Best Paper Award.
Completely shocked. Called my family immediately.
- The desk rejection hurt. I had spent months tailoring the paper for that specific journal. Getting rejected without review felt personal (it wasn't).
- Technical dead ends. My first three approaches to the TDA feature extraction didn't work. I only found the right approach through systematic experimentation.
- Writing struggles. Explaining topological data analysis to reviewers who might not know TDA was a massive challenge. I rewrote key sections many times.
- Imposter syndrome. Even after getting good results, I kept thinking "someone must have already done this." I checked obsessively.
- Pivoting venues quickly. After the desk rejection, I didn't mope for months. I revised the framing within two weeks and found a better-fit venue.
- Investing in figures. I spent significant time creating clear, intuitive diagrams that explained the TDA pipeline visually. The reviewers specifically praised the figures.
- Honest limitation discussion. I didn't oversell. I clearly stated where the method works and where it doesn't. Reviewers appreciated the honesty.
- Strong baselines. I compared against the actual state-of-the-art, not weak strawman methods.
- Rejection is redirection. The desk rejection forced me to reframe the paper, which actually made it stronger.
- Visuals sell ideas. Reviewers and audiences understand diagrams faster than equations.
- Explain your work to a non-expert. If your mother/friend can understand the idea (not the math), your explanation is good enough.
- Don't wait for perfection. My paper wasn't perfect when I submitted. No paper ever is. "Good enough to submit" is a real threshold.
- Awards are nice, but they're not the goal. The real reward was the knowledge I gained and the connections I made at the conference.
All templates are available in the templates/ directory.
| Template | File | Description |
|---|---|---|
| IEEE Conference/Journal | templates/ieee_paper.tex |
Standard IEEE two-column format |
| Springer LNCS | templates/springer_lncs.tex |
Lecture Notes in Computer Science format |
| Beamer Presentation | templates/beamer_talk.tex |
Clean, minimal academic talk template |
| Journal Cover Letter | templates/cover_letter.tex |
Submission cover letter template |
| Reviewer Response | templates/reviewer_response.tex |
Point-by-point response letter |
| PhD Thesis | templates/thesis_template.tex |
Chapter-based thesis structure |
\documentclass[conference]{IEEEtran}
\usepackage{amsmath,amssymb,amsfonts}
\usepackage{graphicx}
\usepackage{textcomp}
\usepackage{xcolor}
\usepackage{cite}
\usepackage{hyperref}
\usepackage{booktabs}
\begin{document}
\title{Your Paper Title: A Method for Something Important}
\author{
\IEEEauthorblockN{First Author}
\IEEEauthorblockA{Department of Computer Science\\
University Name\\
email@university.edu}
\and
\IEEEauthorblockN{Second Author}
\IEEEauthorblockA{Department of Mathematics\\
Another University\\
email2@university.edu}
}
\maketitle
\begin{abstract}
Your abstract goes here (150-250 words)...
\end{abstract}
\begin{IEEEkeywords}
keyword1, keyword2, keyword3, keyword4
\end{IEEEkeywords}
\section{Introduction}
Your introduction...
\section{Related Work}
Literature review...
\section{Methodology}
Your method...
\section{Experiments and Results}
Results...
\section{Conclusion}
Summary...
\bibliographystyle{IEEEtran}
\bibliography{references}
\end{document}\documentclass[aspectratio=169]{beamer}
\usetheme{Madrid}
\usecolortheme{seahorse}
\usepackage{amsmath}
\usepackage{graphicx}
\usepackage{booktabs}
\title[Short Title]{Full Title of Your Research Talk}
\author{Your Name}
\institute{Your University}
\date{Conference Name, 2024}
\begin{document}
\begin{frame}
\titlepage
\end{frame}
\begin{frame}{Outline}
\tableofcontents
\end{frame}
\section{Motivation}
\begin{frame}{Why This Matters}
\begin{itemize}
\item Key motivation point 1
\item Key motivation point 2
\item Key motivation point 3
\end{itemize}
\end{frame}
% ... more slides ...
\begin{frame}{}
\centering
\Huge Thank you!\\[1em]
\large Questions?\\[2em]
\normalsize your.email@university.edu\\
\small Paper: \url{https://doi.org/your-paper-doi}
\end{frame}
\end{document}Use this before submitting ANY paper. Print it out if you have to.
CONTENT & STRUCTURE
[ ] Title is specific, informative, and under 15 words
[ ] Abstract is self-contained and within word limit
[ ] Abstract contains at least one specific quantitative result
[ ] Introduction clearly states the research gap
[ ] Introduction ends with a contribution summary
[ ] Related work is organized thematically (not chronologically)
[ ] Methodology is reproducible from the description alone
[ ] All symbols/notation are defined before first use
[ ] Results include comparison with recent state-of-the-art
[ ] Ablation study is included (for multi-component methods)
[ ] Limitations are honestly discussed
[ ] Conclusion summarizes contributions (not just results)
[ ] Future work is mentioned
FIGURES & TABLES
[ ] All figures are referenced in the text
[ ] All figures have descriptive captions
[ ] Figure text is readable at print size
[ ] Tables use booktabs style (\toprule, \midrule, \bottomrule)
[ ] Best results are bolded in comparison tables
[ ] Colorblind-friendly color palette used
[ ] Figures are vector format (PDF/SVG) where possible
REFERENCES & CITATIONS
[ ] All claims are supported by citations
[ ] Reference list includes recent papers (last 2-3 years)
[ ] No broken citations ([?] or missing references)
[ ] References are formatted per journal/conference style
[ ] Self-citations are reasonable (not excessive)
FORMATTING & POLISH
[ ] Paper fits within page limit
[ ] Consistent formatting throughout
[ ] No orphan/widow lines
[ ] Spell check completed
[ ] Grammar check completed (Grammarly or similar)
[ ] Co-authors have reviewed and approved
[ ] Supplementary material is prepared (if needed)
[ ] All author names and affiliations are correct
[ ] Acknowledgments section included (funding, etc.)
[ ] Keywords are relevant and specific
SUBMISSION LOGISTICS
[ ] Target journal/conference is appropriate for this work
[ ] Formatting follows submission guidelines exactly
[ ] Cover letter is prepared (for journal submissions)
[ ] All required files are ready (source, figures, supplementary)
[ ] No identifying information in blind review papers
[ ] PDF renders correctly (check on different viewers)
[ ] All reviewer comments have been addressed
[ ] Paper fits within final page limit
[ ] Author information is complete and correct
[ ] Copyright form is signed and submitted
[ ] Formatting matches camera-ready template exactly
[ ] DOI and page numbers are added (if required)
[ ] Final PDF is generated and checked
[ ] High-resolution figures are included
[ ] Supplementary material is finalized
[ ] Registration fee is paid (for conferences)
ONE WEEK BEFORE
[ ] Slides are complete and reviewed
[ ] Talk has been practiced 5+ times
[ ] Talk fits within time limit (with 1 min buffer)
[ ] Backup slides prepared for anticipated questions
[ ] Slides exported to PDF as backup
[ ] Talk saved to USB drive AND cloud storage
DAY BEFORE
[ ] Check presentation room and AV setup (if possible)
[ ] Verify slide format works on conference equipment
[ ] Charge laptop fully
[ ] Bring power adapter and display adapters (HDMI, USB-C)
[ ] Set phone to silent/airplane mode
[ ] Get good sleep (seriously)
DAY OF
[ ] Arrive early to test setup
[ ] Have water available
[ ] Disable notifications on laptop
[ ] Close unnecessary applications
[ ] Deep breath. You've got this.
ONE MONTH BEFORE
[ ] Thesis document is complete and submitted to committee
[ ] Defense date, time, and room are confirmed
[ ] All committee members have confirmed attendance
[ ] Started preparing presentation slides
TWO WEEKS BEFORE
[ ] Presentation slides are complete
[ ] Practiced full talk at least 3 times
[ ] Had a mock defense with lab members
[ ] Prepared answers for common committee questions
[ ] Created backup slides for each chapter
ONE WEEK BEFORE
[ ] Practiced 5+ more times (total 8-10 practices minimum)
[ ] Timed the full talk (aim for under time limit)
[ ] Reviewed committee members' research interests
(they'll ask questions related to their own work)
[ ] Prepared 1-page summary of key contributions
[ ] Mental health check: are you sleeping? eating? exercising?
DAY BEFORE
[ ] Final practice run
[ ] Prepare professional outfit
[ ] Charge all devices
[ ] Print backup copies of slides (just in case)
[ ] Early bedtime
DAY OF
[ ] Eat a good breakfast
[ ] Arrive 30 minutes early
[ ] Test all equipment
[ ] Remember: you are the world expert on YOUR thesis
[ ] You've done the work. Now show it.
┌──────────┐
│ IDEA │ ← Literature review, experiment observation,
│ SPARK │ advisor suggestion, shower thought
└────┬─────┘
│
▼
┌──────────┐ ┌──────────────┐
│ VALIDATE │────▶│ Is it novel? │
│ THE IDEA │ │ Is it useful?│
└────┬─────┘ └──────┬───────┘
│ │
│ NO ──┘── YES
│ │ │
│ ▼ ▼
│ ┌────────┐ ┌──────────┐
│ │ REFINE │ │ RUN │
│ │ or │ │ INITIAL │
│ │ PIVOT │ │ EXPTS │
│ └────────┘ └────┬─────┘
│ │
│ ┌────┴────┐
│ │Results │
│ │good? │
│ └────┬────┘
│ NO │ YES
│ │ │ │
│ ▼ │ ▼
│ ┌────────┐│ ┌─────────────┐
│ │ DEBUG ││ │ FULL │
│ │ ITERATE││ │ EXPERIMENTS │
│ └────────┘│ └──────┬──────┘
│ │ │
│ │ ▼
│ │ ┌─────────────┐
│ │ │ WRITE │
│ │ │ THE PAPER │
│ │ │ (Method → │
│ │ │ Results → │
│ │ │ Intro → │
│ │ │ Abstract) │
│ │ └──────┬──────┘
│ │ │
│ │ ▼
│ │ ┌─────────────┐
│ │ │ INTERNAL │
│ │ │ REVIEW │
│ │ │ (co-authors)│
│ │ └──────┬──────┘
│ │ │
│ │ ▼
│ │ ┌─────────────┐
│ │ │ SUBMIT │
│ │ └──────┬──────┘
│ │ │
│ │ ▼
│ │ ┌─────────────┐
│ │ │ Accepted? │
│ │ └──┬───┬──┬───┘
│ │ │ │ │
│ Reject │ Major│ Accept
│ │ │Minor │ │
│ ▼ │ │ │ ▼
│ ┌────────┐│ │ │ ┌──────────┐
│ │REVISE &││ │ │ │PUBLISHED!│
│ │RESUBMIT││ │ │ │ 🎉 │
│ │or try │▼ ▼ │ └──────────┘
│ │another │REVISE │
│ │venue │& RESUB │
│ └────────┘────────┘
┌─────────────────────────────┐
│ START: Define your topic │
│ and 5-10 key search terms │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Search Google Scholar + │
│ Semantic Scholar │
│ Sort by: relevance + date │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Read abstracts of top 30 │
│ Select 10-15 most relevant │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Deep-read the 10-15 papers │
│ Note: methods, results, │
│ limitations, future work │
└──────────────┬──────────────┘
│
┌─────────┴─────────┐
▼ ▼
┌──────────┐ ┌───────────┐
│ Backward │ │ Forward │
│ snowball │ │ snowball │
│ (refs of │ │ (who cited│
│ these │ │ these │
│ papers) │ │ papers?) │
└─────┬────┘ └─────┬─────┘
│ │
└────────┬────────┘
│
▼
┌─────────────────────────────┐
│ Use Connected Papers for │
│ visual mapping │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Organize into themes: │
│ • Theme A (e.g., methods) │
│ • Theme B (e.g., domains) │
│ • Theme C (e.g., theory) │
│ Identify THE GAP │
└─────────────────────────────┘
┌──────────────────────────────────┐
│ Is the journal indexed in │
│ SCI / SCIE / Scopus? │
└───────────────┬──────────────────┘
┌───┴───┐
YES NO
│ │
│ ▼
│ ┌──────────────────┐
│ │ Is it a NEW but │
│ │ reputable venue? │
│ └────┬─────────────┘
│ ┌──┴──┐
│ YES NO → SKIP IT
│ │
▼ ▼
┌──────────────────────────────────┐
│ Is the scope relevant to │
│ your paper topic? │
└───────────────┬──────────────────┘
┌───┴───┐
YES NO → FIND ANOTHER JOURNAL
│
▼
┌──────────────────────────────────┐
│ Check for predatory signals: │
│ • Unsolicited email invitation? │
│ • Unrealistic review time? │
│ • No clear editorial board? │
│ • Excessive APCs? │
└───────────────┬──────────────────┘
┌───┴───┐
CLEAN RED FLAGS → DO NOT SUBMIT
│
▼
┌──────────────────────────────────┐
│ Is the impact factor / CiteScore│
│ reasonable for your career stage?│
└───────────────┬──────────────────┘
┌───┴───┐
YES NO (too high?)
│ │
│ ▼
│ ┌──────────────┐
│ │ Submit anyway │
│ │ if the work │
│ │ is strong. │
│ │ Aim high! │
│ └──────────────┘
▼
┌──────────────────────────────────┐
│ What's the typical review time? │
│ Can you wait that long? │
└───────────────┬──────────────────┘
┌───┴───┐
YES NO → Consider a faster venue
│
▼
┌────────────┐
│ SUBMIT! │
└────────────┘
┌──────────────────────────────┐
│ Read reviewer comment │
│ (after 24h cooling period) │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Is the comment │
│ technically valid? │
└──────────────┬───────────────┘
┌──────┴──────┐
YES NO
│ │
▼ ▼
┌──────────────┐ ┌──────────────────┐
│ Is it easy │ │ Is it a │
│ to address? │ │ misunderstanding? │
└───────┬──────┘ └────────┬─────────┘
┌───┴───┐ ┌───┴───┐
YES NO YES NO
│ │ │ │
▼ ▼ ▼ ▼
┌──────┐┌──────┐┌───────┐┌────────────┐
│Fix it││Add ││Clarify││Politely │
│thank ││expts/││your ││disagree │
│them ││analysis│text ││with │
│ ││explain │ ││evidence │
└──────┘│scope ││ │└────────────┘
└──────┘└───────┘
| Tool | Free? | Best for | My take |
|---|---|---|---|
| Zotero | Yes | Most researchers | My top pick. Open-source, browser extension is excellent, syncs across devices. |
| Mendeley | Yes | Elsevier users | Good PDF reader, but Elsevier ownership raises concerns. |
| EndNote | No ($) | Institutional users | Powerful but expensive. Use if your university provides it. |
| Paperpile | No ($) | Google Docs users | Best Google Docs integration. Worth it if you write in Docs. |
| JabRef | Yes | LaTeX purists | BibTeX native. Perfect if you live in LaTeX. |
My recommendation: Start with Zotero + Better BibTeX plugin + Zotero Connector browser extension. It's free, open-source, and handles 95% of what you need.
| Tool | Type | Best for |
|---|---|---|
| Overleaf | Online | Collaboration, beginners, no-setup |
| TeXstudio | Desktop | Power users who want speed |
| VS Code + LaTeX Workshop | Desktop | Developers who already use VS Code |
| Vim + VimTeX | Terminal | The truly dedicated |
| LyX | Desktop | People who want WYSIWYG-ish LaTeX |
| Tool | URL | What it does |
|---|---|---|
| Google Scholar | scholar.google.com | The default. Broad coverage, citation tracking. |
| Semantic Scholar | semanticscholar.org | AI-powered relevance ranking. Better discovery. |
| Connected Papers | connectedpapers.com | Visual graph of related papers. Beautiful and useful. |
| arXiv | arxiv.org | Preprint server. Latest research before peer review. |
| DBLP | dblp.org | Computer science bibliography. Clean and comprehensive. |
| IEEE Xplore | ieeexplore.ieee.org | IEEE publications database. |
| Springer Link | link.springer.com | Springer publications database. |
| ResearchGate | researchgate.net | Social network for researchers. Request full texts. |
| Sci-Hub | — | You didn't hear this from me. |
| Tool | Free? | Best for |
|---|---|---|
| Grammarly | Freemium | General grammar and style checking |
| Writefull | Freemium | Academic writing specifically (trained on papers) |
| LanguageTool | Yes | Open-source Grammarly alternative |
| Hemingway Editor | Free (web) | Making complex writing more readable |
| ProWritingAid | Freemium | Deep style analysis |
| Tool | Type | Best for |
|---|---|---|
| matplotlib | Python | Publication-quality 2D plots |
| seaborn | Python | Statistical visualizations |
| Manim | Python | Mathematical animations (for talks) |
| draw.io / diagrams.net | Web | Flowcharts, architecture diagrams |
| TikZ/PGFplots | LaTeX | Plots directly in LaTeX documents |
| Plotly | Python/JS | Interactive visualizations |
| Excalidraw | Web | Hand-drawn style diagrams |
| Tool | Best for |
|---|---|
| Overleaf | Real-time LaTeX collaboration |
| GitHub | Code, data, version control |
| Notion | Lab notebooks, project management |
| Slack | Lab communication |
| Zotero Groups | Shared reference libraries |
AI tools can genuinely accelerate research when used responsibly:
| Tool | Use for | DON'T use for |
|---|---|---|
| Elicit | Finding relevant papers, extracting claims | Replacing your literature review |
| Semantic Scholar TLDR | Quick paper summaries | Understanding papers (still read them) |
| ChatGPT / Claude | Brainstorming, debugging code, explaining concepts | Writing your paper for you |
| GitHub Copilot | Coding experiments faster | Code you don't understand |
| Consensus | Finding scientific consensus on topics | Replacing critical analysis |
Ethics note: Always disclose AI tool usage per your journal/conference policy. Never pass AI-generated text as your own writing. Use AI to assist your thinking, not replace it. Your ideas, analysis, and scholarly judgment are what make your work valuable.
These are books I've actually read and found genuinely useful, not just a list scraped from Amazon.
| Book | Author | My one-line review |
|---|---|---|
| How to Write a Good Scientific Paper | Chris Mack | The best concise guide. Read this first. |
| Writing Science | Joshua Schimel | Teaches you to write papers as stories. Changed how I structure papers. |
| The Craft of Research | Booth, Colomb, Williams | The definitive guide to formulating research questions. |
| The Elements of Style | Strunk & White | Tiny book, enormous impact. Makes your writing tighter. |
| English for Writing Research Papers | Adrian Wallwork | Essential if English isn't your first language. |
| Book | Author | My one-line review |
|---|---|---|
| The PhD Grind | Philip Guo | Honest memoir of a CS PhD. You'll feel seen. Free online. |
| A PhD Is Not Enough! | Peter Feibelman | Career advice for after the PhD. Read in your final year. |
| The Professor Is In | Karen Kelsky | Brutally honest about the academic job market. |
| How to Be a Modern Scientist | Jeff Leek | Short, practical guide to the modern research toolkit. Free online. |
| Book | Author | My one-line review |
|---|---|---|
| How to Solve It | George Polya | Classic problem-solving heuristics. Applicable to any field. |
| Thinking, Fast and Slow | Daniel Kahneman | Understand your own cognitive biases as a researcher. |
| The Art of Statistics | David Spiegelhalter | Makes statistics intuitive. Great for non-statisticians. |
| Deep Work | Cal Newport | How to focus in a world full of distractions. Life-changing. |
| Metric | What it measures | What's "good" |
|---|---|---|
| Impact Factor (IF) | Average citations per paper in past 2 years | Field-dependent. IF > 2 is decent in most CS fields. |
| CiteScore | Similar to IF but based on Scopus, 4-year window | Usually higher than IF for the same journal. |
| h-index | Balance of quantity and impact of journal | Higher is better, but compare within field. |
| Acceptance Rate | % of submissions accepted | Top conferences: 15-25%. Top journals: 10-30%. |
| Review Time | Weeks from submission to first decision | 4-12 weeks is typical. 20+ weeks is painful. |
┌─────────────────────────────────────────────────────┐
│ WEB OF SCIENCE │
│ ┌─────────────────────────────────────────────┐ │
│ │ SCI (Science Citation Index) │ │
│ │ • The "original" prestigious index │ │
│ │ • ~3,700 journals │ │
│ │ • Highest prestige │ │
│ └─────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────────┐ │
│ │ SCIE (SCI Expanded) │ │
│ │ • Broader coverage │ │
│ │ • ~9,200 journals │ │
│ │ • Same database, more inclusive │ │
│ │ • Most institutions treat SCIE = SCI │ │
│ └─────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ SCOPUS │
│ • Run by Elsevier (separate from WoS) │
│ • ~27,000 journals (broadest coverage) │
│ • Many journals are in both Scopus AND SCI/SCIE │
│ • Some institutions value Scopus equally │
└─────────────────────────────────────────────────────┘
Practical advice: For most academic purposes (hiring, promotion, PhD requirements), SCI/SCIE and Scopus-indexed publications all count. Check your specific institution's requirements. Don't get caught up in the SCI vs. SCIE distinction — most places treat them the same.
STOP if you see any of these:
- Unsolicited email inviting you to submit (especially if flattering)
- Unrealistically fast review times ("guaranteed 7-day review!")
- No clear editorial board, or board members who don't know they're listed
- Journal scope is absurdly broad ("Journal of Everything and Also Some Other Things")
- Excessive or hidden Article Processing Charges (APCs)
- No retraction policy
- Journal name is suspiciously similar to a reputable journal
- Website has poor grammar and broken links
- Not indexed in any major database (Scopus, WoS, DOAJ)
- Fake impact factor from non-standard metrics
How to verify a journal:
- Check if it's listed in Scopus (scopus.com/sources) or Web of Science (mjl.clarivate.com)
- Search it on DOAJ (doaj.org) for verified open-access journals
- Check Beall's List (beallslist.net) for known predatory publishers
- Ask your advisor or senior colleagues
| Aspect | Open Access | Traditional (Subscription) |
|---|---|---|
| Reader access | Free for everyone | Behind paywalls |
| Author cost | APC ($500-$5,000+) | Usually free to publish |
| Visibility | Higher downloads, potentially more citations | Access limited to subscribers |
| Speed | Often faster | Can be slower |
| Prestige | Growing rapidly | Still dominant in many fields |
| Funding | Many grants cover APCs | No publication cost |
My take: If your funding covers APCs, open access is a no-brainer for visibility. If not, don't feel pressured. A good paper in a subscription journal is better than a weaker paper in an open-access one. You can always self-archive preprints on arXiv.
I won't pretend I had a strategic master plan from day one. My early papers went wherever my advisor suggested. Over time, I developed my own sense of which venues fit my work. Here's what I learned:
- First papers: Targeted mid-tier conferences to build confidence and get feedback. No shame in this.
- Growing confidence: Aimed for better conferences and SCIE journals. Got rejected more, but the feedback improved my work.
- TDA work: Found a niche community where my work was appreciated. Venue fit matters enormously.
- Best Paper Award: Came from submitting to a conference whose scope perfectly matched my contribution (ICIVC-2021).
The lesson: Don't just chase impact factors. Find venues where your work fits and where the reviewers will understand and appreciate your contribution.
The PhD is not just a research degree. It's a life experience that will test your resilience, relationships, and sense of self. Here's what I wish someone had told me.
Your advisor is the single most important professional relationship during your PhD.
Tips that actually help:
- Communicate proactively. Don't wait for your advisor to check in. Send weekly updates, even if they're short.
- Manage up. Your advisor is busy. Prepare meeting agendas. Come with specific questions, not vague "I'm stuck."
- Understand their incentives. Advisors need papers, grants, and student success. Align your goals with theirs when possible.
- Document everything. Decisions, deadlines, agreed milestones. "As discussed in our meeting, I will..." emails are your friend.
- Disagree respectfully. You're allowed to push back on your advisor's suggestions. Frame it as "I see your point, but I've been thinking about X because..."
- Be visible. Attend lab meetings, present your work, engage with their research group.
When the relationship is difficult:
- If you're not getting enough feedback, ask specifically for what you need.
- If expectations are unclear, request a written document of milestones.
- If the relationship is truly toxic, talk to your department's graduate coordinator. You have options, even if it doesn't feel like it.
Let me tell you something: everyone feels like a fraud sometimes. If you've never felt imposter syndrome, you're either lying or not challenging yourself enough.
╔══════════════════════════════════════════════════╗
║ IMPOSTER SYNDROME REALITY CHECK ║
║ ║
║ What you think: "I don't belong here. Everyone ║
║ else is smarter. They'll figure out I'm a ║
║ fraud any day now." ║
║ ║
║ The reality: You passed admissions. You've ║
║ produced results. Your advisor chose to work ║
║ with you. The "smart" people around you also ║
║ feel like frauds. EVERYONE IS FAKING IT to ║
║ some degree. ║
║ ║
║ What helps: ║
║ • Keep a "wins" document. Every small victory. ║
║ • Talk to peers honestly. You'll find you're ║
║ not alone. ║
║ • Compare yourself to past-you, not to others. ║
║ • Remember: PhDs are DESIGNED to make you feel ║
║ inadequate. That confusion is the process, ║
║ not a sign of failure. ║
╚══════════════════════════════════════════════════╝
I'm not going to tell you to "just set boundaries" and "leave work at 5pm." That advice, while well-intentioned, ignores the reality of academia.
The honest truth:
- There WILL be crunch periods (deadlines, submission weeks) where you work 12+ hours.
- There SHOULD be recovery periods after crunch where you rest and do non-work things.
- The danger isn't occasional overwork. It's perpetual overwork with no recovery.
Practical strategies:
| Strategy | How I implement it |
|---|---|
| Protected time off | One full day per week with NO research. Non-negotiable. |
| Exercise | 30 min of movement daily. Gym, walk, whatever. This is not optional. |
| Social connections outside academia | Friends who don't care about your h-index keep you grounded. |
| Hobbies | Having something you're good at that isn't research is vital for mental health. |
| Sleep | 7-8 hours. Sleep-deprived researchers produce bad science. |
| Saying no | "No" is a complete sentence. You can't do everything. |
Personal reflection: The hardest lesson I learned was that productivity and hours are not the same thing. I've written entire paper sections in 2 focused hours that would have taken 8 distracted hours. Protect your energy, not just your time.
Networking in academia isn't about collecting business cards. It's about building genuine relationships with people who share your intellectual interests.
Actionable networking strategies:
- Attend conferences. Not just the talks — the social events, coffee breaks, and poster sessions.
- Present posters. They're the best networking tool because people come to you and you have 1-on-1 conversations.
- Ask good questions at talks. "I really liked your work on X. I'm doing something related with Y. Could we chat later?" This works.
- Twitter/X academic community. Share your papers, engage with others' work, comment thoughtfully. Many collaborations start here.
- Email researchers you admire. "Dear Prof. X, I read your paper on Y with great interest. I'm working on Z and I see a potential connection..." Keep it short, specific, and genuine.
- Collaborate. Co-authoring a paper is the strongest academic bond you can form.
- Be helpful. Share code, answer questions, give honest feedback on others' manuscripts. Generosity compounds.
BEFORE THE CONFERENCE
• Research the speaker list. Identify 3-5 people you want to meet.
• Prepare a 30-second "elevator pitch" of your research.
• Bring business cards or have a clean personal website ready.
DURING THE CONFERENCE
• Sit in the front rows (speakers notice you).
• Ask at least one question per session you attend.
• Approach people during coffee breaks, not during talks.
• "What are you working on?" is the best conversation starter.
• Eat meals with different groups each time. Don't just stick with
your lab.
AFTER THE CONFERENCE
• Follow up within 1 week. "It was great meeting you at X. I enjoyed
our conversation about Y."
• Connect on LinkedIn / academic social media.
• Share their interesting work on your social channels.
• Follow through on any commitments you made.
A personal reflection.
There were moments during my PhD when I wanted to quit. Real, serious, "I'm going to open LinkedIn and apply for industry jobs right now" moments. There was a month where nothing worked — experiments failed, writing was terrible, I felt completely stuck.
What kept me going was honestly quite simple:
Remembering why I started. I genuinely love understanding how things work. That curiosity didn't disappear; it was just buried under stress.
Taking it one day at a time. "Finish the PhD" is overwhelming. "Run one more experiment today" is manageable.
Talking to other PhD students. Discovering that EVERYONE struggles, not just me. The people who look like they have it together? They're struggling too. They're just not showing it.
Celebrating small wins. Got a clean compile of LaTeX? Win. Got one experiment to produce sensible results? Win. Wrote 300 words? Win.
Accepting that confusion is normal. A PhD is fundamentally about doing something nobody has done before. Of course you'll be confused. If you weren't, the problem wouldn't be novel.
The PhD will change you. You'll learn not just about your research topic, but about yourself — your limits, your resilience, your capacity to grow. It's hard. It's supposed to be hard. And it's worth it.
This survival kit is a living document, and it gets better with every contribution. If you've survived (or are surviving) a PhD, you have wisdom to share.
- Fork this repository
- Create a new branch (
git checkout -b add-my-tip) - Add your contribution
- Submit a Pull Request
| Contribution type | Description |
|---|---|
| Personal stories | Your honest experiences, failures, and lessons learned |
| Templates | LaTeX templates, email templates, cover letter templates |
| Tool recommendations | Tools that helped you, with honest reviews |
| Checklists | Any checklist that would help other researchers |
| Field-specific tips | Advice specific to your research domain |
| Translations | Help us make this accessible in other languages |
| Corrections | Found a mistake? Fix it! |
- Keep it honest and practical. We value real experience over polished advice.
- Be respectful. Different fields have different norms. What works in CS may not work in biology.
- Cite sources when making factual claims.
- Use inclusive language. This resource is for everyone.
- No self-promotion or spam. Share tools and resources you genuinely find useful.
A huge thank you to everyone who has contributed to this project. You're making the PhD journey easier for the next generation.
Want to be listed here? Submit a PR!
If you find this resource useful in your research or teaching, you can cite it:
@misc{joshi2024phdsurvivalkit,
author = {Joshi, Milan Amrut},
title = {{PhD Survival Kit}: Everything Nobody Tells You About
Surviving (and Thriving in) a PhD},
year = {2024},
publisher = {GitHub},
howpublished = {\url{https://github.com/mlnjsh/phd-survival-kit}},
note = {Open-source academic survival guide with templates,
checklists, and practical advice}
}This project is licensed under the MIT License — see the LICENSE file for details.
In simple terms: use it, share it, modify it, teach with it. Just give credit where it's due.
┌────────────────────────────────────────────────────────────┐
│ │
│ You don't need to be the smartest person in the room. │
│ You just need to be the most persistent. │
│ │
│ Keep going. Your future self will thank you. │
│ │
└────────────────────────────────────────────────────────────┘
Built with hard-won experience by Prof. Milan Amrut Joshi
mlnjsh@gmail.com · GitHub · Google Scholar
If this helped you, consider giving it a ⭐ — it helps others find it too.
15+ publications · SCI/SCIE/Scopus indexed · Best Paper Award @ ICIVC-2021
Last updated: February 2026
 Milan Amrut Joshi Project Author |
 Manubot Scholarly manuscript automation |
 Joshua Kunst Data viz & academic writing |