Staying sane via IT skill?
This post covers two points: However painful the online transition has been, I am fascinated by how the fun of the free software journey can exceed the immediate value of sanity – promising to restore it more meaningfully if one can endure the learning curve. By doing so, one is essentially practicing a key life skill: persistence/grit.Overview of online vs. in-person/blended teaching
>> I am sure you also manage your various [email] notifications to stay sane (vital IT skill!)
One of my favorite co-networked learning teachers wrote the line, above, that prompted this post.
In my use-case, it has been a waste of time to try to manage my inbox. I have too many students who need too much assistance in too many different areas. Examples include: exam registration problems – and we have a lot of exam terms where I work; group work problems; technical difficulties – to say nothing of the increased need, when teaching online, for course material to be repeated more often than is necessary when teaching in-person. I really appreciate that students ask for repetition, as this is a foundation for learning (repetitia iuvant), but it becomes a problem when answering questions forces me to multitask, which I am bad at. I am multitasking because I take a dialogic approach to much of my work and dialogues take time.
Since health measures were enforced that precluded in-person meetings, email has taken up an increased amount of my time. For example, where it was once possible to give exam result explanations in person during a 90-minute period, now individual emails go out to students, taking, on average, ten minutes each. In some exam terms, I mark over 300 papers.
While I am among the “lucky” ones to have been studying and practicing networked learning before all of this, so have experience with the meaningful integration of technology in teaching, this does not mean that I have been able to “stay sane [via] vital IT skill”. I love that phrase – and aspire to realize its promise! Here are some reasons why that goal is so hard:- There is a huge difference in blended learning (where some, not all, of the teaching is done online) and fully online teaching, not least of which is the problem of how to maintain an ethic of care in “disembodied teaching”
- It takes several rounds of action research (c.f. Lewin 1946) to figure out what works and does not work in one’s local teaching environment; in order to cut down on action research cycles to improve my online teaching, I made a huge time investment in the past two years, filled with a variety of experiments
- For networked learning to work properly, there needs to be institutional supports in place. One example could be to reduce the administrative duties of teachers with larger workloads. Unfortunately for some of us, there has been an increased load of paperwork in the past two years
- A participatory, dialogic approach to teaching takes more time, not less, when teaching online. In-class dialogues get cut off when class ends; email dialogues are ongoing: answering one means only one person got the participatory experience: extending this experience to all emails means answering them all. To be clear: I am talking about the dialogue that is extra to dialogic components already included in course design
- The hardest problem I’ve faced, re. the above, has to do with detailed conversations with 400 students on how they can improve their work while the semester is underway, not just at exam time, when it is ‘too late’
- The “easy-to-use” digital collaboration/automatization tools come with a price tag – monetary and philosophical. Not everyone can or is willing to pay it.
I threw together a pseudo-infographic to illustrate how much more time online teaching has taken than in-person teaching – but forgot to include one of the most painful time drains: administrative work. It also does not include the time spent on (free) software discovery and evaluation.
Free software as an instrument for sanity
Deciding to take one’s computing into one’s hands as much as possible means making a lot of decisions on many levels, including research discovery and exploration of the range of tools available, deciding which are tools and which are “instruments”:Instruments have depth, dimensions and adaptability to many uses and aims. e.g. musical instruments can play cross genres of music and settings. a microscope can be used to see and experiment with an infinite number of materials. a framework can be applied to anything we need to think about. a model is a tool for one proscribed use. Tools have a shallower, predefined us to achieve one purpose. e.g. a hammer hits and drives nails. – Carol Sanford, source
According to that definition, free software is an instrument, more than a tool. As such, it comes with a learning curve, including: figuring out alternative workflows to accomodate the digital instrument of choice; learning how to maximize digital instrument of choice; learning how to collaborate with others given digital instrument of choice.
But there is not always a choice: a pain point in academia concerns publishing and conferences which often come with cookie-ridden, proprietary software requirements. There is a move towards “Open” publishing but even some of these “options” require university institutions to pay exorbitant fees before its staff can be qualified to opt for it.
Therefore, if one is in a position at all to be able to think about free software in pedagogical design – no matter how sleep-deprived they are because of this, it is a great privilege.
Here are some final thoughts. Given the need for increased automatization of academic work once it is largely digital [see above section for explanation], it is critical that this automatization does not come at the cost of cultivating care-ful (c.f. Stiegler 2018) individual expression (c.f. Dewey 1946). Experience in teaching teaches us that Automatizing All The Things will be terrible – even if we get it right in one place in one semester, the next semester will bring new students with new dynamics. The criteria for pattern design cannot be pinned down but can include a rough framework of tools, processes, and desired outcomes, including the value of the human place.
What can be automatized? The incredibly kind Andrea of Moldable Emacs mentions automaticizing what makes us bored. This is good insight – and an observation significantly born out of kindness.
Boredom comes from too much reptition: when one has learned something. For me as a newcomer to free software – where I suddenly have a choice not only of instruments but of methods – there has been no boredom. Rather, I juggle the problems listed in the previous section with wise allocation of time, which includes figuring out which skill set I can next invest my time in to accomplish more efficient management of a portion of my new free software workflow. I documented my back-to-school GTD Emacs journey here. On the basis of fun journeys like that one, I conclude that joy can exceed the value of sanity for at least one part of the freedom ladder journey towards IT skill.
Page generated 02D14. Last edited 02O10.