This is a rant post, similar to the previous one I had on the old blog about certain opinions about code style. This post is more particular to pet peeves when working in a group, which has become many times more relevant in the past year for me1.
This will probably just sound stiff and never fall onto the right ears, but I wanted to have it written down somewhere. It's possible that I need to get better at group management or conflict resolution skills.
It's also important to qualify these statements: these of course don't occur with every group project and group partner I've worked with, but it's shocking how often this does happen. And most of the offences are alright every now and then, especially when you know it's out of character for a groupmate; but when it's a common problem, and especially if I try to mention it once or twice -- that's when it becomes a pet peeve.
Breaking up on promises. Not just once or twice (we're all busy with school and life, so unexpected things will come up from time to time), but repeatedly. Saying that you'll do something, by some deadline, and not completing it. Or, when confronted, say that you'll change for the better; and no change follows. Repeatedly. And usually without any reason. It makes a person's words lose credibility.
Bad response times -- e.g., a few days, when the project is due in a day.
Work is always too little, too late. If you're taking this course, if the proposed code split was supposed to be 50/50, you should probably contribute more than 10% of the final code. I have reason to believe2 that I've written over 80% of a large majority of group projects in the past few years, including groups of more than 2 people. This is especially true on parts related to the class material -- if you're only working on the straightforward parts that have nothing to do with the course, is it fair to say you've learned the class material?
With virtual work sessions, it's hard to keep people accountable. If they're not doing work when they're supposed to, then you organize virtual live work sessions. And then they sit there on the call, not doing anything, not giving a reason why -- just following you as you code. I think the reason may be that they're waiting for instructions -- but I'm in the same boat! Choose something from the to-do list we've generated, and go with it! I'm not sure what I should be doing either, but that shouldn't be a good reason to simply stop work when there's a mass of work remaining. If it's a weakly-defined mass, then we can discuss how to narrow it down. But stopping altogether is not productive.
Copying code. Usually it's not harmful in and of itself, but the major problems are:
Lack of citation. If a teammate wants to find out where the code comes from so they can get an explanation of what it does or how it works, they may not be able to find it. This could also potentially get you into legal trouble or a grade nullification.
Inconsistency of code style. Makes your code harder to read.
Don't understand the code at all, and can't explain it to me when I ask. At this point, it hurts more than helps. Usually causes writing a lot of extra boilerplate code so that the inputs and outputs of the copied code are in the exact same format as in the example it was pulled from, when a lot of it is probably pedantic and can be done away with if you understand what you're doing.
(This and the following bullet point are also illustrated in the blog post linked above, but are too common during group projects that this list would be incomplete to leave them out.) Bad or inconsistent code style. Even non-standard code conventions are okay, as long as there is a convention that is stuck to. A lot of the time this comes from copying code. A lot of the time it can also be fixed by the IDE. Consistent code style is not a nicety -- it makes code more legible, and thus it makes you more efficient.
Low-effort naming. This includes variables, git commits, filenames, etc. Along with a lack of commenting, it takes way more effort than it should to understand the intent of a variable or function. A consistent naming scheme would be best, but too often names are hardly even coherent. (This is what I called "implicit documentation" in the previous blog post.) Git commits are especially prone.
Asking debugging questions without context. I'm not a mind reader, even if we're working on the same project. When you ask about "that image you sent" without additional qualifiers, when we're talking about an image processing project, I don't know which image you mean. Sometimes, strangely, when asking for more information, the response is, "oh, never mind." It doesn't have to be too specific -- when was the image sent? What messenging platform? It's the same as if you were asking in person, or on Stack Overflow (as some users know too well): you can't ask the question as it appears in your own head, but provide the necessary level of context so that the question can be answered in any specificity at all. Another common scenario is that I get asked a question, and I send a response making fairly general assumptions, and then there's a follow-up with "oh, but I'm using [some obscure setup]." This changes the focus of the question, and this might happen a few times over. Why not provide all the details at the start?3
Complacency in a poor developing environment (if you're supposed to have been working on software projects for years). For example, saying you can't debug some strange error when GDB isn't even installed on the machine. Or saying you can't run a debugger because MacOS won't let you. And then continuing in vain for hours because you reject the tried and true tool that could solve the problem in an instant? There are most definitely workarounds to issues like MacOS's security restrictions, and being familiar with them is necessary to be productive with software projects. There's always a learning period, but not encountering the standard debugging toolkit for the general language-of-choice in three or four years of computer engineering classes? It's not inexperience, it's ignorance.
Hardcoding a testing setup. Again, it's okay to have a few hardcoded values set up. But when the whole test setup is hardcoded, scattered piecemeal throughout the codebase rather than in a neat configuration block, then it gets out of hand. Changing the configuration means scrolling through dozens of lines in the codebase to edit a single value. Worse is if the configuration includes an absolute path to your test file (which are pretty much never necessary). Even worse if it's committed to GitHub.
Poor report style or not working on the report. English grammar and style are important, too!
Keyboard shortcuts. This is more harmless, but clicking on File -> Save is awful slow.
Photos of the screen in lieu of a screenshot. Again, mostly harmless. You're already at the computer, so it takes less effort to use the provided screenshotting tool! And the resulting image will be smaller and clearer.
Footnotes
1. Two major reasons: 1) It's junior year, which means many more elective, project-based courses; and 2) with the pandemic, we've shifted away from assessment-based courses to project-based courses.