I’m sitting in a large chain bookstore in a suburb of Cleveland in front of the Sci Fi/Fantasy section, which somehow gives me the cred to blog about how to get more diversity in tech.
For years “people” have been talking about increasing diversity in tech and there has been a lot of organizations and support – i.e. women who code, black techies, girl develop it, etc. This blog post isn’t about them.
This blog post is about the self-proclaimed change agents working within tech…basically those embedded within the status quo who advocate diversity. Firstly, I want to say that this isn’t to discourage or criticize your efforts. Rather this is feedback – because I think regardless of your reasoning, the efforts are beneficial. Secondly, I’m not an outraged feminist, I want more balance in the world that I live in and I’m naive enough to believe that I don’t need to rant with upcase and bangs to be heard. I hope my reasoning is loud and clear enough.
So I’ve met a handful of techie folks who are interested in pairing/teaching/mentoring people like me – “newbies”, “diverse”, etc. (For the record, I don’t have a rolodex of potential mentors, so the ones that have been willing – thank you!) Sometimes it’s hard to take you up on your offer and I want to tell you why. (Yes, I might also have imposter syndrome.)
When I have paired with these folks I find similar patterns of not being open to other ways of thinking. When I’ve given feedback so that we (as in you and me) can collaborate more effectively, I find that many are unaccustomed to having to think in a non-tech jargon way, or think in metaphors. Some seem uncomfortable with teaching strategies (that I find so helpful) such as high level to low level, working outside in or inside out, and visual diagrams. Further, some seem defensive when feedback is given. (A friend told me a story of a time when she was struggling to explain a bug that was happening in safari that wasn’t in chrome , her pair told her to “go back, and figure out how to describe this to me as if you are the lead”. So she tried. At which he replied, “no! wrong! you’re not getting it.”) Basically when these sorts of things happen I question whether us pairing together is ultimately more about me learning or so you can feel that you are doing right in the world.
Okay well I think it’s time for me to declare the obvious – I grew up an only child and I was pretty independent. I also have lived a fairly privileged life (reread the first line of this post). But I say this not to justify my potentially indignant, ungrateful attitude but because I want you to know that I’m independently minded and tough on myself too. I rode dirt bikes as a kid, I learned “computing” playing Where in the World is Carmen Sandiego on my public library’s Apple IIe, my parents immigrated…my parents says that I’m living their dream because I’ve traveled to 25 countries for pleasure, work, sport and political research. But for what it’s worth, I think what my parents did – immigrating to a country in their early 20s not knowing the language, in fact not knowing a related language, is far braver than anything I have ever done. (That’s my bar.)
So when we talk about encouragement and support, what should we be talking about? What are our tools? There are a lot of organizations and efforts to increase numbers. But here’s what I argue, the next generation of coders doesn’t have to live the same life as the current generation of coders. And further, learning to code doesn’t have to be so painful. It doesn’t have to be this idea of “I’m wrong all the time!” (which is what I thought all the time in bootcamp). Here are some techniques that I think are instrumental toward building trust, confidence and collaboration (as individuals and as collaborators):
TDD: Regardless of your opinion of DHH’s opening talk at RailsConf (2014) this year, I’m proclaiming my love of TDD. TDD transforms negative feedback of being “wrong” into “incremental building”. It’s like a Choose Your Own Adventure with repetition (which also aids in learning).
“Yes and”: This was the topic of my first blog post ever and I fully endorse “Yes and” as a sure way not only to collaborate but also to use those creative brain cells to connect things you may never have dreamed. “Yes and” is an improv technique that comedians, like Stephen Cobert and Tina Fey in fact (name drop!), use to build on a skit and make the skit a believable reality for the audience. In a non-improv environment, “Yes and” in itself builds on what is being said. The person who has risked failure bringing up an idea feels good and you are learning how to appreciate how others are thinking by actively having to adapt (and potentially adopt) their ideas. (For the record, as I’m learning to code, aren’t I basically always improvising?) Anyway, at minimum, yes, try to not to say ‘no’.
Echoing back and ask questions: I’m sure we all know how often miscommunication attributes to lack of understanding. Here’s the thing: I’m a newbie. I don’t know all the jargon. (Boy, can I ever grok non-jargon tho.) It’s pretty hard to learn, recall, and act on what feels like a million things at once, like: code libraries, editor shortcuts, stack implication, domain logic, AND being able to communicate! Being open to me echoing back what I think you are saying – this will let you know what I think you’re saying. And try to echo back what you think I’m saying because that tells me what I’m saying means to you, which gives me information and increases the likelihood that I will start to understand your way of thinking, consequently, increasing the chances of picking up jargon.
Use Rules of Thumb: Let’s be honest, it’s easier (and fun) to remember things like: DRY, POODR, MVC, Rule of Three, Single Source of Truth, Arrange Act Assert (AAA). My brain is trying really hard to learn and recall (see #3) and I’d like to be more efficient. Let’s take a simple example. I’ve lived and traveled to countries where driving is on the opposite side to the US. I used to try to remember where I am, what the driving standard is for that place and then look that direction of oncoming traffic. Okay that’s a lot of thinking. Seriously, looking both ways works in every country. That’s it. Look both ways.
Zone of Proximal Development: I learned this from a talented dev at Pivotal Labs…this teaching strategy is: I do you watch, I do you help, You do I help, You do I watch. I think this could be the base for moving on to ping pong pairing – where one person writes the test and the other person makes the test pass. It’s also potentially less awkward because when someone is driving, sometimes I feel like I’m interrupting and vice versa sometimes I feel interrupted. I find ZPD fosters a greater chance of success for a newbie and allows for questions and learning to be comfortable. All of which build confidence!
The main idea here is that I am a person that is new to code, not new to life. How would you feel if all of my examples were technical scuba diving terms? Or the names of the side streets of Melbourne Australia (which coincidentally have amazing art, bars, and cafes)? Or touching your toes as a way to be flexible? Or if I tried to teach you how to write the chinese characters for fire, prisoner and big without teaching you the character for person first? Sure you’d try to learn it because those things are cool right? But you might be overwhelmed, even frustrated eventually. I bet if I took the time to work with you to build a foundation of knowledge that fostered understanding that is in your terms and helped figure out a way to connect those seemingly disparate tidbits of knowledge, you’d learn a lot faster and be able to recall those tidbits the next time an appropriate scenario occurred.
Google is my friend but I’d like you to be too.