I'm tired of women who tell they don't like to work with women! You're not going to become a better dev by imitating a sexist grandpa. Men won't like you more: event if they didn't like women either, you're still a female... And other women will just try to avoid working with you. Why would I bother to work with someone who judges me before we even start?! 🙄

Spent a couple hours writing a new feature yesterday, and finished it only to discover that somebody lazily wrote the global method that my feature was utilizing. Emailed them and told them that I completed the feature and asked them to fix the bad method. Figured that I wouldn't commit my code changes until he fixed his method. He proceeds to fix the method, and then completely redoes the feature I ALREADY TOLD HIM THAT I FINISHED. He removed me from the backlog story that I was assigned to and did the feature the exact same way I did. Motherfucker I already told you that it was done, you just needed to fix your lazy shitty global method. You did twice the work and wasted my time. If you wanted credit for your work, that's fine -- you could've created a new story to fix your method. Now I've wasted hours of my time writing a feature and then reverting the changes because you couldn't follow directions

WTF chrome/google?! Fuck you & your new designs & features!!
Anyone else got forced new grouping for tabs after the update?! Hey, you can group tabs in.. I know, I just don't want to!! It's fugly and annoying and counterproductive..
It used to work to change flags to not have that 'feature' but I can no longer force the old layout for tabs even with flags.. :/ It's driving me nuts..

When i ask you a question through skype or mail, I expect a fucking answer.
You might just say that you don't know. That is okay.
But we all fucking work from home and I can see you're there. FUCKING ANSWER YOU INCOMPETENT, USELESS, UNPROFESSIONAL SACK OF SHIT.
It is so fucking counterproductive. I fucking hope all the chocolate chips in your life turns out to be raisins.

It is fucking impossible to underestimate these people.

I am seriously jealous of all of you here on devrant, for not having met these washed up twats.

Github 101 (many of these things pertain to other places, but Github is what I'll focus on)

- Even the best still get their shit closed - PRs, issues, whatever. It's a part of the process; learn from it and move on.

- Not every maintainer is nice. Not every maintainer wants X feature. Not every maintainer will give you the time of day. You will never change this, so don't take it personally.

- Asking questions is okay. The trackers aren't just for bug reports/feature requests/PRs. Some maintainers will point you toward StackOverflow but that's usually code for "I don't have time to help you", not "you did something wrong".

- If you open an issue (or ask a question) and it receives a response and then it's closed, don't be upset - that's just how that works. An open issue means something actionable can still happen. If your question has been answered or issue has been resolved, the issue being closed helps maintainers keep things un-cluttered. It's not a middle finger to the face.

- Further, on especially noisy or popular repositories, locking the issue might happen when it's closed. Again, while it might feel like it, it's not a middle finger. It just prevents certain types of wrongdoing from the less... courteous or common-sense-having users.

- Never assume anything about who you're talking to, ever. Even recently, I made this mistake when correcting someone about calling what I thought was "powerpc" just "power". I told them "hey, it's called powerpc by the way" and they (kindly) let me know it's "power" and why, and also that they're on the Power team. Needless to say, they had the authority in that situation. Some people aren't as nice, but the best way to avoid heated discussion is....

- ... don't assume malice. Often I've come across what I perceived to be a rude or pushy comment. Sometimes, it feels as though the person is demanding something. As a native English speaker, I naturally tried to read between the lines as English speakers love to tuck away hidden meanings and emotions into finely crafted sentences. However, in many cases, it turns out that the other person didn't speak English well enough at all and that the easiest and most accurate way for them to convey something was bluntly and directly in English (since, of course, that's the easiest way). Cultures differ, priorities differ, patience tolerances differ. We're all people after all - so don't assume someone is being mean or is trying to start a fight. Insinuating such might actually make things worse.

- Please, PLEASE, search issues first before you open a new one. Explaining why one of my packages will not be re-written as an ESM module is almost muscle memory at this point.

- If you put in the effort, so will I (as a maintainer). Oftentimes, when you're opening an issue on a repository, the owner hasn't looked at the code in a while. If you give them a lot of hints as to how to solve a problem or answer your question, you're going to make them super, duper happy. Provide stack traces, reproduction cases, links to the source code - even open a PR if you can. I can respond to issues and approve PRs from anywhere, but can't always investigate an issue on a computer as readily. This is especially true when filing bugs - if you don't help me solve it, it simply won't be solved.

- [warning: controversial] Emojis dillute your content. It's not often I see it, but sometimes I see someone use emojis every few words to "accent" the word before it. It's annoying, counterproductive, and makes you look like an idiot. It also makes me want to help you way less.

- Github's code search is awful. If you're really looking for something, clone (--depth=1) the repository into /tmp or something and [rip]grep it yourself. Believe me, it will save you time looking for things that clearly exist but don't show up in the search results (or is buried behind an ocean of test files).

- Thanking a maintainer goes a very long way in making connections, especially when you're interacting somewhat heavily with a repository. It almost never happens and having talked with several very famous OSSers about this in the past it really makes our week when it happens. If you ever feel as though you're being noisy or anxious about interacting with a repository, remember that ending your comment with a quick "btw thanks for a cool repo, it's really helpful" always sets things off on a Good Note.

- If you open an issue or a PR, don't close it if it doesn't receive attention. It's really annoying, causes ambiguity in licensing, and doesn't solve anything. It also makes you look overdramatic. OSS is by and large supported by peoples' free time. Life gets in the way a LOT, especially right now, so it's not unusual for an issue (or even a PR) to go untouched for a few weeks, months, or (in some cases) a year or so. If it's urgent, fork :)

I'll leave it at that. I hear about a lot of people too anxious to contribute or interact on Github, but it really isn't so bad!

TL;DR: A new "process" for collaboration between teams was created in order to stonewall requests from my team.

A couple months ago, we created a new Dev team that specializes in writing internal tools. This team was staffed with internal developers, and got a separate manager. The whole point of this team was to collaborate with my dev team so we can both help each other develop tools that the company needs.

One of the developers that was on my team went over to this team while he and I were still working on a big application. For a few weeks, he still worked on this application as he normally would, and we'd sit with each other and work through features together whenever we needed a fresh set of eyes.

Well, eventually his new team got protective of him and created a new "process" for our teams to request assistance from one another. So now instead of just popping over to someone's desk to ask a quick question, you have to send an email to the team and request that you can borrow that particular developer for a question, and then the entire team sits down and discusses whether or not they're going to allow that person to answer your question. Then after a week of discussion, if they decide to allow it, they schedule a meeting for a week later, in which you will get the question answered.

So instead of just spending 2 minutes to ask and answer the question, you have to spend weeks in order to request assistance, and then schedule a meeting.

It's ridiculous, and it's all because his team got protective that he was working with another Dev team. Dev teams collaborate all the time, and work together. My team is constantly helping other teams, and we don't have this ridiculous process. We get asked a question, and we answer it. Simple as that.

Last week, I sent an email for assistance in completing a feature, and didn't hear back. I talked to the Product Owner for the team, and he said "Just send an email," to which I responded that I did and hadn't got a response. He said "Oh....." I then told my boss that this is an enormous bottleneck, and he seemed surprised hearing that this is a bottleneck.

A week passed and today I still hadn't got a response, so my boss reached out to the Product Owner to push him. Finally, I got a response and they scheduled a meeting to answer my question 3 days down the road. So it's going on 2 weeks to get this simple question answered.

Normally I'd just have the other developer come over and help, but apparently they yelled at him the last time he did that.

The issue is that the process was created with the assistance of our "senior" developers, who never work with this other team in this capacity, so they just nodded and smiled and let them put this ridiculous process in place.

Like, get off your high horses. You don't "own" him, he's allowed to collaborate with other teams. This question would've taken literally 10 minutes, but because of your new "process" you've turned it into a 2 week debacle and you've effectively delayed the app launch with your pettiness.

They say that this process isn't intended to prevent us from getting assistance, and that might not have been the original intention of the Product Owner/manager, but it's very clear that the developers on the other team are taking advantage of it and using it as a big stonewall so they can beat around the bush and avoid providing assistance when it's needed.

If this becomes a trend, I'm going to schedule a meeting (which apparently they love to do,) and we're going re-work this entire process, because it's extremely counterproductive and seems to only exist in order to create red tape.

"In practice, UML is a counterproductive tool in software and system design." Gerrit Muller (Gaudí Systems Architecting)

A meeting with an external event organizer, who just so happened be a rather attractive woman. I've never had so many superfluous colleagues (all guys) show up and show off.
That meeting went long.

boubas say aNgEr iS cOunTerpROductIve, yet all I do is essentially manifestation of anger towards biological limitations, fundamental barriers, and death.

If I have to choose one deadly sin, I choose anger and wield it as my weapon.

Big talk to all bros, in a conflict situation, say for example in relationship, sometimes when arguing with significant other, you need to be a bigger person and calm it down when the conflict turns out counterproductive regardless of how much pain you feel or your emotional demands not being met.

As man you have to, no other choice.

A small conflict however are healthy for both to grow the relationship.