081 - Learning to code and embracing failure with Kristen Foster-Marks

For today’s episode, we chatted with Kristen Foster-Marks—director of engineering for Flow at Pluralsight—about imposter syndrome, embracing failure as a new engineer, Kristen’s journey into tech, and her unique research into the academic field of second language acquisition and what it can teach us about learning how to code. Kristen's article series on SLA and learning to code can be found here: https://www.pluralsight.com/blog/software-development/sla-learning-to-code-part-1

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Seth Merrill:

Hello and welcome to All Hands on Tech, conversations with top voices in software development, machine learning, cloud, security and technology leadership. I'm Seth Merrill. For today's episode, I had a delightful wide ranging discussion with Kristen Foster-Marks, director of engineering for flow at Pluralsight. You'll hear us chat about imposter syndrome, embracing failure as a new engineer, Kristen's unique journey into tech, and her research in the academic field of second language acquisition and what it can teach us about learning to code.

Kristen, this is really exciting. I'm really excited to have you on here to talk about your interest in second language acquisition and learning to code and your personal engineering journey. That's all stuff I'm really excited to get to. Before we start, can you introduce yourself? Maybe talk about your role here at Pluralsight, and what you're about?

Kristen Foster-Marks:

Yeah. Absolutely. Thanks, Seth. Yeah. I'm super excited to be here, too. Yeah. My name is Kristen Foster-Marks, and I'm the director of engineering for our value delivery team here at Pluralsight Flow. There are a lot of things that I do in that role, including helping develop the flow delivery reports, which I am super excited about, love those reports.

They're just a set of reports that help engineering leaders and teams gain insights into their ticketing data, with a goal of improving processes and workflows. I've joked before that these reports, if previous teams at previous companies had been using them, I might have stayed at those jobs. But another component of my role that's really relevant to this conversation is that I need to develop what I would label beginner to intermediate level fluency in now a wide swath of technologies, ideally, every technology that my team is using.

Whereas before, it's striving for near expert level fluency, and just the few technologies that I worked really closely with as an individual contributor. It's been a really fun and unique challenge so far. I'm actually finding unique ways of utilizing the Pluralsight course catalog to this end.

Seth Merrill:

Why have you had to move more into beginner and intermediate level fluencies in your new role?

Kristen Foster-Marks:

Yeah. I've been with the company for a year and a half now. I spent the better part of that year and a half as an individual contributor, working with Python, working with Django, dipped into Kafka a little bit. The number of technologies that I needed to be fluent in were really just small. There were other people on my small team who were covering other bases of our code base.

But now that I lead this team of developers, I need to have an understanding of all the technologies that we're using in order to be able to make decisions and help contribute to those architectural decisions and help and communicate across teams. I don't need to be an expert in any of them. I've got members of my team who are in the trenches, doing the coding on a day-to-day basis. But definitely I need to know what all of these things are, and what they're used for, and the pros and cons of using them over similar types of technologies.

Seth Merrill:

We recently did a webinar on making the move from individual contributor to manager and a lot of this type of stuff came up around a sense of imposter syndrome around "Oh, I don't know if I'm going to get the chance to develop my hard skills the same way in a leadership role now that I'm in management." But I'm curious how you're thinking about that as you're making this move into a leadership track.

Kristen Foster-Marks:

It's definitely a mindset shift. I'll be honest, there are days when I have to rain myself in. Let's say that a bug comes in, rather than jump in there, and solve that bug myself, I have to remember, "Okay, Kristen, you don't really have the time anymore to tackle this bug and see it through the pipeline." That takes hours and sometimes days of dedicated attention. Stepping back from that role, that can be really hard.

I mean, it's really just delegating. I know that it's a joke that every new manager, the first thing they need to learn is how to delegate. That's absolutely true. I found that to be absolutely true. Yeah. The imposter syndrome part of it is really interesting. Luckily, I haven't felt that yet. Knock on wood. I'm sure that it will come. But I also feel like I'm at a place in my career, and just even in my development as a person where I feel like I'm being a lot kinder to myself, and more realistic about what I can even expect myself to be able to do.

We can't do everything. We can't know everything. Really there's nothing software engineering to teach a person that.

Seth Merrill:

Yeah. We were talking before we hit Record about just working from home. I think we've all realized we can still be highly productive and efficient, but also give ourselves more leeway to be human, I guess is how I would say it.

Kristen Foster-Marks:

Absolutely. Also, to build on that stuff, I feel there really is a ... Man, I might even call it a movement, a movement across companies right now to create that space for their employees to voice those things, to be vocal like, "Hey, you guys, today is not my best day. It just isn't." We can be kind to ourselves, and we can be kind to our teammates. It's normal. I feel like that's becoming normalized, which is a good thing.

Seth Merrill:

Exactly. I want to come back to this at the end of our discussion as we talk about providing space for new coders to learn and to fail and have that learning space. But I'd love to talk a little bit right now about your specific journey into tech. I don't want to even call it like you have an interesting or unique background, because I think nontraditional backgrounds are becoming the norm in a lot of ways in tech.

Kristen Foster-Marks:

Yes.

Seth Merrill:

But I know that you have college experience studying psychology and studying English. I'm curious if you could talk a little bit about how you came into tech and why this is something you're passionate about now given your background.

Kristen Foster-Marks:

Yeah. Absolutely. Yeah. There were a couple of factors that pushed me towards this career change. Warning, I'm going to get a little bit personal about money here. But my own personal philosophy, I think is a culture we need to talk more openly about financial matters, especially the concept of financial security, really, so that we can learn from each other. Here it goes.

I got married in 2015 while I was still teaching English and composition at Colorado State. At that time, my husband had just finished a computer science degree. He transitioned away from public school teaching. I had gotten to see him over the course of three years ago, from having no coding knowledge to going through a degree program and coming out of that degree program highly employable.

I mean, right out of school, he was making good money, the money that he would have had to spend a career in the teaching world to ever get to, which is really sad. I know that everyone knows it, but we really did not pay our teachers enough, especially when we saddled them with debt during their training programs. That's a different conversation. I leave it at that. But yeah, Aaron was just out of his program.

He was able to make the money where a person can support themselves and thrive, and then there was me, half partner of what Aaron and I refer to as the family business. I had been teaching at the university since 2012, at that point. I was making around $32,000 a year with a master's degree, doing intellectually, emotionally demanding work. This was the job where to really do it well, you're looking at probably 60 hour weeks.

Nobody was doing this job well on 40 hour weeks. There was very little opportunity for professional development upward mobility. It's like you get stuck in that just low salary lane with nowhere to go. I'll be honest. This was pretty dang demoralizing for me. I mean, I was working so hard at a job that you need extensive training to get, and I was being outlearned by my spouse to just such a high degree.

I didn't grow up in a household like that. My mother's had a stellar professional career. I feel so fortunate to have had her as a role model. Growing up, that's what I expected for myself. I had this idea in my mind of what my own professional career was going to be like. There was that aspect. Getting back to this financial security point, the extreme disparity and Aaron's and my income, it felt a little tenuous to me, at a certain point.

It's like, "What if Aaron got sick and couldn't work?" Like, "What if he got sick sooner rather than later? We didn't have like savings built up yet. How can I possibly support both of us on that salary, let alone do things like save for a house and have an emergency fund and save for retirement, and maybe do a little bit of good in the world, too, for those who are less fortunate."

After reflecting on that a bit, I decided to get out of the teaching world. Again, I had just seen Aaron learn how to code. I could see that there were tons of companies hiring for tons of software positions. I also thought, "Hey, if Aaron can do it, I can do it." I ended up looking out at the Galvanize boot camp had a Fort Collins location at that time, which really was lucking out, because I think I was a 15 minute drive from the Galvanize campus.

I lucked out even more, because the teaching staff at that location was just absolutely stellar. They cared so much about us burgeoning programmers. Yeah. The rest is history. I mean, I really feel like making that career change. Hands down, it's the best decision I ever made, except maybe the decision to marry Aaron. But yeah, just haven't looked back.

Seth Merrill:

Yeah. I love how practically and honestly you talk about that. Because a lot of times it feels like there's still a lot of stigma or gatekeeping around, "Oh, you don't come from a computer science background." You're not a "real developer, real engineer." But I like that you're willing to talk about the real world practical motivations for doing something like that and making it happen.

Do you feel like those stigmas still exist around how people come into tech?

Kristen Foster-Marks:

I personally have not witnessed this computer science degree gatekeeping at the companies that I've worked for. I feel really fortunate for that. But I have heard about companies and rather engineering leaders who do refuse to look at the resumes, of folks who have come out of these programs, or folks who have self-taught themselves.

There are so many of those folks, too. I just feel like this is really unfortunate. The evidence is there that folks can get themselves ramped up and ready to thrive as junior developers after a six month intensive program, or after a year of dedicated study. I know at Pluralsight, I'm constantly finding out that this person, or that person came out of a boot camp or was completely self-taught.

These are always people that I just assumed had CS degrees, because of their technical prowess. These are really good developers. It's really good people to be on a team with. Yeah. As folks who still subscribe to the stigma that you need a CS degree, as I see more and more of these nontraditional path success stories, hopefully any remaining keeping break down as a result of that.

But again, luckily, I haven't seen it firsthand. Maybe we're well on our way already.

Seth Merrill:

Yeah. We referenced imposter syndrome. I like that you were willing say you haven't felt that. I'm curious if you ... In general, do you feel like those that come from nontraditional backgrounds in the tech, whether that's a boot camp, or whether that's been self-taught, do you feel like they struggle with imposter syndrome more so?

Or is that idea around like, "Oh, naturally, if you don't come from a computer science background, you're going to be less confident?" Do you feel like that's breaking down as well?

Kristen Foster-Marks:

I think so. I hope so. Yeah. Imposter syndrome, it is a thing in tech, for sure. It's rampant. Yeah. I mean, in terms of seeing that more in folks who have come from nontraditional paths, I can honestly say that I'm not sure that I have seen that more out of either path into this field. Honestly, I think a lot of developers feel it.

Seth Merrill:

I was just going to say, as a non-engineer myself, I can imagine that maybe some of that imposter syndrome comes with the idea that the industry has a really high learning curve or a barrier to entry. Maybe because there are now more ways or they're becoming even more accessible ways for people to get into technology and into engineering. That sense of like, "I can't possibly do this" is breaking down a little bit.

Kristen Foster-Marks:

Yeah. Absolutely. I think that we can see different reasons that that imposter syndrome is really relevant in this industry. I think a part of that is because a lot of folks who make it into the tech industry are high achievers. If we're being honest, we have to recognize that high achievers, by nature, rarely think that they're good enough. They're always striving to be better and achieve more.

It's just part of the definition. But I also think that a big reason for this rampant imposter syndrome, it might be that the technologies that we use to build and deploy and manage our applications, they appear on the scene, and they changed so frequently that we're all always in a state of needing to learn something new in order to do our jobs effectively.

We talked earlier about ideally as an individual contributor, you want to reach expert status, expert fluency in the tech that you're using. Well, I mean, in reality, we're constantly being shoved back into the beginner category, because technologies they pop into the scene, or they change drastically. I remember I learned Angular in my boot camp. It was Angular version one.

Then the next that ... Then I went and taught a cohort at a later Galvanize boot camp, and we were using Angular two. It was vastly different. It's like, "Oh, my gosh. I just learned this thing, and already, everything that I learned ... Even though it's still Angular, everything I learned six months ago, I have to learn something new in order to teach it." I mean, yeah, I think that they say that the shelf life for skills in any one technology is estimated to be two years.

Yeah. I definitely witnessed that in the five years that I've been in this world. In that way, it is not easy being a software engineer. We're always chasing a moving target as we strive to keep our knowledge and skill base [inaudible 00:14:30].

Seth Merrill:

Yeah. It seems like the biggest skill of being in tech and engineering is just knowing how to learn and knowing how to adopt new skills really quickly.

Kristen Foster-Marks:

Yes. Absolutely. Absolutely. Sticking on with this subject of imposter syndrome, I think another component to it, too, the work that we do as engineers, it's so public. When I announced my career change to my family back in 2015, I remember one of them saying, "Kristen, you're so social. How are you going to sit alone at a computer all day?" But we all know that that is not how coding gets done. That's not how products get built.

As engineers, we're constantly collaborating with each other. When we write code, we asked our colleagues to review it. They're assessing it for things like style, logic, performance. Does it actually do what it's supposed to do? Are we using the right tools and methods? All that is to say is that there are a thousand ways to fail just a code review. That's just one component of coding.

Sometimes we mod and we pair program. During those times, your colleagues get to see your lack of knowledge, or your faulty logic live as it's happening. That can be really scary and demoralizing. Especially depending on the level of psychological safety on a team, and whether a team or an organization has normalized failure already through something like fail-fast messaging.

Yeah. There's so many opportunities to publicly fail that ... I think that that contributes to it as well.

Seth Merrill:

I find it so interesting that when you talk about your family misunderstanding what development even looks like today. They assume it's the Hollywood vision of in a dark room, just tapping away your computer all by yourself.

Kristen Foster-Marks:

Yeah. With your red bowl and Cheeto dust.

Seth Merrill:

Yes. Exactly. I'm curious. Were there any misconceptions that you had about it that as you went through your boot camp process, and then entering the workforce as an engineer that you were like, "This is nothing like I thought it was going to be?"

Kristen Foster-Marks:

Yeah. Definitely. I mean, I may have to laugh at myself a little bit here, for laughing at my family member who made that comment. I wasn't even prepared for how social and collaborative it is. I've been a perfectionist my whole life. I will say, honestly, that learning how to code and working at companies that produce enterprise software, that will cure you of perfectionism in a heartbeat, because you can't. You're going to fail. It's part of it.

I think that that was a little bit, just the level of collaboration, really public failure was a little shocking to me. But it's amazing. Once you've been through that, just how freeing that is, I'm such a healthier person now that I've been through that experience. That really that I have learned how to fail in front of people, that's definitely a net win. But I mean, let's see here. What else was surprising to me?

I had the benefit of watching my husband get his first job and get his second job, and get to hear about what development was like for him on a daily basis. I think that I was probably more prepared than folks who don't have that benefit, or didn't have that benefit of seeing what the world was like beforehand. I know that I was talking about the money part of it earlier. But programming really is a ton of fun.

I love being in this world. It is so much fun. I got to see through Aaron's experience, just how much fun this career could be. That was something that I felt prepared for. But I think was also, in some way, maybe a little bit surprised at just how satisfying it can be when you like, "You solved that bug," or you come through for your team to get this products delivered on time and just stuff like that.

Seth Merrill:

I love that. I love that. You have such a positive outlook on it. I love that. I feel like it's what people need to hear that there's a lot of good. It's not just hard, and it's not just people trying to keep you out of the industry. It's also really collaborative and really fun.

Kristen Foster-Marks:

Oh, my gosh. Yeah. Yeah. I mean, the group of software engineers, as a whole, it is becoming more and more diverse all the time. I probably shouldn't refer to them as a whole. But software engineers are fun. You get a lot of, again, the high achiever, nerdy, really dedicated type. It's a fun group to work with.

Seth Merrill:

We talked about, use this term, getting into tech. I think a lot of times it almost oversimplifies the work that is required. Namely, you're learning languages from scratch. They're not human languages, obviously. But you're still learning languages from scratch. I want to transition into your interest in this academic area of second language acquisition and what lessons can be applied to learning how to code.

Can you give me a high level overview of the research and the writing and learning you've been doing about this area and why that topic has interested you in general?

Kristen Foster-Marks:

Yeah. Absolutely. Yes. Second language acquisition is a ... when a person goes and gets an undergraduate or graduate degree in teaching English as a second or a foreign language. There's three primary fields that makeup that degree, one being linguistics, another one being a teaching pedagogy, and then that third branch that is so important to being successful as a language teacher is second language acquisition.

It's an academic field. It's its own field. The questions that researchers ask in this academic discipline, that they are varied. There's a lot of different components of the language learning process that folks are looking at. Really, researchers are just trying to understand that the factors, whether they'd be something about the language learner or something about the language learners' environment that either help or hinder that learning process, that acquisition process.

I was always fascinated with SLA. SLA is the acronym. As I was going through my degree program, and I was particularly fascinated with the fact that we have so much evidence about what helps and hinders second and foreign language learning. This is an activity that many of us participate in, or have participated in at some point in our lives. Universally, agreed that it's a hard thing to do to learn a foreign language.

But few of us outside of the language teaching world know that all of this SLA research exists, and particularly the specificity of some of the questions that are being asked there. Some of the findings that have come out of that research field, that point to like, "Hey, this doesn't work for language learning," or like, "This really works, learner should be doing that."

In my opinion, if language learners were aware of some of the findings that have come out of SLA research, I just think that they would be better equipped to apply those findings, and successfully learned their target language. I know that as I dove into the topic during graduate school, it was really fun to be able to make sense of the experiences that I'd had learning Spanish and French and Korean over the course of my life.

Honestly, to be able to understand the reasons why I had failed in some of those endeavors, I've never reached fluency in another language, despite having lived in South Korea for two years. I used to be embarrassed about that. But after understanding at a scientific level how language acquisition happens, I can now point to certain things in my learning environment and myself as the learner that I was in that moment in time.

That helps me to explain, "Okay. Well, this is probably why I was never able to make it past that intermediate level fluency." Yeah. I love this field. It's one that I just nerding out on.

Seth Merrill:

Yeah. I love that.

Kristen Foster-Marks:

Absolutely.

Seth Merrill:

Yeah. I'll make sure to include the link to this in the show notes of the podcast. But we're working with you on a series about this crossover between learning a human language, second language acquisition, and learning how to code, and the insights you've discovered there. Towards the end of that first article in the series that you wrote, you talked about how there hasn't been a lot of peer-reviewed academic research on how this field of second language acquisition can be applied to learning to code.

I'm curious if you could go into why that is. If that was maybe one of the motivating factors for you to continue to dig deep into those sub-domains and the factors that people study in SLA to apply to coding.

Kristen Foster-Marks:

Yeah. Absolutely. I have a couple of theories about, yeah, this question of like, "Why has computer sciences, specifically computer science education, coding, learning how to code, why have we not seen this interdisciplinary approach combining SLA research?" I have to admit, I have no evidence to support my theory. They're just theories.

But I think one reason is that there are probably very few folks in academic settings where most of this SLA research happens, who have a background extensive enough in both SLA and computer science to even begin to empirically examine even a couple of the many analogies that I've observed, let alone enough expertise and understanding to get a true interdisciplinary research movement going.

Research requires funding and research has to get approved, typically by advisors or colleagues who feel comfortable enough to oversee that research. If that doesn't exist already, it's hard to get that stuff up and off the ground. It's interesting when I peruse the scholarly databases for research that applies SLA to learning how to program, I can only find one article. That was published back in 1995.

The article actually proposes that we apply SLA to learning how to program. Either then I found a handful of articles through Google Scholar that actually have been published in the last five or six years by a group of scholars at the ... It's Embry-Riddle Aeronautical University in Florida. I actually just got that fairly recently. I want to reach out to these folks and just see, are they trying to get something organized up and running, because again, they have a few papers that they've published.

If there's anything else out there that combines the two fields, I haven't been in able to find it using my scholarly databases and my research skills. It might be out there. But that's all I found so far. I find this lack of the combination of these two fields really interesting, because linguistics, which is such a strong component of, again, any ESL program was one of the earliest fields to partner up with computer science.

Some of the earliest and even most lucrative computer science problems that we've been trying to solve with a powerful computers that emerged in the 20th century have been problems in understanding and creating human language, problems in natural language processing. There are entire departments and degree programs that combine linguistics and computer science.

Seth Merrill:

Yeah. I like that. In the absence of that empirical research, from what you've been able to find you've been doing your own research and drawing analogies between the two. I wonder if you could talk a little bit about what are some of those core sub-domains of second language acquisition that you feel like are especially applicable to the topic of learning to code?

Kristen Foster-Marks:

Yeah. Good question. I'll be honest. I have found applications to learn to code in all of the sub-domains so far. I'm super excited about this series, because it's just going to be fun to be able to dig into those in detail. But there are a few that I think are probably most relevant to people trying to learn how to code it, and maybe a little less nerdy in ways.

Seth Merrill:

Without this turning into a three hour podcast.

Kristen Foster-Marks:

Exactly. Exactly. You all can wait for the articles.

Seth Merrill:

Yes.

Kristen Foster-Marks:

But one thing that SLA researchers look at is age as a factor that affects acquisition. If you pick up any second language acquisition textbook, there will typically be a whole chapter dedicated to exploring how age affects that process. I think this comes as no surprise. There's this persistent folklore that it's easier to learn a foreign language the earlier that one starts. But people think you got to start learning when you're a kid in order to ever gain fluency.

Some of the central questions that have been explored here in that area are things like are children or adults that are foreign language learners, how likely are adult learners to ever speak the target language without an accent even if they end up gaining grammatical and lexical fluency at some point. Spoiler alert, research indicates ... Doesn't prove. But it indicates that the most adults are actually better language learners than most children.

Because their first language awareness, their metacognitive abilities, and their awareness of just how language works from having gained fluency in the first language, just puts them a step ahead of most kids. Age is an interesting one. Crosslinguistic influence is one of my favorite sub-domains. It examines just what affects the learners native language has on acquisition of the target language.

Questions here include, do syntactic grammatical differences between the native and target language impede acquisition of the target language? A good specific example here that I think listeners can probably relate to is that Spanish uses gendered and pluralized definite articles, la chica, el chico, las chicas, de los chicos. English has a much simpler definite article system. We just use "the," the boy, the girl, the boys, the girls.

The syntax difference between the two languages, it just adds a little bit more of a challenge for native English speakers trying to learn Spanish, because there's that extra component that they don't have to think about and process, especially when they're trying to speak. Really, this is just one of thousands and thousands of examples. There really is an astounding amount of difference between human languages, about particularly those that fall into different language families.

Tons of research has been done there. It's something that they train us to understand what those major differences are between the language that you're teaching, and then each of the languages represented by the students in your class. At CSU, I was teaching classes where I might have Hindi speakers and Arabic speakers and Mandarin speakers all in the same classroom.

As part of that, I needed to know what those major differences between English and those languages were so that I could help those individuals get over some of those hurdles. Then another one that I think is really important, learner motivation, it always gets its own chapter. Looks at how learners' intentions and goals influence their ability to just sustain and persist what always ends up being a really hard task of learning and acquiring this language and trying to gain some sense of fluency in it.

Some folks will argue that motivation is the single most important factor in explaining why some fail and some succeed. I believe that's true. I also believe that that's true in programming. With language stuff, you can imagine how a 13-year-old who's being forced to, let's say, study German in order to satisfy school requirement is going to differ vastly in ultimate attainment and success from a refugee who lands in Germany and now has to make a new life there.

Learning German is likely critical to that person's ability to survive and thrive in this new country. The motivations between those two different people is very different. This absolutely has an effect on acquisition.

Seth Merrill:

Yeah. I really like that. I know that you, in the first article that you wrote, you talked a little bit about wishing that you maybe would have known some of these things as you were going through and how you could have applied some of these scientific principles around motivation and around crosslinguistic influences, like you mentioned.

I'm curious if there's anything in particular kind of a learner belief or myth that you carry with yourself that as you began researching this was mind-blowing or eye-opening to you to realize, "Oh, this is something I could have applied this research do to help myself."

Kristen Foster-Marks:

Yeah. Absolutely. Let's see here. I think that a really important one in SLA, one of the myths ... Or I shouldn't even say in SLA. One of the mythologies that language learners often hold is, you get this idea that like, "I shouldn't start writing or speaking in this language until I gain some fluency. Otherwise, the mistakes I make now, I will keep forever." This idea of like, "If I say things incorrectly, then that's how I will always say them. They will fossilize."

SLA research for a long time ago that this is not true, and we actually gain and develop writing and speaking fluency through producing the language. The mistakes that we make this week will not fossilize and become the mistakes that we make for the rest of our lives. As long as we can get some feedback on those mistakes and process them and continue to speak.

To me, the analogy in coding is this idea like, "I need to spend a week reading documentation and watching courses before I try using this language or feature or technology, and I'm sure as hell I'm not going to talk to anybody about it until I'm ready, because that's embarrassing." There's that imposter syndrome coming up again.

I think many of us know that in order to develop these skills, whether they'd be programming languages, or some of the technologies that utilize those languages, we have got to spend lots of time coding and playing and tinkering. There's only so much benefit you're going to gain from just exclusively reading documentation and watching instructional content. You have to actually produce output, too, to make it stick and really learn. Ideally, you need to be getting feedback on that output.

We talked about code reviews earlier, and how they can be really scary. Because you're putting your work out there for people to critique, that's the point of a code review is to find what is wrong with things. Well, if people point out 10 things via this code review that you can improve, that's a learning opportunity. You just got paid to learn that. You just got paid for that. Yeah.

I think that that's the one thing that I wish that I would have ... Certainly as a language learner would have put myself out there more and not just waited until I was ready to start producing the language. It's something that I have to remind myself of very frequently, even in my current role that I need to talk about coding, and I need to produce code, and I need to have people who are listening to that, and seeing that, so that I can get feedback from them for my own improvement.

Seth Merrill:

Yeah. One thing that I hear comes up a lot when we do live streams with developers that are in this learning public fail and public mindset. When people ask them, what language do I use? What tech stack do I use? It's really always about what do you want to build? You have to have a project. You have to have a goal in mind. It seems that crosses over to what you're talking about with motivation, with goal setting, and things like that.

Kristen Foster-Marks:

Yeah. Absolutely.

Seth Merrill:

We've talked a little bit about failure. It seems like one thing that's come up in your researches, if we can anticipate, what happens when you face roadblocks or you face failure in the language learning process, then we can respond to that in a really effective, studied way, I guess is how I would say it. I'm kind of curious. What you've learned through your studies about failure and about overcoming roadblocks and overcoming setbacks in the language learning process, and how that can be applied to learning to code?

Kristen Foster-Marks:

Yeah. That's a really good question. I think one thing that comes to mind is ... Well, this is even just general educational theory and general learning theory. But I think most people are familiar with the idea of growth mindset that Carol Dweck introduced. I probably shouldn't throw a year out there. I'm not quite sure what year she started publishing on that.

But she distinguishes between growth mindset and fixed mindset. A fixed mindset representing this belief that my ability is fixed, I'm either good at things or I'm not good at things. With growth mindset being this idea that, "No, if I try hard enough, and if I work hard enough, and if I spend long enough doing this thing, I can get it done. I can do it."

I think that it's interesting, and I've seen this in my own experiences. But it also comes out in the SLA research that people really believe that some people have language learning aptitude, and that some people don't. Actually, the US government invested tons and tons of money in developing assessments around sussing out whether people actually have language aptitude or not. They were really motivated to get people upskilled and fluent in languages really quickly for national security reasons.

They invested a ton of time in research into this. They did find that some people do have better aptitude than others. But to get to my point, anybody can learn a foreign language, and anybody can learn to code. You have to believe that you can do it. There's that belief aspect. We can hold beliefs, either about ourselves, or the language learning process, or the nature of learning that in conjunction with each other can convince us that we can't do this thing.

But if we actually assess the situation, we can do it. We can absolutely do those things. It might take some people a little bit longer than others. We do have evidence that says that some people have that attitude, and that others don't. But a lack of aptitude doesn't mean that you can't do the thing.

Seth Merrill:

I liked that you talked about giving developers the space to tinker, and actually get in and just code and then be able to have that feedback loop. One thing that is really important, and I think we're seeing this a lot in, for example, how Pluralsight approaches content and giving people hands-on learning opportunities. I'm curious if you could speak to why hands-on learning and giving people the space to actually practice and fail and learn with code is so important.

Kristen Foster-Marks:

Yeah. Absolutely. I think part of that has to do with learning styles. I know that some people they do learn by watching and by listening. Their learning style might make ... Some of those just sit and watch courses a little bit more effective for them than for somebody who doesn't learn that way. I think that the fact that Pluralsight is really expanding the types of instructional materials, the modes in which they deliver instruction, is really great in helping those folks who don't learn the, I'm going to sit down and watch this video away.

But with that said, even ... I never just sit down. I do learn from videos, that is my way of learning. But I never just sit down and watch a three hour course from start to finish. I will typically watch a couple of the videos, and then go find something in my company's code base, where I can apply that learning, and then go back and watch a few more and learn something new. Then go back to the code base and practice it.

In that way, I'm getting some reinforcement of the concepts that I'm learning. I'm getting to read some code. If I see that I can contribute in some way to those code bases even better, that gives you the opportunity to actually produce output. Sometimes I will go to my own developers. For example, I'm learning about Spark, Apache Spark, and specifically PySpark, because a big component of my team's stack uses a Spark for big data processing.

We have a developer [Duansho 00:38:59], he's so smart, an amazing teacher, and he is the expert on our team. I'll go watch some videos. Then during our one-on-ones, I'll come with a list of questions of, "Okay, Duansho, I learned this. Can you tell me how this is working in our particular application?" I'll just go peruse the code. Yeah.

I think that engineers really need to keep in mind as they're learning these skills, that the more that you can bring in what we think of in language learning as the four skills; reading, writing, listening, and speaking, if you can incorporate that concept in your own learning, read lots of code, listen to people talk about code, listen to the videos. Talk to others about it so you can gain speaking fluency.

Because this is such an important part of our jobs, as engineers, is being able to report what we're working on and describe problems that we're running into to either our leaders or to our developers that we pull in to help. Then of course, there's always the writing part. Essentially, we're writing code. That's the bulk of what we're doing.

Seth Merrill:

To what you said about how you learn, it's not just sitting and watching videos, and it's not even just taking breaks to apply it hands-on, but it's also all those other things of applying it in the context of your business or a problem you're trying to solve or explaining it to a colleague, which helps you create that connection with them, but it also cements the learning for yourself.

Kristen Foster-Marks:

Exactly. Absolutely. In language learning and SLA, we talked about meaningful input and meaningful outputs. You need both in order to learn and to acquire that language, same for coding. I think, especially, when we force ourselves to produce that output, and somebody can ... When we start negotiating for meeting with another interlocutor, they can point out to you where you have things wrong, where the mistakes in your logic are, or where you're not quite understanding the technology.

If you don't pursue those opportunities, then you might not come to understand your own misunderstanding on your own.

Seth Merrill:

It seems in a lot of ways assuming that you have a safe space to do it, failure is synonymous with learning a lot of times in learning to code. I'm curious if ... I'm sure that you've experienced a lot of that failure in your learning process, that's not me a slight to you, it seems like it comes with the territory. I'm curious if you have any personal insights for those that are maybe in that situation you were six years ago. How do you deal with that failure, and use it as a growing opportunity, and not as a setback that causes you to question your entire life?

Kristen Foster-Marks:

Yeah. Absolutely. I will say it is hard, especially if you're coming from a lifetime of perfectionism, which I think a lot of us are. That perfectionism can be ... It can really bring a person down. It hinders. It doesn't help, I think, in most cases. I think that for folks who are coming into it, you really just have to normalize it to yourself the idea that you are going to fail a thousand times a day, truly, a thousand times a day.

If you're coding for even six to eight hours, it really is going to be ... You're just going to make mistakes. Luckily, the computer is the only entity that is ever going to know that you made a mistake. No other human has to know. But eventually, eventually you will end up at a company on a software team. Then most of your mistakes only your computer will know about. But some of your mistakes will become public. It's okay. It's going to be hard at first.

But everybody around you is also making mistakes. If you're really lucky, you'll wind up on a team that has this explicit fail-fast mentality. I remember, I worked at Zayo Group, a couple years ago. That was just such a lovely job with such lovely people. I remember just really beating myself up about introducing a bug into the production instance. Any type of public failure, really, I would just beat myself up about.

I remember having a conversation with Nick Besch, who's a VP of engineering, just a really wonderful, calm person. I remember him saying to me, "You know what? It's all good. We fail-fast here. We fail-fast. Move on. You learn from it. We're all going to fail again." That was just ... I think that for any leaders who are out there listening, you really have the opportunity to help your developers and your colleagues and even the leaders above you that make failure a norm, and make talking about it a norm.

At the individual level, I think, we as developers have the responsibility to prop each other up through those failures. If you see someone struggling with that, lend them a hand and just let them know, like, "Hey, it's okay. I can't tell you how many people have told me personally. Oh, Kristen, don't worry about it." One time, I deleted the whole production database, and I'm like, "Oh, my gosh, does that really happen?"

Yeah. Sometimes it happens. Sometimes people accidentally delete the production database. You know what? Nobody dies because of it, everybody lives.

Seth Merrill:

Yes.

Kristen Foster-Marks:

Yeah.

Seth Merrill:

Yeah. Yeah. Yeah. That's something my manager personally said when we just went through a period where we were just a little bit understaffed, and it was this freeness of this burden, that failure, of just saying, "Look, we're going to fail at some things and that's okay." As a leader to have someone do that it's just a huge burden lift of it's not only acceptable to fail, it's encouraged because it's a learning opportunity.

Kristen Foster-Marks:

Absolutely.

Seth Merrill:

I love that.

Kristen Foster-Marks:

Absolutely. Yeah. We can be kind to ourselves, too. I mean, I think I mentioned this. But I've been doing this for five years. I'll be honest. Two days ago, a mistake that I made, a bug that I introduced into our code base ended up delaying a deployment. It was a very public failure, because this deployment had already been delayed for a couple days. I was always beat myself up about it.

I ended up having a one-on-one, regularly scheduled one-on-one with Lilac, my manager. She was just so kind about it. She was like, "Kristen." She's like, "Is anybody making you feel bad about this? Or are you making you feel bad about this?" I was like, "Oh, my gosh. Lilac, you sage, you're so wise. I'm the only one who's making me feel bad about this." Absolutely. I'm the only one. Yeah. We have to be kind of ourselves. We have to be kind to each other.

Seth Merrill:

I have one final question as we kind of wrap up. I'd love for you to lend your personal experience of recently going from individual contributor to leader. But I'd love to ask what does the future of learning to code look like for you, both for those learning to code, and then managers of people who are in that process themselves?

Kristen Foster-Marks:

Let's see here. Yeah. I think I do have a few predictions around this. It's no secret that we have an absolute dearth of qualified software engineers in the US right now, especially relative to the number of positions that need to be filled right now, but also that they're projecting will need to be filled. We already don't have enough people. Five years from now they're expecting us to ... there to be even a wider gap between what we've got and what we need.

I think now there's irrefutable evidence that adults with no technology skills can learn enough coding to become junior software developers in six months. I think that we're going to be seeing a lot more company sponsored boot camps. I've seen this popping up a little bit. We're large companies, and companies that aren't necessarily software companies, even they seem to be catching on that they need a lot of developers that there's not a steady pipeline coming out of traditional programs.

That they're recruiting and their training can happen in-house. I think that we're going to see a lot more of that. I hope that we're going to see a lot more of that. I'll be honest. That's a big part of the audience that I'm thinking about as I'm writing this SLA series. I really hope that folks who are scared of it, but are interested in it, and maybe have the opportunity.

It can gain the confidence to just go do it, because they can. If your company is going to help out with that, then, man, take advantage of that opportunity. I think we're going to see even more folks come into the field self-taught. I think that's another trend that we're going to start seeing. I have had two women join my team in the last few months, Olivia and Sarah.

They had long careers in other fields. THEY taught themselves how to code, didn't go through boot camp. They're killing it. There are just so many learning resources online that are both free and paid. A person can do it. A person can do it. I think we're going to need some serious access to internet. The world, that nations, that leaders need to get on that more seriously, getting Wi-Fi out to their constituencies.

Because, yeah, there's a lot of untapped potential out there, just in folks who don't have access to that technology and don't have the ability to take advantage of those resources. I'm hoping that we'll see that more. Then I think that you asked ... Did you ask what leaders can do?

Seth Merrill:

Yeah. Just what can they do to support lifelong, continual hands-on learning for their teams?

Kristen Foster-Marks:

Yeah. That's a great question. I think that leaders and companies need to have a very explicit culture of learning. I think it's something companies need to talk about, that they need to organize around and have abs strategies and roadmaps for. Because I mean, especially ... I think it's probably like this in all fields. But especially in programming, if you don't have at least part of your daily work hours, or your weekly work hours dedicated to focus learning.

Not watching a video here and there between meetings. But I can sit down for two to three hours and really dive into this stuff, at least a few times a week, then we're just going to see our developers fall behind with their skills. I think that will breed more imposter syndrome. I think that imposter syndrome is very stressful. It's so stressful to feel that.

I think that sometimes people get to a point where they're like, "Oh, my gosh. I can't do this job anymore. This is too hard. I'm just going to go find a new job using the skill set I already know." Hopefully, they're not outdated by that point. But I think that we do see this. I think that leaders and the companies behind them needs to just acknowledge that we need dedicated time and resources for this.

Seth Merrill:

Yeah. Yeah. I like that you mentioned that. It seems like it may also burnout if you don't have that dedicated time, because then you're just trying to make up for it by working harder and spending more time on things where that perhaps smaller time dedication to learning can pay bigger dividends.

Kristen Foster-Marks:

Absolutely. Yes. Absolutely. Because at the end of the day, there are plenty of engineers who love to do this stuff so much that it's their hobby. They're doing it on the weekends. But not all of us are like that. I'm not one of those developers. I'm not building side projects on the weekends. I need my work time to include that time to learn. I think that that's becoming more and more normalized. It is absolutely the norm at Pluralsight, which I love.

It was one of the reasons that I joined this company. Yeah. I just hope that we can see more and more of that. Because you're right, that burnout, it's so bad, and people leave companies because of burnout.

Seth Merrill:

Yeah. Well, Kristen, thank you. This was fascinating for me to talk about. I love the analogies you drew. It seems we'll need another one of these conversations at the end of your article series to sum up some of the additional learnings and things that you've discovered. I feel like we could fill another couple hours.

Kristen Foster-Marks:

Oh, my gosh. That would be so fun. Well, Seth, thanks so much for having me on. Yeah. This was just so much fun. Nice break from coding.

Seth Merrill:

Yes.

Kristen Foster-Marks:

Yes. Absolutely.

Seth Merrill:

Well, thank you.

Kristen Foster-Marks:

Great. Well, thank you.

Seth Merrill:

That's it for today's episode. I hope you enjoyed. To listen to past episodes of All Hands on Tech, please visit pluralsight.com/podcast.