Central to it being that you consider it unjust. The other option is to take into consideration the perspective of the maintainers, find their feedback to be just and then decide whether you want to contribute in the manner that they expect or you're not ready to do that kind of work.
You don't have to stop loving a project just because you're not ready to put in the work that the maintainers expect you to put in.
When I open a PR without discussing it at all beforehand with anyone, I expect the default to be that it gets rejected. It's fine by me, because it's simply easier for me to open a PR and have it be rejected than to find the people I need to talk to and then get them all onboard. I accounted for that risk when I chose the path I took.
> When I open a PR without discussing it at all beforehand with anyone, I expect the default to be that it gets rejected.
TNG S2E8, "A Matter Of Honor" is about this topic. The submitter introduced risk on the maintainers (the risk being here largely eating up the maintainers time needlessly) by working in isolation and only presenting the finished work without any feedback or awareness from the rest of the participants.
Within the past 2 months, as I've started to use AI more, I've had this trajectory:
1. only using AI for small things, very impressed by it
2. giving AI bigger tasks and figuring out how to use it well for those bigger tasks
3. full-agentic mode where AI just does its thing and I review the code at the end
4. realising that I still need to think through all the code and that AI is not the shortcut I was hoping it to be (e.g. where I can give it a high-level plan and be reasonably satisfied with the final code)
5. going back to giving AI small tasks
I've found AI is very useful for research, proof-of-concepts and throwaway code of "this works, but is completely unacceptable in production". It's work I tend to do anyway before I start tackling the final solution.
Big-picture coding is in my hands, but AI is good at filling in the logic for functions and helping out with other small things.
You can get comfortable with it in 5-10min and after that you will slowly discover that it does absolutely everything you could wish for.
Today I'd honestly suggest to skip learning about git altogether (besides the basics, like branching, staging etc) and just start using lazygit immediately.
I've seen people claim that having a clean git commit history is not worth the time, it takes too long to have it nice etc, opting to just stuff their refactor, renaming and new feature changes into one commit. With lazygit I spend a few extra minutes a day to make it nice and I've gotten compliments for it from others when they review my PRs, because it makes the review much easier.
It feels validating that other people have a similar experience. I simply can't take in that much information. It eventually starts making me feel terrible.
The big issue is that I'm not very good at moderating my intake. I'm a crack addict for information and one small dose will turn into a bender.
My grandparents had a hunting dog. She did not care about "play-time" at all. On the other hand, she got excited when she heard "forest" or "rabbit". Had to be careful with those words.
I think when she wasn't in the forest, she was just waiting to go there again. Instead of ball, it was forest.
well, mine are not hunting dogs. But when we go for a daily walks, they immediately start tracking "whatever" walked there before (living at the city border, surrounded by fields, we have a lot of animals strolling through streets)
Have you been repeatedly banned anywhere? (Reddit, Facebook etc).
The only time I've seen someone have a "tainted fingerprint" was because they were a relentless incel troll who kept getting banned on reddit over and over.
(Not saying this is your case but... I've had people say interesting things on this site at times)
Another part of a good code review is to pick your battles. I used to comment on every little thing. Now I have a threshold below which I won't bother unless it would significantly improve the readability or runtime characteristics. Your coworkers' sanity is just as important as the code to ensure that the team achieves their goals.
If I feel like the author might just not be aware of some "better" (subjectively) way of doing things, then I'll leave a "FYI: could also do this in X way" type of comment.
The “suggest change” feature in github is a great way to suggest nitpick fixes without coming off like a jerk. You actually do the work, and the author can easily merge in all those changes with one click. They’ll avoid making those small mistakes / style choices over time. Also it feels more collaborative and less “do this because i said so”.
My threshold includes time/delay. Knowing that asking for some fix is going to delay this thing getting done by a long time - sometimes days - impacted my caring about certain things. Sometimes it was easier to just make a small fix myself than 'request' it and wait for 3 days just to get something fixed.
Personally, I would prefer someone actually make the suggested fix they're describing - doing the actual code - so I could see it fleshed out. Commenting "use a generatorInterface" to someone who's probably not used it before is less helpful than actually implementing the generatorInterface in the PR and then discussing the actual code. Not always time for that, but if it's never considered, there's never any time for that approach.
tanget: I had a PR blocked because... "use more descriptive variable name" was applied to a 'for (i=0; i<upperBound; i++) ...' loop. The complaint was about using 'i' in the for loop. This was in a test file - the first test file on the project that had been live for 7 months - and I think this nitpick was just a bit over the top. And it wasn't enforced later, just ... someone making a stink over 'a new guy' joining and trying to exert some influence.
Specialising is only possible in larger companies (more than 500 employees). What size have these companies been? A smaller company might want to hire a backend expert, but who might have to jump into front-end for short periods - sort of an 80-20 split. Communication during the hiring process can be suboptimal for a lot of reasons: one person does the job posting, another does the interview, a third actually knows what the job entails, but they were never involved in the process. You have to account for that yourself: request a "get-to-know-eachother" with team members and ask them what they do daily. That's the only way to figure out what your own job will be like. If they are set on hiring you and are a good employer in general, they will not have a problem with a request like that.
> Specialising is only possible in larger companies (more than 500 employees)
I've seen this sentiment a few times now, so I'll weight in and say that I have to disagree. I mainly work for companies smaller than 50 devs, and frontenders do front-end, backenders do backend. I've never witnessed the behaviour described. Maybe it's a USA thing?
My experience is the total opposite. Smaller companies tend to interview you for and assign you to exactly what they tell you you'll be doing. It's the big publicly traded companies with sprawling administration that seem to consistently do the bait and switch thing.
You don't have to stop loving a project just because you're not ready to put in the work that the maintainers expect you to put in.
When I open a PR without discussing it at all beforehand with anyone, I expect the default to be that it gets rejected. It's fine by me, because it's simply easier for me to open a PR and have it be rejected than to find the people I need to talk to and then get them all onboard. I accounted for that risk when I chose the path I took.