tbh but this article is pile of shit. Why would author expect ppl to push themselves through the whole thing to simply understand what it is all about?
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.
> 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)
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.
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.
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.
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?
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.