In Fall of 2025 I began my PhD journey at UT Austin! Here’s some stuff I’ve learned so far.

I’ve been enjoying my time so far returning to academia. I’ve been working on some really interesting projects, and we’re hoping to publish them soon (tm). It’s definitely been a whirlwind of a year/semester, but I thought I’d sit down and reflect on what are some important lessons I’m taking away from this semester.

Communication is key

Compared to when I was a software engineer, the kinds of communication that are expected of me are different. As a software engineer, most of the communication you deal with is either with other members of your team, with engineering in general, or with stakeholders in a project. Typically, communication within a team can assume a very high amount of shared context. With engineering at large, you have some base context that is shared so communication must include a salient delta representing the area you’re team is working on. With stakeholders, very little context is shared, but you also generally only provide stakeholders with very high level details - focusing more on the impact of your work, rather than the detail of it. Academia is completely different - you’re frequently communicating with a wide spectrum of lab members including fellow students, professors, and post-docs. While some projects involve groups of people, you’re frequently communicating with people who have little shared context, but the goal of discussion is generally to make progress on subtle, deeply technical issues. This requires being prepared to deliver concise accurate reports that provides your collaborators with information about the topic you’d like to discuss, and sufficient details to allow them to bring their insights to your work.

I’m still working on developing this skill, but frequently presenting details about my work helps. While my advisor meetings and lab meetings are good venues to practice, I’ve been trying to talk to other researchers outside my lab and tell them about things I’m working on to get better at explaining things.

You are your own boss

The level of freedom you’re given as a grad student (or at least the level of freedom I experience) is lot more than what I was used to as an engineer. At the start of your PhD it seems like it’s normal to not yet have a concrete direction to explore in, and while my advisor and lab provide me with some directions that have funding and need researchers, I’ve still been poking around to get a more complete sense of problems that resonate with me. A professor told me earlier this year that your advisor exists to give you advice. While the advice is often good, there is no one stopping you from ignoring that advice. Hearing that has helped me understand that I am allowed (and in some ways, expected) to explore topics on my own and bring ideas I’m interested in to my advisor. And in order to sell a compelling story around an idea, it’s worth doing a little investigation (and dare I say, research?!) into it so you can present a more interesting sketch. This requires finding time to do work outside of the scope of what your advisor already expects of you. Classes provide an interesting avenue for this, but there’s other ways to find some time. Frankly, I’m pretty grateful that I’ve got a few years of industry experience under my belt here - it’s helped me better plan out my project deliverables and manage the time and resources I’m given.

Engineering is a tool, not the job

This is the hardest thing for me to come to terms with, but as a researcher I’m not creating complete fleshed out products that are ready to deploy. I’m working on proofs of concepts, ideally in a way that can then easily be shaped into something that is at least consumable by relatively risk-tolerant adopters. This means that when working on a project, it’s more important to think about what is necessary to demonstrate the insights of a research question, than usability. There’s definitely a delicate balance here - if everything is held together with duct tape and dreams, it probably isn’t amenable to experimenting with different approaches or making changes as the research goals become clearer. I think I tend to bias in the other direction where I think more about what I would ideally want my project to look like if it was being deployed in a production scenario. I think there’s merit to making research artifacts that are easy to consume, and I keep an eye on labs that put a lot of effort into open sourcing their work, but part of the academic game seems to be publishing your ideas as fast as possible. In the coming semester I hope to do a better job of being aware of what my expectations around engineering are and setting clear outcomes that benefit the research side of my work, while also ensuring that I maintain a level of engineering quality that I can be proud of.

Conclusion

Hopefully you find my learnings interesting! Maybe I’ll have to reflect on this list again after next semester to see if they still hold true for me and if there’s any new insights I have.