Also difficult to tell if a solution actually solves a problem, and elegantly, if there's no spec, because the implementation is noise.

Reply to this note

Please Login to reply.

Discussion

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.