I (m24) am in a graduate level operating systems class. Our final project is to build a small teaching kernel with our own process scheduler, memory manager, inter process communication mechanism, and some basic user space tools.
My partner (f22) and I split the work early. I would handle the process scheduler and the low level CPU context switching, and she would implement the inter process communication subsystem. We agreed on it at the start. I built a Multi Level Feedback Queue scheduler because it was listed as a recommended baseline in the assignment sheet.
Last week she told me she was getting unpredictable message latency in her inter process communication layer because the wakeup rules in my scheduler caused threads to drop into lower priority queues under some load patterns. She explained, really confidently, that the issue was not in her code but in how Multi Level Feedback Queue works as a design. She said we should switch to a proportional share scheduler, specifically a stride based proportional share scheduler, so message passing threads wouldnt get stuck with weird priority changes that made her throughput analysis kind of meaningless.
I honestly thought she was over thinking it. This is a teaching kernel, not production. I told her that switching the entire scheduling algorithm this late could break invariants I had already built around, especially the context switch routine and the accounting stuff. She pushed back and said proportional share scheduling is actually simpler in a bunch of cases, and that my code was "artificially constraining" the rest of the system.
She went and built her scheduler anyway over a weekend and sent a pull request. She included benchmarks, some diagrams of expected fairness behavior, and notes comparing our current latency graphs with the stride ones. I didnt fully read everything, I just skimmed and saw it touching almost every scheduling structure.
I rejected the pull request. Then, because her changes altered structures my code depended on, I force pushed my branch to the main repository to "reset things". She messaged me right away saying that force pushing to main in a group project is not ok and that I had basically wiped two days of her work.
I told her that if she wanted to "experiment" she should have done it in a feature branch and not replaced the scheduling subsystem without any agreement. She replied that she did use a feature branch… and that submitting a pull request is literally how you open a discussion, but I shut it down without answering the technical parts at all.
Now she is barely talking to me and only sends short little updates. Some classmates told me she is one of the strongest systems programmers in the cohort and that her stride scheduler was actually a good call for inter process communication predictability, and yeah that made me feel a bit weird. But I still feel like rewriting a kernel subsystem right near the deadline is kind of reckless.
YTA. Why are you objecting to trying something to see if it functions better? If it doesn’t, you have your answer.
Would you feel similarly insecure and defensive about these suggestions if it was another male “confidently” telling and asking you the same?
You seem to have issues with a woman who is confident and knows what she is doing. Best work on changing that mentality.
It is not about that. It is overconfidence, i feel like she cares more about the vibe of being perceived as a strong programmer but isn’t. It’s like she treats everything like it is social life because she is overly social.
YTA. So you don’t know how Git works and ruined all her effort because you were insecure about things changing last minute so instead of trying something new or even reading her full work like a proper partner in a group project, you were like naah I don’t want it and just did that?! And when you heard how good she is at what she does and that she was right, you felt weird?! Weird how exactly cuz you’re still wondering if you’re wrong so seems like you’re just upset she corrected your work
I know how git works I wanted us to consider main how it was at that point and flatten the structure so old feature branches do not confuse us.
YTA. I’m not in graduate level operating systems, but on the process and collaboration side:
You’re the one who violated norms. Rejecting a pull request is fine, but force pushing to main and erasing someone’s work after they followed proper workflow crosses a line.
She took a risk by implementing a big subsystem late. That can be questioned, but she still kept it in a branch and used a PR. You overrode the collaborative process in a way that created loss of work and damaged trust.
That said, I’m a little confused by the writing perspective here. If you rejected the pull request, she didn’t replace anything? Then you say she should have used a feature branch and then agree that’s exactly what she did?
>I told her that if she wanted to “experiment” she should have done it in a feature branch and not replaced the scheduling subsystem without any agreement. She replied that she did use a feature branch… and that submitting a pull request is literally how you open a discussion, but I shut it down without answering the technical parts at all.