Updated: Turns out there is already someone making this point much better. Check out The Selfish Programmer (Justin Searls) (youtube.com).
In the wake of the recent xz/liblzma backdoor vulnerability, we find among this chaos a phenomenon that has been overlooked and sometimes in denial for many programmers: Burnout. It is one of the factors allowing this exploitation to happen, and no one so far presents it better than Rob Mensching's A Microcosm of the interactions in Open Source projects (robmensching.com).
Please give support and shout out to xz/liblzma maintainer Lasse Collin, and good-heart Open-Source maintainers in general.
However, burnout will not be the main focus of this article. Instead, it will act as the reminder that when the right time comes, we as programmers are entitled to follow the principle of "The Selfish Coder" to tackle burnout.
What is it?
I'm not sure whether such principle exists elsewhere, with same or different definitions. So, if you feel offended by my re-inventing something, sorry, not sorry (in selfish mode while writing this). I will make it short where it revolves around:
The codes that come into your control should first serve yourself.
Your employments, your contracts, your clients, your teams, your jobs, etc. can say that the codes that you create, borrow, change, or delete do not belong to you at the end of the date. That can be undeniable, but we are not talking about ownership here.
You have the obligation to do your jobs, solve the problems you are assigned, and create the features that meet the requirements you are commissioned to. Therefore, to serve your duties, you are entitled to question the usefulness of the codes presented to you, whether written by yourself, your juniors, or your seniors, and do whatever your abilities and ethics allow to make the best out of these codes.
What is it NOT?
Being a selfish coder does not mean being defensive to feedback.
If your maintainer returns your pull request with feedback to improve your codes, do so when you find the feedback is justified and, once again, makes the codes serve you better. Otherwise, refuse to perform the requests that can alter the codes to the state that you feel harder to work with it later (if you are required to do so). That may include:
Writing unnecessary comments when such ideas are already clarified by the codes.
Asking to return a commented codes that I found noisy and deleted along the way.
Refactoring to expose a public API that no-one uses.
Being a selfish coder does not mean writing unreadable codes.
Whoever (include yourself) says the codes you write are too hard for anyone but yourself to understand is lying. The codes would be hard for everyone, including yourself. Your first priority is not to make the codes understandable for other people. Your priority as a selfish coder is to make the codes understandable for yourself, especially for your future self. You cannot expect your codes readable to other coders if you yourself find it hard to read them, right?
Being a selfish coder does not mean being uncooperative.
One rule for a selfish coder is to help themselves first before they can help others. This is the same as not jumping in the water to save a drowning person when you do not know how to swim. Being a selfish coder does not mean to say "Yes" all the time, but to say "No" at the right time. And more than we may expect, the selfish coder can be more willing to cooperate, mentor, or support when they see such act can also solve their own problems or bring them certain benefits.
Being a selfish coder does not mean burnout.
Finally, let's talk about burnout. Burnout is the mental tiredness after you work hard to do something, especially when you find no value in it. A selfish coder does not want to give in working on anything that in turn does them no good. They seek tasks that bring benefits to them, hence also giving a healthy dose of sense of accomplishment. Furthermore, acting as a selfish coder in the long run can help one improve their own self-awareness, the skill that makes them more resilient to toxic interpersonal behaviors and exploitative social tactics.