The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.
My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #36: Do not avoid technical discussions/information - Boipelo Mawasha
One of the best pep talks I ever received came several years ago by the Director of R&D for a small software company I was working for at the time. I had the interesting experience of being seated in his office each day because were out of office space and I had no where else I could set up my desktop system. It was a blessing in disguise because I got the chance to "pair" dev/test every day for six months. Since I was sitting right across from him in this extremely close quarters environment, he very quickly sized up which technical topics I could handle and which ones were, at that point in time, out of my reach.
One time, when I was really frustrated while looking at paths in the code, I slumped in my seat feeling defeated. He looked at me with a wry smile and said:
"Michael, working with code, writing code, developing large systems… it's not sorcery. It's a skill, just like any other. We start small, and with practice, we do larger things and cover more ground. Marathon runners start by running around the block. We learn by doing, and we learn by making clear what we don't understand. I get that you may be frustrated, but don't give up, and don't try to evade the challenges. Ignorance is the easiest problem to fix, because we can always teach you what you don't know. We can't teach what you don't know if we don't now you don't know it!"
Workshop #36: Take the initiative to bring any conversation to YOUR level.
One of the things I have received comments about when it comes to my writing is that I use analogies. LOTS of analogies. I relate all sorts of things that might seem weird to the topics I'm discussing. There is a reason that I do this; I want to do whatever I can to help make a mental connection with the person who reads what I am writing. Analogies and comparisons to other concepts, disciplines, and activities take a topic and re-frame it so that other people can make a connection with something they are familiar with.
To that end, the next time you find yourself in a conversation where there are technical ideas being discussed, have the courage and the will power to stop the discussion. Rephrase what's being said using analogies of your own, and then ask "do I understand this correctly?"
By making an analogy and directing yourself to think of one, you get the chance to see if you really do understand what is being described. Yes, you run the risk of being wrong. You also run the risk of looking foolish if you are not grasping something that you think should be obvious. I hereby give you permission to take that risk. Yes, show that you are potentially ignorant. Show that you might be foolish. Most of all, show that you respect the developer and the time that they are taking enough to convince both yourself and them that you either do get what is being discussed, or you don't.
I always feared that a developer would laugh at me if I couldn't figure out what they were explaining to me. To date, no developer has ever laughed at me, or made fun of me. In fact, when I've asked "dumb questions", or used my weird analogies to see if I understood a particular topic, the opposite has happened. They tend to stop, reconsider what they are saying, and then try to re-frame the discussion to help ensure that I can understand what is being said or shown.
In my current environment, I work with developers that are in the same building, as well as halfway around the world. Because of this, IRC is one of my best "work friends". The benefit is that I have a record of my chats with the developer, and the ability to review and make sure sure I am genuinely understanding what they say. I also get to see if they understand the analogies I am using to try and make sense of what they are showing me.
Bottom Line:
I know what some of you may be thinking… "hey, that's great for you, but that wouldn't work for me if I did that."
Really? Why not?
Because you feel you can't ask good questions?
Because you feel you won't make sense when the time comes?
Because you're frightened that people might "laugh" at your "ignorance"?
Yep, all of those risks are real… and most of the time, they never materialize. The fact that you are asking clarifying questions, and trying to make sense of the technology in question, shows you are making an honest assessment of what you know. Show that you want to make sure you understand, and that you want to improve the areas you don't understand. In my experience, most of the time, you will get help to do both.
No comments:
Post a Comment