> but had thought of it as some kind of failing. Your comment makes me feel better about it. I do it as well; I think organizationally it's a failure, but it i

> but had thought of it as some kind of failing. Your comment makes me feel better about it. I do it as well; I think organizationally it's a failure, but it is an effective personal coping mechanism. In other words, it's bad for the organization that their codebase isn't really a melting pot of different developers' ideas but instead, if you zoom in enough you notice that it's really a series of hundreds of small fiefdoms each with their own slightly different customs and semantics. This is what creates that software bureaucracy. For employees though, it works. It's about the only way that I really derive any sense of satisfaction from software engineering. When I can stand back and say yes, this package is mine, I made it and I will take care of it. With the melting pot packages it feels more ambivalent; some portion of the code is mine. Probably not the clever bits, they're probably bugfixes. So I don't have enough mindshare to get satisfaction from achievement, I don't have the satisfaction of at least solving one of the hard problems. No, those people have come and gone, and I'm left with the shale oil of satisfaction: fixing bugs, writing unit tests, and adding documentation. Like shale oil, the joy it brings is very close to the effort it takes to extract it. This isn't the "I accidentally hit an oil vein while digging a garden" joy of really getting to solve something. Some people derive a lot of joy from doing things that help others (like unit tests, bug fixes and documentation); I'm unfortunately not one of them. Sometimes I wonder if it isn't at least partially because it's so hard to feel the impact. I know HN hates the idea of gameification, but I wonder if it couldn't be applied to good effect here. If someone could make an integration with CI, and with major editors, we could scrape data regarding how many times your unit tests have caught bugs, and how many times your function/class documentation has been viewed. There could be a leaderboard for people that are into that. But for me, just the raw numbers is enough. "Unit tests you have written have exposed 137 bugs in PRs, and documentation you have written has been viewed 138,476 times" would be a huge motivator. It gives me that warm and fuzzy "I actually productively contributed" feeling. Right now I get nothing back; I have no idea if anyone has ever read the documentation I spent hours writing, or if my unit tests have caught any issues.