Continuous Integration, or How to Be Less Precious and Share More
Continuous Integration, or CI, is a term used in software development, which loosely refers to the idea that everyone working on a project should be committing their work to the shared, public facing version of the product daily, if not multiple times a day. The rationale is that if everyone works on their own parts of the project in isolated silos and only shares that work at the end, the changes that it won't integrate well with other parts of the project are high. It is much easier to make sure that little parts play together well and fix it if they don't than it is to trouble shoot massive integration issues.
As academics, it often feels like we work alone forever, only to turn in huge chunks of completed work to have them ripped apart. How many of us have worked on a chapter draft, conference paper or journal article for months on our own only to have it savaged by some reviewer or reader afterwards? Why not take the core idea of CI and start to share smaller, in progress chunks to head off problems earlier? What follows next is my argument for this kind of a practice, in response to concerns I've heard from clients:
My advisor will only read polished drafts. Of course they will only read polished work! Advisors are the busiest people on the planet, they will have you know - they don't have time to read rough drafts or sketches. This is exactly why you should share work around with a wider net of people before that polished draft is turned in. Here are some people you can try sharing with:
Writing Groups, formal or informal
Writing Workshops - these are sometimes hosted in a departmental setting, sometimes by reading groups, but most students have access to a formal or informal version of workshopping opportunities.
A writing coach - trained coaches can look at a draft, even if they aren't in your specialty (sometimes, this is even better!) and let you know if it makes sense, if the structure is clear, etc.
Your own self. Set aside time to re-read work in progress at the end of the day, or at a regular time during the week. You'll be surprised what you can catch yourself.
My rough drafts are really rough. No one will understand them. My rough drafts are essentially long outlines with some sentences, and of course, those aren't helpful to share with other people. But what I call a Draft 1, or the prose version of my long outline, is helpful to share. I warn people that I am NOT looking for proofreading, just for feedback on the ideas, structure, and sequence. This spares me from people only going through and looking for Oxford commas when I really need them to tell me if it makes sense.
My argument only makes sense in total - it isn't helpful to read less than that. I'd actually counter this and say that if your argument only makes sense when taken as a whole piece, you aren't doing enough to signpost and connect your argument together for your reader. Of course, arguments are nuanced and they build and grow, but if it truly does not make any sense without the supporting pieces, it might be helpful to examine how you're building an argument. Having outside readers read smaller pieces can really help with that.
So much of writing is a lonely process - we research alone (mostly,) we draft alone, we revise alone. Making smaller milestones and sharing your work out more frequently can take some of the pressure off the big check ins with advisors and committees, make you feel less isolated, and improve the quality of the writing overall. It is much easier to fix small problems early than big problems later. Sometimes it is totally frustrating to hear that something isn't working, or to have to redo a whole site that you just spent weeks building. But, better to get the feedback early from a big team of people you trust than to have it come at you in a higher stakes way. Take a page from the software world and continuously integrate small pieces of your work into the bigger whole - it'll pay off.