Research_guidelines
Dirk’s User Manual
Introduction
Greetings! I appreciate your interest in understanding how I work. This document aims to provide insights into my preferences, work style, and communication. Let’s dive in!
1. Call me Dirk
First, although I will respond to titles such as Dr. Colbry or Professor, I prefer that people call me Dirk and I use He/Him/His pronouns. I realize calling someone in authority by their first name can be hard for some students from other cultures, but it is truly okay and not disrespectful. Also, please tell me what you would like to be addressed. If you are patient with me, I also really like learning how to correctly pronounce names that are unfamiliar, it just may take me some time and practice.
2. Fun Fact About Me
I prioritize my life in the following order: family, personal health, students, and work. Outside of work, I enjoy making things using digital manufacturing, using tools such as 3D printers, CNC machines, laser cutters etc.
At work passions revolve around facilitating others’ learning and research. I lead the SEE-Insight research lab, coordinate the data science capstone program, run the CMSETech group, and contribute to the CyberAmbassadors national organization, focusing on professional skills training.
3. Work Dynamics
I thrive on managing multiple roles, projects, and tasks through a complex organization system I assembled, continuously fine-tuning it for efficiency. My toolkit includes calendars, role lists, project lists, next-item tasks, multiple contact lists, and habit lists—all organized through scripts on my multiple computers. Rarely in my office, I encourage reaching out via email, my primary communication channel.
I dislike causing delays, so if you’re waiting on me, let me know, and I’ll prioritize your needs. While I use a complex system of lists, when I say, “I’ll put it on my to-do list,” rest assured it’s not a dismissal, but a reflection of the challenge in timing due to the multitude of tasks and roles.
Every Friday, I try to conduct a “weekly review” to organize my roles and tasks, sharing a summary with my team. I encourage you to do the same, I will always try to respond with the understanding that my responses might come during the weekend and only after I prioritize time with my family.
4. Collaborative Writing
When collaborating on writing it is often best to use a system that has “track changes” capabilities. These include Word, Google Docs and Overleaf. For any document the team should designate someone as the “Primary Editor”. Typically, the primary editor is the lead author in charge of submitting the document, but the roles can sometimes vary and sometime the lead author may not be the primary editor. For students working with faculty, the role of primary editor is typically for the student while the teacher, mentor or advisor is more of a collaborator. An example exception is if the faculty is acting as the primary author and asking for input from multiple students. For projects that include multiple faculty and students it is important to designate the person taking responsibility for the writing and making them the primary editor.
The primary editor’s job is to keep track of ‘official’ document by accepting/rejecting changes and cleaning out the comments. It is expected that the primary editor turns off track changes and edit the main document directly. If the primary editor needs to communicate with the rest of the team, then that can be done using the tools “comment” functionality. Only the primary editor can accept/reject changes and remove comments.
It is the responsibility of the other collaborators to only make changes with “track changes” turned on. This ensures full control of the final product to the primary editor. The other collaborators should respond to comments but not delete them. Instead of deleting them they can reply to the comment and acknowledge that they have addressed what was said as a signal to the primary editor to delete the comment.
Similarly, when collaborating on writing code I prefer using a git repository which I can easily clone and edit. Git is my go-to version control tool and is the best way for me to work collaboratively with a wide variety of teams. I especially like it when we use tools like issues and pull requests. Please make sure the repository has complete instructions for reproducing the work and let me know if you need help, I have a lot of examples and tutorials I can share.
5. Learning Style
I find my own learning preferences align strongly with hands-on experiences and real-world applications. This approach extends to my teaching style as well, while I occasionally find myself in lecture mode, I prefer to try and engage students in real-world, project-based learning.
However, I also recognize that this hands-on approach might pose challenges for those new to a skill or with a different learning style from my own. If you ever find yourself struggling with the hands-on approach, please don’t hesitate to communicate your concerns. I am more than willing to explore alternative teaching methods, adapt to different learning styles, and provide additional resources to ensure a comprehensive understanding.
My goal is to create an environment where everyone feels comfortable and supported in their learning journey. Open communication about learning preferences allows us to tailor the learning experience to everyone’s needs.
6. Energy Sources and Drains
What Gives Me Energy:
I find joy in problem-solving and coding. Breaking down challenges into solutions energizes me. However, beware, once engaged, a problem tends to occupy my thoughts until a solution surfaces.
What Drains Me:
While helping others brings me satisfaction, constant reliance without effort is draining. I’m not a catch-all tech support; I appreciate those who strive to solve problems independently.
7. Preferred Communication
Email is my go-to. For efficiency, one question per email helps me manage tasks better. For me email isn’t a space where work goes to die. I appreciate the flexibility it offers through asynchronous communication.
I also enjoy conducting code reviews asynchronously, a process that involves students sharing links to their Git repositories with questions. I create detailed videos, walk through cloning the repositories, conduct a thorough code review, and address questions. When it is useful, I generate a pull request and include the process in the video to help with the learning experience.
For face-to-face interactions, use this website to schedule a meeting. Zooming is my default, and including a short agenda helps me prepare and optimize our time.
Note that my bookings website only shows time that I have not yet blocked off for work. If you are unable to find a time on the website, please email me blocks of time you are available. I can often move things around and prefer to schedule things manually rather than have people wait.
8. Earning a Gold Star
Initiative is key. Taking the lead in problem-solving while awaiting my input earns major points. Students, in particular, shine when they approach problems with a plan and seek guidance.
9. Misunderstandings
I’m an open book who cares about others’ opinions. While I may appear neutral, I often hold nuanced opinions which I sometimes do not communicate well. I am terrible at arguing my point (especially if it intuitively seems right to me). It generally works best to engage me in conversations to understand each other better. Let me know if you think I am being obtuse or condescending, I sometimes need a push to see other points of view. Give me time to absorb the criticism, it often takes some reflection before I can respond properly.
Thank you for taking the time to familiarize yourself with how I work. I look forward to a productive collaboration!
Written by Dr. Dirk Colbry, Michigan State University
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.