PhD Comics: How Grad School Is Just Like Kindergarten.

Why?

Honestly, just because it sounds fun³! When I was in high school⁴, I really used to enjoy coding⁵ because it let me create things that people could interact with and say, “woah, that’s cool!” I began participating in entrepreneurship competitions and programs with my software projects and saw many of the processes that I would later encounter in research—problem identification, understanding existing solutions, formulating a hypothesis, prototyping, testing, iterating, and marketing the work. However, at some point, I began to feel that the projects I was working on were not intellectually fulfilling and their success⁶ was related to several factors other than their technical aspects. By the time I started my undergrad, I had decided to pursue research⁷, and my experiences during my undergrad only strengthened this decision. I touch upon a few of these experiences in the next section.

How?

I think the most important factor is experience, about which I have talked a bit in my advice to juniors. Working closely with helpful and encouraging mentors and colleagues has been invaluable in helping me learn about the research process, decide whether I want to do more of it, and prepare for grad school to actually do more of it. For instance, my internship at UIUC taught me about the open-ended nature of research, working with and within deadlines, and the process of writing and publishing research, among many other things. Very importantly, it gave me a sneak peek into the lives of graduate students, as they would juggle their different responsibilities, experiment and fail, present their progress to their advisors, and lead their own projects. At the end of it all, I thought it was kind of hard, but also kind of fun, and I could maybe do it too. I got the chance to lead a project of my own, from conceptualization to writing the paper, while working with collaborators from UVA. It was indeed challenging, but also satisfying to see the project through rebuttals and revisions, until it was finally accepted at ASE 2025. This was the first big conference I attended, and also the first time I presented my work to a large audience. Finally, my time at Microsoft helped me see the gap between theory and practice, and what software engineering means in the real world. I believe all of these elements have been pivotal in my journey to grad school, and I am grateful to all the mentors and colleagues who have supported me along the way.

Me having another cup of coffee at ASE, as if I didn't already have enough, while wearing a cap indicating my desperation to find a graduate position. The cap did attract a healthy amount of laughs during the five days I wore it at the conference.

The elephant in the room

I work in software engineering, and I can’t ignore the impact of AI on the problems that I have worked on and the kind of research I would like to do in the future. My stint at Microsoft overlapped with rapid improvements in AI-agents for coding, and I could observe in real time as the way we thought about problems and our problem-solving methodology changed. The question of what kind of research one can or should do is not for me to answer, but I do have two axes along which I measure any given problem. The first is impact, i.e., whether a problem has a noticeable effect on the world and whether there is demand for a solution. The second is fulfillment, i.e., whether the technical challenges involved in solving the problem are intellectually stimulating. Naturally, AI has the potential to solve a lot of problems with high impact, but solving the problem itself becomes less fulfilling as AI might do most of the heavy lifting. This is not to say that certain problems are trivial or uninteresting. I am also not advocating for throwing away AI. Problems that can be solved with AI should indeed be, though they might not be the most fulfilling problems to work on. The question that I have to ask myself is about what kind of problems I want to work on. Here is a little visualization of my dilemma.

Many other factors need to be considered too. For example, certain problems may currently be in the bottom-right quadrant, but they might move to the top-right as AI improves, possibly before I can finish my PhD! It may also be difficult to work on problems in the top-right quadrant because one may be competing with other labs with manifold the resources. And everything is so rapid and so uncertain that nobody really knows where things will go. I was deeply bothered by this uncertainty, fearing that either I would not enjoy what I do or that I would not be able to make any meaningful contribution. The latter is up to other people’s judgment, but I can at least try to ensure the former. It is a bit eerie that the following lyrics from Forest⁸ fit the situation so well.

I scream, you scream
We all scream, ‘cause we’re terrified
Of what’s around the corner
We stay in place
‘Cause we don’t wanna lose our lives
So let’s think of something better

And later on the point I am trying to make becomes even more explicit.

My brain has given up, white flags are hoisted
I took some food for thought, it might be poisoned
The stomach in my brain throws up onto the page
Does it bother anyone else that someone else has your name?

Indeed it is bothersome to imagine that someone else—or worse, something else, like Claude or GPT⁹—could take my name, i.e., “researcher” or “software engineer”. The only way to avoid this would be to take on a name that is more than that.

What all of this means for this blog

Well, nothing much. I will continue to write¹⁰ about my experiences, possibly with a bit more focus on technical topics and research. However, this blog will continue to be free style and candid as it has been.

1. Split my screen between my terminal and Netflix, then try watching both at the same time.

2. Keep the terminal open on my laptop in fullscreen while I play my ukulele.

3. SSH into the server from my phone² and take a look at the logs while having dinner.

4. Check on the experiment every 30 minutes or an hour (but only as often as I remember to).

It is easy to see that these methods are both inefficient and annoying. The problem is that I am not comfortable with using Discord³. I do, however, use Signal, so I came up with an easy way to use Signal to monitor my experiments instead. Here is how.

Set up

Install signal-cli on the machine where you want to trigger the notifications. You can download the precompiled binary and add it to your PATH if you do not have root access on the machine. You can then follow the instructions in the README to link signal-cli to your Signal account. Since I already had an account that I used from my phone, I used signal-cli link to link signal-cli to my account.

Usage

There are a lot of ways to use signal-cli to send messages. What I did was to create a new Signal group with only myself in it (aptly named “Alerts”), and send messages to that group. I needed the group ID to send messages to the group, which I got by running signal-cli listGroups. Because I created the group after linking signal-cli to my account, I had to run signal-cli sendSyncRequest to synchronize signal-cli with my account before I could see the new group in the list of groups. All I had to do now was to run the command below.

signal-cli -a <my_phone_number> send -m "<the message>" -g <group_id> --notify-self

Note that <my_phone_number> is the phone number of the account linked to signal-cli. The --notify-self flag is important, since it triggers a notification for you even though the message is sent by your own account. If you are using different accounts for triggering and receiving alerts, you may not need to use this flag. Instead of creating a separate group for alerts, you could send messages to the Note to Self chat by passing --note-to-self instead of -g <group_id>. As I said before, there are a lot of ways to do this.

Practice

I actually created small executable scripts to wrap some of the signal-cli commands. This makes it simpler for both my coding agents and me to trigger alerts. Once I have added these scripts to my PATH, I can use simple commands like sigalert "Experiment finished!" to trigger alerts from my experiment scripts. I also created a script to send messages to any other contacts by referring to their predefined aliases, like sigmsg alice "Hey, Mrigank's experiment has finished!"⁴. While using coding agents, I can add an instruction to send me messages about their progress in executing a long-running task. I can also automatically spawn a coding agent once an experiment has finished, and have it send me a summary of the results⁵.

I do not necessarily agree with everything said in these resources, and did not follow all of their advice. I did, however, find them immensely helpful in demystifying many aspects of the application process and providing insight into the inner workings of graduate admissions. Some of them are worth reading even if it is a long time before you send out applications. I thank Darko Marinov for sharing some of these with me.

• Writing a Research Statement by George Candea.

• How to Write a Grad School Personal Statement by Mike Hicks.

• HOWTO: Get into grad school for science, engineering, math and computer science by Matt Might.

• Advice on Contacting Faculty for Prospective Research Students by David Evans.

• Getting into CS graduate school in the USA by Mark Corner.

• Getting a Computer Science PhD in the USA by Shriram Krishnamurthi.

• Applying to grad school by Michael Ernst.

• Advice for Foreign Students Wishing to Pursue Graduate Study in Computer Science at UCSC by Jim Whitehead.

• Prospective Students by Michael Franz.

I might add to this list as I rediscover more resources I found useful.

But one can complete only what they started. I do not precisely remember what I wanted to do when I joined IISc—but I do remember that it was a romantic idea, something to do with learning a lot, something to do with research, something to do with working on big ideas. It was a difficult romance to maintain, particularly around deadlines and exams when we would all question our teenage decision to join this institute instead of taking on mushroom farming¹. By the time we were only a few months away from the end, many of us had lost track of our once-so-captivating relationships with our romantic ideas, and all we could wish for was to finish our degrees and move on. IISc seemed to have become a chore, a matter of staying afloat as we kept up with a few letters and numbers, a matter of dragging our feet through the constant whining and griping of ourselves and our peers. It would have been easy to move on from buildings and numbers and our many gripes, but how could I so easily move on from that romance—especially when it barely seems fulfilled! Did I learn enough, become a researcher, or work on anything big? And what about all the other things that I didn’t even know I wanted until I was here?

During my final, fleeting glance at IISc, I realized that this romance had not come to an end. While I embraced the realization that I would never again feel so much like a student taken care of by this collegetown in the middle of a metropolis, I understood that my time at IISc had taught me what this romance was truly all about. This post is going to be about that.

Asking questions

We all know that we are not taught to ask questions in school. It might even be the case that sometimes we are taught not to ask questions. I knew from all over the internet that asking questions is important. People on the internet called it critical thinking, and I thought it was pretty simple. Of course my thinking is critical! I even asked a few questions in school, and probably more questions than most of my peers. But IISc changed my understanding of what it means to ask questions.

Here I had the chance to be friends with people who could question essentially anything. I would almost wait for them to ask a question in class, because every time they did, I would either find that there was something I did not think I should know, or that there was something I thought I knew but actually did not. Not only could these people ask questions, they could pare down other people’s questions, they could make questions more general or more specific, they could branch questions out or merge them together, and they could even rephrase questions so that they answered themselves! My time at IISc has convinced me that asking questions is a way of life—it transcends the classroom and is a way to both understand and experience the world at large.

Answering questions

Asking questions is only one side of the battle. And when the questions are hard, there might be no easy answers—not easy even for the professors! People usually get nervous when they don’t immediately know how to answer a question. Sometimes they even get irritated and brush it off altogether. Or worse, they answer incorrectly. However, whenever posed with a question, professors in IISc have consistently proven that they are genuinely curious and are interested in the students’ and their own understanding of the topic. Professors listen to questions intently, confirm whether they understand the question, and then think carefully before answering. Some professors even take what others might consider an awkwardly long moment of silence, deep in their thoughts, before speaking again. And they don’t just answer but also walk their audience through the process to get to that answer. Most importantly, they do not hesitate to admit when they do not know. It does not matter how senior or accomplished they may be—if they cannot answer confidently, they will not answer.

I often heard the phrase stupid question in school, and I admit that some questions indeed sound stupid to me. When someone asks such a question in class, I do not even know where I would begin to answer it or what specifically I would say to clear their confusion. Often I wouldn’t be able to even understand what their confusion must have been. But while I am thinking of all this, the professor comes up with an answer that clears the confusion—it is almost a magical experience to see this happen. It turns out that answering questions is less of a matter of knowledge and more of a matter of curiosity, patience, and humility.

Being disliked

People usually don’t like to be disliked. Most people hate it more than they hate to disagree with others. I therefore find myself looking with awe at the few people who are not afraid to be disliked if that means they can be honest and be their true selves. And I believe I have been quite fortunate to have been close friends with a few of these people at IISc. It has been with these people that I have had some of the most meaningful and unpretentious conversations of my life. And though I am frankly envious of their honesty and courage, I have come to learn a bit from them—to speak my mind, to stand against the wrong, to appreciate the right, to be disliked if necessary.

Working hard

Everyone works hard at IISc. In some way, there is no other way to keep up with everything inside and outside the classroom. While it’s almost as if most of us are made to work hard by the system, I have friends at IISc who, driven by nothing but passion, can work for worryingly long hours without for once thinking of anything besides what they are doing. For instance, one friend of mine can absolutely not accept that he is unable to understand a concept or solve a problem, and if faced with such a situation, he will scour through every book, paper, or lecture that he can find on the internet, not resting until he can come out of his room and explain the concept confidently to anyone who will listen². I have friends who have, with sheer tenacity, mastered a skill that they had no prior experience with, succeeded in a discipline different altogether from their own, or bounced back from repeated failures. What do you do when you are surrounded by such dedicated people? More often than not, you are inspired to work hard too.

Not working too hard

Sometimes you want to, and sometimes you need to, leave your desk and go for a walk, take a coffee break, do a bit of sport, play some foosball, or watch a movie. It is unlikely that you will always be able to pull yourself to do any of these, but friends can make it much easier. You just need someone to remind you that if you don’t slow down, you crazy child, you’re gonna kick off before you even get halfway through, and if you happen to insist too much, someone to assure you that it’s all right, you can afford to lose a day or two³. And before you realize it, you too become that friend for someone else. It sounds funny when I insist to freshmen that they must learn to relax, but everyone who has been through IISc can testify to it⁴.

Close to every other student in my class has an exciting story to tell about how they made it to IISc, sometimes arguing with their parents, fighting their circumstances, or defying extraordinary odds. And all of that for their romantic idea of pursuing science, pushing its frontiers with their own hands, and becoming great scientists. What did IISc do to these romantic ideas? At least for me, it enriched the romance with a deeper understanding of what I really want—not just to be a scientist, but to be a person who can ask questions, create a path toward answers, fearlessly speak their mind, work hard, and yet not work too hard to forget the point of it all. I have graduated, completing possibly just my credit requirements, but hopefully starting the next chapter of my romance with a lot more insight.

Photograph from the convocation while receiving the Prof. M N Murthy Medal.

This blog follows the ChatGPT-interview format that I first used last year². Like I did then, I have only lightly edited ChatGPT’s responses and have left my own nearly verbatim.

Host (ChatGPT): Every year, especially before summer, many undergraduate students find themselves asking some version of the same question, “What should I do this summer?” The question may be about internships, professors to work with, research topics to explore, whether to apply to programs abroad, or even whether one should be thinking about academia or industry at all. But beneath these concrete decisions often lies a deeper uncertainty about how one ought to think about opportunities in the first place. In this conversation, Mrigank argues for thinking in terms of experiences, mentorship, transferable skills, and alignment with longer-term goals—and for being deliberate, even a little selfish, in choosing where to spend one’s limited time and energy.

Host: Mrigank, when juniors come to you unsure about which internships, research opportunities, or topics they should focus on, how do you help them start figuring out what direction to take?

Mrigank: I always begin by asking what they want from their bachelor’s degree, that is, their final goal. Broadly, most people fall into two categories: those who want to do research, which often means pursuing a PhD, and those who want to leave academia and join the industry. Of course, this is only a broad split, and most students are either torn between these two paths or have already chosen one over the other.

For students who want to end up in industry after their undergrad, I admit that I don’t really have any expertise to offer, because I did not participate in the campus recruitment process at my university. What I know from friends is that you need to practice solving LeetCode problems, prepare for interview questions, and maybe build some small projects to put on your CV. If you worked on some research project, it might be a bonus. Some of the things I say about opportunities and experiences might be relevant to such students, but I am not sure how much.

For the students leaning towards research, I have a little more to say.

Host: Since the path one ultimately wants to take can shape what kinds of opportunities one should look for, what would you say to someone who does not yet know whether they want to pursue research or jobs?

Mrigank: This is a common situation, particularly in universities like mine, where both paths have been well-trodden. I was almost certain that I wanted to do research, so this was not a dilemma for me. But I think sampling both directions is a good idea, especially in the freshman and sophomore years. One can try out a research project with a professor, even if it’s not in an area they are passionate about, in order to get a sense of what research is like. As I mentioned before, it will be a worthwhile experience to have on your CV even if you later decide to go into industry. If you don’t like it a lot, you can then try an industry internship the following summer.

Alternatively, if you have a long-term vision for yourself, you can think which path is more likely to lead you there. For example, some of my juniors have told me that they want to work at DeepMind³. For these students, I pointed out that most of the people doing most of the cool stuff over there have PhDs, so pursuing a PhD would be a statistically better choice. Actually let me point out a common misconception here. Many undergrads think that a PhD is for people who want to be professors, but this is simply impossible⁴ because manyfold more people graduate with PhDs every year than the number of faculty positions available!

At some time during one’s undergrad, it is important to get clarity on which path one wants to pursue. While one should indeed be open to exploring, the reality is that undergrads have limited time and resources, which have to be utilized with some planning before stepping into the next phase of their careers. Since applications for both graduate school and jobs start roughly a year before their start date, it helps to have a clear direction by the middle of the junior year⁵ as the two tracks demand different kinds of preparation.

Host: Students leaning toward research often worry about finding the right topic to work on. Do you think that is the right thing to be worrying about?

Mrigank: The right topic is the one you like! I know that insight does not help much because there are so many topics out there, and it is hard to know which one you will like until you try it. Sometimes you may end up liking multiple topics too! But ultimately you should hope to narrow down to one so that you can build depth and contribute something meaningful to it. I think with the limited time that undergrads have, sticking to one topic is a good idea.

But what topic? If you don’t know, I will suggest that you should not worry about it too much. My advice is to think in terms of experiences rather than topics when it comes to finding or choosing opportunities. The key here is to gain the transferable skills that will be useful in a future research career. These include studying a problem by reading papers, thinking critically about existing work, formulating your own questions, designing and running experiments, building software systems, writing papers, and so on. Undergrads are a blank slate and can enjoy anything they put their mind and heart into, so the exact topic is not as important as the kind of experience you get from working on it. Surely, it is helpful to have preferences which you might build from taking classes or working on projects. For example, I ruled out transit network design after a short internship I did in my first summer. Similarly, I had a liking for applied areas and did not want to work on theory. If you have some preferences, you can restrict your search to those areas.

It is a little unsettling for many students, and understandably so, to have to decide on a topic so early in their careers and also so quickly. But the reality is that you are not really locking in! For example, as far as I have seen, it is typical for people to begin their PhD with a topic different from what they worked on in their undergrad. In fact, it is not even uncommon for PhD students to switch topics during their PhD. Professors pick up new research areas all the time as well. So there is plenty of time to explore in the future.

The bottom line is that you should pick up opportunities based on the experiences you will obtain from them, not just the specific topic you will work on. If a good opportunity comes along, go for it and stick to it for a while!

Host: If transferable skills and experiences are the main thing to optimize for, how should one decide which research opportunities are worth pursuing?

Mrigank: As I said, any opportunity within the space of topics acceptable to you and that provides you with the experiences I mentioned earlier is worth pursuing. I understand that there is some disparity between different universities when it comes to how accessible such opportunities are, but one should at least be mindful of what they are looking for. And these opportunities can come from anywhere and from anybody—from a professor in your own university or from a professor abroad, from a senior professor or from a junior professor, or from an industrial research lab, and so on. While it is true that there is some correlation between the reputation of the professor or the organization and the quality of the experience you will get, some students tend to sweat over it more than necessary. I think many of these notions are not generalizable and very specific to the mentor and the project you will work on. They are also somewhat secondary to the other factors I mentioned. Not only should you know what you want from an opportunity, I believe you should also be upfront about it with your potential mentor. Discussing your goals and expectations can help them help you better, and it also conveys that you are serious about your work because you have a vision for yourself. For example, your goal may be to publish a paper or to get a strong letter of recommendation, and your expectations may be to have regular meetings. On the flip side, if you are unsure your expectations will be met, you can toss out the opportunity and look for another one. You can also speak to other people who have worked with your potential mentor before to get a sense of what working with them will be like and whether their mentoring style is a good fit for you.

My mentors have played a huge role in my journey and I cannot stress enough how important it is to find good mentors. The experiences I mentioned earlier, related to the research process, will probably be handed down to you by a good mentor. But you will have to be a good mentee to extract the meta-level knowledge that an experienced researcher has to offer. By being proactive and making the most of your interactions with your mentor, by asking questions and carefully listening to them, you can learn how they think about research, how they break down complicated problems into actionable steps, how they present their ideas, or how they critique other researchers’ work.

Host: We’ve talked about what to look for in an opportunity. Are there common pitfalls or red flags students should be mindful of, even when something seems appealing at first?

Mrigank: I do have a few things to say about this. I can think of three axes that I would like to touch upon. Please keep in mind that I am not making general statements here, and these are specific cases that students should look out for.

The first is alignment. If an opportunity does not align with your goals, it is probably not worth pursuing. For example, if you want to apply for PhD programs, you should probably not spend your summer doing a product- or service-oriented internship in a company. There might be peer pressure, or you might get a lucrative offer from a popular company, but you should keep in mind that you are spending time away from potential research experiences that could have helped you build a stronger profile for graduate school applications. There is no correct answer here, and I am simply asking you to weigh your options carefully.

The second is exploitation. You should never let yourself be exploited under the guise of an opportunity. I can tell you that there are many startups that will tell you, particularly if you’re a student in a well-known university, that they are building something that will change the world and you will be working on the bleeding edge of research if you join them, but will make you perform grunt work for 12 hours a day without proper compensation, mentorship, or learning. Unfortunately, this is far more common than you might think, and while these startups themselves might be legit, they know that undergrads are energetic and hardworking, and take advantage of their eagerness to prove themselves. Not all startups are like this, but many are, and if you find yourself in such a situation, just run. It is simply not worth your time and talent.

The third is prestige. I will give a very specific example for this: foreign research internships. This is a big thing in my university, perhaps because historically many students from my university have visited institutions abroad for research internships. Lately it has become somewhat harder to get into such internships because of the suspension of several programs, but the buzz around them carries on and many students stretch themselves thin trying to find such opportunities. Now I do agree that the majority of students who participate in such internships benefit from them in terms of their immediate career goals, for example, by working on a meaningful project, publishing a paper, or getting strong letters of recommendation. But a sizeable number of students end up with an experience that is not really worth the hassle of visa applications, travel logistics, and possibly even funding their own visit. For these students, the internship is too short to get any tangible work done and there is no plan to take the project forward after the internship. This is particularly the case when you cannot work remotely, like in many non-CS areas. Essentially, foreign internships are not a golden ticket, and it is likely that one can benefit just as much or even more from working with a professor in their own campus. At the end of the day, it is the quality of the experience that matters more than the location where it takes place. So while I will not discourage students from looking into such internships, I will suggest, as always, to be mindful and deliberate in what they are looking for from them.

Host: If you had to distill all of this into one guiding principle for choosing opportunities and making these decisions, what would it be?

I think the underlying principle is to be deliberate, might I even say selfish, in deciding where to spend your time and mental cycles. You should know what you want from what you do, and how you could get it. You should be fearless in pursuing your wants, in asking for help if things are not working out, and walking out if there is no reconciliation with your goals.

Host (ChatGPT): Perhaps the central idea in this conversation is that undergraduates should think less in terms of chasing the right opportunities and more in terms of seeking the right experiences. In a stage of one’s career where time is limited and exploration matters, that is an important distinction to keep in mind.

foreach (var file in SomeFileCollection) {
    var parsedFile = file.SomeParsingOperation();
    if (parsedFile != null) {
        // store parsedFile in a Dictionary
    }
}

They noticed that SomeParsingOperation can be expensive for large files, and modified this loop to run in parallel using System.Threading.Tasks.Parallel.ForEach. Luckily for us, SomeParsingOperation had an asynchronous version called SomeParsingOperationAsync.

using System.Threading.Tasks;

Parallel.ForEach(SomeFileCollection, file => {
    var parsedFile = file.SomeParsingOperationAsync().Result;
    if (parsedFile != null) {
        // store parsedFile in a ConcurrentDictionary
    }
});

This change seemed very reasonable, and though we didn’t have any performance tests to validate the improvement, we merged the change into our project. For many months, everything seemed to be working fine—until one day, we started noticing that this part of the code was taking several hours on certain large inputs. We realized that we had never run our code on such inputs before, and immediately concluded that it is likely these inputs are too large for even the parallelized code to parse quickly. We knew that in practice, we do not need to parse all the files in SomeFileCollection for our functionality. So my solution to this problem was to implement some heuristic to select only a subset of SomeFileCollection that we need to parse, and discard the rest.

Before opening a pull request, I asked Copilot to review my changes⁴. There were no major issues, and I asked it to fix the minor nitpicks it found. One of these was something to do with the parallel code from above. I thought its some style suggestion and nonchalantly accepted this change like the rest⁵. I ran our code on a larger input again, and what took several hours before was now taking just a few minutes. Sweet! I requested one of my colleagues to re-run the code on some more large inputs so that we can be sure, and called it a day. Some time later, they texted me back saying that it indeed takes only a few minutes, but he just realized that he forgot to pass the flag that enabled my heuristic for cutting down the number of files to parse.

This meant that the only change affecting the performance was that in the parallel code. Copilot had modified it to use System.Threading.Tasks.Parallel.ForEachAsync, which it claimed would give us “true parallelism”.

Parallel.ForEachAsync(SomeFileCollection, async (file, ct) => {
    var parsedFile = await file.SomeParsingOperationAsync();
    if (parsedFile != null) {
        // store parsedFile in a ConcurrentDictionary
    }
}).GetAwaiter().GetResult();

I created another pull request to isolate this change and we ran tested it out again. And voila—this was all we needed to do⁶! In the original code, Parallel.ForEach blocks a thread until file.SomeParsingOperationAsync().Result is available. This takes away the opportunity for the thread to be used for other tasks while waiting for the result, which is especially bad since SomeParsingOperationAsync performs I/O operations. On the other hand, Parallel.ForEachAsync is non-blocking and allows the thread to be used for other tasks while waiting for the result of file.SomeParsingOperationAsync()⁷.

The lesson here is to really understand how concurrency and parallelism work in your programming language. It is very easy to write code that looks parallel, but is actually not. In our case, Copilot happened to point out what we had missed for months. Maybe we should have started using Copilot earlier—but better late than never!

When I was in 10th grade, I thought that happiness was clearing board exams with good scores. In 11th and 12th grades, I thought that happiness was getting into a good college. In college, I often thought that happiness was getting a good grade or landing a good internship. And in finding happiness from the future, I frequently forgot about the happiness I could find in the present—spending time with friends and family, pursuing creative hobbies, traveling and exploring new places, or taking care of my body through exercise and sports.

2025 was a year of reflection, as I began asking myself what happiness means to me. My observation is that the pursuit of happiness has so far been an endless tunnel. Not only does it inspire me to sacrifice the joy of the present, it also slowly drains out all the fun from my work. Moreover, I realized that this pursuit will possibly never end. Today I think that happiness is getting admitted to a good doctoral program. Tomorrow, it will be publishing some number of papers in top conferences. The day after, it will be landing a faculty position at a reputed university. Interestingly, it does not stop there either. Then I might think that happiness is getting tenure, or winning a prestigious award, or receiving a lot of citations on my work. Who knows? I attended a talk in a New Faculty Symposium¹ and was almost shocked to learn that even professors² face stress, insecurity, and anxiety in their careers.

And this is what nethi nethi beautifully captures. Not this, not that. I don’t know what happiness is. But it seems that happiness is not in its pursuit, it is not in punishing myself, and it is not in the future. It is somewhere in the present, around me—maybe in my work, or in my relationships, or in my hobbies. In 2025, I redefined my understanding of happiness. My new manifesto is simple. I will enjoy my work and will not work if I am not enjoying it. I will read and learn different topics as I did when I was a kid. I will work toward some regular physical activity. I will not feel guilty about spending time with friends and family. I will explore new places. And I will learn new hobbies, like playing a musical instrument. I am not quite there yet, but I am on my way. I have started running whenever I can³ and have been learning to play the ukulele⁴.

There is another specific thing that I felt is definitely not happiness—hyperconnectivity through social media. While I had already stopped using WhatsApp towards the end of 2024, it was over several months in 2025 that I started to feel the benefits of disconnecting. Just like WhatsApp, I began evaluating the role of each social media platform that I used—Twitter, Instagram, LinkedIn, and Facebook. I realized that the noise-to-signal ratio on these platforms was extremely high, most of the content was rage-bait or slop served to me just to fry my brain, there was unnecessary pressure to brag about accomplishments, and the fear of falling out of touch was overblown. Consequently, I deleted these accounts one by one over the year, and I really enjoy the peace of mind that comes with it. It will be a while before I can completely understand the pros and cons of leaving social media, but I am optimistic that I will look back at 2025 and be glad to have made this decision.

I still do not know what happiness is. Maybe I will never know! But perhaps that is the point. Not this, not that. Nethi nethi. I will not mistake happiness for something it is not.

Of course, all the ideas I am throwing around in this post would have been impossible without the great people around me. Like in all the years before, I have been lucky to find mentors and collaborators who supported me in my career goals and pushed me to think more clearly and honestly. I have also been fortunate to have friends and family who are always ready to deal with my quirks and eccentricities⁵, even when I am still figuring things out.

Our work presents the first systematic study of technical errata reported in Internet Protocol specifications. These specifications are published by the Internet Engineering Task Force (IETF) as RFCs (Request for Comments), which are natural language documents written by experts in the field. RFCs are widely used as authoritative references for implementing Internet protocols, and ambiguities in these documents can lead to incorrect software implementations. Each RFC goes through a long drafting and review process before it is published, where many experts scrutinize the document over several iterations — and yet it so happens that the final published RFCs contain ambiguities. While many of these may not be a problem for domain experts, they can be a significant hurdle for people² writing software based on these documents. RFCs, once published, are immutable, but the IETF provides a mechanism to report errata to keep track of any issues found in the documents. We analyzed 273 verified technical errata reported in RFCs published over the last 11 years and classified them into 7 categories spanning inconsistencies and underspecifications.

Drawing from our analysis, we developed an LLM-based system, RFCScope, to automatically detect such ambiguities in RFCs. Our system gathers cross-document context and slices the RFCs into smaller chunks to make them easier for LLMs to process, before prompting the LLM with prompts based on our taxonomy to identify ambiguities. Our system also self-evaluates its findings, removing a significant number of false positives while rarely missing out on true issues. We evaluated our system on the 20 latest RFCs related to Domain Name System (DNS) and found 31 previously unreported ambiguities in 14 of them. We were able to confirm 8 of these issues with the authors of the respective RFCs, and 3 of these have been accepted as official errata³.

    Our data and tool are available on GitHub.

It was a pleasure working with my collaborators on this project. Lize helped a lot with the manual analysis of errata for both our taxonomy and evaluation, and also supported the literature review for our paper. Prof. Yixin and Hyeonmin were very helpful in providing relevant insights from the networking domain, and Prof. Yixin also made it possible for us to get in touch with the authors of several RFCs to validate our findings. Hyeonmin also created beautiful illustrations for our paper, like the one in the image above. And of course, Prof. Wenxi was a wonderful mentor throughout the project, providing me with a lot of autonomy while also always being available for discussions and feedback. I am very happy to be a part of the first paper from her group and look forward to more collaborations in the future.

Security vulnerabilities are essentially bugs, with the specialty that they can lead to unexpected behavior that can compromise the integrity of the system. This integrity may be defined in terms of confidentiality of user data, availability of service to clients, or prevention of unauthorized transactions. Since these are not usually bugs in the functionality of the software, they are not always preventable simply by adhering to specifications and cannot be easily detected by standard testing due to the atypical and sophisticated ways in which they lead to exploits. With big software, this problem is exacerbated for several reasons. First of all, a large codebase is most likely written by many people over a long period of time, because of which no single person can have a complete mental model of the entire codebase. Secondly, the complexity of the data and control flows in a large codebase, including its interactions with external libraries and systems, makes it very difficult to analyze the code manually. These together dismiss the possibility of manual code reviews or ad hoc analysis by individual developers. Moreover, it is not easy to patch parts of the code arbitrarily without a deep understanding of the behavior of the system, because a seemingly innocuous change can have unintended consequences elsewhere in the code — making development teams reluctant to accept such changes.

Static analysis has long been a choice for finding vulnerabilities in codebases. Static analysis literally means “analysis without execution,” and it involves looking at just the source code to find patterns that may indicate bugs. These can be simple analyses like type checking or linting, which is often provided as part of many compilers and development environments. But these can also be more complicated analyses related to the data and control flows in the program, like tracking the flow of untrusted data to sensitive operations. The advantage with these tools is they generally do not require any special setup and can be run on any codebase without any specific configuration. In the context of security vulnerabilities, static analysis tools can take advantage of the fact that software is written by humans — and humans are quite predictable in how they write code, since they usually pick it from people around them, like their peers and professors at university, other developers in their team, open-source projects, and online forums. This leads to common patterns in code, including common weaknesses² that have been known to lead to vulnerabilities, which can be searched for using static analysis. Modern static analysis tools like CodeQL provide expressive query languages to search for such patterns and can process large codebases efficiently.

However, the advantages of static analysis do not come without costs, specifically when dealing with large codebases. Many classes of static analysis problems are either undecidable or computationally infeasible to solve exactly, especially for large volumes of code. For this reason, static analysis by design is run in an approximate manner³, making use of heuristics to bypass computationally expensive steps. This can lead to false alarms where static analysis flags a non-issue as a potential vulnerability (or does not flag a real vulnerability, although this is less common). This might be acceptable for small projects where a developer can manually triage the results, and the traces indicated by static analysis can be easily followed manually. But for large projects, this can lead to an overwhelming number of false alarms that will be too expensive to triage manually — effectively rendering the tool useless. In some cases it might be possible to modify the static analysis queries to reduce false alarms, but this puts an additional burden on a software team that may not have the expertise or the resources to maintain such queries. In software engineering practice, it is often much better to sacrifice some real vulnerabilities in favor of a smaller number of high-confidence results that can be handled easily. We will come back to this point soon.

What we need is an intelligent system that can understand the code at a deeper level and weed out false alarms, assisting the tedious manual triage process. A very tempting option is to use Large Language Models (LLMs) for this purpose, since they have shown remarkable ability to understand and generate code for various programming tasks. LLMs by themselves cannot be asked to look for vulnerabilities in a large codebase because of limited context and diminishing accuracy with large unfocused prompts. But what they can do very effectively is to start from static analysis results and triage them by looking at the relevant parts of the code, just like a human developer would. Unlike static analysis, LLMs are probabilistic and can also hallucinate — but if they can statistically reduce the number of false alarms, they can be very useful in the field.

LLMs can reason well when shown relevant code and asked specific questions. But how do they access the relevant code in the first place? This too is an engineering challenge, because it necessitates building infrastructure that can digest large codebases and provide semantically aware tools to traverse the code and retrieve relevant snippets. Even with such a tool at hand, a delicate balance must be struck between providing too little context, which may lead to missing important information for reasoning about the vulnerability, and providing too much context, which may lead to the model getting distracted and losing focus. Of course, for a small codebase, one could throw the entire project at the model at once — but for larger codebases, it is important to decide what slices of code are even relevant to the vulnerability in question.

Remember that handling such static analysis results is actually quite a low-priority task in most software teams, because they are mostly unrelated to normal functionality and do not usually have an exploit to demonstrate their severity. Yet, finding such issues before an exploit is even attempted is the whole point of static analysis, and so fixing them is important for long-term security of the software. Thus, a practical toolchain for assisting this whole process should not only triage results but also suggest high-quality and focused patches that can be reviewed and applied with minimal friction. Statically looking at code cannot always reveal intended behavior, and so patches must be best-effort and good starting points. LLMs once again provide a promising avenue for this problem, because they can easily generalize from a few instructions and examples to handle entire classes of patches, while a symbolic approach would require separately handling each of the many code styles found in the wild. And once again, a solid infrastructure is needed to ensure that LLMs are directed to the right parts of the code and produce patches that follow both the style of the codebase and also the guidelines related to the vulnerability in question. GitHub’s Copilot AutoFix can do this to some extent, but it is known to get overwhelmed by large codebases and produce incoherent and incomplete patches that are all over the place. This is again a problem of scale.

All of this was a prelude to the main point of this post, which is that scale can introduce unique challenges that are not present in toy settings. This can seem counterintuitive because this makes several problems in software engineering harder to experiment with and nearly impossible to solve in the traditional sense, even when perfect solutions exist for small cases. Software engineering is a field science, and the main takeaway that I hope to convey is that a tool designed without confronting these realities may not work as intended when taken to the field⁴ — when the question is that of a million lines of code. In a future post⁵, I will follow up on this by sketching some ideas on how to think about building components for a toolchain that solves the problem I outlined above and how to evaluate them effectively.

As he walks, a cold breeze slashes through the sweat trickling down his forehead. The night is chilly, yet he is almost fuming. His heart hammers against his ribs — its frantic rhythm could convince anyone he has just finished a sprint across the empty road. Fortunately, there is no one here to witness his struggle, to see the way his feet drag like those of a corpse, or to notice how each step feels heavier to him than his last. The wind seems to whisper to him, urging that he turn back and return to his room, where the messengers of the night await him. They came for him again, just as they do every night. But tonight, they arrived armed with more than just words.

They demonstrate an uncanny familiarity with his thoughts as if they have always been watching. They know his thoughts before he does, sifting through his mind and all its regrets and denials, doubts and judgments. One speaks of the future, painting a grim certainty of failure that he must learn to accept, and another of the past, dredging up mistakes long buried that bring merely a lingering discomfort. A third gossips about his friends — murmuring of deceit, of betrayal, and of the masks they wear when he is around. And the fourth never speaks, only gesticulates, his crooked sneer feeding the fear that gnaws at his core — that he does not belong. Not among his peers. Not at work. Not even at home. He is at best an undeserving outsider, a mere shadow of the people he is surrounded by.

Yet, for all their torment, they offer him something he can no longer find elsewhere. They listen when no one else does. They nod in agreement at his darkest and most gruesome thoughts. Their cruel affirmations feel like a twisted form of validation, providing almost a sinful sense of achievement. As their words wound him, he started to crave their company. He dreads their visits, but he also longs for them. Without them, there is only silence. And in that silence, he is alone.

He walks on. His eyes trace the decaying leaves scattered across the freshly asphalted road, their crisp edges stark against the black surface, like clouds glinting in the sky above him. As he nears a flickering streetlight, a shadow shifts in the periphery of his vision. He breathes a sharp gasp, his racing heart threatens to burst from his chest. But when he turns, he sees a watchman, slumped beneath the glow, half-asleep. The tension in his chest loosens, just slightly. A bitter smile tugs at his lips. He checks his watch. 4:24 AM — it has been over two hours outside. He tilts his head back, gazing at the sky, where scattered stars emerge through the heavy clouds.

The night seems to be challenging him, roaring at him and daring him to confront it. The blinding sparks of lightning summon him to stop thinking, to stop running away, and to return to the messengers it has sent for him. His feet are slowly giving up from exhaustion, his head heavy with sleep that he has been denying himself for countless nights. But he cannot return, because tonight is different. Tonight, the messengers had come with a plan — a plan to end it all, the pain, the loneliness, the fear. They made an offer so tempting to his desperate mind that he could not refuse. They had promised an escape to a place where he would be free from his perpetual agony, a place where he would finally fit. And just when they had him convinced, something dropped in his room and stole away his fragile attention. He had accidentally knocked over his bedside table, and with it a silver watch his parents gifted him on his birthday, a thriller novel his previous roommate got for him last summer, a photoframe featuring his friends and him from their spring trip to the beach, and a lamp with a soft yellow light that his girlfriend bought him so he could read at night. While he hurried to pick up the chaos he had created from some of his most precious items, he started to look through the proposal the messengers had made. He understood the vileness in their intentions. All this time they had been slowly poisoning his mind, locking it up in one shackle after another — and tonight they had come to finally imprison him forever. And that is when he chose to escape.

He rubs his eyes, gently wipes the sweat from his forehead, looks at his reflection in the regular puddle on the roadside, and decides to sit down on the curb. The birds have already started their chirping, and the sky is slowly brightening into a smooth blue. It is not clear whether the birds are singing to encourage him or to mock him, but he hardly cares anymore. He has defeated the messengers of the night. Although the sun is now rising, he knows they will return. But he will be ready for them with his newfound resolve. The messengers of the night can never take him prisoner.

This is a short story I wrote for a mental health series in the undergraduate magazine at IISc, called Quarks. Mental health is a sensitive and important topic in the IISc student community, and I hope this story resonates with people who have struggled with such issues, possibly also offering some optimism. If you are struggling with any mental health issues, please reach out for help. IISc students can benefit from free, confidential, and professional counseling services at the IISc Wellness Centre.