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.
