Search This Blog

Tuesday, June 6, 2017

Doc as Code

Wow, I was SO off-base. I read and have to say, I had a TOTALLY different definition of "Docs Like Code" so thank you for posting this.

Maybe this is called something else, but I haven't found the buzzword yet.

I was thinking along the lines of the technical writer controlling the content much like a programmer does for the system they create. If someone wants a change to the way the system works, they have to log a request to have the change made and then the programmer has to evaluate how that change would impact the system. I had also seen requests from customers that requested adding a value to a drop-down on a single screen turn into changing many more screens. The reason was because the customer had no idea that drop-down was used on more than that single screen - that was their "pain point" where they couldn't select the value they really wanted to see.

Thus, for documentation, if someone wanted a wording change or a different style, they would have to log a request, I would evaluate the request to identify the impact. They may have been suggesting a change to a snippet that was used in many more places. And I wouldn't have expected the customer to know that - that would be my job, just like it would be the programmer's job to figure out where their suggestion impacts the system.

No comments:


I'm not familiar with any of the tunes Burn the Priest (also known as Lamb of God) are including on their upcoming album of cover tunes,...