The trend is, write code, explain how it works later. If developers want to take themselves seriously I think they need to become engineers and practice design and design documentation, including writing specifications and publishing them. This is non-negotiable in many if not most corporate environments. It's not easy but you can't expect other engineers to build other implementations by reading yours. 1. because reverse engineering is a pita and not a proper way to implement a spec. 2. because often, they care more about getting attention for their "product" regardless if others can build on it. 3. they have a head start for funding and attention. Specifications have no wow-factor, and allow others to "take credit" for your work by implementing it. Upside-down incentives I guess.
Discussion
Lol, yes, I naively tried to learn more coding by looking at nostr "examples".
β because reverse engineering is a pita and not a proper way to implement a spec. β
π€£ Hence why some of us exploit it for all itβs worth. Enjoy the show. π€
Also difficult to tell if a solution actually solves a problem, and elegantly, if there's no spec, because the implementation is noise.
There's just something that really bothers me about: to get the benefits of this technology "Simply install my software" "Simply install my software". No, let me see why the technology makes sense. I have multiple layers of DNS Servers that are configured in a specific way for my "data center" I can't be replacing all of my servers with yours. I will NEED to make my own server/library whatever in order to use it an be compliant in my network. Some of us have big labs to run.
that's why complex languages, complex build systems, and complex (read: dynamic linked) libraries don't really help anyone
that's why i say "on a long enough timeline, everyone becomes a #golang maxi"
it satisfies all of these requirements, and you just made it clear why they are so important
I strongly suspect that most people with no concept doc simply aren't knowledgeable enough to write a good one. That's a whole separate skill set, from coding.
Someone with lots of experience is really fast, and they literally "think" the design through, by editing the design docs, so that everyone around them can see them "thinking" in real-time, and collaborate through a discussion of the docs.
That's entirely my argument. That's a skill I haven't learned yet, I like to think I stay in my lane. If you are going to be building "new" and open technology and wish to have adoption I think you need to take the time to learn the skill of design documentation.
I call that agile
You're going to trigger nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z
hahaha
fuck agile
the biggest problem in software dev is architects, people who know how to keep features down to a small enough size that the work can be stable at the prescribed deadline
at 3 years full time i started to get a bit of a grasp on architecture and i feel like i can pretty much be given a job description now, and within a couple of days tell you how long it will take, how many people it will need, and what features probably will need more time
software architecture is like building architecture but different... instead of load bearing requirements and foundations and whatnot, we have feature counts, which have trees of features under them, and you have to elaborate them down to a certain depth to actually get the picture of how much is involved
people and time are the main resources, as distinct from materials and labor and equipment... in my recent work i have also discovered that it can slow things down a lot if it's not easy to coordinate people's days to each other, remote work is really hard to do if people aren't "excessively" chatty about what they are doing because you can only sync up progress and deal with problems if people TALK ABOUT THEM
anyhow
maybe some day soon i'll actually get to architect for something bigger with more people, but for now, just continuing to do my own thing and notice the features and time involved so i can use this info later and to help my own work in the meantime
All the hating on software design, test, and automation, in here, is sort of ironic, since Nostr has almost only produced bad software.
By the third iteration, at the latest, "just hack it, bro" begins to break down and regressions creep out. Sometimes Nostr prototypes don't even work well enough, to demo the concept.