Plenty of TechComm folks use Git for their own purposes (GitHub pages, documentation repositories, etc.). What’s often overlooked, though, is the usefulness Git offers to us as an archaeological tool. Learning even the basics of Git can be the difference between a writer actually getting to practice Agile development with a team, or becoming the last bastion of waterfall in an otherwise Agile environment.
You might think that direct access to production code isn’t worth much if you aren’t a developer. High-level programming knowledge isn’t necessary, though, to make looking through code and its history a valuable tool.
Real time access to changes
Agile puts a lot of emphasis on cross funtionality among team members. Using Git takes you into this sort of territory, since it means that you can be responsible for your own text changes. In a small way, you become another developer.
Making your own text changes isn’t any harder than updating any text file, once you know what text looks like in your project’s programming language(s). Plus, taking responsibility for these changes yourself means that you never need to worry about games of telephone regarding what the text should be. Labels in the user interface, error messages, output, etc. use your exact wording and punctuation the first time, and every time, because you’re the one making the edits.
Git increases transparency
It’s often far too easy for changes to slip past even the most attentive writer. A last-minute change goes through the chute too quickly, or a team member simply doesn’t realize that a code change necessitates flagging documentation changes.
Directly accessing changes in Git ensures that the team’s writer sees every change that’s made, regardless of whether it was flagged for their attention. This can be especially helpful if you work with a team that produces more backend work, or if you’re on an API-centric project.
Minimize the waterfall
If you have to wait until developers follow up with you, you can end up trapped in a miniature waterfall situation. While sometimes this is unavoidable, as implementation details can greatly change documentation needs, seeing changes as they happen helps to make sure that you can start writing before development is done.
It’s sad to say, but the jokes about having to bring developers cookies/brownies/insert-baked-good-bribery-here spring from a nugget of truth: sometimes it’s like pulling teeth to get the information that you need when you need it!
Checking Git first, and using the archaeological tools that I’ll be describing in later posts in this series, lets you glean the “easy pickings” information by yourself. When you come to your teammates asking questions, you can come armed with all of the easy answers already in-hand. It’s incredible how exhibiting a little extra technical know-how, and making sure that your questions are as well-informed as possible, can change a conversation.
This post is part of my Git for Writers series, which I’m posting as an accompaniment to my Git Started: Git for Agile Writers workshop at the STC 2015 Summit in Columbus, OH. These posts expand on some of the ideas I’ll be presenting, since you can’t cram everything on such a large subject into one 45-minute workshop.
If you’ll be at the Summit, I look forward to seeing you there!