Eclectics Unite: Leverage Your Diverse Background

by Sijia Wu

In her talk at RubyConf 2022, Sijia Wu emphasizes the value of leveraging diverse backgrounds in software development. She shares her unique journey as a software developer at PayPal/Braintree alongside her roles as an academic translator, snowboard instructor, and drummer in a rock band. Sijia invites attendees to explore the connections between their varied experiences and coding, challenging the notion that only technical skills matter in tech.

Key points covered include:

- Insecurity and Self-Doubt: Many developers struggle with feelings of inadequacy, especially if they don’t code outside of work, leading to insecurity about their roles.

- Transferable Skills: Sijia highlights how her work as a translator requires quick learning and problem-solving, mirroring the demands of software development. The ability to digest technical information and maintain consistency in style is paramount in both fields.

- Teaching and Pair Programming: Drawing parallels between snowboarding instruction and pair programming, Sijia explains the importance of clear communication, feedback mechanisms, and empathy in teaching techniques and coding practices.

- Creative Processes: She compares playing drums in her rock band to test-driven development (TDD) in software, illustrating how iterative practice leads to improvement and skill mastery—a core principle in coding.

- Valuing Diverse Narratives: Sijia encourages developers from non-traditional backgrounds to recognize the importance of their unique experiences, arguing that they should not underestimate their diverse skill sets.

- Reassessing Competency: Instead of questioning their coding hours, she urges developers to focus on their effectiveness in delivering results and their enjoyment in collaboration.

Sijia concludes with a call to action for audience members to share their own narratives, whether technical or non-technical, fostering inspiration and mutual support. She reinforces that one can be a competent developer not solely because of formal coding experience but also due to the rich perspectives contributed by diverse professional journeys.

00:00:00.000 Ready for takeoff.

00:00:17.100 Hello, and thank you for coming to my talk. Did anyone fly in from the Houston Hobby Airport?

00:00:22.560 A few of you? Okay. I did too, Monday late evening. As I came out of the gate, I was looking for the exit and walked past the bookstore.

00:00:30.480 I saw this book and thought, 'How did you know that is exactly what I'm here for?' I was freaking out because it's my first time ever speaking at a conference to a live audience, and the book was just there with its calming presence, not judging.

00:00:54.300 I gave it a five-star rating on Goodreads for good karma. Anyway, my name is Sijia, and I'm currently working as a software developer at PayPal/Braintree. That's me on a good hair day.

00:01:05.400 I work on a Ruby team, writing Ruby daily. I've exclusively worked with Ruby throughout my entire development career, which is pretty rare, or so I've been told. This is like the one conference where I can somewhat successfully pretend to know what I'm talking about.

00:01:15.960 In addition to writing Ruby for work, I've done a few other things. I'm an academic translator, a snowboard instructor, and sometimes a bartender at events and fundraisers. I also play the drums in a rock band and occasionally take on vocals. I've previously worked as a layout editor and in customer service and have taught languages online.

00:01:27.720 That was a non-exhaustive list, and a lot of these things might not seem to have anything to do with software development at first glance.

00:01:36.960 I have a confession to make: I don't write code outside of work. For the longest time, I felt ashamed to admit this. It's been one of my biggest sources of insecurities and self-doubts, and I've wondered if that simply makes me a less effective developer.

00:01:49.680 When you work in tech as a developer, you often feel like you should constantly hone your skills, keeping them sharp to stay competitive. I look around and see people building impressive personal sites and apps, making contributions to open source projects in their spare time. A lot of you here are probably doing that, and sometimes I can't help but compare myself to them and feel inadequate.

00:02:04.200 Apparently, I'm not the only person who feels this way. Many people wonder if it's bad if they don't code outside of work. Some don't program in their spare time and wonder if that makes them bad programmers.

00:02:17.340 It's not just about not coding outside of work; I feel like the absolute amount of time I've spent strictly writing code has been less compared to other developers I know or work with. I haven't always been in software; I went to school for electrical engineering, which is very much a technical discipline, but our curriculum was mostly focused on signals and circuits, not heavy on programming.

00:02:32.760 After switching to software, I've taken breaks and worked a variety of non-technical jobs, some of which I still do today on a freelance contract basis. Perhaps some of you have taken a similar path or have switched to a career in software development from different roles or industries, and you might have non-technical experiences that seem irrelevant on your resume.

00:02:46.800 But are those experiences really as irrelevant as they might seem? As someone who does various things, I've been amazed by the similarities and connections between what I do as a software developer and my seemingly irrelevant non-technical experiences.

00:02:55.800 There are skills that are absolutely transferable; there are concepts and patterns that are similar. I would like to share some of what I've noticed with you in this talk today.

00:03:08.340 I've been working as a freelance translator since 2015, primarily with the Chinese-English language pair. I translate scientific reports and research articles into English so my clients can submit them to international journals and hopefully get them published.

00:03:22.560 The common perception is that the skills required in translation are mostly linguistics-related; you need to be fluent in at least two languages to translate. While this is true and necessary, many other skills go into doing the job.

00:03:33.600 For a while, I noticed that translating somehow feels similar to coding, but I couldn't pinpoint in what ways until I had the idea for this talk. So, I started to examine the relationships, similarities, and connections between coding and the other things I do.

00:03:46.620 I realized that translating and coding require many common skills. Both activities necessitate that you become an expert in a certain topic or concept in a short amount of time. In tech roles, I'm sure a lot of you are familiar with this: you often start working on a project with little knowledge about it initially.

00:03:59.160 This is even more pronounced when ad hoc tasks are thrown at you or during incidents that you get pulled into while on call. You're not expected to know everything about what you'll be working on before you start; however, you are expected to familiarize yourself with the project quickly and understand the context using all resources at your disposal.

00:04:10.800 You gather, digest, and evaluate information systematically. We're talking about a significant amount of information, which could include the codebase, commit history, logs within the system or on external monitoring platforms, descriptions or comments in JIRA tickets, Slack threads, email threads, and much more.

00:04:26.400 Sometimes you might even have to look things up in your internal documentation or Google, or just ask a lot of questions. Actively acquiring, processing information, and making informed decisions based on that information are essential parts of the development process.

00:04:40.080 This entire process of approaching and solving problems is quite similar in translation. You're not expected to know everything before you start translating an article, especially journal submissions, which could contain never-before-published findings at the forefront of their respective fields and disciplines.

00:04:58.260 This realization shifted my perspective because I would often beat myself up thinking I should know something already, or questioning why I didn't.

00:05:09.600 Many times you're not expected to know everything going into a new task, but you are expected to learn and pick things up as you work through problems. In translation, you are expected to look up and verify terminologies, ensuring you use the most appropriate ones.

00:05:20.520 This is similar to deciding the most suitable data structure or method to use when coding. When collaborating on a translation task, maintaining style consistency is crucial, just as style consistency is vital in codebases.

00:05:32.520 Furthermore, when translating, you need to understand the logical relationship between information pieces to organize and present it in a manner that makes sense in the target language.

00:05:41.640 This process, as well as the skills involved, are remarkably similar in both activities.

00:05:44.340 Another thing I do is teach snowboarding. I am a freshly certified level one snowboard instructor and I work with beginners, guiding them from their first day on snow to eventually being able to safely go down a blue run on their own.

00:05:53.760 A blue run is a slope typically angled between 14 and 22 degrees, which is ideal for those just starting out. I've been surprised by how much crossover there is between teaching snowboarding and coding, specifically pair programming.

00:06:03.960 Teaching snowboarding, or formal instruction of any kind, in pair programming involves communicating technical concepts such that people can understand. You might have to break down the information into digestible chunks and demonstrate with examples.

00:06:16.640 In both activities, you are either providing or receiving immediate feedback, which can either be informative or evaluative.

00:06:21.420 Feedback could be informative where you point out what you're observing, like telling a snowboarder they might be leaning back when their board is pointing downhill. In software, we can see our code, but we may sometimes lose sight of the bigger picture.

00:06:32.640 Thus, it can help to receive feedback such as, 'This method is 30 lines long and has six levels of nesting.'

00:06:38.640 Feedback could also be evaluative when we judge something against established coding standards or best practices.

00:06:41.760 In snowboarding, you might hear that your range of motion was insufficient to build enough energy for your ollies.

00:06:44.880 In software, someone might say they can't discern what a variable is being assigned to because that part is unclear.

00:06:49.560 Then, there is corrective feedback, where we point out what's counterproductive and suggest ways to improve. When I teach snowboarding, it's not just about telling my student what to do, but rather showing or suggesting things they could try.

00:06:56.280 For instance, I might suggest playing with weight placement over the board to gain control rather than tensing up all leg muscles, which is less efficient and can lead to quick fatigue.

00:07:02.520 This principle applies to software development as well because you might tell a pairing buddy something like, 'We've repeated this chunk multiple times; we could maybe refactor and dry it up.'

00:07:06.240 Or, you might suggest moving a calculation outside a loop to improve method performance.

00:07:10.560 Lastly, I want to emphasize empathy. Everybody talks about empathy, but it can't be stressed enough because people sometimes forget what it's like to be a beginner.

00:07:15.060 Diving into the codebase for the first time can be overwhelming, much like snowboarding can feel daunting in the beginning. It can lead to a flurry of thoughts about knee bends, back posture, waist alignment, direction, and hip alignment—all while you're moving.

00:07:19.080 It can be a lot to process until it becomes second nature. This is perhaps what the bunny slope looks like to a beginner on their first day.

00:07:25.140 Moreover, the first time you point your board downhill and make your first turns can be frightening.

00:07:27.240 As an instructor, you have to recognize these fears, which are very real to the other person, and acknowledge them.

00:07:30.960 It's essential to understand that your perceptions and thoughts might be profoundly different from those of your learner, and you want to work through the challenges together.

00:07:34.860 This collaboration, supported by empathy, is vital for facilitating a smooth learning experience, both on the slopes and in the workplace.

00:07:38.520 I've also noticed similarities between playing the drums in band rehearsals and the software development methodology we all know and love.

00:07:42.660 In my band, The Way Back, where I am the drummer, we meet every week to work through our set list. My role is to keep time and provide consistent rhythmic support.

00:07:46.920 Unless you are a lawful neutral drummer who memorizes all the music before rehearsal—something I'm definitely not—the first couple of runs through a new song are almost guaranteed to be bumpy.

00:07:50.040 Your beats might sound hesitant; you might miss some cues and forget transitions, which is normal. Though your bandmates might not voice it, you know that's what they're thinking.

00:07:55.200 So, you practice your drum part until it sounds pretty rough, but that’s okay. The goal in this phase is merely to progress to the next one.

00:08:01.440 Once your beats become steady and you are familiarized with the song, you need to count the bars to time your entry, signaling transitions.

00:08:06.600 It doesn't have to sound exactly like the original recording; no one does when they play live. After mastering that, you can refine the details, dynamics, and add flair.

00:08:11.040 This repetition at band rehearsals feels awfully similar to the cyclic process referred to as test-driven development, or TDD.

00:08:16.740 We begin by writing a test and defining the feature or what we want the class to do. For instance, we want the drummer to maintain a steady groove for a specific song.

00:08:26.040 You want to ensure the test fails, which is likely because any initial attempt without practice might be rough.

00:08:34.920 You then write just enough code to make that test pass, leading to a sense of bliss—the green phase.

00:08:43.740 After getting all tests to pass, you restructure your code, simplifying and making it more readable. This is the refactor phase.

00:08:51.600 You systematically repeat this cycle as you tackle new features, which reinforces your problem-solving abilities.

00:08:57.120 There are numerous connections between the tech world and non-tech activities if you start looking for them. That perspective comes from my experience.

00:09:02.640 I became curious about whether others with varied non-technical or non-engineering experiences noticed similar connections. I found that I had access to a vibrant developer community.

00:09:08.520 In addition, I took a poll in my company Slack asking how many of you have held significant non-technical or non-engineering roles.

00:09:13.980 Out of the 44 responses, 56.8% reported such experience, and notably, many of them didn’t study CS or STEM in college.

00:09:22.860 Once I reached out, I learned about a variety of backgrounds, from graphic designers and comic book sellers to linguists and those managing financial records, each discovering their path to tech.

00:09:31.560 I enjoyed hearing their stories and the connections they found, such as how writing grants resembles architecture design in feature development.

00:09:38.880 One person described diagnosing crop issues in organic farming as akin to triaging a tech stack issue, making such connections fascinating.

00:09:45.720 Another explained how their customer service communication skills contributed to navigating conflicts more smoothly as an engineering manager.

00:09:55.680 A common theme in conversations with coworkers from non-traditional backgrounds was insecurity, often related to time spent coding or lacking a formal CS background.

00:10:05.520 One coworker shared their experience interviewing for a staff engineer position and facing scrutiny over not having a formal CS degree.

00:10:14.220 Many felt the need to justify their non-technical backgrounds, feeling the pressure to explain their non-linear paths which I could relate to immensely.

00:10:22.920 What we've all been doing, either consciously or subconsciously, is important—crafting our own narratives. Instead of mechanically listing past experiences, telling a compelling story can bridge understanding.

00:10:30.480 You must help others see how your non-technical experiences can help you succeed as a developer. You first have to identify the connections yourself.

00:10:41.160 Articulating these connections is rewarding and enables you to connect the dots for others, especially when those associations aren't obvious.

00:10:44.880 People often hastily deem experiences irrelevant when, in fact, they can be valuable insights when the narrative is presented compellingly.

00:10:48.480 If you approach this with confidence, people will be less likely to question you or your qualifications.

00:10:52.260 In order to bolster their interest, share your enthusiasm and insights into those connections, inviting a deeper conversation.

00:10:58.200 To circle back to the beginning—does having spent less time writing code mean I'm less of a developer? When questioning your competencies, refocus on productive inquiries such as whether you can deliver.

00:11:04.560 Are you effective? Are client expectations met? Do your coworkers enjoy collaborating with you?

00:11:09.600 If you answer 'yes' to these questions, you are competent and should resist allowing anyone to make you question that.

00:11:18.540 I’ve shared insights on combating insecurities, but it’s an ongoing journey for me. I remind myself, and you should too, that discrediting our non-technical experience too quickly can undermine your unique advantages and perspectives.

00:11:26.520 You can be a well-rounded developer not in spite of but because of your non-technical experience. If you evaluate candidates, consider those with significant non-technical backgrounds as potential assets.

00:11:36.720 Invite them to share their narratives and allow them to demonstrate their competency; they may already be deserving of your consideration.

00:11:42.300 At the end, I invite you all to share your experiences, be it technical or non-technical, and the connections you've discovered.

00:11:47.040 There might be a Slack thread ongoing in the conference Slack where we can share our experiences, encouraging inspiration, connection, and mutual support as we navigate our respective paths.

00:11:51.000 That's all I have. Thank you so much for attending today. If you have any questions or want to share, feel free to approach me after this talk or reach out on LinkedIn or email, or even through the conference Slack. I hope you enjoy the rest of the conference and hope to see you around.