ferroman

trust is very VERY expensive commodity

easy way will always win

"occurs when someone misrepresents, exaggerates, or fabricates an opponent's argument to make it easier to attack."

You literally imagine something that isn't in this text and start theroritizing based on this.

It's called "strawman fallacy", you replacing the thesis and add things that wasn't there to draw plausible conclusions instead of trying to get more information if there's not enough. Calling it "hypothesis" isn't charging anything.

Using prompt as source of truth is not reliable, because outputs for the same prompt may vary

Figuring out how to get others to see what you see but this is exactly the point of article: event if you make them see, they just pretend they don't because it's not in their personal immediate interest to admit you are right or you were right (later)

clinical psychologist's like to invent imaginary scenarios and add something that is not in text, aren't they?

This is exactly my experience (and I've been doing this fo 20 years now). Saw it on every job I had. The usual bs is "we are developing new performance and grows framework" "promotions will happen on next cycle" "we are reorganizing now" "we want to add more transparency" etc. But somehow they always know who to call when shit hit th fan. Don't fall for it. Look for another job once you see this. Looking for new job nowadays take a while and it's better to be employed during this process.

well, that whole post convinced me to not even try any of this lol. gl with community tho.

I’m working on putting together a sort of personal framework for writing technical docs for software projects. This is stuff I'm really struggling with, so any tips are welcome.

That's cool

You can generalize it, but that was a point to make the list more specific. And yes, world is a very different place today. The number of SW engineers doubles every year, so, at least half for them are new. We are engineers and we should try to measure or competency, аnd should try to systematize the things that we use. Of course, this list is not something absolutely universal, but we should at least try think about standards we that we want to meet.

Teams, of course. The goal was to measure it, and we tried to be more specific.

It is relevant, but we try to make it more specific.

Unfortunately, it's much more complex than that. Does your software work? Does your software work right? How quick you can add this to it? How to avoid bugs when you introduce complex change? How to share knowledge with new people in project?

What do you mean? Is it's too low or too high?

Because it allow to keep the domain logic somewhere. In these days people don't do documentation, or documentation is always outdated. Having high-level tests in DSL will do more than just tests - it give you information how your application behave from the user perspective, in more general sense. So you will have less issues when new people join to the project, or when project owner changes. And it force you to focus goal during feature implementation. From my experience, new features often have behavior that are not oblivious, and some times conflict with other application features logic. These tests allow to see these conflicts before implementation.

Domain-specific language of course. I prefer Gherkin.

Thanks for feedback. We decide that more detailed test - more precise measure, but we still try to keep the list as short as possible.

True, but not much team follow these, in practice. We just want to make it more specific and modern.