@ Silberengel
2024-10-09 12:27:53
## Why waste time, looking at other people's stuff?
I get this question a lot, on Nostr, and it feeds immediately back to the next question: *Why don't you just build your own client, if you're so smart?*
This was a completely new question for me, as I'm used to collaborating with at least one other person, even when doing FOSS stuff. (No, this isn't my first such project; we just used to call it "volunteering" and "sharing the code", which sounds way less glamorous.) It never occurred to me, that a habit of collaboration and interaction was some sign of my ignorance and incompetence, or somehow proof that I can't vomit up "Hello World!" in 5 different programming languages.
I also made the deadly political mistake, when I entered the Nostrsphere, of refusing to call myself a "dev". For me, "dev" is a special title, given to someone doing a specific type of programming (fiddling with GUIs, mostly, which I've only done occasionally, as a sub), whereas the types I've done are "test automation", "development operations", "database management and data curation", "requirements engineering", and "application administration". Because it's so much easier to find someone interested in building a GUI, rather than building AnythingElse, I tend to slide into AnythingElse and it eventually became my professional specialty to be the Girl Friday of every project.
But, in Nostr, there is no AnythingElse category. There are only (GUI) client devs and AllOfTheIdiotsWhoMustBowDownToTheDevs. Which merely doubled my instinct to distance myself from the term. I do not want to join some cargo cult and be pedestalized and regarded as some sort of superhuman everyone owes fealty to, in return for raining GUI presents down on my loyal subjects.
Software engineers are simply people who are skilled craftsman, not gods, and it is fair to point out that some are more skilled than others. It is also completely fair to criticize their products, report bugs, and wonder aloud at endemic low-quality.
Which brings me back to the initial question:
## What does the inquisitive dev know, that the others don't?
1) You learn an awful lot about an awful lot, by looking at specs, reviewing code, and trying out various implementations of concepts you are already familiar with. There are, in fact, n number of use cases for every event type, and I've seen so many of them, that I can conjure them up, or invent new ones, on the fly, rather than wasting time inventing similar events.
2) They don't have to explain their concept to you, later, when you interact. Each interaction brings you closer to parallel-levels of knowledge, which raises the signal-strength of the interaction, and widens your own knowledge base, for interacting with third parties.
3) You are increasingly-likely to contribute code or perform some other more-advanced task, for other people, as you don't face the hurdle of adjusting to a new repo or unfamiliar language, while being less-likely to merely fork-and-ignore because you have a standing business relationship with the other developer.
4) If the other dev stops maintaining the repo, you'll be inclined to continue on your own. You may even eventually receive administrative access, rather than needing to fork, as they trust you with their stuff. This means that the risk of the repo becoming abandoned falls, with each active dev snooping around it, even if that is not their primary project.
5) It helps you determine who to focus your energy on interacting with, further. Is this person new to software development, perhaps, but has some interesting transfer-knowledge from some other branch, that has resulted in a surprisingly novel concept? Is this person able to write very clean code, so that merely reading their code feels like mental training for your own craftsman's toolbox?
...and many more reasons, but this is getting too long, so, let's just cut to the chase.
## What does a craftswoman want?
But, this still doesn't answer the question of my private motivation. Why do I want to gather all of this knowledge, from those further ahead, than I?
I think Nostr has long moved past the initial stage, where mere speed was of the essence, so that one npub could _finally_ post a note and have it appear on the other npubs' client. That must have felt like a miracle, but it increasingly feels like a disaster, as the steadily-rising complexity of the Nostr ecosystem causes haphazardly-structured and largely-unexamined code bases to begin to atrophy, or result in developers running around at an exhausting speed, with their bug-extinguishers, to put out fire after fire.
I think the time has arrived, for a different kind of development. Maybe even for a different kind of developer. Not replacing the experimentalism that made Nostr fun, but adding the realm of production-quality software engineering. The sort of software development that requires relay administration, testing, support... collaboration, interaction, maybe even someone who does AnythingElse.
I want to build useful, elegant products people enjoy using and feel comfortable relying on. I want them to use them, naturally and happily, to accomplish tasks they consider worthwhile. I don't want them thinking about me, while they use it. The craftswoman should never be greater than her work.
I want them to feel free -- nay, be eager! -- to give me both positive and negative feedback. My assumption is _always_ that our production is imperfect because we are imperfect, so you do us a favor, by pointing out where we can improve. That's why we wish to integrate a feedback form that produces ngit issue events, putting your questions and comments straight on our board.
And there will be an AnythingElse person, reading that board, and responding promptly, rest assured.