Austin Z. Henley

I work on AI + dev tools.

Home | Publications | Blog

Lessons from my PhD


See the discussion of this post on Hacker News and Twitter.

Most of what I learned during my PhD had nothing to do with my dissertation topic, grad school, or even computer science.

These lessons are so ingrained into me now that I'm shocked when I find out that not everyone knows them! I think they can be applied to virtually any office job.

I've written down a few of the lessons in hopes that my students find them useful:

Thank you to everyone that taught me these, especially my PhD advisor, Scott Fleming.

Lead or be led

Before I went off to my first research internship, my PhD advisor imparted some valuable wisdom with me: "lead or be led".

Sure, it sounds like a useless platitude. At the time, my advisor meant it as a way to keep me focused on getting what I want out of the internship. He just wanted me to be strategic about my time. But the mantra continues to come up again and again in my career.

If you show up to a meeting/internship/job expecting to be told what to do, then chances are someone will tell you something to do. It might not be the best thing for you to be doing though.

Alternatively, if you show up to a meeting/internship/job with a convincing game plan, then chances are people will get out of your way so you can go do it. Sometimes they will even surprise you with the ways they can support you with it.

Don't expect people in these situations to ask you what you want to work on. You should already be telling them.

You won't always win though. There is a lot of strategy to how you go about this. But first, show up with a plan.

Topic sentences

This is the #1 tangible skill that I learned from graduate school. It makes writing so much easier.

After coming up with a rough outline for whatever you need to write, the next step is to write the topic sentences.


Write the first sentence of every paragraph you intend on having. Keep them simple for now. You can improve the prose later. That is it. Don't write the paragraph bodies yet!

Now read the topic sentences.

Do those sentences convey what you wanted? Do they flow together? Are you missing any major details? I often have to iterate on these a few times.

Keep these topic sentences around. In fact, I was taught to bold them. My PhD advisor used a LaTeX macro so they can be turned on and off.

Whenever you or a collaborator needs to skim the writing, they just need to read these bolded topic sentences to understand the story.

Now go write the paragraph bodies to support the topic sentences. Doing so will probably reveal that you missed something and you'll need to refactor the topic sentences. That is part of the process.

Another great benefit: If you ever need to write a summary or abstract of something you have written using this process, you get the initial draft for free: copy and paste all of the topic sentences. Voila. For example, the topic sentences from a paper's Introduction makes a great starting point for the abstract!

If you can't figure out your topic sentences, then you don't know what you want to write yet, which is also helpful to realize.

Get excited

Any job has parts that we don't enjoy doing. But if you don't find a way to get yourself excited, then it is going to be painful and you probably won't do very well.

This saved me when I had nothing but weeks and weeks of qualitative coding and data analysis ahead of me.

I still have to remind myself of this on a regular basis when I'm dealing with a mountain of administrivia. There really isn't a secret to it. Take a swig of coffee and get yourself psyched up.

Unmotivated details

I picked up a pet peeve from my advisor: unmotivated details.

Why are you telling me this?

These unmotivated details are everywhere! Papers, presentations, blogs, meetings, emails, etc.

Before you explain something, you probably need to motivate it. Why should this person care about what I'm going to tell them? It often only takes a few words to do so.

A variant of this problem is when people are explaining what they did. I see this with students in particular. It is a common pattern for them to try to justify their grade or salary by explaining how they spent their time. But why do we care what you did?! Tell us why you did it and what came of it.

Another way of thinking about this is to frame your work communications as storytelling. The ability to communicate a well articulated story is worth gold, but it takes practice, and unmotivated details are a sign that you don't have the story figured out.

Slides versus speaker

I was terrified when I had to do my first conference presentation. There isn't a shortcut for practicing, but there are some big tips that make slide design and presenting go much better.

There are two main modes of presenting: the speaker leads and the slides assist OR the slide leads and the speaker assists.

Speaker leads: You want the attention to be on what you are saying. The slide exists to assist your message by showing a short form of what you are saying aloud. The slide should be very simple.

Slide leads: You have a figure or table that you want the audience to understand. The speaker is there to help guide their attention.

You'll probably switch between these modes multiple times throughout any presentation. You can't have both at once though! If I am trying to understand a graph, then I can't be listening to you, and vice versa.

Another big tip: Prime the audience for what slide comes next. Do this by having a verbal segue for every slide.

For example, you are on a slide showing comments from users about your product. You transition by saying, "after receiving this feedback from users, we explored potential solutions...", then click, you show the next slide with your solutions.

A few more recommendations:

Managers as input/output machines

When I first started working with my PhD advisor, I thought our weekly meeting was for me to prove to him that I had been productive.

That is false.

Now that I have grad students, I see this same behavior. But it isn't a good use of anyone's time.

These meetings are for getting feedback.

In the words of my PhD advisor: "advisors are input/output machines". You put into it your update and you get back feedback. The meeting is for your benefit.

However, you have to show up with something in order to get feedback. If all you say is "I'm still looking into that one thing" or "I'm stuck", then there is little to go off of. Sometimes that happens though. But if you want help from your advisor/manager, you have to show up with something. This is virtually always possible to do, even if you think you didn't make progress, though it does take a bit effort to get organized.

A few suggestions for running update meetings with your advisor/manager:

Daily progress tracking

In grad school I fell into the practice of scribbling notes into small notepads. It took several years before I was able to articulate why I was doing it though.

Each day, I wrote down a few bullet points of what I did. I probably spent less than 2 minutes on it. I found that tracking my daily progress has a number of benefits:

It is surprisingly easy to forget what you worked on last week, let alone last month.

In the future I want to experiment with posting my daily progress in a public form.

There you have it, a handful of lessons I learned during grad school that I think anyone can make use of.