I like the point about working steadily. Enforcing steady work can be hard—in fact, I know it’s harder than demand-driven sprinting. Steady work requires planning, which itself can feel like it’s taking away from work time. Plans always fail or get changed, too, which might make them seem pointless. Perhaps one of the best motivations I can give for planning is that feeling of getting to check items of a list at the end of the day. That feeling alone is often what allows me to trick my dumb animal brain into a transient feeling of accomplishment, giving me the much-needed opportunity to shut off my work brain for the night or for the weekend.
Write down everything you do, plus the tip about organization. Interestingly, for me, these are somehow in conflict. I fully agree with writing down everything you do. An engineering log is invaluable, because the same niche issues will come up again. You want to be able to search for that one command you need to run when things aren’t working. This, of course, requires some amount of organization…but I would say, do the bare minimum when it comes to organization. I’ve sunk a lot of time into Emacs org-mode setups and the like, and at the moment, I’ve dropped it all and gone back to pencil-and-paper. Importantly, I track engineering details as bugs on my repo on GitHub (so they’re searchable) and I still write down miscellaneous administrative things (like codes I need for school) in a file on my computer.
Honesty with your advisor. This is, in retrospect, a no-brainer, but one I really only learned through many years of having advisors. This is hard, and shouldn’t be expected to be anything short of hard! It can be as hard as—or harder than—the honesty needed for a healthy friendship or romantic relationship.
Take opportunities to present your work. Sometimes this is daunting—even a talk at a lab lunch can be scary and require hours of work. My biggest suggestion here is: make opportunities to present your work in low-overhead ways. I hate making slides when I have other things to focus on, i.e. when there is still engineering work to be done. So for weekly meetings, I’ll either (rarely) make one or two slides; more likely, though, I’ll write up some code and show it as a demo. Even if this inspires a single clarifying question, it’s likely inspired more conversation than just talking about your work in the abstract would. A demo gives people something to actually ask questions about, rather than forcing them to admit they don’t understand your (likely bad) verbal explanation of your work.
Don’t compare yourself to others. It’s a mantra. By the end of my however-many years in the PhD, those words will have lost their meaning to repetition…but I’ll still be repeating it. The gist of my feeling here is: it was they who let you in, so let them also be the ones to kick you out if you truly don’t belong here. In the meantime, don’t count yourself out.
There are a few tips that involve having a social life. Boiling that sentiment down to a tip on a list does not do it justice, in my opinion. The PhD is an isolating experience; “having a social life” is meant to be a balm on that isolation. Yet I truly feel that we shouldn’t just be helping students address their isolation when it arises—we should be helping them avoid it in the first place. Having a life outside of your work—a social life, if you want it, but even just a hobby—is the preventative measure that helps you from feeling worthless when your work inevitably feels worthless. Having something other than your work helps you put problems (large and small) into perspective, when they inevitably arise. If you don’t attach your own self-value to your work, then you can avoid letting the state of your work affect your opinion of yourself.
Thoughts on Taking Classes
It’s helpful to go into a class with an answer to, “what do I hope to get out of this class?” This is mostly applicable to the later years of the PhD, where your time (not to mention your mind-share) is even more valuable!
Thoughts on Getting Scooped
My advisor, Zach, often says that you’re never truly scooped. Regardless, if you can’t get it out of your mind that you’ve been scooped, it might be helpful to think about it in the following positive light. When you started working on whatever you are working on, you were presumably motivated by some need. You were at point A and wanted to get to point B, but there was some gap between them. So you came up with an intermediate goal, C, which has now been scooped. Yet, if you’ve really been scooped, this means you may be able to get to B! Though it may be hard to ignore the hard work you put in to get to C, try to rekindle your excitement about the original goal. This will likely get you thinking about how the scoopster’s solution to C can be used to get you to B…at which point, you’ll likely realize that there are still problems it’s not solving, that you handle in your solution!