Mobility Spotlight

Episode 03: Chris Ling's journey from Law to Software Engineering

Post by
Nick Ionita, Co-founder & CEO
Episode 03: Chris Ling's journey from Law to Software Engineering

Welcome to Flux's Mobility Spotlight where we share stories of people who have made successful job transitions and the companies with cultures that encouraged them to do so. Our goal is to highlight these transitions and understand what drove them, experience and working-style overlaps that might not be obvious, and to share advice for others considering a similar move.

If you prefer podcasts, you can follow/subscribe through your favorite player here!

In this episode we're speaking with Chris Ling who is a Data Engineer at Flux. Chris has taken an extraordinary path to get there from studying environmental science at MIT, practicing law, serving as the associate director for Diversity & Inclusion at the Oregon State Bar, and now software engineering. In this discussion we cover:

🥾 How to pick a bootcamp and preparing for your first role afterwards

👂 The power of listening and treating others as stakeholders

🤝 Our responsibility to mentor and build community

Chris' career pathways

Nick (Flux): Welcome to Flux’s mobility spotlight where we share stories of people who have made successful job transitions in the companies with cultures and encourage them to do so. Our next guest is Chris Ling. And this is a pretty special episode since Chris works at Flux. Chris is on our data engineering team. And he's taken a pretty atypical path to get there from studying environmental science at MIT to practicing law, serving as Associate Director for Diversity & Inclusion (D&I) at the Oregon State Bar, and now software engineering. So it's a super interesting path. And I know it's something Chris, you talk a lot about and mentor others on, particularly just the path into software engineering. So I'm really excited to dig into this with you and for you to share some perspective. To get started let's talk about your current role at Flux and the type of engineering you're doing.

Chris (Flux): Thank you for giving me an opportunity to share my story. As you mentioned, I'm a data engineer at Flux. And because we're a startup, that actually involves a bunch of overlapping responsibilities. That's not just strictly data engineering, I'm heavily involved in working on back end projects that involve our data science and data export pipeline. So that just means figuring out where we get huge amounts of data from different types of industry and occupational contexts, and being able to process them in a way to provide matching related insights to connect talent to awesome jobs. So right now a lot of our services are built with AWS infrastructure. It's maintaining those pipelines and building them out based off of the needs of our platform as it grows. In addition to that, I do what you would consider to be database administrator work as well as some DevOps work and I also throw a hand in on analytics side by maintaining our current repository of data warehouse views and how they interact with our reporting platform, which is currently Mode as well as things that we have customized ourselves that you can see on our platform.

Nick (Flux): That's great detail. And obviously you've had a hand in helping establish all of that from early on since joining the team as we build the initial platform, and now all the fun that comes with scale and continuing to make that more robust. One of the things I love about building a company is that we've been so fortunate to hire people that we've worked with in the past, and you were a referral. So we met Chen, and Chen joined and then referred you immediately. So that was how you found out about this, but let's take this step back because you were doing a software role before you came here. How did you find out about that role? And what led to the transition from law?  

Chris (Flux): Yeah, there was a confluence of different different variables that came into play. I've always been interested in sort of technical and software related things, but I never had any experience doing any programming other than sort of adjacent to some of the science research that I did in my undergraduate degree. So like learning Basic or playing around with MATLAB, but nothing super focused in terms of building a curriculum around software engineering. But what I found when I was working as a lawyer as well as working as a D&I specialist was that the parts that I really gravitated towards in terms of feeling like I was contributing and feeling like I was getting better insight centered around data. And maybe that could be something from how I used to work in trust litigation. We would have to go and do a lot of investigation into financial misconduct by bad trustees. So recreating financial timelines based off of looking at very disparate bank accounts and other sorts of assets to going to diversity and inclusion programming, where you're looking at demographic data and participation rates in a variety of programs - mentorship programs, orientation programs, and you're trying to prove that you're making an impact towards this qualitative goal of building diversity within a particular profession. And those things always fascinated me. 

I got to a point in my career, where I felt that the bottleneck for me was that I wanted to do more, and I wanted to do more right away. And whatever stereotypes you've heard about the legal profession, it is one that is built on precedent and a very deliberate pace in having change made. And I just want it to be an environment where I could go and start taking larger risks. I had confidence in my ethos and my values. And I wanted to apply that in a world and in a job setting that people would allow me to take risks and build things. So I quit my job in the middle of 2017 and went to a boot camp 40 hours a day, five days a week for three or four months. I just immediately ground through it and soaked up as much as I could about software engineering.  And then I got referred to a friend of a friend’s husband who worked at Vacasa, not even on the engineering side, but on the business development side for international business.  I had a quick chat with him and we hit it off really well. And I mentioned that I had dropped an application because I was interested in seeing this intersection of how data can be used to help people in some contexts, in this case owners who are trying to maximize the effectiveness of their ability to make this passive income through vacation rentals. He flagged somebody down on the team and that kickstarted them calling me up and going through the screening, and eventually I got that opportunity to work for Vacasa where I did very similar things in the vacation rental context with transforming data, maintaining data pipelines and doing analytics related work or and helping analysts infer information from predictive modeling.

Nick (Flux): I think particularly engineering boot camps are a great way for a lot of people to get into that profession, if you didn’t study it in school or whatever would be required, formally. What did you find like were the biggest skill or experience gaps you needed to close when you started playing a production role? Just making that leap from not having been an engineer to being an engineer?

Chris (Flux): I think this is something that many people who, in the past were afraid of taking getting a CS degree or many people who are afraid to make the leap into software engineering, wrestle with because they don't have any knowledge of the space, is contextualizing why you're coding a thing. I think it's very similar to how we used to learn Math in the past, as it was a lot of rote memorization. And we all joke about, oh, I don't use algebra in my real life or you know, I don't use calculus in my real life. But I think that's a failure on the side of being able to. We weren't taught to contextualize things very well. And I think the biggest gap that I had was like, Oh, yeah, I could code a thing that could return an integer versus a float, and it didn't perform some sort math calculations, but it was the why. And then relating back to my prior industries, which was very stakeholder focused, very service oriented. We would always ask ourselves the question of why. So being able to think about software and say that it is a very similar exercise of thinking about why are we connecting all these pieces? Why are we writing code in this way? What does an API actually mean? It's a contract by which we are a common communication or common type of language that we're agreeing to so that we can help facilitate some sort of data transaction. Even once I started thinking about things like that, that was like a huge barrier that I was able to leap across. 

Nick (Flux): I think with your interest in data, and even thinking back to your interview, which is probably one of my all time favorites, was your ability to kind of follow that chain of why's through a very open exercise. It’s like I have all this information, what are the patterns, I'm starting to see what are the questions I can start asking and kind of following that chain? Which, I think for anybody designing or building a product or just working around those occupational lenses, that ability to go through that exercise is so key in building the right thing and approaching it the right way. 

So you were practicing law and then you moved into an advisory kind of role with the State Bar around D&I. What skills from those experiences have really served you well, and helped with that transition into engineering?

Chris (Flux): Yeah, I think the biggest part is listening. And really, when we when I say stakeholder management, I don't really mean it in terms of like widgets, or abstractions, or like a b2b customer sort of way, but it's pulling back and what's the humanizing element of why we're doing thing and I think you can see even when I write tickets, it's not sort of the typical way that an engineer would write tickets, like I always like to write. It's also a tip that I picked up from a former colleague of mine where I say what's the ask? And then I go to what's the engineering thing and I try to construct that user story, even if it wasn't provided to me initially, because I think context matters. I was in so many environments where you would have all these distinct groups of stakeholders who had all these different sets of priorities in the diversity space. And you had to really listen to everybody and try to figure out where are their commonalities? Where is their miscommunication? And where are the things that you have to compromise about? And in the legal setting, when I was working as an attorney in the litigation space, it wasn't always just that the client tells you what to do, and you do it. But you infer from your relationship with the client, what is the client actually asking for and being able to present back to the client and say, Hey, you said “A”, and you're really fixated on this is a goal and it's a priority. But have you thought about “B”? Like you've been saying, you've been dancing around these other issues, and I think that these are also important to take into consideration.

Nick (Flux): That makes a ton of sense. Stepping back and let's take a lens around hiring and advice for people wanting to make the move. I think your leap to software engineering is a very unique one. Maybe if we widen that a bit to anyone who's wanting to get into software engineering or even more specifically data engineering, what do you think is an important skill in the job you’re doing right now that people don't usually associate with it?

Chris (Flux): I think like I said in my last question, it's contextualizing. I give presentations to coding Bootcamp, graduates, and students and I say when you're talking about scripting languages, computer programming languages, think about them, like actual languages, like your pythons versus your JavaScript versus your Ruby is like the romance languages. It's like Portuguese versus Spanish versus Italian. There are these commonalities. And so the success of you as a software engineer is not necessarily although there is correlation between depth in a particular language or a particular set of technologies. But it's also highly dependent. And we overlook this so often, so again, I'm contextualizing how we're using these tools to build anything, always asking, is this the way that my user wants to interact with it? Have we asked clients, are you using it this way? Is this what you intend to do with it? How can I facilitate and make things as smooth as possible for you to interact with what I'm building? And that's a skill that I think especially people who are transitioning into software engineering and have a predisposition or a preconception that software engineering means it's math, it's logic, it's typing on a keyboard, we miss out on and then we want to like just drill into the nitty gritty. And I think this generation of software engineers are going to be so much better than the previous generations, because I'm seeing when I'm volunteering, and I'm mentoring, this greater awareness towards that towards the product, towards the stakeholders. And I think that's key for us to just be better as an industry in general.

Nick (Flux): I love that. And I think you're so right on that. I look at people we've hired and we're working with now versus in my experience even 10 years ago. A lot has changed. I think that's fed into that, but I think you're 100% correct. 

Since you took the boot camp route, a side question for anyone considering or going through that right now. What general advice do you have for choosing one? I know you mentor people in boot camps - are there things that maybe aren't covered as much that if someone could learn them would be really critical for stepping into a job afterwards?

Chris (Flux): Yeah, absolutely. I would say the first piece of advice that I would give somebody considering a boot camp is to do your research because there's a huge variety of different boot camp types that address different needs of students. For example, the boot camp that I went to, which is the Tech Academy, it's a Portland boot camp, was highly centered around this self paced curriculum. They gave you a time estimate, saying we're giving you 15 to 20 weeks to complete all these courses, but you can do it at your own pace. And that was where I needed to be because by the time I wanted to make the switch, I really wanted to make the switch. And I didn't want to wait six months for a cohort to open up at a more formally structured boot camp. The downside to that flexibility was that I didn't necessarily build a lot of breadth. So I had exposure to a lot of different languages like C sharp Python, JavaScript, but I didn't necessarily build depth of stack. The boot camp that I volunteer at alchemy code lab. They're very focused in terms of having strong, modern frameworks centered primarily around JavaScript and JavaScript-related technologies. And so because of that, for example, when I get a graduate out of there they understand how to build this vertically integrated web app, but you know, maybe they're concerned when I am mentoring them around how do I convince other the potential employers that I can translate these skills to like a Ruby context or to a PHP context? 

There's pros and cons to every kind of boot camp that you go to, in terms of your second question about what you could do outside of the boot camp experience to kind of help lock in, I would say that I have the worst luck possible setting up development environments. I can get down and code once it's all set up, I can code for days, but just setting up the technologies we use, I'll be stuck for like two days, three days, passwords will mysteriously not work for me. So I have to reset things. All the time. And I really wish I had context in terms of how do I code when I'm interacting with other people with a shared code base, and being able to have that development cycle where we go through sprints, and we're assigning tickets based on priority, and those things I had to learn on the job. And maybe I would have had a little bit more of a comfortable transition if I had known those workplace management related skills. And some boot camps are better than others with that. Like at my boot camp, we simulated sprints, but it wasn't exactly that way. Different boot camps do different things. They're more project based, and they're more like hackathon based. But I just, I would love to see more experiences where it feels more like a day to day we're setting up our environment. This is what our stack is, you have to learn how to onboard yourself. 

Nick (Flux): And then you throw those pesky people like product managers.

Chris (Flux): Yeah, it's really funny because having come from the stakeholder side, in a large way I aligned very heavily with product. A new facet that I've discovered is that now I'm in this very specific type of technical role, I really want to be involved on that product side, and I realized that there's a little bit of that, it has to come down the lifecycle a little bit and ruminate and germinate and do all those fancy things are just like becoming a formed idea, as opposed to a brainstorm idea. But man, do I love to have my fingers in every pot? As much as possible? Yeah.

Nick (Flux): I think that's one of the beauties of working in an early stage startup where there's always an extra set of hands needed and you can get your fingerprints on as much as you're, you're able to touch. 

You've helped hire people here. Let's strip out the tech skills and the obvious stuff. If you were hiring somebody for your role right now in a data focused engineering capacity, is there anything else you look for beyond like the obvious things? What usually stands out in the candidate? 

Chris (Flux):I really look for the willingness to explore through a problem, but doing so in an organized fashion. I don't know why it's this bimodal distribution, but I feel like people feel that they either have to come to a task immediately, or they want to be in that sort of academic environment where you're just kind of like coming up with the best solution. And really what it means to me and I think I gravitate towards this, because of my lawyer background, because you're making a lot of educated research based decisions, but you're also speculating a little bit. So you have to balance that. If a client comes to you and says, hey, I've got this legal issue, you can say  based on my prior cases this is what I would anticipate, but let me, let's put a pin in it, let's research it come back. You have to make those deliberate decision points where you're saying, we're going to spend X amount of time on this, and then we're going to formulate a plan. And what I look for in candidates is that thoughtfulness of being able to say, I'm not going to jump in right away to a solution, let me think about what the problem space is, let me contextualize. And if they can do that and communicate well, especially nowadays, in this remote new world brought on by our global circumstances, but also I think that's the trend with technology. Communication is highly important. Like Wei our CTO always talks about over communication and how that's a good thing in this context. And I do prefer over communication, because then I know we're communicating. And then it's just a matter of filtering out the right information for a given context. So yeah, I would say like organization, communication, I don't worry so much about the technical skills as long as they show a general aptitude with understanding how to build building blocks, because like I said, I really do view programming languages, like actual languages, like you will build fluency on the job. People learn languages all the time. I have faith in people's ability to do that. 1

Nick (Flux): Yeah, agreed. A bit of a curve, this is a detour for a minute or so. You've got a fantastic background in diversity and inclusion work, and you've done it as a job. You've got big hands in it here with us both in terms of how we continue to shape our mission and the type of company we want to create and how that transfers down into a product that’s all about connecting people to opportunity. How have you taken and applied pieces of such a focused role and are there pieces of that that influence how you approach your daily work as an engineer?  How do you think about product, what things have you pulled from that you apply?

Chris (Flux): This is the reason why I always joked to Chen about how she kind of was like, Oh, my company's hiring and provided no context as to what the company was. And so when I finally started doing my due diligence, I was like, Oh, my God, this is the intersection of all the things that I've done in the past, all the career development I've done in the past, all the weird meandering, I've done in the past all the focused attention that I place on building relationships with underrepresented people, that's all here. And maybe, initially when we had the discussion, it wasn't so overt and talking about D&I but we were talking about equitable concepts. And so the way that I think it informs things is that I really do try to put myself in the shoes as much as I can of other people's work to the extent that I can. 

Look, I guess I have a great story from an external perspective about what my transition is, but I'll be honest, I have a lot of privilege in terms of where my education was able to take me and the flexibility that I was able to have and making this transition was highly informed and I benefited by the fact that I had the opportunity to go to a great school had the opportunity of a supportive  community and network, and the opportunity to work in a customer service oriented environment. And so I always want to ask the question, Who am I impacting? It goes back to what we've talked about throughout this conversation. Whenever I think of a product question, whenever I think about an engineering question, I always think about who it is impacting. On the data science side, Chen is our primary stakeholder for a lot of our internal data. So I really want to think about, not just her saying “I need this change”, but what are the implications? And what are the inferences underlying the reason why she wants those changes. And when we start having that conversation, we're able to draw those bits and pieces of things that would have been subsequent tickets, but now we can form them into a story. Because we have a complete story, we really listen to our stakeholder. So that's what I bring from my D&I background, taking the time to listen and tease out the story.

Nick (Flux): Yeah, that's fantastic. Thank you for that.  Maybe my last question here. You've given a lot of good insight here. Any other advice you'd give somebody wanting to make a similar move to you or even just a big leap? These are big transitions you made, what advice do you have for people considering something similar? 

Chris (Flux): You need to build relationships. I learned that the hard way. When I was a law student, I thought I could just get around with my grades and my credentials, you know how you are in your early 20s. You think everything's a meritocracy in this very particular race. And it turns out that relationships matter and networking matters. You know, like getting your face out there and building genuine relationships and not just like very mercenary type relationships. Those are so critical. Ask people out to coffee, get a gut check, find out any connection that you have to the industry, and yes, it's harder now. But so you can still ask for virtual coffee, and just say hey, can I pick your brain for an hour? I'm trying to figure out what's going on. 

What I did love about the legal profession, in that regard was that when I started working with the diverse organizations and the professional organizations, it was an unspoken thing. And maybe this is an Oregon specific thing. But everybody’s always asking for coffee where there's an unspoken rule that we'll always sit down for a coffee. We'll always share our time, and we would joke, maybe it’s because we want you to stroke our ego a little bit. And so it's a little bit of self gratification by being able to listen to some bright eyed young professional to be asking “Oh, what's this amazing thing that you did?” You know maybe it's part that, but it's also that we want to build a community. And you have to, in order to make the transition, you will rely on others. And the sooner that you can start to ask those questions, find a mentor, find some relationship to help facilitate you and guide you through this process. I'm always volunteering my time for that. 

 At Alchemy, I'm frequently talking to the Career Development person over there. I always have an open door policy. I think I'm in the middle of devising all sorts of volunteer office hours with that. Boot camp that I want to pilot, just around the topic of how do we approach different types of technical interviews? And what are the commonalities we can glean from all of those interview experiences, and how do we build strengths for them, but how do we also tackle particularized interactions? And so like, yeah, like several of these people exist, they don't have to be me. They don't have to be exactly like me. But there are enough people in the industry who are happy to have a coffee, willing to give you information that you should take advantage of it. And the worst case scenario is that they say, no, I don't have time or they ignore your email.  

Nick (Flux): That's so true. I think most people generally do want to be helpful. And a lot of times, it's actually I found in my experience, both asking for help, and throughout my career giving back where I can. Just being clear about what you're looking for help on. Sometimes someone may not know where you're coming from or have the context. And being clear about what you're needing help on or what you're looking for. Even if that person can't  give you that, they may know somebody who can and it just comes down to asking and getting over the hurdle.

 Anything that you want to plug, any any call outs?

 Chris (Flux): I would exhort all of my colleagues in the software engineering space, to take a role in volunteering and mentoring, especially during this challenging time. Volunteers are always needed in any context. Think about the community, the professional community that you want to build for yourself. You need to play a role in that and you're gonna see some amazing people. To the extent that there are other people who are facing the diversity question in terms how do we promote and grow this within our company? Or how do we get great hires, you have to get out there in the community, you have to see who these people aren't. You can't just rely passively on people coming to you. I find such great reward and I'm so impressed by the people that I interview and that I volunteer with, that I mentor, they're learning things that I didn't learn two years ago, three years ago when I started my software journey, and they're learning different things every day, I see a new technology being used every day. I think it's incumbent upon us if we're going to say, we're going to build this profession, as a profession that we take an active role in sustaining and growing it so that's what I would leave with.

 Nick (Flux): Chris, I appreciate the time and you sharing your story. This was super insightful. Appreciate it as always. Thank you.

Flux
An internal mobility platform that develops, engages, and retains your workforce.