What’s New ?

The Top 10 favtutor Features You Might Have Overlooked

Read More
Computer Science

Things I Wish I Knew Before Writing My First CS Thesis

Aug 19, 2026 7 Minutes Read Why Trust Us Why you can trust this guide. Written by working engineers and reviewed by our editorial team under a strict editorial policy for accuracy, clarity and zero bias. Kaustubh Saini By Kaustubh Saini Kaustubh Saini Kaustubh Saini
I'm Kaustubh Saini, founder of FavTutor. I have a genuine passion for coding and data science. In my articles, I aim to break down complex topics, share coding insights, and make learning more accessible. When I'm not writing, I'm always exploring ways to enhance your learning experience at FavTutor.
Connect on LinkedIn →
Things I Wish I Knew Before Writing My First CS Thesis

My cursor blinked at me for almost an hour before I typed the first word. Sounds dramatic, but it's true. Coding trains you to expect instant feedback - a red squiggly line, a failed test, something telling you exactly what's wrong. A thesis gives you nothing like that. Just a blank page and whatever you decide to put on it. If that's where you're at right now, you're not behind. You're right on schedule. Here's the stuff I wish someone had mentioned to me before I started mine.

Picking a Topic That Actually Excites You

This one decision quietly shapes the next several months, so it's worth slowing down for. Chase something you're actually curious about. Not the topic that sounds most polished in a committee meeting.

Give yourself a proper stretch of time - a week, maybe longer - just reading around before you commit to anything. Email your advisor early, too. Ask what's been bothering them lately, what keeps coming up as unresolved in their reading list. If a topic has you Googling follow-up questions at midnight out of genuine interest, that's usually a better sign than one picked because it looks good on paper. Curiosity holds up. Obligation doesn't, not for six months straight.

Getting a Fresh Set of Eyes on Your Early Draft

The earlier you get outside eyes on your work, the better, because you're too close to your own writing to see what's actually missing. A logic gap that's obvious to anyone else can hide from you for weeks. So a lot of students end up building some kind of check-in step before pushing much further with the writing itself.

For some that means a classmate who already knows the subject. For others, it's a moment where they just think, "I need someone to write my essay when I'm stuck," and they bring in outside help to look at the structure with fresh eyes. What actually matters in that exchange is reliable accuracy - someone genuinely wrestling with your argument, not just fixing commas. A weak transition caught now is a lot less painful than one discovered three chapters deep.

Once the core argument feels steadier, the real work shifts toward staying consistent over the long haul.

Building a Research Routine That Sticks

Nobody writes a thesis in one dramatic weekend, no matter what movie montages suggest. What actually gets it done is boring, repeated effort - showing up most days, even when you don't feel like it. That beats the occasional heroic all-nighter almost every time.

Break the Thesis Into Small Milestones

"Write a thesis" is too large a thought to hold onto for long. Split it up instead: literature review, methodology, results, discussion. Give each piece its own rough due date, even if you'll probably miss a couple. Checking off smaller pieces keeps the whole thing from feeling like an unclimbable hill.

A loose timeline can help too, just so the shape of the project isn't a total mystery:

Phase Typical Duration Main Goal
Topic selection & proposal 2-3 weeks Land on a question worth answering
Literature review 3-4 weeks Map what's already known
Methodology & experiments 6-8 weeks Build and test your approach
Writing the first draft 4-6 weeks Get every section down on paper
Revisions & feedback 2-3 weeks Sharpen arguments and fix gaps
Defense preparation 1-2 weeks Practice explaining your work clearly

Your program will run on its own clock, obviously. But having even a rough map beats walking in blind.

Keep a Running Log of Your Sources

Few things eat an evening faster than hunting for a citation you were sure you'd remember. Start a spreadsheet, or pick a reference manager, on day one - not two months in, once you've already lost track of half your reading. Future you will owe present you a favor.

A few habits genuinely paid off for me:

  • Document code the same day you write it, not weeks later when the logic's gone fuzzy.

  • Save experiment results with timestamps and a short note on what changed.

  • Keep backups in at least two places, even when it feels like overkill.

  • Hold a fixed writing block each day. Thirty minutes counts.

  • Read one finished thesis in your subfield, just to see what real structure looks like up close.

None of this is revolutionary. It's still the difference between a project that comes together and one that turns into a frantic scramble the week it's due.

Writing the First Draft Without Overthinking It

Your first draft doesn't need to be good. It just needs to exist somewhere other than your head. Chasing polish this early mostly just stalls you out, especially in technical writing, where every sentence can start to feel like it needs to be flawless before you move on.

Start with methodology and results - usually the easiest, since you actually lived through what happened there. The introduction tends to fall into place once you know exactly what you're introducing, which is a strange but reliable pattern. Save the literature review for days when reading sounds more appealing than writing, and let the sections trade off depending on your energy.

Ugly sentences are completely fine in a first pass. A messy paragraph is always easier to fix than an empty page is to fill. Grammar can wait its turn. Getting ideas down is what actually pushes the project forward, even when the writing itself is rough.

Presenting Your Work With Confidence

By the time your defense rolls around, you know this project better than anyone else in that room, full stop. Worth remembering when the nerves inevitably show up beforehand.

Try explaining your work out loud to someone completely outside your field - a roommate works fine, so does a parent. If they can follow your core contribution in under two minutes, you've actually understood it, not just memorized the talking points. Prepare for the obvious questions too: why this topic, why this method, what you'd change with hindsight. Committees tend to respect an honest "I'd probably approach that differently now" far more than a defensive answer that dodges the question.

Your thesis is evidence of months of real problem-solving. Code that broke for no obvious reason at 2am. Hypotheses that fell apart and got rebuilt from scratch. You kept showing up through all of it, which counts for a lot. That's worth being proud of, whatever number ends up on the final page.

Final Thoughts

Your first thesis teaches you more about research, writing, and yourself than any single class manages to. It's messy in the middle and strangely satisfying by the end, almost every single time. Trust the process, even on the days it feels completely shapeless. Lean on the people around you when things stall. And remember - every experienced researcher once sat exactly where you're sitting now, staring at their own blank page one.

Photo: Source

Kaustubh Saini
About the author

Kaustubh Saini

I'm Kaustubh Saini, founder of FavTutor. I have a genuine passion for coding and data science. In my articles, I aim to break down complex topics, share coding insights, and make learning more accessible. When I'm not writing, I'm always exploring ways to enhance your learning experience at FavTutor. Connect on LinkedIn →