This is a guest post by Rachel Kibler.
The best developer I’ve ever worked with is an iOS developer named Brandon. I worked carefully to build a strong relationship with him, but he is also a friendly and hard-working person who cares about people and work.
Our mobile releases were big. And with the way our app worked, data in our test environments couldn’t readily match the richness and variety of production data on personal devices.
We found a bad bug when we released our beta. It was really bad, and we hadn’t seen it in our test environments or on test devices. Transferring production accounts to test devices worked, but that didn’t import data that was encrypted on the device, which seemed to make a difference. We were stuck.
For a week, we tried loading up our test devices, trying to reproduce the issue. My production account showed a bit of the problem when transferred to a test device. Reluctantly, I handed over my production account, with all of my emails and text messages, to multiple team members.
They still couldn’t figure out the issue. But Brandon texted me late one night, telling me that he wanted to show me something the next day.
His big reveal was git bisect. This command performs a binary search between two states of code, asking you whether selected commits are “good” or “bad.” It changed everything.
Brandon walked me through how to use git bisect, finding good commits and bad commits, and narrowing down where the offending commit was. My week-long struggle took about 20 minutes to figure out when it had gone wrong, though the commit was gigantic, and it didn’t tell me where it was bad. Brandon took it from there, going through the commit carefully to find the bad code.
Thanks to Brandon, I had a new tool in my arsenal to use in the future.
Brandon taught me other technical things, too, and he viewed our relationship as a partnership, with each of us helping the other to be better and do better. I became a better team member, and I learned things that made me more efficient at finding issues. He learned to relax a little, and he trusted testers more readily.
I am not a patient person. The thing that frustrates me most about writing code is having to spell everything out. Why doesn’t the computer just know what I mean? As another developer who’s also brilliant said recently to me, I can’t just say, “Get a Mountain Dew from the soda fountain.” I first have to describe a cup and its functionality, as well as explain what a soda fountain is, where it can be found, and how to use it.
This frustrates me. I lose patience with code quickly, and I’d much rather find the ways code is broken than write it myself. One of the big things I’ve learned from developers is not the technical stuff, but the attitude of being patient and learning to live in frustration and confusion.
I would be disheartened all the time if I had to stare at the same piece of code for hours at a time, combing through forums for answers, hoping for a stroke of genius. Working alongside developers has made me more compassionate for them and their work, and it has encouraged me to be more patient with myself and my own learning.
We all learn, all the time. If we aren’t learning, we’re stagnating. But learning can happen in many ways, and sometimes, just being around people who work hard in different ways from us can be enough.
My relationship with Brandon was cultivated over several months. We went for walks a few times a week, ate lunch together, and built up a friendship as well as a solid professional relationship. We talked through technical problems, and I showed an interest in the challenges he was facing, even if I didn’t understand the details. And that made all the difference.
Building relationships takes time and dedication. I take time to get to know my developers, their style of work, and their attitude toward life. Once that trust is built up, great things happen.
Rachel Kibler is a software tester for 1-800 Contacts. She can be found on Twitter (@racheljoi) and on her website at www.racheljoi.com.
