Reputation
For me reputation rather than documentation did the work. What I did, viewed by others. Also my process improvement projects and so on, above my normal line of work. I certainly think that reputation is more powerful and useful for other things.
I did notice a couple of issues with that thought. The first was already covered, that I do document a few things to remember them for review or add them to a resume later.
I’ll add a second: situations I can imagine where ensuring that information is more rigidly documented is a good idea. A co-worker that steals your ideas and presents them as their own. A difficult boss who judges you based on things other than your achievements. Loud meetings where it’s difficult to be heard.
I have some advantages in being seen as capable by others. I’m educated, with a positively-viewed accent in fluent English, white, male, and above average height. I have a voice that can become loud if I force it to. I’m shy and have trouble with social engagement, but I’m also outspoken about testing and happy to share what I know. I also get staff on-side with me and show that I’m working to make them look good, so that I can get leverage for process improvement, which has the side-effect of making me look competent as people who like you will speak of your talents more freely. I think that all works considerably in my favour. I try to use these advantages to make testing better for both the company and the testers. I also benefit personally from them.
I think that’s worth mentioning that for a whole bunch of reasons. Not just for people who may struggle more to prove their existing talent but for people who review, interview or otherwise judge other employees, to keep that judgement more level, to give space to the shy and quiet, time to the ESL speaker, and look beyond the immediate and cosmetic. Just to keep that in check during meetings and reviews.
Documentation
When it comes to documentation I make a lot of notes because my memory is not very good and I’m subject to a lot of anxiety attacks where I get mixed up. I also break down a problem better when I write, I think it’s my rubber duck. My session notes during testing end up as PDFs which I store in bug tracking. I’ll store notes locally also, even if they’re not required on the story. This gives some indication of what I did and why I did it. I also keep scans of notes from talks, lectures or courses, or type them. Everything in OneNote is generated with a date/timestamp and I can add more, so if I need to claw back through what I’ve done I can do that.
I try to only document what I need to, as it’s a cost. So it’s worth knowing what’s going to be in the review so that you can collect what you need to prove what you need to prove. You have to account for the inevitable gaps and failures in the review system, and being prepared sounds like a good idea. Or at least will reduce wasted effort.
I find that a good move is to mention a new idea or project, then pull out a sheet of paper with details or a diagram and point to it. For some reason talking as if it’s performative then pulling out proof has been impactful. I think people are impressed by the reveal and remember it. Or the level of preparedness, perhaps.
Learning to talk about testing, and understanding a little of how the company operates internally, and a few things about management helps, I think. Being conversational in the domain languages of the land.
Then there’s presentation. People react to how people look and talk more than the content of what they say, which is hard to understand anyway. Being clear and concise and using positive language I think is one way to boost the content of what you say. The design, if you will. How to get what you want to be heard to be heard in the way you want it to be heard.
Hopefully that sparks some ideas, at least.