4 ms·

Not at any level? My imagination is reeling—I’m thinking of Cold War era Spy Novels describing siloed groups who don’t know what any other group is doing. Each

Not at any level? My imagination is reeling—I’m thinking of Cold War era Spy Novels describing siloed groups who don’t know what any other group is doing. Each is laser focused on their own tasks and everything is a tactical choice. It’s the great reveal in the Movie adaptation when the separate threads come together and the grand national strategy is revealed. And now I’m also imagining the comedy versions of this genre, where the reveal has no purpose. At some level there is _structure_, and it can be communicated. If for no other reason than to validate the evident structure in code. > “…sitting at the same table as the almighty coding knights? […] Remove documentation…and your products cease to exist, their inner workings left to the imagination of…” The author finished the sentence with “users”, but who are they talking about? Those coding knights and their imagination which sort of parallels my Spy genre example. That said, the article seems a bit naive about the depth and breadth—reads like Ra-Ra.

remoquete 2y ago
Author here. What do you mean by depth and breadth?
- xtiansimon 2y ago
  -1, huh. Take my opinion with a grain of salt. Today I work for a small private firm, but years ago I worked in a corporate job (with tech writers). I drank the Kool-Aid. I believed the work I was doing was important and critical because someone up the vertical decided it was and they hired someone who hired someone who hired me to do a job--its corporate world. The tell for preaching to the choir, what triggered my response, are the hyperbolic strong statements ("products cease to exist", "your business don’t crumble overnight", "failures are dramatic") which sound defensive. The rest of the blog post reads as defining what exists and setting standards, and further explanation of why it's all important. This is the breadth and depth. What I'm not reading are on/off-ramps and shortcuts that all of the developers who disagree about the mission critical position of documentation would regard as sensible accommodations. Today I work in a small firm and we need documentation. What I learned from underpaying small business is documentation is important and has a role (otherwise our small firm wouldn't waste our time on it). But if I took the position argued here, I would be told I was wasting time, that I should focus, get it done, and move on my job tasks. If you're working closely with writers, then you need to believe what they're doing is important without being told. If you don't believe this, then maybe your role does not need documentation (yet? or your group is small enough and people like the job security or you're just overworked, or something else). When I'm working collaboratively and I hear people tell me what I'm doing is not important, I have to believe there is some truth to it. A limit. Good luck in your work.
  - remoquete 2y ago
    > When I'm working collaboratively and I hear people tell me what I'm doing is not important, I have to believe there is some truth to it. No, you don't have to. And that's the whole point.

remoquete 2y ago

Author here. What do you mean by depth and breadth?

xtiansimon 2y ago
-1, huh. Take my opinion with a grain of salt. Today I work for a small private firm, but years ago I worked in a corporate job (with tech writers). I drank the Kool-Aid. I believed the work I was doing was important and critical because someone up the vertical decided it was and they hired someone who hired someone who hired me to do a job--its corporate world. The tell for preaching to the choir, what triggered my response, are the hyperbolic strong statements ("products cease to exist", "your business don’t crumble overnight", "failures are dramatic") which sound defensive. The rest of the blog post reads as defining what exists and setting standards, and further explanation of why it's all important. This is the breadth and depth. What I'm not reading are on/off-ramps and shortcuts that all of the developers who disagree about the mission critical position of documentation would regard as sensible accommodations. Today I work in a small firm and we need documentation. What I learned from underpaying small business is documentation is important and has a role (otherwise our small firm wouldn't waste our time on it). But if I took the position argued here, I would be told I was wasting time, that I should focus, get it done, and move on my job tasks. If you're working closely with writers, then you need to believe what they're doing is important without being told. If you don't believe this, then maybe your role does not need documentation (yet? or your group is small enough and people like the job security or you're just overworked, or something else). When I'm working collaboratively and I hear people tell me what I'm doing is not important, I have to believe there is some truth to it. A limit. Good luck in your work.
- remoquete 2y ago
  > When I'm working collaboratively and I hear people tell me what I'm doing is not important, I have to believe there is some truth to it. No, you don't have to. And that's the whole point.