This fact, which i do believe to be true, has completely killed my interest in almost all of other peoples projects.
My interest in a project has always been rooted in the idea that its interesting to see other knowledgable people or people learning to attack a problem for themselves. I have really never cared about the "thing that it does." I liked reading the code, dissecting attempts and really learning about the person that wrote it through their line by line decisions.
That is now all gone. The "noise ratio" of slop projects which have none of the previously interesting thought and intentionality have drowned out the "rigorous projects."
It's actually very sad for me, it was something I previously really enjoyed. I am looking for a board that aggregates projects that still have that interesting "human factor" i would subscribe in a heartbeat.
So if you don't want to spend the time doing that, or as is more accurate in corporate settings, the general turnover of the team is high enough that no one is around long enough to build that deep foundational product knowledge, and to be frank most people do not care enough.
This is why telemetry happens, its faster, easier and more resilient to organizational turmoil.
> This is why telemetry happens, its faster, easier and more resilient to organizational turmoil.
I don't disagree with that, I was mainly talking about trying to deliver an experience that makes sense, is intuitive and as helpful and useful as possible, even in exchange for it taking longer time.
Of course this isn't applicable in every case, sometimes you need different tradeoffs, that's OK too. But that some favor quality over shorter implementation time shouldn't drive people crazy, it's just making different tradeoffs.
I think in terms of corporate teams this is the issue a lot of times, people just are not on the team long enough to build that knowledge. Between the constant reorgs, these days layoffs and other churn the no one puts in the years required to gain the implicit knowledge. So orgs reach for the "tenure independent knowledge base.
For the same reason a PR can be useful even if it turns out to be imperfect. Because it reduces the workload for the maintainer to implement a given feature.
Obviously that means that if it looks likely to be a net negative the maintainer isn't going to want it.
If i do the work for a feature im usually already using it via fork, i offer the patch back out of courtesy. Up to you if you want it I'm already using it.
reply