From a discussion thread on Making Light today, a link to JeffWofford.com:
“A programmer’s greatest enemy is getting stuck.”
Go and read that post. And when you’re done, read the following posts, “Four Kinds of Stuck” and “Keep Taking Steps Forward.”
I recognize many of the specific examples from the days when I was getting paid to develop software, and from the programming I do now in the course of my Ph.D research. I’m mentally applying the concepts to the bigger picture of my Ph.D, though.
Doing a Ph.D. is, by its very nature, an exercise in being stuck somewhere between Stuck in the Muck (knowing what to do, but not knowing how) and Conceptually Stuck (not knowing what to do). It wouldn’t be original research if you didn’t have to figure out how to do something that hadn’t been done before.
The problem is, at the same time, you’re learning how to properly do the things that have been done before — and you’re still making mistakes on some of those things. So when something isn’t working, it can be hard to tell whether it’s an easy problem you’re just screwing up, or whether it’s a hard problem you’re properly working through. That makes it hard to tell whether you should say “Okay, this isn’t the solution, I’ll figure out a different approach” or “I have to keep working on this until I figure out what I’m doing wrong!”
I find that scheduling weekly meetings with my advisor helps. She has more experience than I do, so she’s able to suggest things to try that I hadn’t thought of.
My Ph.D work is solitary. But in other projects, I’ve found that working with a good team also helps me tell the difference. If I can turn to a colleague and say “Hey, I really can’t get this to work out right. Is there something I’m missing?”, then it’s much easier to keep taking steps forward and get unstuck faster. (And of course, they can turn to me and ask the same thing, so two people get unstuck.)
So I’d much rather work with a good team than do purely solitary work. I find it reduces stuckness.