PhD productivity

I went to a seminar this week given by Dorian Peters and Rafael Calvo. They're doing a lot of interesting work on Positive Computing - the deliberate design of computer interfaces and applications to improve people's lives. But what really struck me was when they talked about Self-Determination Theory (Deci & Ryan), which found that our perceptions of our competence, autonomy, and relatedness independently predict the variability in our well-being.

There are obviously other factors, but this is, I think, a big discovery for me. In a PhD, our sense of competence and relatedness are nearly always very low - the lonely, confusing path of the PhD student has been written about many times. In my work life, my autonomy and sense of perceived competence are under direct attack as well. My well-being then directly effects my productivity, in my work life, study life, and personal life. I've found myself in a funk both at work and while studying recently, and having something explanatory to point at is, I think, extremely helpful. It means I can dissect my emotional state more thoroughly, and hopefully get past it.

I've talked about "The Rut" previously, and I've hit it again this year. I can cope with PhD uncertainty and doubt when other parts of my life are going well, but when my professional life is in dramatic flux as well, it's hard to get anything done at all. The Tweet above asserts that dealing with this is a skill, and that makes sense. I think it's time to start working on this skill, and finding the tools I need to help me with it.

Design Based Research and Agile Methodology

I find the parallels between Agile software development methodologies and Design Based Research quite interesting. I come from a software development background, and in a sense Agile methodologies are a formalization of the approaches software developers naturally tend to drift towards in the absence of formal project methodology. The statement in the Agile Manifesto says it well:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile methodologies are designed to be more flexible and responsive than traditional software development methodologies, and have come to the forefront since the early 1990s as one of the best ways to develop software - the software is built iteratively, in close consultation and collaboration with the end user, and without a defined intended outcome (apart from "build the software the user needs") stated at the start - the software evolves as it is built.

Design Based Research also emerged as a major force in educational research in the early 1990s. It is a response to the traditional research approach of hypothesis testing by conducting experiments with as many variables controlled as possible. The real world of education is messy - people act differently in different contexts, and consequently an experimental result found in the lab doesn't necessarily correspond to an outcome in the real world. One of the ideas that absolutely blew my mind when I first started learning about educational research was the Hawthorne Effect - that people behave differently when they are being observed by experimenters. Design Based Research is an approach of testing a learning intervention in a real-world setting (a classroom or course), not just to see what effect it has, but rather to iteratively improve the intervention until it is successfully helping learners learn, but also to develop a local theory about why it helps them learn. 

 I went into my PhD with the idea that I would develop in a reasonably Agile way, and was delighted to discover DBR, and how compatible the two approaches seemed. The following table is from my Thesis Proposal:

What I've found in practice is that both DBR and Agile development are methodologies designed for groups of people. As a PhD student, I'm largely doing my research by myself, so while DBR still makes sense (though gathering and analyzing the large quantities of data involved is a bit overwhelming), Agile seems like overkill.  I'll still write about the parallels between the two approaches in my thesis, and suggest that perhaps Agile methodologies might actually provide some formal structure around the DBR process (which is rather ill-defined and non-prescriptive in the literature as far as I have read), but the extent to which I've been actually able to adopt Agile methodologies and demonstrate their effectiveness is hampered by the fact that there is only one of me, so the need for processes to manage the "team" is limited.