Alyssa Whitwell came on as a guest with us to share her recent transition into a formal software engineering role at Clover Health and her experience in the prior roles she’s held in the healthcare biz.

Topics include:

  • why actuaries are badass
  • how to self-medicate for “impostor syndrome”
  • what tips and tricks Alyssa has used to learn to code over her career

For the full text transcript see below the fold:

Audio:

Play in new window || Download

Video:

Max: Welcome all! Max of the Accidental Engineer. Today we have the pleasure of Alyssa Whitwell joining us.

Alyssa is a data engineer at Clover Health here in San Francisco, California, USA. How long have you been with Clover?

Alyssa: I’ve just hit my two years actually!

Max: Nice!

For our audience that has not heard of Clover or what it is that you guys do, do you mind sharing a little bit about what it is that you guys do?

Alyssa: Yeah, so Clover is a Medicare Advantage tech startup, and we’re currently based here in San Francisco and in New Jersey. All of our members right now are in New Jersey. We’re actually a Medicare plan, so we contract through CMS and the government, and our business model is around using data and leveraging engineering, analytics, and technology to improve health outcomes.

It’s really unique, because if we improve [patients’] health outcomes then we’re also financially profitable based on the regulations around CMS. So our goal’s to have people live healthier and happier lives.

Max: Makes sense.

For our audience that are curious about how you’ve made it to this point as a data engineer at a tech startup, can you talk about what your background was from college through to today?

Alyssa: Yeah, I graduated from UCLA in Math and Econ, and while I was in school I did two internships at Hewitt Associates, which is now acquired by AON, and it was basically a human resources consulting company. We helped large employers figure out what kind of healthcare plans they wanted for their employees, and it was my first experience with healthcare–with consulting in general and working with actuaries.

It was right around the time when all of the PPACA and Obamacare legislation was coming up. I did it for two summers, so it was a really exciting time to be in that field.

And then after college, I did management consulting. I worked primarily with pharmaceutical and biotech clients and focused on the mental health and oncology spaces. I tracked market share for lots of different cancer drugs and pipelining, from mental health drugs that were coming into markets presumably after they passed FDA trials.

It was really interesting work. It was really cool to see healthcare from a different perspective: of the pharmaceutical company that is generating molecules.

But it was also a little bit hard to take becuase I was doing end-of-life stage cancer drugs, and, I was tracking, “how long do patients with terminal lung cancer live?” so we could give them this drug.

After a while, I just didn’t wanna be in that space anymore. It was very difficult to work when you’re talking about people’s lives.

Max: That is completely understandable, yeah.

Alyssa: I was looking for other opportunities and I had kept in touch with a lot of actuaries I’d worked with and other mathematicians, and I ended up taking a position at Blue Shield of California.

I worked in their Network and Trend Analytics department for 3.5 years. I was in an actuarial department, but I was not an actuary. I was a data analyst, and I would basically use medical claims data to do financial modeling for hospital contracts. I would help calculate estimated cost ranges for people who had PPO plans and were looking for care. And that was extremely interesting, but I was really motivated to figure out how I could help people in the healthcare space more directly and use things like data and information about navigating the healthcare system to improve people’s lives.

So when I heard about Clover, the mission statement really resonated with me. We were really small. It was a really awesome opportunity, and I joined on the Data Science team initially. Then about nine months ago, I started on the engineering team.

Max: Awesome. I think that a lot of our audience might suspect that your undergrad doing math and econ is a pretty technical background. But from what we’ve talked about previously, learning to code has been a more recent development.

Being a management consultant at your first job out of college didn’t mean you were slinging Python or C code or anything like that.

Share for us how you got into software engineering as opposed to the analysis type of stuff that you were doing in healthcare.

Alyssa: So I took two courses in C++ in college. It was required for math majors, but it wasn’t at the level of regard to write Python code. It was a good introduction. The hurdle of learning how to think like a machine or think like a computer was there, and I think I kinda got it. I got to do some VBA work when I was in consulting and when I was at Blue Shield of California, but the exposure to a modern tech stack at Clover was huge for me.

I had never worked with Postgres before. I had never used a text editor before I came to Clover, so that was a huge change.

And then when I started, we were so small I got to interact with all of the engineers all the time. We were all on the same floor, I would sit together with them. We got to do projects together, and I really started to pick up just on the [software] ecosystem I think, and Clover is a primarily Postgres and Python shop.

I had some exposure to unit tests—even on the analytics side, we have SQL transforms, and we pair it with Python code because we want to make sure that the business logic is sound for what we’re calculating, so that was my first exposure to Python.

I started to pick up on it, but I didn’t know what was going on really. “Why would you write something a certain way?” And, “why is this resource-intensive, why is this a bad practice?”

I really got interested in it, and I was really interested in the technical growth and mentorship opportunities that we have on our engineering team.

We started this new associate software engineer program in January of this year, and I actually joined from the Data Science team to be a part of that first cohort.

Max: Awesome.

Alyssa: Yeah, we do a dedicated mentorship with someone on your team, and I had a fantastic mentor. We did a lot of pair programming, and I remember the first time that we paired together, I was so nervous, because I was like, “Oh, I don’t know anything. She’s gonna think I’m stupid. I don’t know the first thing that I’m supposed to do.” She was super empathetic and compassionate about it, and from that point on we paired together every day for three weeks. I really started to learn why you write code in a certain way, and from there I’ve been striving to be more and more autonomous.

Max: Before joining Clover as a data scientist and now as a data engineer you were working with actuaries, which you may still do at Clover?

Alyssa: Yeah. Yep. We have a team of, I think, six actuaries.

Max: I think that the profession of actuarial science is not well-known by the general US public. Do you mind sharing for our audience what an actuary does and why you had to work with them in your jobs after college?

Alyssa: Yeah, actuaries calculate risk, that’s the fundamental thing. You typically think of actuaries in the healthcare space, but they’re also in auto insurance and I think property, but retirement, pension, that’s kind of going out of style now.

Anywhere you’re trying to calculate the risk of someone doing something. They have tables where they calculate your likelihood of dying, for instance, or your likelihood of getting into a car accident. With respect to medical insurance, you’re calculating the likelihood that someone will have a catastrophic illness or have certain types of claims.

And actuaries are really important for healthcare, because you need them to calculate your insurance premium, because you need to estimate all of that information and then plug it into your models and forecast. If a large company wants to get health insurance, you have to figure out, “Well, how much should we charge per person per month?”

Max: For sure. It sounds like every role you’ve held since college has involved working with actuaries and yet you’ve never chosen to go down that path. Do you mind sharing why that is?

Skills-wise, I’m sure there’s a big difference between what you know now or what is valued in your role now, versus what might be valued if you had chosen to go down the actuary path.

Alyssa: Yeah, sure. Actuarial tracks in terms of school require heavy math, heavy statistics. I did take a lot of math as a math major. I took some statistics, but what really defines the field is these very structured tests that you have to take to get credentials. You have to get two credentials: the ASA and the FSA before you’re fully credentialed as an actuary. It’s like 10 plus tests, and these tests are not mid-term tests or something. You study three to six months for these things, and they’re very expensive, lots of study materials.

You actually often get time off if you’re an actuary at an insurance company to study for these exams, and they will reimburse you when you pass them, and you get pay raises associated with it. Ultimately the companies will grow you to the point where you are credentialed, and then you can actually sign off on things.

If someone is calculating what the [health] premium should be for an employer group for next year, if you have an FSA, you can sign off on it. You typically have a chief actuary do the final sign-offs. Because of that, it’s a lot of structure, a lot of discipline, very, very rigorous. You typically have these very set things that you’re trying to calculate and then you have to be very confident that what you’re doing is correct.

Because if you do something fraudulent, if you do something that’s negligent, you can get your credentials taken away from you.

I like to think of it as you want this very disciplined structured path if you’re gonna be an actuary. Then when you look at something like data science or even data engineering they are very brand-new fields, people are still struggling to define what that means. At every company the definition for a “data scientist” or a “data engineer” is totally different.

You have people coming from all sorts of fields. We have people who are PhD drop-outs, people who did a bachelor’s in math and then did some stuff after. You have people who have been engineers, and they switch into data science, things like that.

And there’s much less structure throughout–you’re often sifting through large quantities of data or bad data and you’re trying to extract these insights. It’s really cool, because you get to be iterative and get to be innovative, but you can’t really do that in an actuarial practice, right?

You can’t calculate premiums and then charge people premiums and be like, “Actually, we’re gonna iterate on that and give you a different price.” That’s just completely unheard of.

Max: Yeah, and it’s an interesting parallel to engineering, where historically there’s Hammurabi’s Code, where if a building collapses and kills somebody, whoever built the building gets put to death.

Alyssa: A little extreme.

Max: You don’t wanna get put to death for signing off on actuarial forecasts that turn out to be incorrect, but I like the idea of professions where you have some skin in the game. And actuaries have it but to a fault where it’s so regimented that there’s these tests and there’s not quite room for the type of creativity and design that there is in software engineering.

Like you were describing, tests and unit tests support guaranteeing that software works as intended.

Do you find that there’s much in the way of parallels between what the engineering team at Clover focuses on versus what the actuaries at Clover focus on?

I realize they have different responsibilities, but they both have risks, and there’s different ways to hedge those risks I guess.

Alyssa: Yeah, we have a unique challenge where we want to be innovative. In the healthcare space, it’s full of legacy data, legacy code, legacy practices, inefficiencies.

But at the same time, you can’t just go and move fast and break things, right? Because breaking things means you’re harming the member potentially or you’re not being disciplined in how you’re looking at your impact.

You want to be compliant at all times but you want to be innovative, and we see that tension in all of our work.

I was talking to some of my coworkers–some of the actuaries–and they were like, “Oh, we want to be actuaries, but we wanna code more. We wanna be more like engineers.” And then there’s something to be said about–if we’re engineers—we want to think about the member, and we want to be member-focused. “What will this impact in terms of member risk, member understanding of our plan?” I really think that it’s a balancing act between both, we need both characteristics.

Max: For sure. The vast majority of our audience does not have computer science degrees. They might have math degrees like you and me, they might not have come to coding until maybe later in life, well past college graduation.

For people at the same point down the path of learning software engineering and coding as yourself several years ago, do you mind sharing what the experience has been like and how long it’s taken to get to the level of confidence and ability that you now have?

Alyssa: My journey in engineering has been pretty brief, it’s been about nine months so far. One of the things that I struggled with the most was terminology and how to participate in a conversation. As a member of the Data Science team I would hear engineers throw around words like “abstraction,” “wrapper,” those different kinds of things, and I was like, “Oh, I kinda know what an abstraction is, but I need, like, a tangible definition.” One of the best pieces of advice that I got from my coworkers was, “Create a spreadsheet or some sort of document, and write down every single question that you have during the day, and write the answer down, and then go back. And if two weeks later, you’re still asking the same question, that’s a problem you need to figure out why.” That sheet ended up being a definition sheet for me.

I found that as I was getting more of that information I could suddenly contribute more to conversations, and I could actually understand the content of the discussion more. And being confident enough to stop my coworkers and say, “Hey, I don’t know what that word meant. Could you explain what that means and what it means in this context?” was hugely critical. And I think that there’s a point where you think “Oh, I don’t wanna stop the conversation and ask,” because everyone else probably knows what you’re trying to say. But it’s actually really important to say, “Could you clarify what you meant by that?” or, “I didn’t understand your approach to that. Can we whiteboard it out?”

Suddenly you’re really contributing to the conversation. You’re maybe even having the other person clarify what they mean more. And when I was able to stop, and ask those questions, and change the direction of the conversation, the technical design discussion–whatever it was–I really felt like I was a part of the team.

Max: Oh, for sure.

Alyssa: As I mentioned before, a lot of it is just actually writing code so pairing sessions were hugely important to me. Being able to ask people for feedback on my pull requests, being able to contribute to pull requests even if it was looking at a senior engineer’s code on my project and commenting like, “Hey, I don’t understand this part. Is this doing what I think it’s doing? Can you walk me through afterward?” was hugely important.

I think, by the 5th or 6th month, I was really feeling that I could contribute code, that I understood the conversation, and that I could ask questions in a way where I didn’t feel insecure anymore.

Max: Oh, for sure. Keeping track of questions you have that are unanswered or that you don’t feel confident about asking in the moment and then coming back to those questions is something that’s not just true of people who are just starting out in software engineering.

It’s true of people starting a new job just generally. With software engineering teams, when people come on to teams they always have questions about, “Why are you doing this this way? I know of a better way from my last role.”

What tends to happen is that people drop their recommendations after a while because they don’t have or feel like they don’t have enough internal clout yet in their new role to be able to advocate effectively for either making a safe space to ask questions even, or initiate better ways of doing things, or clarifying code that might be obfuscated in some way. So, I know exactly what you’re talking about!

One of the things that we’ve talked about before recording about getting started in coding is the specter of impostor syndrome. So, for our audience members who might not have heard it phrased exactly this way, do you mind defining impostor syndrome for people and..

Alyssa: I might have impostor syndrome about defining impostor syndrome!

Impostor syndrome is the feeling that you’re in this place but you maybe don’t deserve the role, or maybe you’re secretly not intelligent enough to be there. You really do a lot of self-doubting, and you might think, “Oh, I have a question. But is the question because that person wasn’t clear, or was it because I actually have no idea what I’m doing?”

You fall into this very terrible spiral where you just lack confidence and you’re not actually able to improve, because you’re holding yourself back.

Max: So, for one, I think that was a great definition.

Alyssa: I think, cool, that was completely on the fly.

Max: And, two, that jives with what I suspect it means, too.

How should people or how can people “self-medicate” for this syndrome?

Alyssa: I think having people who you trust and being able to ask them for honest feedback.

I think that having constructive criticism, even if it’s reinforcing, is really important. So you were talking about people might not have enough clout in an organization. I was lucky where I had been at my company for a little over a year when I switched into the engineering role. Even though I was a brand-new engineer, I had a lot of domain context, I had a lot of contributions to the company, not necessarily in terms of commits or something like that, but I had delivered on a lot of things where I had relationships with people. So, I could reach out to those people and ask, “Hey, am I being too hard on myself? Where can I really learn?”

My manager has been fantastic and she also switched into engineering. She switched from finance, and she’s super empathetic and was able to give me a lot of advice and a lot of support when I was going into it.

But I think “not being too hard on yourself.” If you’re coding and you’re making mistakes, you’re learning something. As long as you’re not making the same exact mistake five weeks in a row, if you learn from it and you’re on a new mistake, that’s actually progress.

A good parallel was debugging. When you first started coding and you hit some errors, you’re like, “I’m terrible. Why can’t I get this to work?” And then it’s really understanding actually everyone hits bugs all the time even if you write awesome code.

I saw that in how I approached debugging, as I got better at it and was able to solve small problems iteratively until I hit the final solution. I think that’s a good metaphor of overcoming your impostor syndrome.

Max: Totally. And, to come back to the beginning of your answer, it sounds like finding peers or managers that are, a) understanding, b) are empathetic and have the spare time–not even spare time–but the willingness to help out more junior employees.

Something that I found really helpful when I was trying to get into software engineering (my first job out of college was not software engineering, similar to yourself) was going to meet-ups.

When you might not be so experienced you’ll find that everyone else around you is more experienced, which is a great environment to learn from other people because a lot of people have been in your shoes not so long ago. They’re the best people to talk to as opposed to going out on the internet, into the void and trying to find like-minded people over the internet. Getting out the door and meeting people, whether it’s at a new job or in person at live meet-ups is another great way.

Alyssa: And, just as a quick plug, PyLadies is really awesome.

For people who don’t know, it’s a very female-centered approach to coding, and it’s for beginners in Python, and there’s chapters all over the country. Clover actually sponsors the San Francisco PyLadies, so every Thursday they use our space and they usually have presentations. If you wanna practice giving a presentation, you can go do that, and they also have working sessions. They have a mix of experienced engineering people and brand-new people to Python, and it’s a really supportive community.

Max: For sure. Seeing people like yourself who are coping with the same self-doubt is a really great way to deal with impostor syndrome. It’s recognizing that everyone feels similarly, and it’s not totally justified to feel the way that you do, is, I agree, a great way to self-medicate.

For people who are a little apprehensive about picking up their first programming language, how did you end up picking up your first?

You mentioned your college classes and C++. But when you joined Clover as a data scientist, did you already have a toolkit of programming languages that you were familiar with, or did you adopt what was used by your new coworkers?

Alyssa: Yeah, my toolkit was really just SAS, which is a pseudo enterprise-y version of SQL in some ways, and debugging existing VBA code and Excel Macros.

So I didn’t really have much of a toolkit, and my first task was learning SQL. We use Mode Analytics at Clover, so it’s basically a way to have a web interface where you’re querying the database directly and then you can share your reports with other people.

I wrote tons and tons of SQL queries and eventually got the hang of it. And then if you contribute a SQL file to build a table in our repo, you have to do corresponding unit tests, which we write in Python. So my initial introduction to Python was like cargo-culting things. Then gradually you learn more, and then the switch from just writing Python for a unit test to functional code that might ping our API layer or eventually move data around different databases and stuff–it was gradual, but I was able to ramp up through that.

Max: Got it. Were there any specific resources that (besides your coworkers educating you) you found helpful online, or events in-person? You mentioned PyLadies. But were there any classes that you took extracurricularly, that kind of thing?

Alyssa: Yeah. One of the big ones for me actually was How to Think Like a Computer Scientist, and it was recommended to me by a manager on the engineering team. I had picked up a lot of things along the way from my career, which is about seven years long at this point. I had picked up bits and pieces, but I had never gotten the foundational layer and that was a huge gap for me. Again, it was terminology and basic understanding of how computers work, how compilers work, how interpreters work.

How to Think Like a Computer Scientist

This course was great, because it taught you all of those things at a basic level and then taught you some Python along with it. I think doing exercises and a REPL like IPython is really important, because you get this immediate feedback loop.

I think the course has an embedded thing that you can use, but I was just in the REPL side-by-side and trying to figure out how that worked. I also think existing repos are great. When you look at a code base, you have all of these examples of different ways of approaching things. It’s like picking up examples, searching for the repo, and then sticking in like a debugger trace point or something so you can actually see the values that are coming out. I think those have been the most concrete ways that I’ve learned.

Max: Besides internal to your employer’s code, is there any public code that you looked at very early on and found legible for a beginner to be able to read and understand the code and see in action what are some best practices?

Alyssa: Yeah. I think I’ve gone to the SciPy Conference two years in a row. That’s a scientific Python. It’s a really great community, and they have tons of examples up that you can use. And you can sort through them, and I think even when you’re taking these courses, if you Google them, you’ll actually find people who have done versions of the exercises, and you can see what they have done, and that’s quite helpful.

Max: These are extremely helpful examples. Thank you for sharing them with all of us, Alyssa. I hope we get to do it again very soon!

Alyssa: Yeah. Thank you!