DEV Community: Jenn Creighton

Single-threaded Podcast: Kyle Shevlin on Healthy Boundaries at Work

Jenn Creighton — Thu, 31 Mar 2022 18:30:14 +0000

Today on the podcast, I'm joined by Kyle Shevlin. Kyle's a software engineer working with JavaScript, React and more. And we talk about everything, like a little bit of everything, honestly. We start talking off about our history with jobs. We also talk about how to have healthy boundaries at work. What happens to your ability to grow in that role, if you don't, and how there just is no special secret to the universe, life, and everything else. It’s a really great conversation. Hope you enjoy it.

[INTERVIEW]

[00:00:50] JC: Hey, Kyle.

[00:00:51] KS: Hey, Jenn.

[00:00:52] JC: So, stoked to have you here. Seen you on the Twitter, we've had a few DMs here and there. I think we agree on a lot of things in this field.

[00:01:01] KS: I concur. I mean, that's why I sent you some DMs is like, I really agree with this take, this is a good take.

[00:01:08] JC: It was good for me because like, this is not a field where people – people want to disagree with you a lot in this field. I don't think they want to agree with you very often. It's my feeling.

[00:01:22] KS: We could probably go down that road but this might take like Mark Twain said a man pardon the the genderism, but you know, of his time, a man can live two months on a good compliment. And that always struck true to me. And so, like words of affirmation mean a lot to me. So, as silly as it sounds, I go around the Internet sometimes and just share affirmation with other people. Because in some ways, I wish people would do that to me. But to be frank, your talk on composition years ago is like chef's kiss, I can't do that emoji audioly, but I think I just made up a word too. But it was so good. And I've tried to write like a post on composition a few times. And I'm just like, “I am not going to beat this. Here's the link, here you go.”

[00:02:08] JC: That makes me feel really good.

[00:02:09] KS: It's good.

[00:02:10] JC: I had to give that talk in front of some of the React team too. And I was like, “Oh, God, what's going to happen with that?” It all turned out fine, but it's nerve wracking when you don't know –

[00:02:20] KS: Andrew’s going to show up giving you like, some real optimization or something like that, in a stocky way, or something like that. No shade to Andrew. You really have to understand his Twitter to understand how he talks on there.

[00:02:36] JC: Yeah, I understand his tweets differently there. Yeah, you and I are both active on the Twitter. We're kind of like out there in the space, which means that our history in this field is sort of up for anyone to sort of look at and make decisions on. And so, you've had an experience that I've also had, which is that we haven't always found jobs to be a really good fit for us. We haven't been able to stay in certain jobs for very long. So, before we start recording this, we're sort of talking about this. What's been your longest tenure at a job?

[00:03:13] KS: Oh, that's a great question. It was either my first job which I honestly cannot remember how long I lasted. I just know I quit on my own terms, or Webflow. I at least remember getting to my two-year anniversary at Webflow. I am not shy about the fact you look at my resume, it’s not the linear path HR and hiring managers are really hoping for all the time. So, but pardon my French, but shit happens. I don't know what else to say sometimes.

[00:03:43] JC: Yeah, I mean, if you look, I think my longest tenure is a year and a half. I didn't even get to hit two years at a job yet.

[00:03:51] KS: I think tenure is a little overrated in some ways. Like you guys, especially earlier in your career. I want to be clear to anyone who's listening to this, like, if you're early in your career, and you're growing super-fast and you realize you can go get a big old honking raise by going somewhere else, that's okay. I took an 86% raise one time in my career. I went from 80k to 150k. I didn't even know like that was like an amount of money that was possible, like at the time, but that happened early. It's not going to happen as often as you get further. And I think, we were talking about it, but part of why I want to like stick around at places longer now is like as you get further, some of your goals and the things you want to achieve at work really require more time to be like influential or just to even pan out because you're trying to do things that are on a slightly bigger scale than just like, can I learn, learn, learn and upskill really quickly?

[00:04:51] JC: Yeah, those early experiences that I had early in my career were really about like, just getting acquainted with the field, getting acquainted with how things work, seeing if I was a really good fit, seeing if I could get all the knowledge into my brain, looking at different code bases, working. I worked at like consumer, I worked in B2B. So, getting like a sense of the lay of the land. And then once you hit like a certain seniority level, you're really about planning features, leading things. You can't just pop off after a year, if you're wanting to make like a big impact.

[00:05:27] KS: Or learn from your own mistakes, like get feedback on your own decisions. I realized I kind of took us a little bit off track, but I can kind of get us back to the fit thing, because I do want to be clear to people listening about that, too. It's a difficult balance to strike. But I think if you get to a place, you get to a job, and you realize, like, “Oh, this isn't what I thought it was going to be.” Like that happens like I straight up felt hoodwinked that my second job. I went into an interview with a bunch of “engineers”, and I thought these were like engineers similar to me, and they asked me a bunch of questions on web development, and I tell them answers and stuff.

When I took the job, I come to realize they had kind of scripted those, but none of them were web developers. I was literally the only web developer in the company. It was a really small shop. And you make mistakes. I knew within two days, that wasn't the right place to be the challenge being it took eight months to find like the next job, and I'm not shy about like how my job searches go, they don't go the way people think they should. People see the 25,000 followers on Twitter and think, I’ll just be getting the best offers in the world every single day. But the truth is, I think as you get a little further, and you know yourself better, and if you're willing to have boundaries and say, no, I think that's a big part of it. You realize, like, not every job is really right for you, or not every job is really going to help you go forward and the way that you're hoping to go forward in your career.

So, you can end up being selective to the point where people might think you're being overly selective, overly cautious, or all these things. There's just so much that goes into trying to find a good job, have a good fit. And even when you find it, it can change. The best job of my career so far got changed right under my feet really quickly, and kind of sent my whole world in a whole different direction. I don't know, again, shit happens. It's not easy.

[00:07:29] JC: Especially in startups, I had that happen. The best, well, actually, technically, where I am right now is the best job of my career. But previous to that –

[00:07:37] KS: Always applicable, right?

[00:07:40] JC: So yeah, I had this job, I loved it, it was the first time actually I ever got promoted, which was a big deal to me. I got promoted to senior at that job after six months. I mean, I should have come in as senior. But that's a whole another discussion for a whole another day. And I got a lot of the things I needed out of that job. But it was a startup. So, after a year, the culture was completely different as we started to scale up. And so, six months later, this was the one I lasted a year and a half at, I had to leave because it was not a company I recognized anymore, and I wasn't getting the same value out of it anymore. And then it took me a long time to find a good fit. I mean, that was back in I think 2016, 2017. And I didn't find a good fit again, until really now at Netflix.

[00:08:28] KS: See, and that's a long time. I wonder if people really, really understand that I feel a little, I don't know the right adjective, strange, awkward, different, and that I think there's a whole bunch of people in our industry who just like, they don't care about what they work on. It doesn't bother them a lot. They're really able to maybe compartmentalize work into one box in their brain and just live the rest of your life. And so, these people and gosh, they seem to accumulate on things like Hacker News.

I’m sorry, really don't care orange site, you want to make fun of me, please do, like link this post and rail me, I just don't care. But like they congregate in these places. And they're like, “Well, why can't you be the same way? Why can't you just take a big paycheck and not give a shit about what you work on?” And then it's like, “Sorry, I'm not wired like you bro. I want to care about what I do.” And when you spend five years in your case, or other people and you're just trying like, it's so much energy that goes into just trying to make the thing work, or try and figure out the next step that I think that energy really could have been used better in another way. If just the situation was a little different, or you were able to get this break instead of that break or something like that. I don't know. I think about this a lot.

[00:09:51] JC: I've had also the experience of I cared very much about where I was working and the people I was working with and I saw a broken system and I wanted to fix it. I put a lot of time and resources and energy into trying to fix that. I had this good conversation with my therapist the other day. She was like, “Why are you trying to fix like a failing system? Like it's failing, just let it fail. It's not your responsibility.”

[00:10:17] KS: Yeah, it's probably a little easier in times to maybe just go try and find a better system than it is to try and fix the broken when you're in. But I feel that. I think one thing I'm starting to realize, I'm coming up close to 10 years of doing this professionally. I don't want to be the hero. I think about this a lot, right? If some job is coming at me, and like, they're saying, “Oh, you can come in, and you can have all this impact and influence.” And I'm like, “There are things I want to do. There are things I want some influence on. But if you're portraying me to come be some hero to come fix some system or something, I'm not your person.” I think a lot of times that happens in this industry, though, like people try to be heroes, or people are recruited to be heroes. And I think it's really tough. If you can, bravo, can’t golf clap too. But I think most of us just want to work somewhere that at the end of the day, we still feel good, we still feel like a human instead of – I’ve been telling people, I want to feel more than that I'm just a pair of hands that happens to know how to code.

[00:11:26] JC: That hero bit too, I don't want to be the hero. There's actually, in the first season of this podcast, I talked to Jeff Lembeck about hero culture and what that actually does to like, the system that you work in, and also what's doing to the heroes. Because what you're saying about, I don't want to be your hero, yeah, you don't, I don't. I don't want to be the hero. I want to have impact, I want to make things better, especially because I work on internal tools, like that is sort of my wheelhouse is I want to make things better for the people around me and I want to have that impact. But I do not want to be the person that everyone calls for every single thing and everything rides on my shoulders. And there's resentment from other people about the things that are given to me or the way that I am treated at work. I mean, I've definitely been on the outside of that seeing someone being treated as the hero and being like, “This is unfair. This doesn't make sense.” I mean, it doesn't work for this organization.

[00:12:23] KS: It's just unsustainable. If you can't have systems where people can find the information, they need to help themselves, which I'm mostly thinking about like documentation and living in async, like an async communication world. I've been remote for like five years now and that's always a challenge, even for companies that are remote first. I haven't been anywhere that's really nailed it. But yeah, it's just unsustainable, not just for the person who's doing it, but for like the whole team.

We talk about bus factors. Someone getting hit by the bus, and like, all this information, and all this stuff is lost. I don't want to become someone's bus factor. I'm more than okay with just like, I want to be a good part of a team somewhere. I think that's okay. In fact, we're talking about career growth a little here. If you don't want to be like the hero, that's okay. Let's make it clear to the audience. I think people on Twitter, see all these people working on these really cool things, and maybe just assume that like, you have to be one of them. You don't.

[00:13:28] JC: No. You don’t. It's totally okay. And by the way, you'll probably have a better mental health, life balance. The people that you see that this is 24/7 their life, do not have a healthy balance. Like you said, being a human, you want to feel like a human at work. That includes healthy boundaries for when you're not at work, right? And if you're the hero, guess what? You don't have those boundaries. You're the hero. That's a full-time job being a hero.

[00:14:02] KS: I fully agree. I'm showing Jenn my phone, because I've never put Slack or like work email on my phone, and I never will. That's about a boundary. If you want me to do that, I'm probably going to be a bit of an ass about and be like, “Can you give me a work phone?” I need that boundary in my life. I need to feel like, I can close a laptop at the end of the day and that's okay and that's a good day. I think maybe earlier in my career, when I think there's just so much you can learn that you're just, maybe you're at your laptop all the time learning, it can have real positive impact on your career. But if you're not careful, I think it can have a really negative impact on the rest of your life.

I'll give an example. There's definitely been years early when I was making the career switch, where my wife would be like, “Hey, can you get off of that and spend time with me?” And that took discipline and I'm way better at it now. In fact, I don't even have a problem really. I just shut the laptop and go. But I think a lot of people struggle with that. Gosh, there's just so many things you could talk about when it comes to like, career growth, and keeping a balance in your life while trying.

[00:15:17] JC: Yeah, so I also like, I don't keep work email on my phone. I do have Slack. But that's because I have on call, the support rotation. So, it's helpful for me. But also, when I go on vacation, guess what gets removed. Bye. I don't want to see that. It took a while for me to have those healthy boundaries, because I was really worried early in my job, that if I was not showing this “passion” for what I was doing all the time, and available all the time, that I somehow wasn't meant for this career path, or that I wasn't a good software engineer. Because, unfortunately, that was what I was seeing the senior engineers do when I had this. It's a big impact. If you're not going to do it for yourself, at least please do it for those around you. It does matter. They see you. They take cues from you.

[00:16:21] KS: Yeah, I agree with that. I've made very clear like what hours I work, and I don't respond outside of them. And I might like, leave my phone number, if you really need to text me for something. Luckily, I've not really been in the hot path of like, prod issues, most of my career, where that needs to happen. But I think just in general, that's a good idea. Because it's unsustainable, too. Like we've talked about, I've used that word a couple times, but I kind of look at it. I'm 36, and I've got like, probably 30 more years to work, assuming ageism doesn't make it impossible for me, and who knows what the future holds.

I mean, I think it's wild in this industry that you can get up to senior engineer and a handful of years, if you're at the right place, or get hired with that title, like my history. And yet, you could have 30, 40 years to go and it's like, what are you going to do? What's your growth going to continue to look like? And so, I think I've started to take an attitude of like, I don't need to move as fast as maybe people expect, or I guess to some degree that's privileged too. I'm happy to talk about that, as a white straight male. I get a lot of benefit of the doubt, to be fair, and I don't think everyone does. I think that gets reflected and what happens to them and stuff. But I'm really trying to consciously be like, I want to make it the long haul. I don't know that I can, if I'm constantly trying to do this job based on passion. Passion comes and goes sometimes. It doesn't stay for everyone. But skills don't. I'm still skillful ad I can do this, as long as you're not trying to burn me to a crisp every sprint or something like that.

[00:18:08] JC: It's a hard balance, because you want to be engaged with the work that you're doing. You don't want to just – just doing what you're being told to do is not a good system, I think for anyone in any field. It doesn't feel good, you lose autonomy. Autonomy is one of the quickest ways that you can burn out. The lack of that is actually, burnout is not necessarily about overwork, it is really about a lack of control in your environment. So, you want to enjoy the thing that you do, but also still have it bleed out into everything else, because as you said, unsustainable. Will it scale? It will not scale.

[00:18:49] KS: No, no, it won't.

[00:18:50] JC: It will not scale. You don't put email or Slack on your phone. Do you have any other like non-negotiables about your life that help you have those boundaries?

[00:19:02] KS: I ask when I'm interviewing, I will ask often like, how many hours do you work? How many times have you had to work overtime? I'll ask a lot of questions about that. It's probably sending the wrong signal. I think people might take the signal as like I'm lazy and to some degree, they're not wrong. I'll make a joke with them. I'm like, I'm not a spring chicken no more. I've got gray in this beard. I don't have 50 hours in me even. I'm just blown away that we don't have more of the six-hour work day or like four-day work week kind of stuff. Partly because the science like just supports it.

I realize like some economists are going to be like, “Well, we can't lose 20% of productivity.” I'm like, “You're already losing it. You just don't know it or you're not capturing it. You give me an eight-hour day. I'm sorry, my brain is going to be mush by like 3 PM. I might get something out, but it's not the same thing as me working three great hours like to start my day.” I guess one of my boundaries is just I ask about hours and I ask about – I'll ask things like, “Oh, you have unlimited PTO. How much PTO did you actually take last year?” I'm not necessarily great at taking PTO, but that's more because I'm a homebody that doesn't know how to have fun out elsewhere in the world. That's my fault. But I will take a lot of days. I've been asking them a really random question.

This is going to sound weird, but people who follow me on Twitter know, I'm an avid golfer. I was a collegiate all American, like it was my life for a long time. Golf has come back into my life because of tech, because it allows me to afford it. I don't know when climate change might steal all the golf courses from me. So, I'm trying to play while I can. I've been like, “Hey, if I wanted to take Thursday afternoons off to go play around, because there's a group that I play with here that does that, are you going to have a problem with me working Thursday morning, and then maybe Thursday evening, to make up the work?” I use that as a way to identify not only can I get my life to a place where I can have more joy and happiness doing the things I want to do, but also like, tell me how synchronous you need the work to be.

Because if you're like, “No, you have to be here.” You're not prepped really to do great remote work, in my opinion, anyways. You can have office hours or something when you really need that low latency, real time chat. But in our world with a pandemic, and just the fact that we work on the Internet, come on, you really got to become masters of asynchronous communication, and how to work in that environment. So, those are kind of ways I established boundaries, so that kind of make it clear, the amount of hours I'm going to put in, what I would love to do, if you'll give me the flexibility, the autonomy to do it, as you mentioned. And if they balk at it, I joke with people one of my superpowers is saying no. So, I will say no, and I'll just bounce.

[00:21:56] JC: Right. So you golfing is like a part of your mental health and a part of your life balance. And I think we're moving beyond this idea that from these hours to these hours are the work hours, and then the rest is your free time. You can actually kind of interleave these two concepts together. That's my secret is that I don't usually work like a full – I don't even work a full eight hours usually, I'm not going to lie.

[00:22:24] KS: Nice.

[00:22:26] JC: Because my brain can't handle it. So, I tend to take breaks during the day. I will go do a workout. I need to do workouts in the afternoon or else I don't get to them, I found out. So, that's for me and that's important. Or take my dog for a walk like I get outside.

[00:22:40] KS: I walk all the time. Yes. Do it do it. Daylight is a precious, precious commodity. I live in Portland, Oregon. Daylight is a precious, precious commodity. You go enjoy it, get that vitamin D while you can.

[00:22:53] JC: It’s also like, God, you're going to feel so much better when you come back from that walk.

[00:22:58] KS: I'm not off the clock in my mind. I often am thinking through a problem while I'm walking a couple miles around my neighborhood. And you know how many times I come back and I have the answer? In fact, a couple times in my interviewing recently, I've been tweeting about it. I've been in like these LeetCode hacker rank style problems, and I'll hit like, the wall that they want you to hit. And they'll be like, “Okay, what are you going to do?” I'm like, “Well, if this is a real job, I'd get up and get a snack and I'd go for a walk.”

My whole point of saying that is like I really actually want to see how they react. Are they going to be like, “Oh my gosh, what? You're not just going to sit here and bang your head against the wall and fight your way through this problem?” It's probably why one of the other reasons I haven't done super well at those in my career. But I mean, that's reality. If I hit a wall, what are your ways around the wall? It's not to sit there and bang your head against it. It's to get up and get a new perspective. It's ask a question to somebody to get a new perspective. It just blows my mind how many people like find it strange that you might go do something other than sit at your computer, to think through a problem and get work done.

[00:24:06] JC: It's so weird, because what we're doing, when we're doing our jobs is creative problem solving. And that creative part is pretty important. And there's two types of creativity. There's sort of intentional creativity when you're like, I'm going to sit down and make something and there's spontaneous creativity. And that happens a lot in the back of your brain when you're doing something else. So, you go to wash the dishes and you're like, “Oh, I solved the bug.” You got take a walk and you're like, “Oh, I have five ways I could probably tackle this now.”

[00:24:37] KS: Absolutely.

[00:24:38] JC: You need to do that for your own mental health and also for your job to take breaks.

[00:24:45] KS: Just speaking my language. I couldn't agree more. I've got a book for the show notes like that's related to this, When by Daniel Pink. It talks about like how timing plays a role in our life specifically, like times of day and how our bodies are different at different times of day. What chronotype are you? Are you an early bird or night owl?

[00:25:06] JC: What are you?

[00:25:07] KS: I'm like most people. I'm a bit of a third bird. I used to be a night owl. But I'm definitely like getting the olds where like, I wake up earlier, and I go to bed earlier. So, regardless of type, people experience, like a trough of energy. Most of us have probably experienced this, like midafternoon. That's what I meant, like, my brain is mush. But you're talking about background creativity, that's actually when it's best. It's like, you need to go do something else during that time, because the studies indicate that like, that's when you'll come up with like the answers that require divergent thinking. When your brain is energized and ready to go, default task mode is the easiest thing to do, like default decisions.

So, you want to like have tasks in that time that are like important and easy to make, quickly kind of thing. But I don't know, it's a really cool book. I've read it a few times, and it really fits kind of in this area. It's it would be interesting, hopefully to some of your listeners.

[00:26:07] JC: Yeah, I will absolutely put that in the show notes and probably get that book myself. I am on such a bend right now have various self-help and figuring out your brain –

[00:26:17] KS: Nonfiction kind of stuff.

[00:26:20] JC: I mean, I love fiction, but I felt like I needed help. I reached a point in my career, where I was like, “Okay, I need to figure out some answers. How do I do that? Ah, yes, I’ll go to the library.” Very Hermione Granger about these situations.

[00:26:36] KS: See, I'm kind of the opposite at the moment. I'm reading some fiction because basically, all I do read is nonfiction. I've told my good friend Kurt Campbell about this. Sometimes I look at books, like we're going to get ancient here a little bit, like ancient Gnostics. Do you know what Gnosticism is at all?

[00:26:52] JC: Uh-uh.

[00:26:52] KS: Okay, so Gnosticism was like a pseudo religion, about the time of Christ where – and a little before and after. But the gist of it, Gnostic from the Greek Gnosis means to know. The idea was like, you could learn secret knowledge to escape the entrapment of the body, free your spirit from the prison of your body. And if we take that, and we just adjust it, I know I behave this way. And I think a lot of people do. I literally, I'm going to show some books here on my to be read pile on my desk. I'm reading, Designing Data Intensive Applications.

[00:27:26] JC: Yup, I got that one.

[00:27:27] KS: I've got, I've got Domain Driven Design right next to me. But we look at these books with the hope that they will give us some secret knowledge that will unlock something in our life and our career. And the truth is, yeah, you'll get a little better from reading them. But it's not secret knowledge. It's not going to be a magic key that unlocks like this prison cell of where your career is, at the moment or your life or whatever. I mean, and it doesn't have to be these books.

I'll give an example from a different one. I've read Atomic Habits, like three times. Do you know how many habits I've been able to form since reading that?

[00:28:04] JC: Do tell.

[00:28:06] KS: Zero. It's not that I can't understand the concepts of like habit stacking, or incrementally working your way up to a new habit. It's that, well kind of comes back to energy, it all requires energy. I have found during the pandemic, as much as my motivation willpower might be there for a while, the ability to actually do it long enough to make a habit form has been near impossible. I'm trying to be really kind to myself about it. I don't think everyone's so kind. And I'm not always so kind either. But my point being, we read these books to hope they'll change our lives, and I really do hope they do for a lot of people. And I hope so for me, but I've kind of grown to be like, it's okay if I don't magically transform my life from reading these materials.

[00:28:54] JC: Here's something that I actually I've been thinking about this week, because I realized that not just with these books, which I do love, and I do pick up helpful things from, but I realized that with these books, and were certain people in my life that seemed to have it together, I'm hoping that they'll share the one secret with me. The one secret. I'm like, they must know the one thing that unlocks all the things or like I'm trying to learn a new technology or a new concept and technology. I'm like, “Well, what's the one secret little thing that will unlock all of this in my brain?” And sorry, it doesn't exist. You just have to gather up things and try things out and still go through the really hard process of growth to get there.

[00:29:38] KS: Right. You mean, I can't just like do something and be an expert at it tomorrow?

[00:29:43] JC: You can’t. It's so sad, isn't it?

[00:29:45] KS: Where's the matrix plug? I need that. Come on. I don't need kung-fu. I need, I don't know, how to scale databases to millions or some item or whatever.

[00:29:55] JC: Yeah. I just need to download it. I do, I have like maybe five or six technical books right now that are all open at different chapters. And I'm not really reading them in chronological order either.

[00:30:06] KS: I'm looking at my pile here, and this is just this pile. There's a pile near my bed, and there's a pile downstairs and some bookshelves. But this pile is probably about 20 books that I've read maybe a cumulative 100 pages of.

[00:30:20] JC: Which is apparently not a bad thing, by the way. These books are still aspirational and apparently, like having a purpose in your life. I had this discussion with a friend recently because my partner buys books and then doesn't read them. And I was like, “What are you doing? We live in a tiny New York City apartment, we can't keep having books.”

[00:30:37] KS: And moving books is the worst.

[00:30:39] JC: They're so heavy.

[00:30:41] KS: They're so bad.

[00:30:41] JC: I have a Kindle. And I only have some things in like actual physical form that mean a lot to me.

[00:30:47] KS: Well, that's smart. I'm not so wise.

[00:30:51] JC: But like, she had this conversation with me. She was like, “No, the books still have a purpose. Even if you don't read them, the book still has a purpose. It's a thing that you look and you see and you think about in your life, and it helps you just like sort of think about things and give you a framing even if you actually only read a few chapters of the book.”

[00:31:08] KS: Oh, absolutely. I mean, not every book needs to be read cover to cover. Two examples I can think of that I'm looking at are Refactoring. Excellent book. I think every dev who wants to grow in their career needs to get it. And specifically, the second edition is in JavaScript, and my audience is JavaScript. So, like, go get yourself that book. If only to learn what every factor actually is, and how to do it properly. It'll change your actual way of coding. Working Effectively with Legacy Code was a really good one. You only need to read like chapter one to realize, I love the definition. Legacy code is any code that's not tested. It's not that it's old. It's that it's not tested. So, you can't update it without figuring out what it does. But yeah, I'm with you. I've probably read a handful of chapters in both of them. And I was already like, sold, done. I'll recommend to everyone, because they made enough sense. Some books could be blog posts, like might be a good way to put it.

[00:32:10] JC: Yeah, yeah. Like this meeting could be an email, there's similar things with books, sometimes.

[00:32:15] KS: Yeah. What should we talk about next? I feel like I'm taking us everywhere.

[00:32:20] JC: No, this is good, though. Because I mean, yeah, this idea that one thing's going to unlock your brain or that if you – I mean, we were talking about if you sit down at your computer for eight hours that you're producing work. I mean, these are all kind of in the same same vein to me of like, the things that you think you should be doing to get a certain output. And actually, the things you should be doing are things like taking a walk and reading one chapter in a book. It's not what you think it is, these ways to like, keep yourself healthy at work.

[00:32:57] KS: That sparks something for me that I think maybe makes sense. You're talking about people have this idea of maybe what to do to get forward, and to some degree, how you get forward is going to be different person to person, because it also depends on where are you trying to go forward. Are you trying to go forward as a manager? Are you trying to go forward as a technical person? Are you trying to just go forward to get retired earlier sometime? It's still interesting that like, you can pick a direction and you can come to realize, like the things you thought that we're going to get you in that direction aren't maybe what they are. I'll give an example. I've primarily tried to focus on continuing to grow as an IC, mostly because I'm allergic to calendars and afraid of being a manager. Maybe I shouldn't be, but –

[00:33:43] JC: No, no. That’s a healthy fair. I've talked to many managers at this point.

[00:33:47] KS: I'm not even sure I can manage my own career, let alone, my six reports come on. But the things that have made me more effective as an IC are not just like, sitting there and poring over code bases. Or even though I do enjoy them studying algorithms and stuff like that, it that's just kind of fun to learn. That tickles the math part of my brain. But the things that have probably made the biggest difference and things I didn't know before I failed at them gloriously are things like, how do you drive consensus on a topic at work? How do you make changes at work that are about process that are about patterns? Not just like, “Hey, you built this little widget? What about how do you keep people from screwing up their widgets? And how do you do it in a way that doesn't make people scared and come at you or something?”

I don't know. I've had some pretty hostile colleagues in my day, about certain things. I think things like you know, I've maintained a blog for like six, seven years now. I think learning to write well has helped me advance just because I'm able to take the problem we're working on, and actually break it down and identify parts of it that maybe aren't obvious to other people or aren't easy to be seen without doing the work of like writing about it. There are just all sorts of things that might be the ticket to moving you a little increment further along, that might not be what you think they are.

[00:35:23] JC: I feel that very much, especially because I came from a writing background. So, I also have that like. I was like, “Oh, I'm really good at this. And surprisingly, this actually helps me in this field.” And there have been obviously times in my career to, where I was like, “Well, I don't have the people skills.” I haven't like developed the muscle yet for those things like consensus building or alignment, or how to do those things. But also, was working in environments where I didn't have a very good blueprint or idea of how to even go about –

[00:35:53] KS: You just triggered something in my head, keep going.

[00:35:57] JC: To develop that muscle at all. There was no one around that I felt like I could ask how to do those things. Again, I was looking for that secret little knowledge base somewhere about how to do these things. I was like, “What do I do? Read how to win friends and influence people?”

[00:36:15] KS: Yes, the Carnegie School of Career Development.

[00:36:17] JC: Yeah. But often, I think engineers, especially as you level up, you hit this wall, where no one told you that this was going to be part of the job and you don't know what you're doing. How do you make sense of it all? How do you figure out how to do anything?

[00:36:33] KS: Yeah, even as an individual contributor, I think that's happened to me. Like you get to a point where you're just not going to code as much. Because you're going to spend that energy and that time on like, decision making or strategy. One of my friends, Chase, he has a wonderful word for these things that I absolutely love, administrivia. Trivial administration that you have to do. Oh, my gosh, such a good portmanteau. Thank you, Chase.

You were saying that and a word popped in my head that I was thinking about this morning and I think it relates to this. And I think the underrated thing that helps people maybe develop their careers and something I've been craving for years, when I'm talking about like bad fit, support. You wanted that secret knowledge. What you're really saying is, I want someone who will support me, or some people be there to be able to support me, when I can't support myself, and I don't have the tools or the knowledge. We talk in this industry about mentorship or sponsorship, really what you're saying is like, we need support. The thing I haven't necessarily seen in my career is like, I'm just imagining this is probably likely to a lot of people. But the support infrastructure really isn't there.

You have managers and stuff, but really, they're just hoping you don't quit. That's not necessarily the same thing as genuinely like creating an environment or actually carrying about like, “Oh, yeah, hey, here's the next step. Here's what we can do, Hey, I see this talent and you let's work on that or something.” And I think as you get further along, I think one of the reasons I personally think about this a lot, is like I feel like I'm at this point in my career, where everyone's expecting me to support other people, and I'm happy to do that. But without feeling the undergirding that I need, or the help that I want to get to whatever I'm trying to do, it's the classic, you can't pour from an empty cup scenario. You get drained without getting the reciprocation of being filled. Yeah, I just think about that a lot. It's been on my mind a lot. And what you what you said really triggered that, for me,

[00:38:43] JC: I have felt the same in my career, especially with, I'm luckily at a place right now, where I do have the support that I crave and need and can get it in a different way. But when I was earlier in my career, especially with – there weren't a lot of people like me, on my teams, I was usually the only woman.

[00:39:05] KS: I was going to say the only one with purple hair.

[00:39:09] JC: Well, I didn't have the purple hair then but I would have been. Absolutely. I didn't have a lot of people that I felt I could look up for and get that support from. My managers were not well equipped. My managers were also pouring from empty cups. We were just all stretched very thin. We didn't really know how to do the things that we needed to do. I think that's why a lot of the times it ended up being a poor fit. Was that friction that you felt from not knowing how to move about in this job that you had gotten that you thought would be one way. It turns out maybe to be a different or like there were things that needed to be fixed and you just didn't have the support you needed to go about making that a place where you could have stayed.

[00:39:53] KS: Yeah, absolutely. I think you're talking about managers being empty cups too. And I feel that like all my former managers, no shade. I really do mean that. I think the thing I'm getting better at as I get older is just understanding that most people are doing their best. It just might not be what you need and that's okay, if we can have the grace in there to be like, “Yeah, that's okay.” Maybe the trick is also one thing I've been trying to do. And actually, I've been doing this for years and ways probably subconsciously. It's like you try and find maybe the answers somewhere else. Maybe you're not going to get what you need via work. Your manager might not be just the perfect person to help you get to the next rung. But you never know. You might find an outside resource. That was a wonderful – keep that in. Keep that in. Don't edit that out. That was hilarious.

I think one thing people kind of get a little wrong about me is they see like how big my Twitter following is, and what they don't really realize is like, part of the reason that thing is so big, is I put so much energy into it because things weren't going right in other places of my life. I see your face, you're like, “Hey, man, I get that.”

[00:41:11] JC: I know. I know what you're talking about.

[00:41:14] KS: Right? When you get a better feedback loop from Twitter from like, saying an insightful thing or writing something, that's a positive effect. I said earlier, affirmation, you all, like those likes, unfortunately, sometimes means something to my silly little brain. But I guess my point is like success doesn't necessarily transfer everywhere. I think some people are really good at it. I can think of a few off the top of my head who seem to be able to move success from one arena to another really, really well. I won't name names, though. My jealousy can stay a secret.

But yeah, I guess where I'm going with this is like, sometimes you won't be able to get everything you need, where you probably really need it. So, it's okay to look elsewhere. Just be careful, I guess. My goal in life is not to be a successful Twitter person. My goal in life is to have a happy life, and sometimes, even the mechanism we use to find support where we need it might be unhealthy at various moments in time. So, that mute button really helps a whole lot in that regard on Twitter.

[00:42:22] JC: Yeah, I did not start out thinking, “Hey, I want to become popular on Twitter, because it will be good for me in some way.” I needed some validation, out of the job situation. I started giving talks. I was getting what I needed out of that. I did that so much that I did an ungodly number of talks in two years, because I was getting hyped from it. And now guess what, not just the pandemic, I'm slowing down on doing that, in general. I'm not getting the same level of validation I get out of it. I'm way, way more into my work life at this point, and then also my personal life. I just want to spend time with my dog.

[00:43:04] KS: Nice, nice. Yeah, I'm with you. If I have something really important to say anymore, I think it's perfectly okay for me to make a like a video or write about it. I miss conferences, because I miss people like desperately, I really do. But the amount of anxiety and work that goes into making a good talk, I think you've gotten the chance to give the same talk multiple times, I've never been so lucky. And so, it's just fresh hell, every single time.

[00:43:33] JC: Yeah, it’s a lot of hours to write a talk down, a lot.

[00:43:38] KS: You talk about background creativity, a talk uses up a lot of that. It'll be in my brain like, it was probably in my brain for months before I proposed it. And now it's like, it's actively in the back of my brain nonstop for hundreds of hours, probably leading up to giving the talk. So, I'm with you. I'm doing fewer talks. I hope there's a day where I can still go to conferences again and feel comfortable. We were kind of talking about that, about various reasons why we might or might not go to in-person conferences.

But yeah, it's interesting because like, that's a way to experience some career growth. But it's not necessarily directly transferable to your actual workplace. It gets you maybe a network, it gets you maybe more warm introductions to a bunch of places, but it's no guarantee that you're going to transfer the success of getting to get on a stage and say some cool words to some cool people. It's not necessarily going to transfer to like oh yeah, I've got that promotion at my job or something like that. So, it's one of those things that you got to be careful about too.

[00:44:41] JC: Again, you think the path to get to a certain place is this one thing and it is not. You'll get valuable things out of giving presentations and writing blog posts. You absolutely will get valuable things, but it's not, if your trajectory is like I wanted to get to like senior, I want to be staff or I want to be leading this project, that's not how you get there. We're starting to wind down by the way. We're going to be saying goodbye soon. I just want to let you know.

[00:45:10] KS: I need limits. It's all good. I guess the thing I would say then is all the extracurricular success, I'm not saying don't do it. If that's what you want, to do it. If you want to go on talk, like go do a bunch of talks, do it. If you want to start writing do it. It will have positive externalities. The amount of people I've gotten to meet, including like yourself through participating in something like Twitter has been a big net positive in my life. What I'm trying to warn people is like success, one place might not translate to another. Probably the success you need in a workplace probably involves a lot of working well with the people you're working with, honestly, like, whether that's communication, whether that's building trust or consensus about some idea.

Luckily, that's a skill you probably can always improve. It just might take time, and it might be really painful. It's definitely been painful to learn some of those lessons for me. Hopefully, you don't have to go through the same shit I have. That's my only hope to anyone listening.

[00:46:16] JC: Yeah, it's a good hope. Though, growth is always uncomfortable. Growth is always a bit painful. I think it's an unfortunate consequence. And, yeah, as you're saying, things don't translate from one area to another, like one to one, including work life to personal life. Success in one area does not dictate success in another.

[00:46:34] KS: Sometimes they’re net zero. They can't see my grimace. I'm grimacing big time.

[00:46:40] JC: We both are. Alright, so as we're saying goodbye to everyone, do you have any final last thoughts, final things you want to say, words of wisdom, a book you want to recommend, anything?

[00:46:52] KS: I don't have anything particularly wise, just find me on Twitter, Kyle Shevlin and check out my blog, kyleshevlin.com. I mostly write about technical posts. I avoid what I call duct tape tutorials where you're going to duct tape X, Y and Z to make you know this thing. I prefer to talk more about patterns and higher-level concepts. I don't know, I hope it's refreshing to you. If you get a chance to check it out. It would mean a lot to me.

[00:47:20] JC: Alright. Sounds good. Thank you, Kyle.

[00:47:22] KS: Thank you so much, Jenn.

[OUTRO]

[00:47:29] JC: Okay, Kyle mentioned some books. I'm going to be sure to put those in the show notes for you. Check those out. They're good resources, even if they aren't the ones special secret to the universe and everything. See you all next week.

[END]

Single-threaded Podcast: Helen Hou-Sandi on the Real Value of Contributing to Open Source

Jenn Creighton — Fri, 18 Mar 2022 14:03:23 +0000

[00:00:00] JC: Something that I found sort of strange when I joined engineering as a career 10 years ago was the pressure to contribute to open source projects. It felt like it was necessary to move on in your career. And so, I did. I contributed to open source. And I don't regret that. But I wanted to have an honest conversation with someone else with experience in open source, about what open source is, how it works, and what contributing to open source actually gets you.

So today, I'm joined by Helen Hou-Sandi. She is an engineering manager at GitHub, and she has a long history in open source in the WordPress community. And that's what we're going to be talking about today. What is open source? Do you actually need to contribute to it? Let's get into it.

[INTERVIEW]

[00:01:14] JC: Helen, welcome to the podcast.

[00:01:16] HH: Hi. Thanks for having me.

[00:01:19] JC: I am really stoked to have you here because we're going to start talking about open source today, which is a big topic that not that many people actually have really deep insight into.

[00:01:30] HH: No. It is really hard actually to get into that. Yeah, we could talk about that. Yeah.

[00:01:36] JC: Engineers use open source, obviously, broadly, broadly. But the people who actually maintain that open source, or work exclusively in open source, or contribute to open source, that is a much, much smaller number. So you actually have insights that a lot of engineers don't have.

[00:01:56] HH: I hope so.

[00:01:59] JC: So previously, you just started a new role at GitHub. Obviously, like, I think when we think open source, we think GitHub. That's like par for the course. And then before that, though, you were a director of open source initiatives at 10up. And you were at 10up for a long time.

[00:02:16] HH: Very long time. More than 10 years. Yeah.

[00:02:20] JC: What were your responsibilities in that role as Director of Open Source Initiatives?

[00:02:24] HH: Sure. There are many. And being a director often means you're kind of deciding what you're doing, which is both – It feels great sometimes. And other times, it's very stressful, right? Where you're like, “What do I even want to be doing right now?” But generally, the mandate was figure out how we, as 10up, which is a client services agency, right? How do we fit into the open source ecosystem, right? Like, what is our responsibility to that, especially as an agency that, by and large, built sites using WordPress, right? As the content management system? And so that's really where that came from. I think it's kind of hard to describe without me kind of giving you a little bit of the backstory of how we got there. So I guess I'll just give you that.

[00:03:12] JC: Yeah. Let’s get to the backstory. Yeah.

[00:03:13] HH: Yeah. So I started 10up as like a regular old web engineer, like doing websites for clients. But I had started contributing to WordPress, just very lightly, I was like going to IRC chats at the time, like dating myself here. Went to a workcamp, which is like low-cost local WordPress event with the owner of 10up. I was the first employee. And so we were there, and at a contributor day, which is something really cool that happens at workcamps. And that's how I got into contributing in the first place, sort of, and I was given recognition as like a person who was making good UI decisions. And like, for the record, I started as a PHP, MySQL programmer, right? So like not a frontend person. But they ensured me at this contributor day as a person who was making good UI decisions.

And I know that they did that on purpose to kind of like motivate me to keep contributing. And because my boss, the owner of the company was there. It was like, “Wow, that's actually a great recognition both for you professionally and for us as a company. So how about I start sponsoring your time working on WordPress while you're at work?” right?

So we started with like five hours a week, which became eight hours a day a week. And that just kind of kept ramping up over time. And eventually, kind of timed out with my first parental leave. When I came back from that I just never went back on client projects for the most part. And so I just became a full time open source contributor. And from there became a lead developer of WordPress itself just through my work and having sponsored time, right? And I spent years just doing that full time. And so that could mean anything from working on the WordPress core software itself to looking for plugin opportunities polishing Gos, creating good process, being good open source citizens for our plugins or themes integrating into WordPress. We've had things that are not WordPress specific, but almost always web-specific, right? Where it's like, “Here's like a frontend component, or a set of linting rules. Whatever it might be.” And sort of not just embracing the legal side of what open source is, right? But like the actual ethos itself. And I think that's something that that's the part that really becomes complex, right? And how do you interface with open source, right?

So what you said about like most engineers are interfacing with open source in some way, right? But they're interfacing with it in a way that's much more like, okay, legally, the licensing, right? The source code is there for you, right? Which means that you can share it and you can use it, right? And there's a difference between that and like fully embracing that culture of the open process, right? The open process side of open source. That was really my responsibility, was figuring out like what are our rights? What are our responsibilities in open source? And how can we support this platform that we're building on? Be good citizens of that whole ecosystem?

And, frankly, yeah, it's also a part of marketing, right? Marketing, sales and recruiting, because it elevates your company profile. It also elevates your personal profile. And those are things that can and, frankly, should be used to your advantage, because you've done the work, right? So it's real work. That's in the public sphere, right? You can't just like pretend that you did a thing. There are people watching you. And so these are very real things, the real work that you've done. And yeah, you should absolutely use it to your advantage. And so that's what we did for a long time. And I feel very fortunate that I was able to do that for so long, even if my work now is supporting open source at GitHub, right? But not actually having to work in the open anymore as my day to day job.

[00:07:08] JC: Yeah, you've shifted into this different role, still very open source focused, but a very different type of role. As you said, like supporting open source, it is a very different thing than actually being in open source and writing the code and dealing with, you said, the open source community. A lot of people, again, like do not have insight into how open source projects, I guess, happen. I think sometimes we look at big projects that have company backing. Like Angular came out of Google. React came out of Facebook. A lot of open source seems to have this big company backing. But actually, a lot of open source does not.

One of like the big issues and open source is funding. And that means that there's often not funding to have people work on it full time. You're in a very interesting position, where the company said, “We will pay for you to do this. Is that like a common way that people start to move into being full time contributors? Is that their company starts backing them a smaller company?

[00:08:16] HH: Yeah. Broadly, I'm going to say no. I don't think that that's a common thing that happens. WordPress, specifically, it's such a large thing, right? Like, both in terms of market share, I guess, right? I’d say powers like 43% of the Internet. And by the internet, they mean, like, the top 2 million sites or whatever, right? Whatever it's shorthand for. It’s such a large percentage of websites, right?

And so it has like its own ecosystem. It's not just like a part of something bigger. But WordPress itself like exists as this huge business and software ecosystem. It existed before there was a company associated with it. The biggest company associated with WordPress, I don't know if people are going to hate me for saying this, but it's automatic, right? For Matt Mullenweg, one of the cofounders of WordPress, as the CEO, and they run wordpress.com, right? Like a hosted version of WordPress. But that came out of WordPress the software, as supposed to WordPress the software coming out of automatic. So that already is different from what you mentioned, right? A lot of like – Especially frontend libraries, right? Have this tendency of coming out of a company's work and then they want to solicit external contributions for whatever reason, or they find other people using it or whatever it is, right? But with WordPress, WordPress existed first. So that already sets it apart a little bit.

And then we have a very deliberate effort in that ecosystem called Fight for the Future, where Matt, personally, right? Through wordpress.org, right? Through the WordPress project, not through automatic, has called for anybody who does a significant portion of their business to give back 5% of their resources to supporting WordPress.

So in the WordPress ecosystem, you do see more listings for like we want a WordPress contributor, right? We're hiring for somebody specifically to contribute to WordPress, which is a broad mandate. That doesn't just mean contributing PHP or React to the core software. It could mean free plugin offerings. It could mean free theme offerings. It could mean sponsoring word camps. It could mean sponsoring translators. Sponsoring accessibility work, right? There're so many areas that may or may not be tied to a specific software release, which is the thing that tends to get the shine, right? But there's so many aspects of like the broader ecosystem, the infrastructure of serving millions of updates with translations, with good accessibility, with captions, all of that stuff. And so because it's such a broad area, then yeah, you can hire any number of skills into doing that, right? It's not such a narrow thing to be hiring for as well.

And then another thing that I've been thinking about a lot lately is – And I don't know if I have like eloquent thoughts about it. But it is easy to think about sponsoring people to work on WordPress, right? Because it's something that is user impactful, right? Because it's user-facing software. Again, because it's so large, there's always something to be working on. Whereas like the bigger problem is like I don't want to call it like the long tail because somebody to me like, “That's not what statistically it means or something.” But the dependency whole, right? Where you have like a thing that on its own is kind of like, “It's maybe a little bit small thing, whatever.” And like you wouldn't hire somebody to work on it full time. But it's the thing that everybody else depends on. And so how do you think about supporting that? Because like, no, maybe you don't need to hire somebody full time to work on that one little package, right? But it's critical that it keeps operating without incidents, like a thing that happened recently, right? Which, like, I don't know, I don't know anything because it happened before I started at GitHub, and it involved like GitHub suspending an account. And well, it’s just commits and all that kind of stuff. And it's like does sponsorship actually fix that problem? I'm not sure, right? Because like they could have done that whether they were being sponsored or not. We can't know for sure whether that would have fixed that specific situation.

And also, it does remind us that we have this system of dependencies, right? It's not just like in the JavaScript side of things. PHP has the same thing where you have composer on the PHP side. Ruby has gems. Like there are packages fricking everywhere. There's dependency management everywhere. And like how do you start thinking about like how do you support that lib, that tree, that's underneath you without trying to micromanage it, right? And that's something that's also hard.

It's easing about like, “Okay, could somebody like GitHub, right?” I did not have corporate marketing training before this. So I don't know if like [inaudible 00:13:30]. But like, before. The before times. Like you could think about like in a sponsorship style program, right? Like could a company just like donate, pledge, I guess, a bucket of money. And that bucket of money is like distributed based on packages, right? The dependency graphs in their projects or something, right? That's really wild to think about. Like that's not a “Hey, that sounds like a cool idea. Let's make it happen tomorrow,” kind of effort, right? But like is that the type of route that people want to go down? Do we want to think about like continuing to celebrate the individuals, which is a big part of the open source culture, right? Is that there's this tendency, which I personally like, of celebrating individuals and not companies, right? That's something we struggle with in WordPress, is, yeah, like we give props. We give credit to individuals, right?

And not only are you not supposed to share an account because it's like not good security practices. But we want people to be able to have that pride of like I worked on the thing. Not just like my company work kind of thing. But like I worked on a thing. I leveled up my skills. I learned something, right? And so we, as a project, really are pretty on the ball about making sure that it's individuals getting credit for their contributions, for their individual contributions, as opposed to like their companies taking the credit on their behalf. But at the same time, like, yes, these companies are sponsoring the work. They're enabling the work. And so how do they get credit outside of that context? And that's sort of like another one of those like push-pull kind of things that I think Drupal actually does a better job of than WordPress. And I think a lot of it is because they're much more embedded in that style of work, in that enterprisey type of mindset that people like top-down and build, but like that's a real thing, right? So yeah, so that's kind of where my brain has been going lately about open source.

[00:15:38] JC: I love that you brought up the dependency tree, because from the outside, if you're just an engineer who uses open source, and by the way, there's nothing wrong with using open source and not contributing, because not everyone – We'll talk about this probably a little bit later. But not everyone can contribute or should. From the outside, if you're just sort of using the projects, you don't have the sense that so much of what you do is probably dependent one package that someone in their free time wrote and manages. You probably have no sense of how individual contributions really matter in that. Once you're working in open source, you feel like it's a deck. Like someone built like a card, like, tower. And it could just try to fall over pretty easily. Like you mentioned, the incident where someone who was a maintainer of a project, on purpose, put in malicious code and corrupted the packages. And there had to be – And thankfully, there were mechanisms to stop that. But in previous times, there may not have been.

People do need to understand that the dependency tree and how much that actually is individual efforts. You said earlier too, the responsibility, responsibility in contributing of companies that are using open source to contribute back is a conversation that I think doesn't always happen. Quite often, I feel like the responsibility gets pushed to individuals in the engineering community almost as a – I guess we'll just start talking about this now. Like I think the overall theme that I've been hearing for all of my career is you need to contribute to open source, because you use the thing at your work, which is a bit bizarre to me, because the company is the one using the thing. And so they should be giving you like the time to be contributing back, right? Tell me your thoughts. Your face went, “Mm-hmm. Mm-hmm.”

[00:17:40] HH: Yeah. Another thing that's been on my mind, a much smarter person than me. I’m so bad at remembering where these come from. I would have to look it up later. Maybe we can like send you a link or something. But there is a thread on Twitter recently talking about like maybe this trying to put open source in the framework of like money, of capitalism, is actually like not the right thing, right. And that's a really hard thing for us to hear, because like in software engineering, one of the hot topics of the current time is getting paid for your work, right? Like this is capitalism. We operate in capitalism. Let's get paid, right?

And with open source, like, yes. Like what I was saying about, like, is sponsoring in dollars in a way that comes out to be — can’t think of the word — but like relative to other usages, right? Like is that something that would even actually fix a problem? Does throwing money at the thing actually fix the problem?

And I think like the thing we're struggling with is that, deep down, we kind of all know that it doesn't, right? It doesn't fix the baseline problem of like we, in general, like humans, have kind of lost the sense of communal responsibility for essay, right? Like what is the tragedy of the commons? It's not just that like one individual went in and like let his sheep or goats, or whatever it is, like [inaudible 00:19:10]. You see how great I am at remembering things. But it's not just that. It's that they've lost that sense of communal responsibility, right? It's not just the taking of the resource. It’s that you have to kind of fix the underlying motivations for caring about a thing. And that's something that like I don't know how we solve for that, right? And maybe all this focus on like getting somebody paid is kind of taking us down the wrong path long term, right? Short term, like, yeah, I think that people should get paid for their work. I think that companies – Maybe a company under the current framework would only learn to care about these things if it costs them more. Maybe that's the current reality. But if we keep following that path, is that going to actually take us down somewhere that we kick it out of, right?

Also, engineering, like we can talk about tech data or whatever, but it's like you don't want to box yourself into a corner, basically, right? And are we going to do that if we kind of chase this concept of like get paid for open source, right? And I think I'm guessing that we're going to fall into this topic. So I might as well continue the train of thought. But on the individual level, like when we talk about the online discourse, right? The very flattened discourse about what is open source contribution? And like should we be encouraging people to do it? And, at least on the Twitter, is very flattened, right? Where it's either there's no nuance to it, or it's either you should contribute to open source because it is the greatest way to grow your career, right? Versus nobody should ever be doing unpaid work. And it's like this is not. [inaudible 00:20:55]. Like that’s a great way to get off the tweets and like get the engagement, I guess. But like I think that all parties involved know that that's not the real breakdown of things, right?

Like, I think that with company-sponsored open source, that has become a more complex topic. And that just happened with the discourse around WebKit, right? Where it's like why did somebody else have to be sponsored to work on this if it's like an Apple project? And it's like, “Well, I think that Apple is, in this case. Like, maybe oddly for Apple, I don't know. Like, the perception, right? But like they are legitimately trying to run it as like a communal project. And a communal project does mean that like it would not be a communal project if Apple just paid all the contributors to it. That would not be a community-run open source project, right?

And so it's like are you actually mad about that? Like, I'm unclear about like what's wrong with that, right? And so that's the thing that comes out of that, where would companies open source their stuff? Are they expecting contributors to do work for free for them? That does happen, right? They open source things for motivations that are not great, right? Where it's like, “Well, I'm hoping for community contributions,” which is essentially saying like I don't want to have to keep resourcing internally and paying for that, right? Or they're hoping that it elevates the shine of their engineering team, which is a perfectly reasonable thing to want. But you can't do that on the backs of unpaid volunteers, right?

So that is a complex area. But at the same time like there are projects that are genuinely community-run, or they're run by an individual, right? And like contributing to those is not unpaid labor. Like that's not what that is. It is a thing that you feel responsibility for, for whatever reason, maybe because you use it or because you care about like the broader ecosystem, whatever your motivation is for feeling responsible, for caring about a thing. And you take care of it because you want it to continue on, right?

And I think that affects so many things, right? So I have kids, right? And like another terrible part of online discourse where people love to flatten things. And it's like I'm child-free. And that makes me blah, blah, blah. And like, “I'm a parent. And that makes me blah-blah-blah.” And it's like, “Well, none of these things are true,” right? I have kids because like I love children, and I take care of them, because I should take care of them, right? Like not because like I'm getting paid for this job or whatever. Like I made my choice. And I have responsibility to my choice, right? And therefore, do the things that are necessary for me to take that responsibility to take that care. Because the impact that I have on, in this case by children, impacts everybody else that they ever come into contact with, right? And that same thing applies to open source, where you have to care about the impact that caring for or not caring for a thing will have, right? Because both of those things are decisions that you've made. You have made a decision to care or you've made a decision not to care. It's not just that not caring is a lack of action. You have made that decision, right? Not to take care of a thing that you're using. And if you’ve made that decision, have you really thought through the impact of that, right? Like, are you just thinking, “Well, somebody else will deal with it?” right?” which we all know is not true.

That's another big thing, is that on the individual level, like let's say for early career developers, which that's often the target audience of these like thought leadership tweets.

[00:24:44] JC: Yes, it is.

[00:24:47] HH: Yeah, open source can be a really great way of building yourself up. I'm not going to say it's like it's going to make or break your career or whatever, because like it's clearly not tweaked. But I think that, like, all else lacking, right? Like if you don't have the resources to like go to school, or to have fancy equipment, or whatever, which is seeing them like I went through as a young adult. Open source is great in that way, because you don't pay for a boot camp. You don't like – Not everything has to be some wild, like compiler-based thing where you need a powerful machine to manage everything. But you could work on like a small web package, right? And that's not something that requires to have a high-powered machine. Today, you can do that work from a phone or a tablet. You don't even have to have like a computer with the desktop operating system on it, right?

It is a powerful potential training ground for yourself, if you are driven that way. And again, that's like the nuance that's lost on the Internet, is that everybody learns in a different way, right? And so for – Like, I think of it as a method of learning, right? Like, on the contributor side. It is 100%. It is a method of learning to do something. And it may or may not work for you. Not all learning methods work for everybody, right?

I'm an engineering manager, right? So like I think of engineering managers as like part pedagogue. You're dealing with pedagogy, right? Like one on one coaching and pedagogy. And you have to accept that not everybody learns the same way. And so to kind of have this like flattened statement of like nobody should do unpaid labor, or everybody should work on open source because it's good for you. It's like none of that can be true, right?

Like for some people, going to school is going to be the thing that works for them. And the way that they learn things, the way that they like to having structured the way that they can be successful, right? For some people, reading a book is how they're successful, right?

Like, I have a friend who, like, every time I'm like, “Oh, I need to learn. Pick up some knowledge about some programming language or concept.” It’s like, “I read this book. And it's like it does not work for me at all,” right? I'm a person who learns by doing, and that's what made open source really great for me, right? Because in open source you can kind of – You have to be a very willful person, for the most part, right? Because you kind of have to jump in there and have the guts to just be like, “Hey, I'm this rando who you're probably never going to see in real life,” right? And you don't know who I am. And I'm coming across really strong in the chat. But I really want to work on a thing. I saw this thing. And I think it's like wrong, or bad, or whatever. You really have to be like willful about it. And that's hard. That's really hard for people.

If you are that style of person, and if you learn by doing, the open source is like an incredible world of learning of opportunity for that. And I love it. I loved doing it. The difference now has been that 10 years of doing stuff in the public eye, it's like being a politician, right? And we complain about politicians. And that yes, they made a choice to be politician. But like it's very hard to have everything that you say become a reportable event, right? That’s, yeah.

And that's the life of being like a high-profile open source maintainer, is like suddenly you have both that CEO dilemma of like everything that comes out of your mouth through your fingers is like a thing that can be reported on. But also, you have the politician thing where it's like you're also doing the work in the open, and you're like accountable to everybody. And it's exhausting, right? And so that's what frequently happens with maintainers as well, is just you just get tired of doing everything as a public figure. And it's like, “Okay. You know what? I've loved engineering management? I've loved open source. I just don't want to do my work in the public eye every single day anymore.”

[00:28:56] JC: Which is completely fair.

[00:28:58] HH: Yeah.

[00:28:58] JC: I was a maintainer on Apollo client, and then I left after a year because I did get a little crispy, a little burnt out. Because let's talk about the realities of – I love what you said about contributing as a mechanism to learn, because that's how I utilized it. And to be completely honest, I didn't even contribute a lot. I just spent a lot of time in the codebases running the code, seeing how it worked, reading some of the pull requests, getting information, learning new things, which is a valid way of using open source to level yourself up. You don't have to contribute. Because what people do not realize about contributing, you can do it on a smaller scale sometimes. But there are some projects that, to be honest, you're going to need to know a lot about how they work to really contribute really well into the actual codebase. Maybe you could contribute to documentation otherwise or something like that.

But for instance, in the JavaScript world, like the React codebase. Like the chances of you making a really important contribution to that codebase is less likely, one, they literally pay people to do this as their full time job is to understand the entire codebase, and you just can't pick it up real quick. It's going to take a lot of time, and maybe you don't have that. That's cool. That's fine.

So we talked about like, yes, you can absolutely get a lot out of open source to further your career if you want to. I think you have to come at it with the right like mindset about open source.

[00:30:35] HH: Yes. Yes. Yeah.

[00:30:38] JC: The reality of it, right? Which is that open source comes with – If you are maintaining or even contributing, you will just see an influx of issues and people.

[00:30:51] HH: It's very overwhelming. Yeah.

[00:30:51] JC: It’s very overwhelming.

[00:30:53] HH: Yeah. Yeah. You made me think about something that I'm very proud of in WordPress and something that I think about a lot when we talk about the common debate and theme that comes up, is that WordPress uses Subversion for version control. And we use Trac for bug tracking. We do use GitHub in some ways. But it is not like our primary source of truth, right? And that comes up as like a point of contention sometimes where people are like, “Well, I don't want to contribute to WordPress, because it uses Subversion.” It's like, “Well, you could use Git.” But we have a GitHub mirror, and you can like send a pull request. We just don't merge pull requests on GitHub, right? But you can use Git, and some GitHub tools. And we, the maintainers, will do all the annoying Subversion stuff, right?

But the thing that has come out of that, that you lose some of that fidelity if you think about bringing that over to the GitHub model of contribution or like merging stuff. So like GitHub’s little graph, right? We talk about that all the time. It includes like comments and code reviews and that kind of stuff. I don't think it includes comments actually. It includes creating issues, creating pull requests, doing code review, that stuff. But it doesn't include comments. And that's something that's like it's hard, because what we do in WordPress is we don't do like release credits using like commits, right? Because Subversion, first of all, is not atomic the way that like – We don't use it atomically the way that people tend to use Git, right? And we don't branch off that way.

But also, like, that means you're over elevating code contributions, right? Or at least like things that can be written in a way that contributes to the code. And that's really hard, because like designers work just as hard, if not harder on a lot of these things. I mean, it's hard to have good design in open source for lots of reasons. And credit for that is, I think, not a small part of that. And you have things that, to me, are frankly, like, way more important than like my little job of like doing final checks and testing, which is like people who write really good bug reports, people who take the time to look at a badly written bug report and write you reproduction steps, right? Clearly followable reproduction steps. Those are the people who, to me, are like the unsung heroes.

And when you move into like a commit-based credit system, you lose that, because you don't get credit for like leaving a vote in common when that pull request is merged. And so, in WordPress, because we roll things up until like a bigger commit, so what would be like a merge commit of a branch in Git land. So like a single larger commit in Subversion, we have a – You have like your fixes, see, whatever, right? Your references. But we also have a line for props. And that's where we put all the usernames of everybody who we, as a committer, as a maintainer, feel contributed to moving that issue forward, to moving the project forward to achieving a conclusion for that thing. That, to me, is really powerful. And it's really important. And that's something where – Yeah, like I was saying, I think that gets lost in a pull request basis, right? Where, as an engineer, one of the most useful things that you can learn is how to express yourself clearly in a bug port, right? And if you're not getting credit for that in open source, you kind of think of that as like, incidental, right? Whereas to me, that's like a critical core skill of being an engineer is being able to reproduce things reliably and then to communicate that in clear ways that other people can then reliably reproduce, right? That's critical to being an engineer. And we don't give credit for that across open source.

And that's the thing we do in WordPress that I think is really good of us as a project, not just – Like, of course, I'm biased. But like I think that we do a good job of that for the most part. And that's something that like, yeah, I would like to see that change culturally, right? Where we elevate that, because that's the – That's a really hard work, right? Like making the computer do a thing, whatever, like that's what we’re supposed to be doing all day. [inaudible 00:35:20] stupid. And so make sure just telling the computer what to do. Whatever.

Right. Code is hard. But what's even harder is figuring out what stupid thing is happening and then communicating that clearly. And I want that to see more importance. And so like how can we recognize that in projects? And how can we show like new career people who are trying to level up their skills that this is critical? This is a thing that you will get credit for. This is a thing that will elevate you, that will set you apart. This what makes you a senior engineer, right? Or a tech lead. Yeah.

[00:35:53] JC: Yeah. These are the skills that you will advance technically. And you will get to a certain point where you're like, “I should be a senior engineer.” And the reality is you're missing the non-technical skills that actually push you into senior. Senior is never about just the technical skills. Seniority is always about the other things. It's so obnoxious for people to learn this as they like – Later in their career. They're like, “Wait a minute. You meant I was supposed to be learning all the communication stuff that like how to reproduce things, how to reliably really hone in on what the problem is? How to work with people?” Yes. I'm so sorry. We forgot to tell you that. Until you got several years into this career. And now you have to develop those skills. Whoops.

[00:36:45] HH: Yeah. So what if we pull people that off the bat while we're doing this, like, “Open source is good for your career?” Well, yeah, sure it can be. But rethinking what those skills are that we're saying you're going to get through contributing to open source. That's something that I would love to – I don't know, maybe I'll start poking at that as I get through this like onboarding, this crash of information and kind of get back to the thought leadership side of things.

[00:37:10] JC: Yeah. When we talk about contributions, we are so focused on code in those topics, which I think really creates that dichotomy. So clearly of the like you either are unpaid for your labor of coding, which is like what you get paid for at your day job, or you have to be contributing to open source.

And then also, you brought up that you don't want your work to be in the public anymore. That one of the downsides to that is that you're acting as a politician. And so anything you say ends up being like a decree almost. And there is a real sense of hero worship of high-profile open source maintainers. And I have a problem with this. I don't know how it is in WordPress or other PHP related things, but in JavaScript, it is high-profile white men. And then their word is kind of law. And they are like also given this kind of altruistic like shine to them, because it's open source. And open source can be nothing but altruistic. It does not serve the people who are coming up in this field who do not look like them and want to get into this very well.

[00:38:30] HH: I said this very recently, where I said, like, contributing to open source, being an open source maintainer, does not automatically make you a good person, right?

[00:38:42] JC: Yeah, no, and people don't realize that.

[00:38:43] HH: Yeah. Yeah, we're not better people. We're not like enlightened, right? Like, there's nothing funnier to me than that we have tech, which is this like libertarian wasteland, right? Interfacing with open source, which is like the most socialist that a computer could be, right? It’s like nothing is funnier to me than that interaction of things. So, like, I don't know. Like, I find that incredibly funny.

And yeah, open source, to me – So my handle is Helen in a lot of places, like on GitHub, right? That's one of the places where, like, you can clearly see, like, that's my handle. Because, you know, how many out there are Helens? To me, that's like extra wild, because like as an Asian-American, born in the 80s, like entire swaths of my generation were named Helen. [inaudible 00:39:38].

[00:39:39] JC: I didn’t know what.

[00:39:41] HH: Oh, yeah. There's this number of like Asian-American millennial women named Helen. Like, I don't know. It's just a very popular name in our, like, demographic group. So how did I end up with that handle everywhere? Because just like there are no Helens working in open source, apparently. Like I had Helen on Freenode, right? Like I had it everywhere. And it's like, “What? How could this be?” right? And you think about that, it's like, yeah, open stores is like even worse than tech engineering numbers, right? I don't think we've done a survey in WordPress for like seven or eight years at this point. The last time we calculated these numbers, it was something like 10% of contributions were coming from non-men, right? But that only accounted for 5% of contributors. So that 5% of countries are working like twice as hard as everybody else. And it's like, “Come on,” right? How is this the thing that we're in?

And then when you look at like WordPress as a project, because we're trying to elevate other passive contributions more highly, you see that there are tons of women contributing. But they've all been kind of shunted whether per their own interests, or because somebody else felt like they should be placed into that box. They're in like communications, reckoning, design, accessibility, translations, everything except core code. And it's like I know that there are plenty of women doing this who are perfectly capable of it, but they've been shunted aside often before they ever are even in a position to be contributing, right? They've already been pushed aside. And it's like, “How do we have representation?” How do we show like, “Yeah, you can do this. This is a good community. Like, WordPress, has been really wonderful. I have not faced some of the things that I know that my peers, women and Asian-American women, have faced like being in the public eye.” Because WordPress has been like a great community on the whole. There have been incidents, of course. But I shouldn't have to say of course. But yes, there have been incidents. And these things happen. But on the whole, like, it has not been as poisonous as I can observe elsewhere. And if I can see it, that means there's worse happening, or I can't see it, right?

And so I think about that a lot, too, is like even in a place that does as well as WordPress does, we saw such tragic numbers, right? Not just the numbers. We just have tragic visibility, numbers, like the representation, the breakdown of like things that people aren't doing. And it's like it is frankly tragic. And if something as big and as well-positioned as WordPress can't do it, then like I don't even know where to start with that, right? Like that's one of those things where you’re like, “I care about it. I just don't feel like I'm smart or strong enough to like do something that I don’t know.”

[00:42:48] JC: It's a very complex topic, because I think what we often think of as the fix for this is to throw more women at it.

[00:42:55] HH: Yeah [inaudible 00:42:56].

[00:42:58] JC: Throw some women at it. People of different color at it. Just throw them at it. And like not realizing that like – Like you just said, like, if they're contributing in different ways, which are often more comfortable for them, or someone else kind of shoehorn them into a certain thing, which does happen. That doesn't really solve the problem. I don't know what the solution is. I just know that like it makes me sad.

[00:43:22] HH: Yeah. It makes me sad too. That’s been hard for me, like thinking about leaving WordPress as my day job, is just that race, that side of representation. But there are two parts. Like, one, I’m still lead developer at WordPress. Just that I don't do it from a day job doesn't mean that like I no longer know anything about WordPress, or that I can’t be trusted. And the other thing is that like if one person doing less makes that big of an impact, we have a bigger problem, right? So, yeah, thinking about that too.

But WordPress itself, we have some amazing women who work on the project. We have amazing people of color. Far fewer people of color in terms of open source contributions. That's something that also, I know, like at GitHub, we think about, right? Like, not necessarily like open source specifically, but there is the Stars program. Like there's stuff like that, where they're thinking about, like, internationally, what does the audience look like, right?

Like, we have huge untapped areas of potential contributors, right? Like not to think of them as like resources or something, but it is true. Culturally speaking, like the US is a small place, right? And there's huge areas where there is no culture, there's not even that knowledge that such a thing exists, and could be good for you because you can do it from anywhere with any number of resources, right? So that's something to also think about, is to like, as we're worrying about this stuff, maybe we could help ourselves by also being less US-centric and getting that.

[00:44:57] JC: Yes, yes. I mean, tech, generally, is very US-centric. So broadening out of that is good for everyone. As we're winding down, as we're saying goodbye, because I cannot believe we already – We’re hitting time. It went really fast. Final thoughts? Anything to wrap up in a nice bow? I mean, we talked about a lot. And these topics, they're not easy.

[00:45:19] HH: No. I want everybody to be honest with themselves about what's best for them to really This is like when people go to therapy, and like maybe therapy will be the thing that does it for you. But like, think about what is your learning style? What is your working style? What is something that works for you? Right? Like computers are just a tool, and you should make them work for you, not bend yourself to do what the computer wants to do. Because a computer does not actually have a mind of its own no matter how much we like to think about like the AI.

[00:45:51] JC: It's a magic rock.

[00:45:53] HH: Yeah, yeah.

[00:45:54] JC: That you give instructions to.

[00:45:56] HH: It's your tool. So make it work for you. And be honest with yourself about what it is that you need from a tool.

[00:46:01] JC: I love that. Okay. Well, thank you so much for coming on.

[00:46:05] HH: Thank you. It’s so much fun.

[OUTRO]

[00:46:10] JC: I hope that was a very illuminating conversation for you about open source. Maybe you feel like you want to contribute now and learn some stuff. Maybe the pressure is off to contribute. I don't know how you feel about it. But you could always let me know. So feel free to tweet at me or DM me. My Twitter handle is gurlcode, gurl with a “u”. And also make sure you follow Helen. And she obviously has a ton of valuable insights for you. And with that, I will see you next week.

[END]

Single-threaded Podcast: Dana Jones on How Managers Help Reports Grow

Jenn Creighton — Tue, 15 Mar 2022 17:49:00 +0000

[00:00:01] JC: So I'm going to start today's recording with a callback to the first season where we talked with Lauren Tan about engineering management. Because this episode is also focused on that. So if you haven't already heard that really wonderful episode with Lauren Tan, go back and take a listen before you listen to this one.

So today I am sitting down with Dana Jones. She is an engineering manager at Netflix Studio. She's been in leadership for about seven plus years. And she's been in engineering for 20 plus years. And I asked her to sit down with me and talk about how managers help their reports grow. What are managers doing behind the scenes to help you as an engineer? What kind of conversations can you have with your manager about what your growth is going to look like and what you want to do? So that's what we talked about today.

[INTERVIEW]

[00:01:05] JC: Hi, Dana. Welcome to the podcast. Thank you for joining me.

[00:01:08] DJ: Thanks, Jenn. It's great to be here. Thanks for inviting me.

[00:01:10] JC: Of course. I wanted a very specific sort of outlook from an engineering manager on the topic that we're going to be discussing today. But to kick it off, tell me a little bit about how you got into engineering management and why you've sort of made it your career path.

[00:01:26] DJ: Yeah, sure. So I didn't actually set out to join engineering as a career or engineering management as a career. I sort of stumbled into both of them if I'm honest. So when I first met my husband, he was a software developer and I had been in tech support, but we didn't work together. And then when we got married, I noticed that he was tech editing a book. I had no idea what that meant. I was unemployed for the first time after having relocated from Texas to Washington. And so I asked him what he was doing. And he said, “Well, I basically just read the book. Do what it says. And when it doesn't work, I put a note down.” And I said, “Well, I could do that.” So he got me a gig as a tech editor. That book turned into me taking over as the reviser on the book, so that I had to hurry up and learn enough coding to at least revise the book.

So I sort of fell into development. It took off from there, but it wasn't something that was like deliberate. I wasn't one of those people that was hacking away at codes, like, computers, when I was eight-years-old. It wasn't this long-life aspiration. It was just something that circumstances turned it into a career.

And then similarly, when I started becoming more and more confident as a developer and taking on different kinds of projects for different companies in different spaces, I started noticing vacuums in different teams. So there might not be somebody to lead a meeting, or there might not be someone advocating for coding standards. And so I just kind of started taking up that responsibility, and then realized over time that I was a little better at building teams and growing people that I was developing code, and that I had more passion for it, too.

I think, parenting – I'm a mom of four. I think parenting gave me some skills that I could draw in that realm to patience, and understanding, and empathy. And all of those were made stronger by being a parent. So I think it all just kind of worked out that way.

[00:03:24] JC: I love that that strengthened that role for you. And you talked about growing people, which is actually the subject that we're going to be talking about, because I realize it's something I don't have any sort of formal knowledge or understanding of. And I assume other engineers don't as well, which is what steps your manager takes to grow you and then what you yourself can do. So that's a very broad topic. And we'll break it down. But starting off, like, what's your philosophy around growing people?

[00:03:55] DJ: I think that a manager's responsibility when it comes to growth for people on their team is to find and communicate the overlap between opportunities that the company or the role present and the aspirations of the individual contributor. And that starts with getting to know your staff really well. Understanding what motivates them, what their aspirations are, what their strengths are, where they want to grow, where they find joy, what the demands are on their personal lives. All of those things come into play and understanding the people. And then identifying just a few areas that they want to focus on.

So you can't hit every target if you're trying to shoot in multiple different directions all at same time. So it's finding those few areas that they want to focus on. And then really keeping an eye out, keeping an ear to the ground, keeping all the organs engaged, to find opportunities that line up with what those folks want, and then really helping prepare them for when those opportunities come up.

A common move is from an engineer to a manager. But those roles don't come up very often. There's a lot of different skills that go into being a manager versus being an engineer. So I think there's a lot of ground that can be covered in getting somebody ready for when that opportunity does come up.

[00:05:14] JC: I love that you talk about all these factors that can go into getting to know the person and what would drive them, or motivate them, or even be a hindrance, that they have life pressures that are going on that maybe keep them from moving forward. How do you go about developing those relationships? I'm sure a lot of our listeners, just like me, have had an experience of a manager that didn't really want to get to know you that well as a person. What does that look like for you?

00:05:40 [] DJ: Yeah, that's a good point. I think that your path to growth – No matter what role you're in, I think your path to growth is really a joint partnership between you and your manager. And if your manager doesn't see that as part of their responsibility, it can be really tough, right? Because it's almost like they're not meeting you at the table that you're already at. And so you kind of have to find creative ways to pull them in.

So you asked, how does that relationship start? How does that trust start? Really, it’s those one-on-ones. I have weekly one-on-ones with my with my team. I never ever canceled them unless I'm sick or on vacation. I may move them. I mean, calendars are what they are. Move them around sometimes. But I never ever cancel them. They're the last meetings that I cancel. I also communicate from the first moment that I'm with a new team that if they need something, they just need to reach out to me and we'll find time for it. If face-to-face conversations are not the way forward, then maybe we communicate through Slack, or we have a Huddle, or we use some other kind of less synchronous technological way to connect. But it starts with availability and asking questions, being curious.

I can't keep details in my head, as well as some other people. So I take copious notes, too. I write down the names and ages of children that they may have. If I hear anything about their spouses or their interests. I think that kind of personal connection builds a degree of trust, or at least it starts the building of that trust. So yeah, I think it just starts with one-on-ones. And then not over-promising. And communicating information to your team as early as you possibly can. So that they know that you're giving them the context that they need to be effective in their roles. But also, you're not inundating them with every little piece of information you may hear.

[00:07:28] JC: Those personal details, I'd remember like when managers would remember something about my life, and it was like, “Oh, my God! Like, you actually were paying attention?” And it was so – It did build that like sense of trust.

[00:07:41] DJ: Yeah.

[00:07:42] JC: Definitely. And then I think I made a mistake as an IC maybe earlier in my career where I did cancel one-on-ones with my boss, because I was like, “Oh, I have nothing to bring up this week.” And then many years later, I had a manager who was like, “Well, let's just talk like people. Let's go get coffee. Let's just hang out.” And I was like, “What? We can do that? I didn't know.”

[00:08:05] DJ: Yeah. I tell my team, they can cancel the one-on-ones with me if they want to. Because I get it. I mean, when you get in the groove, and you're flowing on something that's really tough and you see that there's a 30-minute call coming up with your manager, maybe you don't have anything pressing, and you'd rather stay in your workspace. That's fine. I'm totally open to that, because it's their meeting. I see one-on-ones as their meeting. I'm not one of those that splits the meeting apart and says the first 10 minutes we talk about the project. And the next 10 minutes – I always start the conversation with what's on your mind.

I may have a note or two to share. And if time allows, I may communicate that to them. But I always start with what's on your mind. And I love the one-on-ones because you just never know where they're going to go. I've had folks that wanted to talk about their work. They want to talk specifics about projects. I've had other folks that wanted to talk about interpersonal concerns that they had with people on their team. I had an engineer one time that just always wanted to talk about her cats. So I'm good with whatever comes up. I find them to be the most invigorating conversations that I have all week long.

[00:09:09] JC: I would definitely want to talk about my cat and my dog. I do. I mean, they're usually like somewhere around me. It’s almost like, “Let me tell you about this weird animal that I'm in charge of and love.”

[00:09:19] DJ: Right? When you open the door like that, and you say what's on your mind, you're really giving somebody the opportunity to tell you what's most important to them. And if it's your cats, great, then I'm definitely going to ask about your cats frequently. Because for one, I'm interested in cats, too. For two, I think it signals that I see you, right? Like, I see what's important to you, and I know what you care about, and I know this is on your mind. And maybe you have some news to share. I don't know. The social lubricant side of it is really, really important as well.

[00:09:50] JC: It's really hard to know that when you're pretty early in your career and you start to first have one-on-ones with your manager, because I did think that they were for project status updates. And so if someone had asked me, “What's on your mind?” I’ve been like, “Oh, I'm supposed to talk about the project.” It was only later that I figured out I could talk about actually what was on my mind.

[00:10:12] DJ: Sure.

[00:10:13] JC: I also needed like a degree of trust with my manager to talk about how to grow in different ways. Because I think it's easy to go to your manager and say, “I want to learn X new tech.” And it's very different to say, “I want to get better at written communication.” Or I want to get better at getting people on board with my ideas. That's a very different, I think, conversation to have.

[00:10:38] DJ: Yeah. I think it comes down to who your manager is, what they prioritize. Because to be fair, there are some managers who treat one-on-ones as project check-ins. So if you're on the reportour, like if we have a manager report relationship, if you're the report, then if you know that there's an expectation your manager has for you for a conversation, you want to meet that.

So I don't want to put the blame or burden on past you, for example, for not being the one to broach those conversations, because that may have been your manager's expectation. And like I said, there are some folks that come to me, and that's what they want to talk about. They're not so keen to talk about personal things, especially in the beginning.

I'm a new unknown person that came in. I'm just a blob with hair, as far as they know. They have no reason to trust me. They have no reason to be vulnerable. Or like to your point, to admit that maybe I'm not great at written communication. To even admit that you want to improve on something is to admit that you recognize you're not great at it. You're not as great as you could be at it. And there's always this fear, I think, sometimes, in the back of our mind where it's like if I admit that I have a flaw, then I'm giving them the chink in my armor. I’m giving them a reason to edge me out if that comes to bare.

So what I think is incumbent on managers then is to normalize that by exposing their own flaws early, often and loudly. So when you mess something up, when you make a mistake, or a misstep, or you're not good at something, not trying to pretend that you are, but just saying, “Hey, look, I've really, really misunderstood you this last time, and I made a bad choice based on it. Can you help me understand this area better?” So I think leading with your own vulnerabilities enables everybody on your team to be more vulnerable as well.

[00:12:36] JC: And it’s such a key piece of combating imposter syndrome. Because part of the reason that you don't want to admit that you're not good at something is that you probably already feel that imposter syndrome of, especially if you are an underrepresented or a minoritized group in tech, especially then, you don't want to give anyone the actual, like, I don't belong here information. You think that's what you're doing when you're admitting that you have some room to grow. And I've definitely felt like I don't want to tell people that I need help, because then they'll know. Know I wasn't supposed to be here.

[00:13:15] DJ: Yeah, exactly. I don't want to give them excuses to reinforce that stereotype. And so that – I don't know if this is a hot take or not. I think that makes it even more important for those of us who are underrepresented categories in leadership to normalize risk taking, mistake making. I mean, a mistake is just an opportunity to learn. It isn't the mistake that matters. It's how you react to a mistake, or deficiency, a fault, or failing, whatever negative, negative sounding word we want to throw at it. Those are the opportunities.

If I stay where I'm comfortable and I just keep doing what I'm great at all the time, then I would still be tech editing books. And I wouldn't have grown. I wouldn't have made the mistakes that it took me to learn to get to this point. So I think if we as leaders, acknowledge, especially, like I said, underrepresented category leaders, I think if we acknowledge, “Hey, we're allowed to make mistakes and grow just like everybody else around us. And here's the mistake that I made. And here's how I grew from it or how I plan to grow from it.” Then that makes it safer for everybody else to be vulnerable on the team. Can they also be in one of those categories?

[00:14:25] JC: Yeah, I need that to like, kind of come out of my imposter syndrome sometimes, as someone being like, “I made a mistake.” And I'm like, “Oh, okay. That's all right. I can admit that. It's totally going to be fine. It's going to be okay. You can do it.” Also, this like getting new grooves in your brain about patterns that you, like, need to do is really hard. Your brain just wants – It wants to do what it's always done.

[00:14:49] DJ: Sure. Yeah. And let me hasten to say I have not solved the imposter syndrome quandary. I still feel imposter syndrome all the time. I think, though, one thing that was pivotal for me, and I wish I could remember where I had heard it, but I heard someone at some point said that imposter syndrome is not something that's ever felt by imposters. So I try to dredge that up whenever I'm kicking myself for feeling like I don't actually – I haven't actually earned the seat at whatever table I'm at in the moment.

[00:15:24] JC: It does make me feel better when I know that if you're experiencing imposter syndrome, you're likely, like, very good at actually what you do. That people who get imposter syndrome are actually like really high-performing individuals. And if I ever – Sometimes that has opposite, where I'm like, “I'm not getting imposter syndrome. Oh, no. Have I gone the opposite way?”

[00:15:46] DJ: Yeah. And let's flip it a little bit, right? Because you feel imposter syndrome when you feel like you're out of your depth. That's really what it boils down to, is you're out of your depth. That's actually a strong, good signal, because it means you're at the leading edge of your capacity. And that means you're growing. So if you take a growth mindset to your life, or your career, and you have those moments where you're like, “I'm not sure that I can do this, and I belong here,” you're right on the cusp of the capacity to learn something, which is super – It's scary, right? It's super scary. But it's also super exciting.

[00:16:19] JC: So speaking of that, in particular, like, when someone comes to you, one of your reports, and they say, “I want to grow in X way.” How do you make sure that their plan for their growth is challenging enough and then also reasonable enough? Because I imagine it could go both ways.

[00:16:41] DJ: Yeah, it's a good question. I mean, it's conversations. So for one, it's I want to grow in this way because. The why matters a lot. Is it because you want to eventually move into people management? Do you want to move in a greater degree of project management or of technical difficulties? So like, what's the ultimate goal? And then this particular vector that you've identified, is it really leading you to that way? So let's start that conversation first.

And then that's where you get a sense of – If you don't already, just from your reporting relationship, that's where you get a sense of, “Is this the right next step for this person? Or are there precursors that need to come?” And then is this the right length of step? So is this step too ambitious? Is it too conservative? And do I know of opportunities that already exist for this person to take this step? How can I coach them? So I wish I had a better like blanket answer for that. But there are so many different ways that a person can grow in so many different kinds of opportunities that make up.

So when I started at Netflix, one thing that I had to adjust to was the absence of levels. We don't – Really? You know. You know. So it’s a very flat organization. So we don't have what some other companies have this career ladder, which can be a really great coaching tool.

If I'm at E2, I need to be able to do these 20 things. And then to move to an E3, I can see what the expectations are. So then I have a clear list of either skills, or experiences, or however you want to phrase it that can help me get there. Without that, it's a little murkier. It's a little harder to coach.

So sometime last year, I think it was the middle of last year, I drafted essentially a coaching tool like that, that provided that kind of clarity, but that didn't have levels. It just said, “For an engineer, here are all the different ways you can grow.” So there's communication, leadership, vision, strategy, technical architecture, like all kinds of recruitment, all different kinds of ways.

And I started having conversations with members of my team and I said, “Look, I don't expect anybody to be able to grow in all these different ways. There're just too many skillsets here to effectively become an expert in all of them. So let's see where you're at first of all. Do a self-assessment. Go through and say – Indicate your current degree of proficiency and all these different things. So have you architected a service from the ground-up? Have you gone to a recruitment event and recruited people from a group different than the one that you represent? Have you done public speaking before?

And then after you do the self-assessment, indicate what you want to focus on. Though, some people may never want to go to those recruitment events or they may never want to do public speaking. They want to do something else. So it gives a foundation to start having those conversations and then say, “Okay, I see that you think that you're poor at –” Tracking back to earlier in this conversation, to written communication. I haven't seen that to be the case, though. So let's look at some of your written communication and see what areas really need beefing up and which ones don't.

[00:19:58] JC: Right, because you could have not a true sense of what you're good at.

[00:20:04] DJ: Yeah.

[00:20:05] JC: You could like be like, “Oh, I'm terrible at written communication.” And like, you're actually not. It’s something else that's actually affecting that. Just fascinating.

[00:20:14] DJ: Yes, those conversations have happened before where I've had ICs come to me and say, “I really don't feel like I'm a very good verbal communicator. I don't know that people are getting my message.” And it's like, “Really? Because two one-on-ones ago with somebody else on your team, they told me the exact opposite. They felt like they got a lot of clarity out of your presentation.” So it's almost like when you hear a recording of your own voice.

[00:20:36] JC: Oh, God. With this, I have to hear my voice a lot.

[00:20:39] DJ: Yeah. I mean, you probably hear a lot with podcasting. It’s like, “That’s what I sound like? That's not what I thought I sounded like.” So it's a little bit of the same thing.

[00:20:49] JC: Yeah. And I think that's a good lesson for ICs, that when you go to your manager with like what you think you need to improve on, it may not be actually the thing you need to improve on. So keep an open mind. And then you brought up that you knew that that was not what they needed, because you had feedback from someone else. And that's really important, too. I think maybe not enough managers that I worked previously had enough feedback from other people, either on the team or in the organization. How do you get that?

[00:21:21] DJ: Again, it's one-on-ones. I think having regular consistent one-on-ones, steady growing trust, having real conversations about the dynamics of what's happening on the team. It's happened to me just this week. I had a newer member of my team who is looking for new growth opportunities. And the dynamics and the staffing is changing on my team such that that's becoming more possible.

And so I think it really is important for you to hear feedback, if not directly from your peers, then at least indirectly from your peers. So I communicate it to this individual. I've heard from to other of your peers that they see you as a strong leader. I've also heard from one of my peers that they believe you to be a strong leader, because they saw you engage in XY and Z. And just kind of like playing telephone operator a little bit for all of that, which I think is a huge part of engineering management, or maybe management in general, is collecting all of the various and diverse signals and making sure that they get refracted where they need to go. Because there's too many different signals to sift through for any one person who's actually generating code and delivering software to pay attention to all of that and funneled through it. So I see that as a huge part of my role to say, “Hey, person A, I heard information from person B in a different part of the organization who manages person C that you worked with? So let me try angulate this for you. [inaudible 00:22:51].”

[00:22:50] JC: Put a graph.

[00:22:52] DJ: Exactly. Exactly.

[00:22:53] JC: Put a graph. Put a graph.

[00:22:54] DJ: Yeah.

[00:22:54] JC: Wow! Yeah. So, admittedly, like – So before, I don't know, a couple of years ago, I actually didn't really know what managers did all the time. And actually, like, last season on this podcast, like specifically had that conversation of like what do managers do? Because it can be a little opaque to the reports what they do. But knowing that you're like going and getting these things. I love that idea of like refactoring the light, like pushing it out to where it like needs to be is I think really important.

On the levels thing, by the way. So as an IC at Netflix, I love that I will never have to go and do promo stuff. It is, I think, a double-edged sword of, one, if you were trying to go from one level to another, that career ladder would have very clear indicators for you. Sometimes those, though, aren't what you want to do. They're not what you want to focus on.

I know someone right now who's going for a promotion at his place. And to do that, he's going to have to do some work that he actually doesn't want to do. But it's like a project that doesn't interest him that much. But he has to do it to get the promotion. How have you had to deal with that in the past?

[00:24:06] DJ: Well, it's an interesting – I'm going to approach answering that question from the point of view of that requirement, because I haven't ever really worked somewhere that had that kind of gauntlet that you had to go through in order to get there. But I have heard of places. I think some of our sister organizations in the fame space go through that. And my take on that is one of two things is happening in that situation. Either the person is up for a promotion to a role they're not going to like when they get there, because the work is representative of what they will have to do in that role. Or their work is not representative, and there's a flaw in the promotion system.

So if I know that I'm going to have to learn to, for example, give budget presentations to move up to director level, which I imagine is part of what's expected of a director, is that they have to manage budgets. I don't know that I'd like that. And so going through – If that's a real representation, if the exercise is a real representation of what you need to do, then it can be a forcing function for you to really evaluate if that's the right promotion for you or not. So I don't think that it's necessarily negative.

But if the person is dreading that work that much, it may be that they're on the wrong track in terms of their career growth. And, I mean, there's really only one way to find out if that's the case, unfortunately, is to go to the exercise and see if they like it. Or I suppose they could talk to somebody who already has that role, and say, “Does this project represent what you do day-to-day?”

But you pointed out something a little earlier that I had to chuckle up, because you said you had no idea what managers did in the same boat. And I tweet about this a lot actually is, before I was a manager, I didn't know what my manager did either, because I didn't see him. He, she, they would go into rooms with other people who I didn't know what they did, either. And then they would come out and there would be a roadmap. That's all I knew. I didn't know what their day-to-day looked like. I didn't always have one-on-ones with my managers coming up. So I wasn't really sure what the job entailed.

And I have found now that I'm doing a lot more formal mentorship. When I'm talking to people who think they want to go into management, the very first question, or at least one of the first two is always, “But what do you do? What do you do? Like, I look at your calendar, I see you're talking a lot. I see you talk a whole lot. But what do you do?”

[00:26:35] JC: Yeah. Your calendar is really packed.

[00:26:37] DJ: Yes. Yes. And the answer is, “Well, it's something different every day.” Like, there isn't a typical day as a manager, because there's so much – Right now, there's open headcount on my team. So a big chunk of my day is taken up in trying to find the right candidate go through interviews, make sure that my team is – Or the interviewers on the panel are prepped on what I'm looking for. Refreshing my understanding of diversity and anti-bias mindset and going in. I mean, so that's taken a lot of my time right now.

But our roadmap will be announced pretty shortly. And then it will be stakeholder management and communicating all of that information. So there isn't a typical day. And hopefully, if I'm effective at my job, then the folks on my team have the context that they need to do their work really well. They understand the connection between what they're doing day-to-day, what the long-term vision is for our team and for our company. And the stakeholders and partners that I work with don't feel like they're in the dark.

[00:27:46] JC: It's very different work is different work.

[00:27:48] DJ: It is very different work.

[00:27:50] JC: I remember someone when they first told me that becoming an engineering manager is not a promotion, it is shifting into a new role.

[00:27:56] DJ: Absolutely. Yeah. And it's not for everybody. There's a lot of people that make that shift and need to shift right back. Because it's a completely different skill set. That's why I said once I finally understood what people management was, I recognize I was better at that, than at technical delivery.

I was always an adequate engineer. And I was better at stakeholder management than I was at the actual coding part of it. I was never as invigorated by that as I was when I would say lead an internship program. So it's a hugely different skill set. It’s a lot more people touch. It requires a lot more emotional “EQ”, higher EQ, at least more regularly, because so much more of your time is spent building and working on relationships and communication than it is on something that's mechanical and intangible. But it can be a different kind of burdening stress, too.

So it's not a promotion in any sense. I think it's a definite career trajectory switch. It's a track switch. It's almost like going from being a plumber to an electrician. Like you know a little bit about houses are put together. And you've probably bumped up against people that are doing that work during the course of your work. But it's not a promotion.

[00:29:22] JC: No, it's not the same work at all. We're both working in the house, but a completely different thing.

[00:29:27] DJ: Yeah. Yeah, exactly. Now, that said, I think that having been an engineer for a long time – I mean, I'm 20 plus years now in this business. So having been an engineer for a long time does give me strengths as a manager of engineers. That would be very hard, although I'll say not impossible, to replicate if I had had some other discipline before this.

For example, I understand the need for flow, and focus time, and the cost of context switching. I was never a Java engineer, but I manage a team full of Java engineers. So there's no world in which I'm going to get in and actually create code in their code bases. But I can go in and review code. I can ask questions. And I can understand what's being written. But having not come from that particular language background, I would never jump in in their code bases and kind of take something over. I think that's demoralizing, anyway, when your manager steps in and takes work over from you.

[00:30:31] JC: Oh, it is – You feel so under-valued, under-appreciated, dismissed, when that happens. Also, not even your manager, but like technical leads, when a technical lead comes in and just takes over your project or tells you exactly how to do it. Where was the opportunity for you to grow, technically, with that project? It just got taken completely – Woosh! Right from under you. Someone just pulled the rug out from under your, right? That's not how you set someone up for growth.

[00:31:02] DJ: Yeah. And Jen, speaking of growth, since that's what this whole conversation is about, it's very interesting when you are coaching people that are at different points in their career, because coaching somebody who is that, like, say, an architect level, comes down to very different topics than coaching somebody who is brand new in their career. And I've managed both. I've managed a whole lot of mid-level engineers. I've managed exceedingly senior engineers, and I've managed people who are just graduated. And the topics you have to go over are really different.

So a lot of times when you're coaching somebody who's an architect level, especially if they're working with people who are much more junior, it's really on the people side of their work, less than on the technical side of the work, and reminding them of what it was like when they were new, and trying to get them to see interactions from the perspective of the other person, and use that to know how to move forward in a functional, empowering way. Because I don't think people ever – I think it's rare that people really seek to disempower each other. I think that effect happens incidentally when we're blind or unaware of how our actions may disempower other people who are at a different point in their careers.

[00:32:16] JC: I have, unfortunately, dealt with that in the past where I had – I guess, he actually was my manager, who would tell me how to do things, very specific technical things that he wanted me to do. I was very displeased with this. And what I sort of figured out about the situation seemed to be that he did not want to give up some measure of control. That giving away that control felt to him like he wasn't doing his job, which is not true at all.

[00:32:55] DJ: Yeah. You know, it's cliche, I say it a lot. And I know that it's tricky to kind of oversimplify something. But I think most workplaces conflict, when you really boil it down to its essence, comes down to a lack of clarity around responsibilities for different people who are working in the same space. So you understood that you were responsible up to a certain point with the work that you were doing. He understood his responsibilities to be a certain amount of work, and there was overlap. You had this area – And without even knowing the details of what you're talking about. I've heard this kind of situation called so many times. There was some element of working in that code base that you both understood to be your responsibility. And that lack of alignment and understanding on shared code bases and individual responsibilities is, I think, where most friction comes up.

So when those interactions happen, and I'm involved in helping smooth things out, or a party to one of those, I try to bring the conversation back to responsibilities, not the interactions that happen, not that specific pull request, or this feature, or that feature. It's like, “Who is responsible for greenlighting a release? Who is responsible for authorizing PR? Who is responsible for making sure that testing happens?” And have that conversation as an abstract topic, rather than coupled to whatever the latest interaction is sometimes, not always, but sometimes can lead to better outcomes and longer term established norms, as long as people approach it from a positive, well-intended perspective.

[00:34:41] JC: Yeah, I've had the experience of like a role being very unclear to me. And that sort of friction happening because I was not sure what I was responsible for. I was not sure what other people in the code base were responsible for. That did not end well. But that's besides the point.

[00:34:59] DJ: And that's a good point, though, because that's really kind of a part of a company's culture. Both of us work at Netflix. We know that our culture, when it comes to responsibility, is really different from a lot of other companies. I came from a string of startups before this, where responsibilities were a lot more delineated by role in particular. The PMs do this. The EMs do this. The engineers do this. The test engineers do this other thing. And here, it's a whole lot more fluid. I struggled with that a little bit, because again, my understanding of responsibilities in my historical context didn't line up with my current reality.

So I think one takeaway from that for managers who may hear this in the future is, as you hire new people into your team, make that understanding be part of your onboarding. Make sure that you're spending a lot of time clarifying for new hires what your companies and your team's culture is around responsibilities and who does what.

[00:35:59] JC: How does that affect when you're coaching an engineer and they want to grow in a certain way and it might have like overlapping responsibilities with something else? Or, again, like at Netflix, we just don't have the same structures. So how does that affect your coaching?

[00:36:14] DJ: Netflix is such a peculiar space, that there are some teams that have PMS, and the PMs more or less own the product division. There are other teams that don't have PMS at all. And so the EMs own that space. And then there are other teams where it's kind of shared. So I would say within Netflix, you can find almost any configuration of responsibilities, separate or shared, that you want.

And so let's take a specific example to make this conversation a little easier to kind of digest. Let's say that I had an engineer on my team who was interested in moving into product management specifically. So they wanted to do more user research. They wanted to understand impact and cost – So, ROI, return on investment for work that they were talking about doing and how to think about that from a product-minded point of view.

So long-term, if my team is very split on like product managers do product manager things, engineers do engineer things, then long-term, they might have to move out of my team to be able to achieve that kind of impact. But within their time on my team, I can still give the groundwork for that. Like, I can still encourage them to set up one-on-ones with PM and understand how do you go about your work? What tools do you use? How do you calculate impact? What users do you talk to? I feel like there's never a reason to block engineer access to the users of their products, especially when those users are internal, like, how they are on the studio side at Netflix.

So you can still lay some groundwork for understanding and, again, prepare for the opportunity, even if the opportunity is not immediate or not available on your team to help them grow and get that context for a future opportunity. A horizon window that comes up.

[00:38:05] JC: So I was going to actually ask, too, about engineers moving off of your team. Like, when that is actually the best way for them to grow up. I have a feeling this will eventually happen to me. It actually is a very prominent pattern at Netflix that you want to stay with Netflix, but you just move to a different team to take on new challenges or new responsibilities. I feel like I'm going to be terrified to have that conversation, even though I know I shouldn't. But it's a scary thing to come to your manager and be like, “I think it might be time to explore something new.”

[00:38:40] DJ: So, I get that. And I've seen this go a bunch of different ways, not just at Netflix, but at other companies as well. I have actually had this happen twice on my team in the last three months, including once just yesterday. So it's very timely. And I get that it's scary to go to your manager and say, “I'm looking for something new or something different.” Because the risk is that, in your mind, you might be thinking, “My manager might be imagining that I think this is a judgment on them, or a judgment on the team, or some other kind of bigger threat than what it is.

And I can't say that there aren't managers who wouldn't take it that way. But in my experience, especially here, that hasn't been the mindset. If somebody is looking for a new challenge, that's a good thing. That means that they're growing. That means that especially if they've invested well on your team, that means that they've grown, they've become a better, more solid, more capable contributor and they're looking to be able to exercise some new muscles.

The truth is, if you don't find them in other space within your company, they will eventually find themselves in other space outside of your company. Once you reach the point in your thinking of, “I want something new.” Like, that's a switch that's hard to unclip. Once you get to the point of imagining the future outside of your current team, it's hard to walk that back.

So in my instance, we just went – I'll talk about both of them. And maybe that'll shed some light on how those conversations have gone. So the first one, we had a team reorg. Just shuffled people around so that we could focus on new areas. I brought on two new engineers. As a result of that, two engineers mustered off of my team. And one of those engineers had been in this domain space, which is for my team production finance. So they had been in production finance for a couple of years, and they wanted something different.

And they came to me first, which I took as a – Especially given this was a new direct report, I took that as a huge sign of faith and trust. And I helped them identify roles that were open. So I said, “Well, there happened to be within our org –” I think there were three other open headcount at the time that they would qualify. So there's these three. These are the hiring managers. Go and talk to them. See if they think that it's a fit. And so that particular switch was made in a matter of three weeks.

The second one, the one that just got announced yesterday, there's a very senior engineer on my team who was working on something foundational for our org. So a new development framework that we're going to be adopting as part of conforming all of our financial data together. And I had a quarter to adjust to that. I kind of could see the writing on the wall that engineer had been at Netflix a long time and had a long career and, frankly, was ready for something bigger. And I'm excited about that.

I think as a as a people manager, as a servant leader, which I take – I know that phrase has had some stigma over the years attached to it. I really take it to heart. I think that I serve my team. And it's my responsibility to help them grow and to prepare for eventual futures, hopefully, on my team, if not that, hopefully, in whatever organization I'm part of, or whatever company I'm part of. But if not, whatever future comes for them.

So if you approach leadership from a mindset of, “I want to grow my team. I want them to be stronger and better when they leave their time with me than when they started their time with me.” You'll have no trouble attracting strong talent in an ongoing kind of way. So your well will never be dry.

[00:42:25] JC: And to follow up on that, I mean, you kind of adjusted a little bit with them. Being happy wherever their future might take them. Because I also come from a string of very small startups. I'd never worked anywhere as big as this. And when I was like, “I'm ready for something new,” the opportunity to move around in the company just wasn't there sometimes. So it did mean like I was going to have to leave. I've never told a manager before I had an offer in hand. Is that the best way to go about it? Is there any time that you do want to like have the chat with your manager before you have – Like, you've done the interviewing an you're giving your two weeks’ notice?

[00:43:09] DJ: Well, it's funny you should say that, because I'm always the opposite every time I've left a role, mostly because when I've tried to do – The last like four or five role changes that I've had, I've put my notice in before I had an offer in hand, mostly because I'm not able to give due diligence to a job that I'm at and the job of finding a job.

And so when I was looking to leave a company for a new role, it was different than when I was looking to leave a team and move to another team within the same organization. That was really never an option for me. The companies that I work at were so small, that wasn't really a possibility. So whatever was driving me to leave would still be in play at whatever another team would be on the same team.

But I don't know. I think it comes down to your own situation. There's no one size fits all answer to that. I was blessed to have financial stability and be in a housing market that was pretty cheap. I could afford to be without work for a little while. I've always worked remotely. So I've never lived in the Bay and had the pressures of the financial weight that comes from living in that area. I had a second earner in my household that we were able to rely on their income.

So I don't want to say that you should or you shouldn't. It really comes down to your own specific role. But I think that when you're talking about moving from one team to another within the same company, assuming that there's no ill will, there haven't been any performance problems or no major personality problems. Your manager should accommodate your need for growth. And if they can't accommodate that need on your team, then they should seek out accommodation for that need on another team. That's our responsibility. So my responsibility is not just to my products that we're building. It's primarily to the team and I'm building. The product is what y'all are building. I'm building a team. You all are building the product.

[00:45:08] JC: I love that. And that's like the perfect note, because our time together has come to a close. But that's like such a perfect, like, little ending clip. And is there anything else you want whoever's listening to this to know about management career growth?

[00:45:26] DJ: I think I'll just leave maybe with the thought that your managers responsibility is to make sure that you are thriving and growing in ways that are important to you. And try to reach a point of trust with your manager so that you can have fruitful conversations about that. And then for the managers that are listening, really lean into empathy and compassion and trying to understand where your reports are interested in going, and be a partner to them in that growth.

[00:45:58] JC: Amazing. All right. Thank you, Dana, for joining me.

[00:46:01] DJ: Thanks so much, Jen. It was a pleasure.

[OUTRO]

[00:46:09] JC: Thanks always for listening, y'all. And again, thank you to Dana Jones for coming on the podcast. I'm going to put some links in the show notes to some resources that I really enjoy for engineering management. And I will see you next week.

[END]

Single-threaded Podcast: Rebecca Murphey on Developer Productivity

Jenn Creighton — Mon, 21 Feb 2022 16:31:57 +0000

[00:00:00] JC: Today, we’re talking developer productivity. And no, I do not mean tips and tricks for VS Code, and I certainly do not mean if we’re using Vim or not. What I’m actually talking about is developer productivity as an entire organization, within a company. I myself, I now work in the productivity engineering org at Netflix. I wanted to talk to someone else who was well versed in this space. I’m being joined today by Rebecca Murphey. She is an engineering manager in the developer productivity organization at Stripe. She’s here to tell us what does it mean, what is developer productivity, how does it differ from other types of engineering. This is a very specialized subfield of engineering with its own challenges, very different from what you would see in product engineering. We’re going to elaborate on that. We’re also going to talk about why companies invest in developer productivity, what are they getting out of it.

[INTERVIEW]

[00:01:16] JC: Hi, Rebecca. Thank you for joining me today.

[00:01:19] RM: Hey! Thanks for having me.

[00:01:20] JC: I have to say that the first time I think I ever heard from you was via an email, and I just never would have foreseen, but at some point, I would be having you on this podcast.

[00:01:32] RM: Here we are. Here we are.

[00:01:34] JC: And yeah, here we are.

[00:01:35] RM: Yeah, I love doing these. They’re always much fun.

[00:01:38] JC: You’re also so gracious to talk to me. How we met is that, I was interviewing at different companies. I interviewed at Stripe where you work. You reached out to me in the hiring process. It was very nice. Happy to see you in the hiring pipeline thing. It didn’t work out for me with Stripe. But I reached out to you, because anytime I see someone working in the space that I’m interested in, especially when they’re a woman, I want their insight, I want to connect with them. You were very gracious to answer some questions I had about developer productivity, and then now come on this podcast and talk about developer productivity.

[00:02:19] RM: It is one of my favorite topics. You’re not twisting my arm here.

[00:02:24] JC: Good. Good. For people who don’t know, can we just get sort of a rundown of what developer productivity is.

[00:02:34] RM: Yeah. I didn’t know – this was something I was always into, but I didn’t know it had a name until probably late in my career, in some ways. I’ve always been really interested what the development, what the experience is for engineers doing engineering? What does it feel like? Is it hard? Is it easy? Are there mysteries? Is there a happy path that you can just walk down with your eyes closed? That space has always really fascinated me. I learned in my last job, maybe I knew before, but like my last job was my first job where I had a job actually working on improving the productivity of engineers at a company. The company was big enough that it was worth investing more people, and making the people that we had more productive so that they didn’t have to solve problems locally that we could solve generally, for example. They don’t have to – individual teams shouldn’t have to think about how they compile and deploy their code. That should be a central function.

Developer productivity is, in my mind, just kind of this idea of, at a certain size, you have enough engineers where it’s worth investing and making those engineers maximally productive. That that is actually, it’s not just nice to have. It’s not just that it keeps them happy. It’s actually, it’s materially impactful on the business at a certain size. Exactly what shape that takes, there’s some things that are really obvious. There are some things that may be really unique to the company, or the where the company is in its lifecycle, or in growth or whatever. The details of what developer productivity can certainly vary. But often, it involves deploys, tests, builds, these sorts of things that we can standardize across projects. It makes sense to have a single team or a single group of people who are working on those capabilities. We use the word capabilities a lot. Those capabilities for the whole business, for all of engineering rather than individual teams trying to solve themselves.

[00:04:35] JC: And you mentioned at a certain size. This is important because, if you work at a very large company, I feel like you already know about this space, because there’s already probably an org dedicated to this if you work in a large company. But if you’re like me, and you also said in your previous experience, you didn’t know this was a thing. You may not have encountered this. So I worked mostly at small startups where this was not a thing. I did not know this could be a thing. I learned about this through working on essentially opensource, which was also developer tooling and then decided that I wanted to do that, but at a different scale, which is not the whole wide world, but at companies. Right?

[00:05:18] RM: Right, right.

[00:05:18] JC: That’s when I sort of figured out that companies had this this org. What was your own journey to discover that this was like a thing you could do?

[00:05:27] RM: Honestly, when I joined Indeed, which is where I was before Stripe. Indeed was right at this moment of, we need this. I think what happens in a lot of companies is that there are pockets of people working on this. Eventually, there are enough pockets of people working on this, start to talk to each other and they start to realize there’s something here, there’s something. We should bond this together and make builds faster. I think that’s not exactly what happened at Indeed so much, as there were a number of teams working kind of on things in this space. The person who hired me, shortly after I started, started to push an effort to coalesce those into a single organization. There, it was called engineering capabilities. There’s that capabilities word, but it’s called engineering capabilities. It included the people who owned our development environment, include the people who owned builds and deploys. Also, I think it included, there was a QA component to it. I can’t remember all the groups, but there were there are about a dozen groups in this organization called engineering capabilities.

It was cool to get to be there and see that kind of come to be. When I joined, I think there were a few hundred engineers, less than 500. When I left there, they were probably in the ballpark of 1500 to 2000. I think there is a tipping point around a small hundreds of engineers, where I think this becomes a valuable investment for a company.

[00:07:07] JC: Yeah. I was going to ask, what size does this start to take on a life form? What size the company is this now? Something that starts to become like a pain point between teams. Because I’ve also worked somewhere that had, say, 100 engineers, and we were still experiencing quite a lot of pain about different teams doing things, different ways and having no centralization. But we also struggled with startup mentality, which was that we needed to keep building things. We didn’t really have the time to step back and look at the landscape and make those decisions on what should be centralized and who should work on it.

[00:07:50] RM: I think it’s a hard – it doesn’t feel good to have your first engineer who – it seems like they’re not making money for the business, right?

[00:08:01] JC: Like you’re bad vibes for the company.

[00:08:04] RM: Yeah, it doesn’t feel good. Like you’re never going to produce a feature, you’re never going to increase conversion rates. To hire a person who’s going to do none of those things, doesn’t – I haven’t been in this position of having to go from zero to one, but I can imagine that that is for people who have been really focused on growth, and time to market and all these things. That is a hard choice. But eventually, it’s just math. There is a day when this is just math. That if you can spend one engineer salary on making 100 engineers 10% more productive. You just by yourself 10 engineers. This is just math. I think that a lot of places maybe like resist the math a little bit longer than they should, and they’re trying to solve these things through like tiger teams, or through squads or whatever, who are banding together to, “We couldn’t deploy anything last week, I guess we better fix that” kind of thing.

I think that at the end of the day, though, it’s just math. If you can use one engineer to make 100 engineers 1% more productive, well, that engineer paid for themselves, but maybe you didn’t need them. If they mix at 1.1% more productive. Boom! Done. I think that that’s a real realization for me too, is that, I think I was agitating sometimes for this sort of work to be happening, but there wasn’t a business case for it. It would not have been a good decision to invest in a productivity team because the math wasn’t there. But somewhere around a Dunbar’s number is like 250, I think like somewhere where it starts to become inefficient for individuals to kind of self-organize. Dunbar’s numbers is the number of people who you can kind of like keep in your head all at once and it’s around 150 or 250 years something like that.

The number of people who you can retain kind of meaningful relationships with in a single moment, that is the size kind of where it starts to be actually inefficient to solve these problems in an organic way. And it becomes important to solve them in a more focused way.

[00:10:19] JC: Okay. And then, once you get to that number, once you’ve convinced the business that this is a thing that should be done, you’re dealing with I imagine the repercussions of the organic growth that was happening up until that point. How do you even start to wrangle that in?

[00:10:39] RM: I want to answer that, but there’s something that you just said that’s really interesting, and I think I didn’t understand for a long time was that. You talked about when you make the business case. That is not a skill that a lot of engineers have, and they often think they don’t need to have. There’s products job to make the business case. That was a real realization for me on this journey too that like, I need to learn how to make the business case, just waving my arms around and like saying, “There’s lots of opportunity here.” That wasn’t that compelling to the people I was trying to convince, it turns out. I think a big growth for me was learning how to advocate not agitate, how to actually advocate with your reason about the need for investment like this. I think I see a lot of early efforts fail, because you have smart engineers who know that this is a thing that they need to do, but they just don’t have the language to talk to the business about it. That was my experience.

I’ve talked to so many other people who are like, “How did you pull this off?” Two things, size and being able to articulate that business case to the business that that what it takes. You’re waving your arms around, and it turns out it doesn’t work.

[00:11:59] JC: Yeah, advocate not agitate. In my mind when I think of agitate too, I think of like a washing machine and like just shaking things about and yes, I’ve done that in my career where I just thought if I shake things enough, we’ll get somewhere. As it turns out, shaking doesn’t move the needle. I mean, it shakes it back –

[00:12:19] RM: It does. It shakes it back and forth, yeah.

[00:12:22] JC: It just shakes it back and forth a bit, but that it lands where it was originally. It doesn’t actually push it in one direction or the other. And you’re right, engineers, generally, we are not taught how to do this. We kind of think of our jobs as very removed from the business in some way. Sometimes almost like an altruistic kind of fashion of like, we’re not wearing the business suit, and then using words like synergy.

[00:12:49] RM: And leverage.

[00:12:49] JC: Yeah, we’re somehow better than that. But I have found even just moving into the productivity org at Netflix, that this is going to be a part of my job and I’m going to have to get better at this somehow.

[00:13:05] RM: Yeah. And this is – part of what I’ve loved about this is it has pushed me to grow so much that so many of these problems that we’re talking about aren’t engineering problems. There are people in process problems, which are engineering problems. It’s really pushed me to grow a lot in how to kind of own the entirety of the value that I’m trying to deliver, not just the code and that’s been really exciting. I want to come back to, like you had – well, this is your podcast. You should tell me where you want to go. I don’t know. I can go back to the question you originally asked.

[00:13:40] JC: I’ve forgotten that question. I’m actually now – I let my guests really dictate where we’re going. You were the one who are like, no, let’s talk about the business case. The engineers don’t know how to do this. Yes, you’re right, let’s talk about that. Let’s talk about a little bit how you develop any of those skills, because it’s easy to develop technical skills, because there’s resources for you. What about resources for this? Understanding how to talk business, how to get people to understand your use cases, get them on board, things like that?

[00:14:20] RM: Yeah. It starts with understanding like the business no matter what the business is telling you about being a family or whatever. The business exists to make money. That is all the business wants to do is make money. Preferably, they would like to make money in a way that is aligned with their mission. But let’s be honest, we can change the mission if we can make more money. I think that’s first thing and it’s super cynical. Yes, there are good businesses in the world who have additional aspirations besides just making money. But at the end of the day, we live in capitalism, like money is what this is about. I think, first recognizing that we don’t exist to – engineers don’t exist to write code. Engineers exist to make money.

If you can make money with writing no code, you should do that. And if there are things that how you’re writing code or things that you experience writing code that make it harder for you to make money, you should fix that. This is gross, and I can’t wait until I can just retire and not have to do any of this to be very clear. It’s all quite gross when we boil it down to, businesses want to make money. But like first, just recognizing that, that there is no value in well-architected code. There is no value in like really handcrafted CSS. There’s no value making –

[00:15:55] JC: You know you’re breaking so many hearts right now.

[00:15:56] RM: I know. But this is the thing, is you have – like there is no value in those things in isolation, most gorgeous, well-commented, we-tested. None of it matters if that code doesn’t make money for the business. For me, it was just boiling it down to like, “How can I connect this to what the business cares about? What does the business care about? How can I connect this to what the business cares about?”

At Indeed, we did a ton of experimentation, an AB test. We AB tested everything we did. Not literally, but close. That was really central to how the business believed that it could create success, was try a lot of things, see what works and iterate, iterate, iterate from there. Try a lot of things, see what works, find that we ran this experiment and people click on more jobs, or get more jobs or apply to more jobs or whatever. I knew that the company really valued experimentation. Sort of by definition, we value rapid experimentation, because the more experiments we can do, this is kind of baked into the culture that more experiments are better. We can debate whether that’s true or not, but it’s really baked into the culture that more experiments are better.

So then, it became a matter, how can I draw a straight line between difficulties, the front-end engineers are facing indeed, and how that is impacting their ability to ship lots of experiments, and how to develop a hypothesis that if we do this, people can ship more experiments faster. Everything I just said, this is a product manager’s job. That’s kind of the punchline here, is that these are product skills. Product, I was really lucky at Indeed, that we did have product partners, even in this productivity space. But that’s not necessarily true everywhere. When you’re starting, and you don’t have a product partner, or maybe you’re a developer productivity grows out of your infra-arm and your infra-arm can’t even like conceive what a product person can do. But a lot of this, it’s like, identify a business problem, develop a hypothesis about how you can improve that business problem and convince somebody that the work to prove or disprove that hypothesis is worthwhile. Rinse and repeat, over and over and over again. But these are product manager skills.

I took a little brief detour into product management and then really realizing even at Stripe, like I never actually left product management, because it’s very much. I’m an engineering manager at Stripe, technically speaking, and I am technical and I have engineers who report to me. But so much of my job is identify a business problem, hypothesize a solution and what the impact would be, and get buy in for it. Rinse and repeat, rinse and repeat. And ignore the things that aren’t connected to a business problem. For example, we’ve been in the midst of a project to improve build speeds, start JavaScript bundling speed at Stripe. We made some big changes first in the development builds. Now, we’re going to make similar changes in production builds that we’re – right now, we’re living in a world where they’re kind of two build systems and it’s not cool. But we knew that, like that was part of plan. It’s fine.

We knew we were going to improve development first, because that’s where the business value was, was in making builds faster for engineers. But we also knew that we couldn’t have two build system, there’s risk inherent in having two build systems. One in development, one in production. One for development code, one for production code. So, we’re working on a project right now to make the changes in production. But one of the things we really had to hone in on in planning that work was, what are we not doing? What are the reasons we’re not doing this? We are not doing this to make production builds faster. They might get a little bit slower. I’m cool with that. We’ll fix it later.

The goal here is to have parity in these two systems, because having parity reduces risk. That is the reason we’re doing this project, is not to make production builds faster, not to make – we are not trying to actually improve anything. Our sole goal here, we did all the improvements last year. Like now, our goal is just parity to reduce risk. Having that clarity of purpose, it really helps you choose the right and most impactful work. We’re in business, like we can do a six-month project to have parity in faster builds. Or maybe we can do a one-month project to just have parity, and then prioritize the faster builds separately some other time. Because we also like – not saying we don’t want fast builds in production, we do. But just that having real clarity of what is the business problem that I’m solving, and what is the shortest path to solving that specific business problem. Don’t – trying to avoid decorating the Christmas tree with like all the things that you might get to do along the way. That was really rumbly. My point is, that these are like – this style of thinking is very product-like and is not necessarily something that engineers have acquired over their career.

[00:21:29] JC: I do see though some similarities, with what you just said about – what we’re not going to do helps us clarify what we are going to do. That was actually an important skill when we are working on new projects that we had a design for, and we had to winnow it down to what the deliverable was actually going to be, because you would get the idealized, like we would like all these things, right? And you’re like, “Oh! Right. I guess, well, we could, but what’s like –

[00:22:03] RM: What is the opportunity cost of doing that instead of the other thing? Because we are – going back to our conversation a minute ago, we’re talking about 0.1% matters, like you’ve entered a scale where 0.1% matters, and you’ve got to be really intentional about not doing 0.2% when that takes more time than doing 3.1% things. But we’re dealing with like, ultimately very small margins in this business of developer productivity. And yeah, we’re dealing with – this isn’t a place. Sometimes it is, but often it’s not a place where one engineer can save 100 engineers worth of time. It’s a case where 10 engineers can save 100 engineers with the time, but only if they’re working on the right thing most of the time.

Yeah, development productivity, I think of as a low margin business where we have to be pretty ruthless in how we choose what we are and aren’t doing. And that yeah, that is a product skill.

[00:23:04] JC: I remember what my original question was, which was about like wrangling the different decisions got made. Part of that question, because we just talked about convincing the business. But when you’re starting up the org, I also assume that there’s the flip side of that, which is convincing the engineers to all get on board with what you’re offering.

[00:23:25] RM: Yeah. I think you and I have talked about this before, I think.

[00:23:28] JC: We did.

[00:23:29] RM: Yeah. This is more product thinking, right? So much of this is product thinking, I think. Convincing, I think if you’re starting out with – we have to figure out how to make people do the things we want. That’s like the extreme of convincing. We have to figure out how to make people do the things we want. You’ve probably already lost, like this is not - every now and then you can sneak in a mandate. That’s usually going to be around security, or reliability or something that’s hard. I have found it’s really hard to push mandates around productivity. Because it does, it is disempowering to say, “I, in my ivory tower know better than you about how your team should be running. Therefore, I’m going to make use this JIRA process or I’m going to make you adhere to these code review roles.”

It’s a really fine balance, and I think a really important thing is to think of these users as customers, and think of these users as customers who have a choice. Now, they may not have a choice like, “Well, your company uses AWS and they want to use Azure.” Oh, yeah, they probably don’t have that choice. But they do have that choice because they can’t just quit. They can just leave if using Azure or using Google, what’s Google Cloud Platform. What it’s called? If that is important to them, they do have a choice, they can just leave. That’s another kind of formative concept here, is that you do not have a captive audience. You have customers, and those customers have a choice to use your stuff or not use your stuff. It’s imperative that you’re solving real problems that they really have, and that you can connect any friction that you’re introducing, with a value to the business that they care about. It’s not enough that it’s value to the business. Because they can always say, “We’ll find another way to get that value to the business. I’m not going to use JIRA.”

It can’t just be – there’s value to the business, and therefore, you will do this. It has to be, there’s value to the business, and value to your team, and value to you, engineering manager and valuable to you product manager, who is that you are going to get faster experimentation, faster delivery, higher quality if you embrace these tools that we’re creating for you. So yeah, it really has to be kind of a customer relationship. The great thing is, there are customers who you can talk to in Slack. They work with you, and they share probably a lot of the same kind of company values and principles. Like we all work at the same company, we all claim to share these same values, and principles and ways of working.

You have an advantage versus trying to sell to like a random enterprise in the world. But you do still have to really connect the work you’re doing with problems that they feel they have, in order to get them to want to buy into this, whatever the changes that you’re trying to drive. At Stripe, that’s been – it’s been due to – I think that, at Stripe especially I’ve been really surprised how little pushback there has been about this, actually. We’re showing up and saying, “We’d like to take over your JavaScript builds” and you’re like, “Cool! That sounds great.” Because I think at Stripe, we have had a really strong culture of developer productivity outside the front-end space for quite a while. I think Stripe invested in this space organically early and was able to kind of turn those organic efforts into organized efforts on a reasonably fast timescale. But front-end, for reasons wasn’t really – wasn’t part of that original developer productivity space.

So, me and my team is in this really unique position of kind of, we have this strong developer productivity culture that we can just lean into, and we don’t have to have some of the arguments that we might be having if we were doing this truly from scratch. We understand that there is value in standardization. There’s value in shared tools. There’s value in common development environments. We’ve kind of fought those fights in the past, and so my team is in a really fortunate position of being able to kind of latch on to a lot of that preexisting culture and that preexisting system, those preexisting systems, and just reimagine them for front-end use cases. But we’re not having to invent the principles of developer productivity, because those were already pretty well ingrained.

[00:28:21] JC: Oh, there’s so much here. Because I feel like –

[00:28:24] RM: There is so much here. I was like, where is she going to go for me?

[00:28:27] JC: Well, when we’re talking about standardization, and aligning on things, engineers, I mean, the ones that I know, very picky about things. I’ve worked with a lot of engineers that wanted the freedom to choose whatever tools they wanted. That’s not always a good thing, but I think sometimes, it’s like, you will rip these tools from my cold dead hand.

[00:28:54] RM: You’re right. Yeah. That’s a real thing and this, I’m going to do some more product shock here, because this is really just all product. One of the first things that I did when I got to Stripe because I was new there. I had been working at another company for five years. I didn’t know a lot about how Stripe worked, or who my customers even were. What did they do for a living, and what problems, what business problems were they trying to solve? But I pretty rapidly was able to identify that there were a few personas that I could kind of organize problems into. There were the diehard, like super skilled industry thought leader, front-end engineers. That was one persona. We got those people at Stripe and they’re awesome. But they’re like, they’re also incredibly opinionated, incredibly interested in the latest tools. That was one kind of persona that we had to think about.

There is also the full stack developer, the person who – they’re just trying to build features, they’re working on the back, they’re working on the front and they’re trying to add a button, or add a form or like add a payment method, whatever. They’re trying to just make very predictable change to the user interface of the product in pursuit of delivering some new business feature. That’s the second persona, and it’s like, “I’m just trying to do my job here. I’m comfortable with the front-end, but I’m not a master or anything, and I just want this to be easy and I just want it to work.”

Then the third persona is the drive by developer, the person who’s like, almost never doing front-end, but every now and then, they have to for – maybe they need to build some sort of admin tool pr who knows. There are definitely engineers at Stripe who find themselves in this, “I don’t ever do front end, but now I’ve got to.” They’re potentially kind of disoriented and don’t, aren’t familiar with error messages or the tools in this space and everything feels like it’s kind of a guessing game to try to get to where you’re trying to get to.

Coming back to these people who are very opinionated, and my cold dead hands, we really focus a lot on making them our partners. We want them on our side. We want them to feel like they are part of solving the problems that we are solving. We are not going to optimize for infinite choice and infinite flexibility. Tomorrow, we’re going to write everything in Vue. Nope, we’re not going to optimize for that. But we’re also not going to make it impossible for them to experiment in that world, because they’re smarter than we are at thinking about where we need to go, front-end wise. Like we want to empower them to explore, but we’re not going to assume – we’re going actively assume that most people aren’t like them. There’s actually only maybe a handful of these people in the company.

So really focusing on, instead of meeting their needs, getting them to help us think about how to meet other people’s needs. Getting them on the team, whether that’s literally on the team, or just getting them to be kind of philosophically aligned with the team. That was a lot of where I put my efforts in my first few months at Stripe, was just building relationships with those folks and making clear, I’m here to help. I’m here to help. I’m not here to blow up the world.

Again, because Stripe has had a pretty strong developer productivity culture, going back several years, they have seen the benefits, like they’ve seen their friends benefit from that culture and benefit from that investment. If anything, they’re just like, “I want that, why aren’t you doing that for front end.” In this particular case, because of culture, because of history, because of individual humans, and relationships, some of which I have had. Like these are people who I’ve met, like in 2009 or something. I’m leaning on relationships from a decade ago, to convince them we’re on your side, and we are going to make changes in there for the greater good. At the same time, we’re not going to shut you down.

So far, that has worked – that, I can’t overemphasize how much that is such a cultural thing, though, because it’s very easy to imagine the opposite, where you go to show up at a company, they have a desperate need for standardization, because of the leverage it’s going to give them. But people are so are territorial and protective. That’s a culture problem, and so that’s a change management problem. There, I think that the strategy is just find somebody who thinks what you’re doing is a good idea, or thinks that the standardization is a good idea, and make a case study out of them.

Somebody said to me at Indeed, some of the best advice I ever got is, go where you’re wanted. Go where you’re wanted, make an impression there. Now we’re going to talk about marketing too, because I think that’s a huge part of this developer productivity job. Go where you’re wanted, make an impact and market the hell out of it, so that other teams realize they’re being silly by objecting. Again, develop relationships with the EMs, or the directors, or whoever it is that you need to figure out where your kind of pressure points are in the organization. Maybe you’ve got one, really difficult engineer who wants to have infinite choice. Maybe you’re not the right person to talk to them, you might have to figure out who the right person is to talk. There’s like a whole influence operation to think too. So yeah, anyway, it is fascinating how like – nothing that I’ve just said is technical.

[00:34:49] JC: No, and that’s important to know about this particular like subfield of engineering. I don’t know what we want to call it, but like, we just talked about it, right? It’s more product work, more developing relationships and figuring out how to influence the correct people, how to identify the correct people. We even briefly talked about marketing. Here’s a question for you. Why would any engineer want to go into this space? I know my answer, but like, there are engineers listening just be like, “Why would you want to do that?

[00:35:21] RM: Why would you have to talk to people? It’s awful. Yeah. I always like say, the job that has prepared me best for this job was when I was a bartender in my early 20s. Because I was profoundly uncomfortable with talking to strangers prior to that, and being able to have pointless conversations with strangers, where the point was the relationship, the point wasn’t what you were talking about. Again, bartending. The point was the money to be, like I had to learn to talk to people so I could make money. It’s okay to not just think the sound is not cool, because it is a completely different kind of engineering from product engineering. A lot of engineers are really rewarded by seeing their work in the world world, not just in the business, not just in their company’s world, but seeing their work in the world, knowing that they solved a problem for a real person who is paying us money, so that’s fine.

When I’m interviewing people for a role on our team, it’s one of the things I really want to suss out is, does this light you up? Do these problems that sit at the intersection of people in process and technology, do you find that interesting? Have you had experience with seeing the impact that you can have by working on these kinds of problems? People are usually really honest, like, “No” or “Yes. Oh my God! I live for this. I don’t know what’s wrong with me.” I think it is important that you are excited, especially when you’re just getting started with something like this. When we have a team of 500, maybe all 500 of them don’t need to be deeply into this. But when we have a team of five, this is actually – these are pretty important skills. I think, why do this? I don’t know, I think it’s fun.

But I also, I did and at Stripe, it’s like such a target-rich environment, that you’re tripping over impact everywhere you go. This I think, this is why these skills are important, is because you have to be able to make choices about what to work on what’s going to have the most impact, or what is the most likely to have the most impact. But yeah, I think it is a target rich environment, and you can have impact on people who you’re going to see at lunch – well, we used to see at lunch. I don’t know. We don’t see them at lunch anymore.

[00:37:58] JC: Sometimes, on the Zoom.

[00:38:00] RM: Sometimes on the Zoom. I find it really rewarding because the people – I have people send me emails that are just like, thank you so much. I am so glad you’re here. My first day at Stripe, I had strangers writing me and saying, “I am so glad you’re here. I’m so glad that your team exists.” Because the impact, opportunity, like they knew it was so huge. I find it rewarding just because I can show up to – I can show up as a nobody to a company. Like a year later, a lot of people know my name because I’ve been working on abundantly obvious stuff, if you’re in this mindset. It wasn’t like, I’d really searched my brain for what we should do. I’ve just been working on abundantly obvious stuff, executing well, and making meaningful impact on engineers’ experience. That gets, at least at the companies I’ve been at, that gets noticed and rewarded. It doesn’t take long to become a visible person who’s making a meaningful difference at the company. I find that rewarding and I’ve never found that same sort of feeling working product teams.

[00:39:17] JC: No, it took me a good while to realize that I did not feel that way about product work. That yes, like I knew I was building things for like real people. It’s not like I didn’t work at companies where like people were using the product or something. But if I did create one more button, like it just wasn’t – it just – oh! It just felt meaningless when I was doing it, even though I knew, right? Like I knew people are using it. I am so thrilled about the high impact of this particular field, because it is what drives me to want to be in it, is knowing who I’m solving the problems for, actually solving problems for people that I can talk to and say, “Yes.”

It is high, high, high impact, which is one of the reasons why you might get into this field. We’re going to start to like wind it down. Some of my last questions are going to be about how do you get into this field? Like you trip and fall?

[00:40:20] RM: Yeah. My story is not instructive at all, but my story is instructive. Like you’re born into this field. That’s kind of how I feel like. When I went to college, which didn’t really work out. But when I went, I went for industrial engineering, which is the optimization of process. Like, the people who like figure out how to get your packages to you faster, the people who like do all of the logistics data that’s industrial engineers. I was always fascinated by this, like how do you optimize stuff? How do you take a repetitive task or how do you take a complicated task and make it simpler? Maybe the task isn’t, maybe the actual process isn’t simpler, but it is perceived simple. There is a version of this story where like, this has always been what my brain is good at. And eventually, I found my way to my actual job.

But I think, more practically speaking, and especially, especially for front-end people, and this is like, I really want to talk to front-end people. Because, number one, it is often a neglected space in developer productivity, because people’s minds go to like CI, and builds, and tasks and all these things that are very applicable, but they’re applicable to both front-end and back- end. But people are approaching with the back- end mindset. Because the people who tend to gravitate toward developer productivity tends to maybe be more of the DevOps, maybe have more of a DevOps kind of background. But I think there’s a huge opportunity for people who have front-end backgrounds to really, there’s low hanging fruit at your company in the front-end developer productivity space, I promise you. I don’t know what it is. But there is lower hanging fruit than there is for the Java, or Python, or Ruby or Go or whatever language you’re using. I promise you, there’s almost certainly lower hanging fruit in front-end space, then in your company’s standard back-end language. There’s low hanging fruit there too, but like front-end is just, it’s just on the ground.

I think the challenge, though, for front-end people to get into this space, and I say this to candidates, I probably said this to you. I say this to candidates is, I need you to deeply understand how front-end development works and the challenges that people encounter. That doesn’t mean like you can take a mock up and make a web page. I need you to understand like how we deploy, how code gets into a user’s browser, how HTTP works, and how it should be too. I need you to deeply understand all of this stuff. And then you’re going to do none of that, like you’re not going to push a single pixel in this job. But I need you to know how everything that goes into pushing a pixel.

I think like part of what I really like about this, and part of what the opportunity here is, is that you can take that deep knowledge that you have and have more impact with it in the productivity space than you can have in the product space. Because eventually, like a little better architecture and a little better performance. It’s just, you’re geeking out like marginal wins on the product side. But if you’re working at a company big enough, you can start to, with that same knowledge and some systems thinking, and some productivity thinking, and some product thinking. You can start to improve everyone who’s out there, pushing those buttons, making those buttons. You can make it so that it’s faster to make the button or maybe the button makes itself. I don’t know. Like maybe the product, maybe you’re making something where the product manager can now make buttons or change. We did that in Indeed. We made it so that the product manager could change the text on a button in specific languages without ever asking an engineer. That provided leverage for product managers to be able to experiment with things without even having – with zero engineering time.

Again, you have to understand all these things within the system that you make to change the text on the button, maybe a Ruby cred app, like I don’t know. You have to understand the challenges that people face and be willing to kind of work across the whole stack to solve those problems. But with this deep understanding of the challenges that front-end engineers in particular, or people building user interfaces in particular are facing. So yeah, anyway, I think that’s a very generic, like that’s the opportunity for people. I think how do you get into this is you start doing it. You start on your team advocating for, a not like, I want to make the test better, because better tests are good. I want to make the tests better, because they’re going to improve our product reliability and decrease the amount that we’re getting paged by 10%.

Come up, start practicing, coming up with that business case for why you want to do the work that doesn’t have a clear connection to the product. Make friends with your product manager, if you have one on your team, and start to like build a relationship there, build trust there. They can become a great advocate for this kind of work, if they understand the business case. They may even help you make the business case, but they probably aren’t going to make it on their own, because they’re not engineers. I think they’re just starting to practice in your own team, having these conversations about the opportunity, like what is the business case for investing in these sorts of improvements. Talk to people on other teams, get like – maybe you do form a squad to go make builds faster.

But I think, if you’re starting from nothing, start within your team, find your friends in the company, which is harder in these times for sure. Find your friends, find your community of people who also care about this. But just to say over, and over and over again. This has to come from a business. There has to be a business justification. You can’t better engineering for the sake of it, doesn’t sell. You have to sell something the business cares about. And often, you can do that on your own team. That’s is the place to start.

[00:46:49] JC: You don’t have to do it at the – [inaudible 00:46:51] trying to do it right at this broad organization level.

[00:46:56] RM: Exactly. Exactly.

[00:46:56] JC: If you think this is something that you want to do. That sounds like also a great proving ground for if this is really something that you want to work on. Also, yeah, we’re going to have to start using words like leverage and capabilities. I like that we’ve sort of [inaudible 00:47:08] this in throughout this conversation.

[00:47:11] RM: Yep, I’m still very self-aware that I’m using these words, so there’s always some air quotes going on. But I think that the other thing is that, this takes time. You can’t just one day, like I’m going to start a developer productivity org. It takes time and it also – this is a hard thing for me to learn. Your company’s culture might not be aligned with this way of thinking.

[00:47:36] JC: That is true for so many things.

[00:47:39] RM: Yeah. That’s not your failure. That’s not their failure. It’s just some companies may not like this math, they like different math, or they have other maths that they’re using to figure out how to spend the resources. I think it’s important to recognize when you are laying out a business case, and it’s not getting anywhere, like that’s not necessarily you’re failing. That could just be that company takes very –is in a very short-term thinking mode right now. And maybe they should be, maybe they’re about to run out of money. I don’t know. Yeah, I think this is, size dictates when this makes sense, but culture also plays a big part at the end of the day.

[00:48:22] JC: We’re going to end on that note. Thank you so, so much for talking about this. People are going to love this. I’m super excited.

[00:48:31] RM: I hope so. I love, love, love talking about this stuff and I’m really excited that you asked me to. I could talk about this for two or three hours, but we’ve reached the end of our slot.

[END OF INTERVIEW]

[00:48:48] JC: If you’re curious to learn more about productivity engineering, Rebecca has sent some links that I’ll put in the show notes for you, so definitely check those out. If you enjoyed this episode, why not share it on your favorite social media? The podcast is still growing, so getting the word out there is pretty important. I’d be really excited if you shared. Next week, we have a break because I’m coming on a well-deserved vacation, and then we will be back the following week with a brand-new guest. See you then.

[END]

Single-threaded Podcast: Prince Wilson on Learning through Live-coding

Jenn Creighton — Sun, 13 Feb 2022 16:51:28 +0000

[INTRODUCTION]

[00:00:00] JC: This is Single-threaded. I'm Jenn Creighton.

Okay. So for a lot of Devs, myself included, the idea of someone watching me code, make mistakes and try to learn things, I think that’s terrifying. But Prince Wilson doesn’t.

So Prince, he’s a web developer by day, but he comes alive, the Twitch streamer, at night. He does this fantastic live coding sessions, where he’s also learning in the process. And for me, I thought this was fascinating. What a way to really challenge yourself and learn.

And as we talk to Prince, you’re going to see great a community. It’s a great discussion. And hey, you might even be encouraged to try streaming yourself. Who knows?

[INTERVIEW]

[00:01:06] JC: Thank you so much, Prince, for joining us on the podcast, all of our listeners. I'm super excited to introduce you to all of them. And today we're going to be talking about how you stream writing code, which is like kind of wild to me. I've watched a little bit of your stream. And I just want to say, first off, that you are effervescent.

[00:01:26] PW: Thank you.

[00:01:28] JC: I was like giggling as I was like – I was like, “You are so joyful.” And you do these little sound effects sometimes. Like a little boop sometimes. And I really identify with the booping.

[00:01:41] PW: It's very much – This is how I code day to day. And I realized that people don't do that. I didn't learn till later on when I was teaching people like, “Oh, people don't like animate their own like coding [inaudible 00:01:54]?”

[00:01:56] JC: You know what the thing is? That most people don't code out loud. And I feel like streaming, you obviously have to, right? It can't just be you sitting there typing. The streaming, from what I've seen, is like very interactive.

[00:02:11] PW: Yeah. So previously, I worked as like a coding instructor. And I got very comfortable speaking aloud, like what am I thinking and kind of also like talking about why I'm doing certain things. And so, I think, for people coming in to the stream, I want to make sure they have the same context as I do. Because sometimes it's strange to see somebody being like writing onto the screen and just like, “Why are they writing it this way? Or what are they hoping to achieve?”

And also, I love kind of failing openly. Because once again, putting my thoughts directly onto the page, it lets people know like, “Oh, they can make mistakes, and like that's fine?” But at least they shared why they tried to do something. And that's what I hope to do with streaming, is just share what I know.

[00:02:52] JC: Yeah. So that is very similar to when I was a younger engineer, and I would pair with the more senior engineer. When I would watch them have a mistake and like how they handled it and they were just like, “This happens.” It was so comforting.

[00:03:06] PW: It's so cathartic to see, right? Like I think everyone, when they see a title, they're like, “Oh my gosh! This person must be incredible at their job.” But they've also just seen a lot of things and also like made a lot of mistakes along the way. Because the more you do something, the more mistakes you have. But you get better at recognizing like, “Ah, this is like why that happened.” As well as like trying to take learnings away from it. I think that's like the most important skill I've gotten.

Also, like streaming, is very much trying to make sure I don't take it to heart where something like doesn't work. Because first and foremost, everyone sees me. So if I think – Everyone's about to see this go down. But also like it really isn't that serious. Making mistake is not going to crush me. And it kind of reminds me that there are the people on the side of the screen who deserve to see like this okay to fail. Like part of coding is an experiment, is just figuring out like how things work and recognizing, “Ah.”

[00:04:01] JC: I love when an engineer who's learning a concept will ask me, “Well, does it do this?” And my response is always, “Let's try it.”

[00:04:10] PW: Same. I think it's important. I think there are rabbit holes that we don't afford ourselves to go through when we don't try things. Especially, I can imagine like, getting kind of nervous about like, “Oh, I don't know the entire map that I'm trying to draw. I just like know like parts of like what not to go through, like, generally.” But it can be kind of nerve racking to be like, “Oh, we're going down a path I have never explored. And let's just see what happens like along the way.” And we can back out at any point, fortunately. But we got to try a little bit.

[00:04:42] JC: Yeah, we got to try things out. When did you start streaming?

[00:04:46] PW: So I started streaming, I want to say, April 2020, which is –

[00:04:50] JC: Good time. Good time to do that. Yeah.

[00:04:52] PW: That was the time I had wanted to do it that year anyway. I had started a new job. And I was like, “This is what I want to put my mindset towards.” I was like surrounding myself with people who were also doing this at the start of the year. And I was like, “I'm going to do this.” And I tried to make that approach happen for it. And so I've been doing it for almost two years now.

[00:05:11] JC: Wow! Okay, so you stream regularly, I believe on Tuesday evenings, Eastern Standard Time. When you first started, was it bumpy at all? Or was it very smooth?

[00:05:20] PW: Absolutely bumpy. So one thing I did for myself getting started is it was kind of nervous to do streaming, and also I happened to join a Discord server at the time where I kind of streamed my coding screen at the time just to get like experience so that people who I trusted. Like, “Ah! This what it will feel like when I do a Twitch stream.” Like, “Can I make sure this works the way that I want to?” And like, “Can I speak my thoughts?” So I practiced that.

And then the first stream I did, I did it. I was very nervous. I was like, “I don’t know. I'm not going to tell anybody I'm doing it. I'm just going to show into Twitch and what happens happens.” And then I learned later that it didn't even work the first time I tried. It didn’t actually go live. It was fine. I did it for an hour thinking, “Oh, this is all working. It's like good.” So I learned that.

The second time I did it, I also learned that you can select the little checkbox that says like, “Record your stream for later so people can watch it.” Didn't check that little box. So the second time when I brought people in, I was like, “Oh, look at my first real stream that I did.” And Aaron's like, “Where is it?” And I'm like, “Oh, it's not there anymore? Oops.” Just a little bumps along the way. It's fine. And that's okay.

[00:06:26] JC: Yeah. I mean, well, I assume it's a learning process to start doing this. You did say you are surrounded by people who are also doing this at the time. Had they been doing it very long? Or are they also new to it?

[00:06:38] PW: I want to say it varied. Some people had been doing it for some time. Some people have been just starting. So it's just like various experiences of like putting themselves onto the Internet, whether that's through streaming or making YouTube videos, just all sorts of different things.

[00:06:50] JC: Which is very nerve wracking.

[00:06:52] PW: Yes.

[00:06:53] JC: Putting yourself on the Internet.

[00:06:55] PW: Very much, especially because people have thoughts about how you are on the Internet, especially when you're just like trying to bring something you know to the table. Some people don't like that. And that's one of my biggest fears when I started Twitch streaming, is like somebody's telling me like, “Oh, you're doing this wrong?” And I'm like, “Thank you. I know, I'm learning.”

[00:07:16] JC: I love that response, “Thank you. Yes, I'm actually in the process of learning. And thank you for your input.”

[00:07:24] PW: I think one of the things I wanted to create space for people is like, if you don't know something on my stream, I want you to ask the question. I don't want you to feel like, “Oh, you must show up knowing everything.” And also, I don't want to pretend that I know everything. I very much want to put myself in a space that there's something to gain no matter what experience you're at, whether you have worked as an engineer, or you have not, but everyone has something to learn from one another. And it's important to emulate that in the community space that you create.

[00:07:52] JC: Ah, I love, that there's something to gain on both sides. So that brings me back to the original reason why you started streaming. You said you had some like you knew you want to do it. How did it start to be a thing that you were like, “I think I want to try this?” And like sort of what were your reasons for like being like this is something I want to do?

[00:08:09] PW: I think I wanted to learn. I specifically started with learning how to program in Rust, the language. And I was like, “Well, I know I want to do this. But I want to kind of do it in a way that's open so everyone else can see it as well. They can follow along. They can share what they know. And we can learn things together. And that's kind of what started it is a dedicated time for me to learn something. For an hour in the evening, that's where it started with. And it just kind of evolved to doing whatever I wanted to do at the time, which some streamers, they have like a patch they're working through, or sometimes they might be working on their own stream setup. Specifically, people who are doing programming streaming. But I just kind of was random and just did whatever I thought was cool at the time. And I just wanted to show up, bring my personality and just make everyone feel welcome.

[00:08:59] JC: I would say, from watching your stream, that you accomplish those goals very well.

[00:09:03] PW: Thank you for sharing that. Oh my gosh! That's important to me. It always feels like that. It doesn't need to feel like a space where, “Oh, you must come in. Prince knows everything.” Like that is not what the vibe I'm trying to get.

[00:09:15] JC: Yeah, and that's a thing that can definitely happen when you're – I've experienced it at least at work, where you like have someone who's more senior than you or has the ear of the CEO sometimes, and sort of like their word is law in the workspace. And so making sure that you don't bring something like that to an environment where people are trying to learn is very important. Because once you bring that into an environment, people do not feel comfortable. Saying that they don't know things, saying that they're new to things, that they're learning, it can be a real hindrance to the learning process.

[00:09:50] PW: Fully agree. And especially because it's important for us to acknowledge that every person has a responsibility creating the safety of their coworkers, safety of their peers, safety of their community. And like, for me, that's why I wanted to create my space to be that. I don't want it to be a space where I accept that behavior from people like where people could dismiss one another. So I'm like that's very much one of my goals, is always to be thoughtful of like, how am I adding to the community. To the ways that I want it to be normed? I think very much like my actions have that capacity to remind people like this is what is acceptable and what is not acceptable.

[00:10:28] JC: Do you have, as a streamer, community guidelines? Or have you had to deal with anyone not being appropriate in the chat?

[00:10:37] PW: Specifically, I've had people who tried to come in and tell me like, “You're doing this wrong.” And I tell them very clearly like this space is not how I would like to use that. If you would like to have a conversation off stream, more than happy to. But I specifically try to make sure that people don't try to – I almost call it like taking all the oxygen out of the room, where it's like they're making themselves the center of the conversation, as opposed to like recognizing how we're helping one another grow. And I want to make sure that everyone recognizes like, “Hey, this isn't how we have to have this conversation.” And it's okay.

And I do think, once again, doing that very live, where people see you and people recording, very much have to think about like why is it important that I do this here and have this conversation? Because people need to know. Like this is how I want the space to be cultivated.

[00:11:25] JC: Being a person on the Internet, I've experienced that people just love to tell you, “Ooh, this is not correct. And you need to be doing X,” or very pedantic responses of like, “Well, actually, it is a blah, blah, blah.” And I'm like, “Mm-hmm.” So I do this with my Twitter, but like I don't have another space, I guess, where I'm like, “Ah-ah. We're not doing this today. This is not the space that I want to create for myself.” And with streaming, I feel like is that you've come into my stream. This is my thing.

[00:11:54] PW: Yup.

[00:11:55] JC: So we're going to act the way I want you to interact with me.

[00:12:00] PW: Exactly. Some teams, some people who are doing programming, they had moderators. So they're handling that conversation most the time. But I am just a small little time streamer who just does it all myself. Unfortunately, I think, once again, it goes back to like when you set that norm, other people around defend that norm. So like if you'll remember, like I have people who watch, and like people will kind of have that conversation where it's like, “Hey, I don't think that's really what we're here to do.” So I think that helps reinforce, this is what I want the setting to be for people. And also, to recognize, like when something doesn't feel right, people can speak to that truth and feel very confident, like, “Hey, I don't think this is what Prince would like to see here.” So I feel comfortable that I know, even if I'm not like looking and controlling that conversation, people are out there advocating for me.

[00:12:45] JC: That's so nice that you have this community that you've built that knows, “This is the guidelines. We're going to reinforce.” This sort of understanding of how the community is going to be working. The streams are really interactive. So for anyone who has never seen a Twitch stream, do you want to sort of explain what it kind of looks like?

[00:13:06] PW: So imagine, if you will, you're going on to the Internet, and then you go to twitch.com and you go to my profile.

[00:13:11] JC: Which is?

[00:13:12] PW: Twitch.tv/maxcellw. That's where you can find me on the Internet. And in there, typically, you'll see my face in a little bottom corner, a little chat box above me seeing the conversations that we're having in Twitch chat. People who are having conversations with their own user profile saying like, “Hey, I like this.” Or laughing at a joke that I made. And then to the left of me, you'll typically see my computer screen like this is what I'm coding, as well as like maybe if I'm on the Interweb doing research for Docs, or trying to show like a local host version of what I'm doing. But over the course of the time, typically we're either learning something, or we're building a project together. And I'm just kind of talking through what I'm thinking and kind of integrating what I'm hearing from chat and building this stuff together.

[00:13:56] JC: Wonderful. And the product that you choose, you said you sort of choose whatever you want to work on. But do you do any predetermined, like a week in advance or something like that? Like I think I want to work on this. And maybe I should look into a couple of things that this goes just a little bit smoothly. Like I'm still learning, but I should have some clue.

[00:14:16] PW: So I've done a little bit of both where I do a part of that experience, where I kind of do a little research ahead of time and be like, “Can I actually do this thing? Can I do this like an MVP style?” Sometimes I do that. Most times what I do is completely on the screen, like fresh, “Oh, I have no idea what I'm about to get myself into. I have an idea.” And I'm just like, “We're just going to do it all here.” And that, once again, reminds people like, “Ah, Prince doesn't know everything. He doesn't know what he’s going to find.” And we're just going through the rabbit holes of whatever we want to go through.

Generally, those caused me the most anxiety when I'm doing them in front of people, partially because most people are not around me when I'm doing my coding journey into my day to day. So like you don't have to see me go do this Google search of how do I center a div for instance? This is a Google search that I will do. And people are like, “Prince, you don't know this?” I'm like, “Yeah, I don't know how to do everything. But I know some things. Don't worry about me.”

I have recently been working on this project with a Discord bot. Discord is like this chat service that people can get connected with. It has different channels and whatnot. And that's the one I've had to do a lot of preemptive research where I have to go ahead and see like, “Oh, what can Discord’s API let me do? What can't it let me do? What are the ways that I need to know certain skills?” Because I am using Rust, I'm trying to figure out, “Oh, what can I do with Rust that lets me do this thing?” and very much have had to do the most research ahead of time. So I'm not just like doing that for an hour where people are like, “Prince, I don't know if you can do this.” And then I learn, “Ah, you can't do that.”

[00:15:47] JC: But it is still a valuable lesson.

[00:15:50] PW: Yes.

[00:15:51] JC: I've learned multiple times that I can't do something. And it's been upsetting every time. And it did take me down a rabbit hole to figure out that I couldn't do the thing. It's really not obvious that you can't do the thing.

[00:16:03] PW: I wish there were some times it’s like almost like in a video game where you're like, “This isn't the path you want to go down. But you know what? I'm going to live with it as it is. It's fine.” But once again, it comes back to, I think, over time, one of the hardest parts for me, as a developer, just general, is accepting that there's so much value to exploring. I think, as a developer, it's really easy to see, “Oh, some paths you don't want to go down.” But some paths, even though you don't know where you're going, like it's still worth learning about, because that will help you in another situation. And it's really hard to remember like that failure of like finding that path is not actually like a failure of you. But rather, it doesn't solve the problem. And then that is okay. Like that is part of the experience of being a developer. But to have not gone down that path at all takes away that reward of learning something new.

[00:16:57] JC: I feel like it's very difficult sometimes to remember the value of doing that, because, often, the work environment that you're in does not value that the same way.

[00:17:09] PW: Yes.

[00:17:10] JC: And so I think people start to do these things outside of their jobs. But you should be able to do this within your job as well. The last two places – Well, the current place I work and the place I worked at before like valued going down the rabbit hole and doing the research and figuring out if something could be done, or just exploring and making sure you understood like the landscape better.

[00:17:33] PW: I think that's incredible. And that goes back to like that’s a norm that's created across an organization. And like every time we take an action, like that's a payment in the bucket of like this is the norms that we want to cultivate. And like having the ability to explore without the consequences, I think, something that's really important to have.

[00:17:52] JC: Streaming is a way of doing this if your work – Because let's face it, like we're not all going to work at companies that are going to have this culture and sometimes you just stick it out for a bit. Streaming seems like a nice way of doing this. And I guess people could do something like this without actually having to stream it to other people, right? Like just work on something small. I get really curious, and I'm like, “I wonder if I can do this thing,” and then open up my laptop and just go.

[00:18:15] PW: Exactly. I think why I started doing it as a stream is just very much like, “Oh, like this is a way for me to share that process with everyone. I've been trying to think a lot about like that since like the start of streaming to where I am now. I've been thinking a lot about like, “How do we make sure I'm sharing that this is a process? Like this is not just me doing it in a closed room. Showing up one day being like, “Look at how I become a senior engineer. This is it.” I'm very much trying to show up and be like this is every day, every week that I have shown up. Like this is what has built to that process. And I want to afford that to people, because most people have not seen the person like myself be on the Internet doing the job. That's just a fact of life. I didn't see that of myself when I was growing up. And so I was very much like, “How do I make sure that I can show people, one, it's possible? Two, also, that it is work. People have to do the work. But also, that you can do that work. It’s possibility. Most people have not gotten that affordance where I grew up. And so it was just like I want to make sure I am putting myself there.

[00:19:16] JC: I wish streaming had been available when I was younger, because I also had no role models for this career. Now, I guess we're both finding ourselves being the role models.

[00:19:28] PW: Exactly. And I think that is important to us, being people who we want it to see helps people in the forest and the future in ways that we don't even know. I had somebody come into my Twitch chat like maybe two three weeks ago telling me that they really appreciated the way that I was doing my streaming. And they had actually shared through the time of just watching us, they had gotten a job. And I was like, “That's amazing. Congratulations.”

And it's not like direct like I helped them along the way. We didn't do any of their work. But like I think that goes back to like cultivating a space where people are wanting to learn. Like that has ways of impacting people without us ever knowing. And I'm not here to be like, “Look at all those I'm getting in a job.” But like rather, cultivating space for people allows people to feel energized to pursuing what they want to do.

[00:20:13] JC: And it's something you don't always get through your job, the cultivating of space for that. I like that this could be like a dedicated place for people to get that.

[00:20:24] PW: Yeah. One of my experiences back in university was very much like being surrounded with people where we'd have clubs is really what I would call them. Just like organizations, they come together and you just do things connected to that organization. And I think a lot about that experience and how that shaped me being one, a person, who participated in the club and also being a person who founded the club and like how that ended up making me think more about like why is it important to cultivate space where we can do things together.

[00:20:52] JC: So streaming originally, also, I think was more of a gaming thing, which I think you do sometimes stream gaming sometimes?

[00:20:58] PW: Sometimes. When I'm like, “Oh, I really don't feel like working,” I don't work.

[00:21:03] JC: A null concept.

[00:21:07] PW: I surprise myself every time. I'm like, “Oh, yeah. I can just use my Twitch stream to do whatever I would like.” And that is okay. Sure. People may not like that. That's okay. They don't have to be there for that part. But I very much like to say, if my brain isn't up for streaming today, let's do something. Anyway, showing up for myself is why I do that. It makes sure I'm being consistent of like when I show up. Because every Tuesday, I show up and do my stream. And sometimes that might mean doing some fun video games. Sometimes I might be doing some scary video games. I've done that before. And I think showing up doing my programming, everyone knows I'm going to do it. So as long as I continue to do it, it doesn't matter if one day I'm taking it away to doing something that lets me recharge and rest.

[00:21:45] JC: Which is an important concept. Because especially when – I mean, I felt this when I was earlier in my career, was grind, grind, grind, grind, grind. Get the knowledge in your brain. Every minute of downtime was like you need to be doing something, learning. Even as recently as like Christmas break, I was like, I'm going to learn Rust.” And then I was like, “You know what, girl? You're not going to be learning Rust. It’s not what you need.”

[00:22:16] PW: And that's important to recognize. Like do I need this right now? And where is it coming from? Just recently, I felt the same pain of like, “Oh, why am I not dedicating all my energy and time to just growing?” Growing is something I've learned or I'm still feeling for myself. I've been writing daily for a few days now.

[00:22:36] JC: I've read some of your – They're really good.

[00:22:38] PW: Thank you for sharing that. I really appreciate it. Sometimes I'm just writing to The Void. And The Void sometimes lets me know. And I really appreciate when people let me know, because it rhymes why important to me. But one of the things I was writing about today was how rest and growth are part of the same cycle. And like rather than seeing them as two separate cycles, where you’re like, “Oh, you grow, grow, grow, grow, grow.” You can't do that without resting. It doesn't work. It's part of that cycle, because in resting is when the growth also happens. It just doesn't happen consciously. And I think I've been feeling the remnants of what happens when you just grow, grow, grow, grow without any rest. You burn out.

[00:23:17] JC: So this is funny. This is the carving time to fill your cup post, isn't it?

[00:23:21] PW: Yes. Yes.

[00:23:22] JC: Okay. So I pulled this up, because, actually, I want to read a quote from it, if that's okay, that like hit me really hard. So from your post, carving time to fill your cup, you say, “For 2022, I am making sure to take time to look and appreciate the work it takes to complete something. I'm trying to be more conscious with how I learn things, because I think that will remind me that the work itself is challenging. I need to remember to take time to rest and not grind through everything. Because while it can be done quickly, it will not submit in my brain like that. It will not always be rewarded quickly. And I cannot continue to chase for it like that.” Oh, hence.

[00:24:06] PW: Oh, I can't believe I wrote that.

[00:24:08] JC: How does it feel having that read back to you? Because when I read it, I was like, “I identify with this.”

[00:24:18] PW: Sometimes when I write things, or when I'm speaking, sometimes I like forget I say those things. And like speaking is so true to my heart, that I when I hear it back, I'm like, “Wow! That really was me.” And that's why I started writing is very much being like I want to not forget this feeling, because this is the feeling when I'm – By this time next year, I want to remember like this is how I felt. And between here and then, this is the growth that it took to get better.

[00:24:49] JC: And there's this real push and pull thing in our industry where we have books like – This is a made-up title. But anyway, like learn Rust in five minutes. I mean, there are versions of this, right? And that's not how it works.

[00:25:04] PW: No, it's not, unfortunately. I sit with myself where I'm like, “Oh, yes, I can master this skill.” And I'm like, “Wait, can I master it? Is that really the – Can I do all of that in the time frame that I'm given? And remind yourself like, “One, you could maybe. But two, if you don't, you're not a failure because of that.” I've internalized feeling like I'm not growing quick enough. And I've been making sure to recognize that's a lie. My inner saboteur is telling me.

[00:25:35] JC: Ooh, I've never heard anyone call it the inner saboteur. But I like that a lot. That's really nice. I hear like critical inside voice. Yeah. But saboteur.

[00:25:45] PW: It’s the person who's telling me like, “You can't do this thing.” The person who's trying to set myself up for the things. The procrastinator inside of me, who is the reason why I don't get things done. I just kind of listen. It’s a voice. Somebody else's voice. Not my voice.

[00:25:59] JC: It is important to know that that is somebody else's voice. Like it's something that I talk about with my therapist a lot where she's like, “That voice was not naturally came about from your personality. That voice was put there by things that happened to you.” And I was like, “Oh, yes.”

[00:26:18] PW: Dang! Dang! Whoa!

[00:26:21] JC: Yeah. Somebody else put the voice there.

[00:26:25] PW: I've been trying to also remember like the things that served you don't have to continue serving you. And you have to let them go. They might have served you to protect you. Very much part of that. And it's a connect all the way through. Streaming has gone through cycles of that too where I'm like, “Am I doing something that is serving me? Am I doing it for other reasons? Am I doing it to feel something else?” And I've very much been trying to think about like, “No. Actually, the reason why I do it is in service to others, and very much thinking about like why it’s important to me.”

I've had many a journey where I'm like, “This is why I do my streaming.” And instead of thinking only solely of like I'm creating content. But very much trying to be like, “No, this is sharing an experience. And like this is a time where I get to do that.”

[00:27:13] JC: When you're a dev on the Internet, and you have in your past produced some sort of content, I think there's a real push for you to keep up putting content, which is something I have sort of not done. But the exception of this podcast, which is very limited, limited. And I'm not going to be doing this all year, right? Because I have limited time and energy. It's something I enjoy doing. I love talking to people. These were all the conversations that I really missed having. I used to have these at conferences, and now I get to have them again with people. But if it really burnt me out, if it was not providing anything, I just kind of don't. I just don't do it. Like for a long time I was like, “I should blog.” And like, “No.”

[00:28:00] PW: That is okay. Another one of the things, when I write, I like figuring out myself and being like, “Wow! Those books, like they tell you to do these things. Sometimes they are right. Sometimes they are right. Sometimes if something doesn't feel like it's pushing you the way you want to be, it is okay to let it go.” I think there's a lot of fear of letting things that you feel like you've outgrown them, they've served your purpose, and you can let them just be off their way. And I've done that with streaming, where like I don't want to do a project anymore, because I just can't do it. The reward for me does not feel that way. And I'm like, “Will people feel upset of me? I hope not, because like a project is just a project. It's just code. Who cares?” But that's very much where I've tried to remind myself like it's not this deep sometimes where you can freely let it go.

[00:28:43] JC: I'm also a big fan of just letting your brain do what it wants to do, which is a thing I like struggled to explain to people as like my brain sometimes doesn't want to learn, because I'll try to do it, and it'll be like an active like grinding of the gears. And I'll be like, “Oh, this is not what you want. What do you want? You want to go watch Cheer season two? Let's go do that. Let’s do it.” Is that how you feel when you're like, “I don't want to code on the stream today.”

[00:29:16] PW: Yeah, that's exactly what it will feel like. And very much comes in cycles where I'm like, “This is a sign that I need to rest.” Or I need to dig in and figure out like why do I feel this way and like reconnect with like what started this goal and like go from there.” But very much have had that part of my brain be like, “I don't think you're going to make the progress you're going to make today.” And sometimes I just need to write it out and be like, “This is what we're going to do. When it gets done, even if it's a smaller task, I'll get like a list of stuff done.” And I'll be like, “At least I'm making progress and very much appreciate in like the 1% days where sometimes I might only do a little task.” And like that's okay too.

[00:29:54] JC: Now, do you identify as an introvert or an extrovert?

[00:29:58] PW: Surprisingly, I identify as an introvert.

[00:30:01] JC: Ah! I love it. You're an extrovert presenting.

[00:30:04] PW: An extrovert.

[00:30:06] JC: Same. Same. For streaming, is it really energizing and then you're tired afterwards or –

[00:30:11] PW: Yup.

[00:30:12] JC: Okay. So you're like full, it actually is like that social feeling that you get that like it's energizing in the moment and then afterwards you're like, “I’m going to take a nap.”

[00:30:22] PW: Yeah, yeah, very much. I am thankful I do it at the end of my day. So I don't have to do anything else post that, very much like I feel energized while I'm doing it. And once I stop, I can feel my body just be like, “All right. Shut it down. Like you're done for the day.”

[00:30:41] JC: And complete. Same. And same. We're good.

[00:30:44] PW: My entire social batteries are done. I very much will be like, “Oh, let me try to socialize with other people on the Interwebs.” And I'll be like, “Oh, Prince, you can't do that right now. Sorry. You got to go away. Play a video game or do something.” Usually it's like, “Good. Just sit here for a hot second,” and just be like, “Oh.” Just like feel my body and feel like myself recharging. Like I very much need to recharge post stream.

[00:31:15] JC: You have an Apple Watch, right?

[00:31:16] JC: Yes, I do.

[00:31:17] PW: Have you ever done heart rate monitoring while you've done the stream?

[00:31:20] PW: No, I haven't. I've considered actually integrating it into the stream when I do my scheduled video games, because I am curious to know if my heart rates does increase my play. But I have not done anything with heart rate before.

[00:31:32] JC: That would interesting to me. Because you say you get some anxiety when you're doing also like brand new things. I would love to see if your heart rate is like bumping up.

[00:31:39] PW: This is a great idea. And I'm definitely going to figure out how to make that possible.

[00:31:43] JC: Oh, my God, please do. I used to turn it on when I would do public speaking to see what it would look like. And I got a really good sense of what my heart rate does when I'm speaking, which is that it jumps and then sustains for 30 minutes. And I was like, “Well, no wonder you're wiped out at the end of this. You essentially did like a yoga class.”

[00:31:59] PW: This makes sense.

[00:32:01] JC: Right. So it's like probably something similar happening to you for streaming, which also explains like, at the end being like, “Oh, we’re done.”

[00:32:10] PW: This makes so much sense now. This is all coming together.

[00:32:15] JC: Now, because it is a social activity streaming, like I think some people would think it's not, right? They would just think that they're watching you do a thing. And that's that. But it's social. Do you feel like things would be different if we weren't in a pandemic where we are often not able to be social? Do you think that you would be maybe more exhausted by the social interaction of it? Or do you think maybe even streaming wouldn't have – I feel like it's really taken off during this time?

[00:32:41] PW: Definitely.

[00:32:42] JC: And I’m not sure that it would have. I mean, I think it would still would have been a thing, for sure. But people are finding new ways to be social.

[00:32:49] PW: That's definitely true. I think we are finding ways to be social towards the Internet with other people, because we like that aspect. That it feels very connected. I think, for me, my behavior wouldn't change just because that was part of what my goals were. But I definitely know that this was a way to create a new social element that I didn't have before. And that definitely feels like that kind of connection is what I was hoping to find and happen to fill other space that I didn't feel like it was being filled. So it worked for me.

I don't think I could have done it without people supporting me. That part would be very difficult. If I did it all by myself, meaning like I would show up and no one would ever show up, I think that part would have devastated me. It's still hard, because I know like there's a little counter that tells you like how many people are showing up. And I've hidden that counter, because I know how much that affects me. Where like I'm like, “No one showed up today. Oh, darn.” But I'm also like, “People are human beings. Like they don't have to show up to the Twitch stream. I'm still here. I got me. I can make my own jokes and laugh at them.” And I typically do laugh at my jokes anyway. Because making my joke, no, I can't hear anybody laughing. So I got to laugh at it myself.

[00:34:04] JC: Oh, yeah, I do that. I do that all-day log guard. I have cats and a dog. It’s just like, “You want to hear my joke?”

[00:34:12] PW: I'm just imagining the cats laughing along.

[00:34:17] JC: Maybe if cats could laugh, maybe they would. But they kind of gave me a look like – They’re like, “She's doing it again. Now, she's doing it again. Make her stop.” I love cats because they're actually like kind of unchanged from their ancient origins actually. Dogs have gone through like massive genetic changes over time. But cats have not. And so you're just getting this little ancient creature that's like, “I'm not dealing with whatever you're doing.”

[00:34:50] PW: We're done with you. Just present the food please.

[00:34:59] JC: Cats would not be interested in streaming. Let me tell you why. They’d be like no.

[00:35:03] PW: Probably not. No.

[00:35:04] JC: Probably not. There’s no market for cat streaming.

[00:35:07] PW: I'm trying to think if I know of any like – There are some streamers who have like a little pet cam. And so like sometimes that happens. And, oh, there's a Twitch streamer, [inaudible 00:35:19] codes. They have a cat and they have like – In Twitch, you can redeem channel points because you were watching this stream for so long. You get some special reward that you can redeem. And one of her redemptions is pet attention time, or cat attention time, where she goes and pets her cat for a period of time. And I love that.

[00:35:36] JC: That's so cute. If I could like press a button and she would pet the cat, like I would like that very much.

[00:35:42] PW: Yeah. That's pretty much how it goes. And I love it.

[00:35:43] JC: Oh, I love it. That’s so cool. So streaming has gotten you this new community, a new social outlet. It's dedicated time for yourself, whether you want to use that for learning, or you just want to play a game. I love all this stuff. If someone wanted to get started also streaming, how would they go about it?

[00:36:07] PW: Great question. For the most part, you can start with whatever you have. I think that's really important. A lot of people think like, “Oh, to be a streamer, you have to have like a light source, or like a perfect camera, or a perfect microphone.” No. You can just show up and do the thing and like show up with what you have. Like whether it's a laptop or a desktop, you can show up and do your stream. And you might not have a special microphone. You might not have a special camera. But I think showing up, going to Twitch, pressing the go live button. Typically, a software that you have to use is like something like OBS Studio, or Twitch has their own little thing that they call Twitch Studio that you can use to kind of make the stream go live. But you just do it with what you have. Show up. Be energetic that you are there, because like it's important. You got to cherish your own wins. And I think doing that, just being there, and just chit chatting and telling your friends like, “Hey, I'm going to try to do this. Will you show up for me?” And like just have them back you up. I did that with my friends where I was like, “Would you be willing to show up and just chit chat with me with programming?” And they were.

And maybe you don't like it. But I would assume you should try it at least and see how it feels for you. Because some people, they don't like it. And like that is okay. I don't want you to do something you don't like. But you might like it, and you might want to try it again. And over the course of time, you might feel like, “Okay, maybe just I start upgrading my setup a little bit to doing the things that I want to do.” Some people like to do hardware projects. Some people do chess on Twitch. So you can do very much your own thing that is a space of showing who you are. And in my opinion, that's the best reason to be on a live streaming thing, is to show who you are, because people are interested in that.

[00:37:49] JC: That's a good note. People are interested in like what you have to offer. Just not something you feel all the time in the real world.

[00:38:00] PW: It doesn't feel like it aligns like that. But in Twitch, I think there is cultivated space for almost any type of thing that you might be interested in. For instance, there are people who do Lego builds on Twitch stream. And I think that's amazing. I would love to see more of that. There are some people who just do knitting, and some people who do like 3D printing. So this thing that we've connected with game programming, or games, which that has a massive platform on there. Don't get me wrong. But it's not the only thing that's there. And everyone wants to see something that they're interested in. So if you have interest in it, I'm sure other people do too.

[00:38:35] JC: So if you're not streaming, but you're watching a stream, what do you like to watch the most?

[00:38:40] PW: Great question. I find myself most connected to video game streams. I do love watching Lego builds. Those are my favorite. I think because I just get to like watch them do the thing. One of my friends, she's a Twitch streamer. And some streamers call themselves variety streamers who do various different types of game. Some streamers do a solo type of game for a while. They'll do that for a while. But she's a variety streamer. So she does different types of indie games. And like, for me, that's my style of games where people – It might be it's meant to be built by a small studio or might have like specific aesthetic. So those are the types of games I like to watch. I just like to be around her and her community because they're also all fun. And so that's just generally what I find myself doing.

YouTube, whole other ballgame. That place has too much of everything. And that's a good thing. I just don't really know. The algorithm really tries its hardest to tell me, “Oh, this is what you want to watch.” But most of the time it is not correct.

[00:39:38] JC: It is not correct. And so I do watch things on YouTube, because like – Like Brad Mondo, he does like hair stuff. And it's like he goes through like the mistakes that were made for like how the hair got dyed and stuff like that. So I learned a lot. And I don't do my own hair for this reason, because I watched his videos. I was like, “No.”

[00:39:57] PW: You learn. Like, “Hey, it may not be for me.”

[00:40:01] JC: Yeah. But then YouTube's like, “Would you like these other fail videos?” I’m like, “No, that wasn't what I was looking for. But thank you for the suggestion. No. But thank you, YouTube.”

[00:40:15] PW: Back in 2020, I got into coffee making. And so I've been enjoying that process a lot. And so now I see nothing but coffee content.

[00:40:23] JC: All coffee all the time.

[00:40:26] PW: Surprisingly, it doesn't energize you like having a cup of coffee though. If I just have a cup coffee, I feel a lot better than just watching people making coffee.

[00:40:35] JC: Yeah. Surprisingly, not intaking the coffee has not the desired effects.

[00:40:41] PW: Who knew?

[00:40:42] JC: Does Twitch also do recommendations like that? Like so if someone wants to start watching your stream, and then they want to find other streams, will it recommend to them?

[00:40:51] PW: So it has a recommendation algorithm. It's not very good.

[00:40:56] JC: Okay. Noted.

[00:40:58] PW: One of the ways that people find other streamers is, as a streamer, you can set like who you would want to share other people who are streaming with. So it's called hosting a stream. So basically, when you're offline, have other people see other people who are streaming, who are online, on our channel.

[00:41:16] JC: Oh, fascinating.

[00:41:17] PW: And so that's one way to show people who are like interested in your stuff. Other people who are doing that thing. In addition, one of the mechanics you can kind of integrate with your Twitch stream is to shout out other creators. So like, for instance, there are creators who I know people watching might be interested in to them. So I share their content that way. But typically, there isn't like a good recommendation through Twitch. And generally, you're finding people on Twitch who are like streaming and other platforms. That's usually how it goes.

[00:41:45] JC: Twitch is the most popular one of the streaming?

[00:41:48] PW: Yes.

[00:41:49] JC: And then what is sort of like a secondary platform that a lot of people stream on?

[00:41:54] PW: YouTube, that's probably the most interesting thing. You could have a whole episode about something like that, where like how people view Twitch and how people view YouTube, and very much like why people go to either. It's very interesting when you have a YouTube channel. That's where a lot of people have done a lot of research around like should you be on Twitch? Or should you be on YouTube? And how does that work?

[00:42:15] JC: I did not know.

[00:42:16] PW: There's a whole thing, a whole thing. I don't know either. I’ve consider making a YouTube channel, but I don't think I can do pre-recorded content yet.

[00:42:24] JC: I would be more scared of going on YouTube just because I've been on YouTube, but I've seen the comments. Even comments on like my old like conference talk videos. Bless the conferences that like will not allow people to comment on the videos. Thank you, because it saves me so much harassment.

[00:42:46] PW: For real. I have been on like a few things where the YouTube videos don't have comments, or none. And I have some where there are. And I'm thankful for the people who turned them off, because my experiences, when they were on, were hoard. Like I said, people like to share one thing. Maybe you could have kept that to yourself.

[00:43:06] JC: You do not have to have every thought. You go on to the comment page, you can just silently grumble to yourself. I don't understand

[00:43:15] PW: You can be like, “I don’t like this,” and just say that. You can write it in a journal if you want, just like, “I didn't like this video.” Perfect. Close the journal. Throw it away.

[00:43:25] JC: Light it on fire, because no one cares.

[00:43:29] PW: Usually, it's also interesting where people think that it's helping further the conversation, but rather, it's just them expressing how they feel. And like there's two different acts. I have found some comments or people asking for more detail. And I find like those be valuable. But for the most part, people aren't nice. We can just leave it at that. That's it. That's it.

[00:43:49] JC: We can just leave it at that. Just like sometimes people would be rude. It's a whole thing. When you put yourself out there, there is the likelihood, especially if you are not the standard, that you're going to get some really rude comments that they would not have posted if you are the standard. That is the reality, unfortunately. I'm very grateful for moderator tools and being able to hide replies and stuff like that. And thank God.

Okay, believe it or not, the podcast is like kind of over, and we're done. But it went so quickly. This was so good. What final thoughts or things you want to leave with people as we say goodbye to our audience today?

[00:44:34] PW: Two thoughts. First thought, don't punish yourself for not getting things done. Reward yourself for the progress that you make. Punishing yourself will not get you to do it harder. So that's what I'm going to leave you with. And then the second thing, if you're interested in Twitch streaming, and you listen to this podcast, let me know. You can find me on the Twittersphere or the Twitch. And you could tell me like, “Hey, Prince, I started this because I listen to this podcast.” And I will happily be your viewer at any given point. So I'll make that happen. And I'll let you know why I like coming through.

[00:45:12] JC: That is so lovely. And links to your Twitch stream as well as your Twitter profile will be in show notes if you want check that out. Prince, thank you again. This was fantastic. It's such a good time. Thank you for joining me.

[00:45:24] PW: Thank you for having me.

[OUTRO]

[00:44:55] JC: Huge shout out for Prince for joining me on the podcast. If you want to check out his stream, it is Tuesdays in the evening, Eastern Standard Time. I will put a link to both his Twitter and his stream in the show notes. See you all next week.

[END]

Single-threaded Podcast: Laurie Barth on Seeking Out New Challenges

Jenn Creighton — Mon, 07 Feb 2022 15:56:59 +0000

EPISODE 01
[INTRODUCTION]

[00:00:00] JC: This is single-threaded. I'm Jenn Creighton.

Y'all, I am so excited to kick off season two of Single-threaded. I had such a good time recording the first season a year ago. The feedback was really great, and so I knew I was going to do a season two. I got a little bit delayed, because I started a new job. But I am back. We have nine, maybe 10 episodes coming. I'm still recording right now. But I know the lineup, and you are going to love this season.

I think you're also going to really like what we're going to be talking about this season. So, season one was really guided by this idea of emotions and feelings, and I was sort of tackling it from different perspectives, getting us different information about how our emotions play a role in this field.

In this season, and I think this is very apt because this is season two of the podcast, and the podcast itself is growing, our theme is growth. So, what does that mean? I mean, it means a lot. Just like last season, we're going to be looking at this from a lot of different angles. I think you're going to find all these conversations really fascinating. I've been loving talking to the guests.

To kick us off, we have my dear friend, Laurie Barth. She is a Senior Software Engineer at Netflix, where I also work. You've probably seen Laurie on Twitter. Her handle is @laurieontech. Now, what are we going to be talking about today? We're going to be talking about boredom, and how that's actually helped us grow and seek out more challenges in our career. We're going to talk about what those challenges look like to us, what we're looking for, and even, sometimes, when it doesn't work out. How can we re-shift our focus? And how can we keep being uncomfortable in a good way in our careers? We really want to stretch ourselves, so how do we do that? You're going to get a lot of advice. Laurie is a fantastic, has had a wonderful career. Let's get into it!

[INTERVIEW]

[00:02:23] LB: I just feel like your other episodes have been so topic-centered and focused.

[00:02:28] JC: Do you know that they're not?

[00:02:29] LB: They feel that way when you listen to them.

[00:02:31] JC: They’re literally just – we start having the conversation. That's it. My favorite thing about doing this is that these were all the conversations I was having at conferences with people. I missed them so much that I wanted to find a way to have them. I'm just surprised that, narratively, they fit together.

[00:02:54] LB: They totally do.

[00:02:56] JC: It was really surprising. Okay, okay, okay. So, first question that I want to ask you, Laurie, is how do you feel about being actually the first guest for season two?

[00:03:06] LB: Am I? I didn't know until right now. So, I guess, very honored. Hi!

[00:03:10] JC: Yeah, I didn't tell you. I actually was like holding back from telling you that you were the first guest for season two.

[00:03:17] LB: Well, I've got to start it off on the right foot, because I feel like season one is such a high bar.

[00:03:21] JC: Oh, God. I'm so worried that I won't meet expectations for season two. But with my fantastic guests like you, I think I will.

[00:03:30] LB: Oh, no, you totally will.

[00:03:32] JC: Because I secretly know what the guest list is for the season. It is so good

[00:03:36] LB: Wait. But now you have to tell me.

[00:03:37] JC: Nope. You're going to find out just like everybody else.

[00:03:41] LB: What's the benefit of being your friend if I don't get inside information like this?

[00:03:46] JC: Oh, please, you get a lot of information out of me and everyone. You are –

[00:03:52] LB: Don't tell people that. That sounds a lot worse than I hope it actually is.

[00:03:57] JC: Okay. It sounded bad. What I mean is you are like everyone's confidant. You won't tell people if they don't want you to. But you also are a gatherer of people and information.

[00:04:21] LB: Yeah, I'm sure there's some like childhood trauma that’s based on. Let's be perfectly honest. Most of our adult superpowers are based on childhood trauma.

[00:04:21] JC: Oh, God. Okay. We won't go down that narrative because there's so many things. I'm like, “Ah, yes. Childhood.” You're so efficient at your job. Yes, do you know why? It’s not a good reason.

[00:04:33] LB: It's never a good reason.

[00:04:36] JC: Yeah. Yeah. You know, a lot of things, you are able to connect pieces and people very well. I mean, that's how you got me this job, essentially.

[00:04:45] LB: Okay, let's reframe that a little bit. So, I was interviewing at Netflix and I got an offer, and I convinced Jenn that she should pursue some conversations that people had reached out to her about for roles at Netflix. And she did so. She went through the entire interview process, and she got an offer, and she had another offer, and she called me up and she said, “Laurie, I don't think I'm going to take the Netflix job.” I said, “You are absolutely going to take the Netflix job. What in the world are you talking about?” She's like, “Well, I really don't think I'm prepared for it.” Total imposter syndrome talking, and I spent an hour basically yelling at her until she did what I told her to do, which sounds terrible, but it's just our relationship. I feel like I did the right thing for you, even if it required yelling at you.

[00:05:32] JC: You did. I needed someone to talk me out of the hole I had dug myself in. By the way, this is the first time that I have ever been given an offer where I was afraid to take it.

[00:05:46] LB: Oh, no, I've had some of those. And they're always good choices. They're always good choices. So, there's different types of being afraid to take an offer, right? If you're afraid to take an offer, because you don't feel confident that you know you're going to do on the job, okay, that's different. If you're afraid to take an offer because you've heard bad things about the working culture, that's very different. But if you're afraid to take an offer because you literally just don't think you have the skill set and you got –

The second job that I ever took, I was afraid that I got lucky with the questions that they asked me in the interview, and they were the two questions I studied. I was like, “I'm not as competent as they think I am.” That job was hard, and that job required me to grow, and stretch, and do lots of things that made me very, very, very uncomfortable. It was the first time I'd had to work on my own. In previous roles, I had had a lot of mentorship and a lot of hand holding and, in that role, I didn't. But I wouldn't be here now if I hadn't been in that role. That role forced me to grow up and learn a lot faster than I think I would have if I had taken a different one.

Then, when I went to Gatsby, I was terrified, because I was like, “This is a company that everybody knows, and they're building open source things. What if I break the library? And what if I don't know what I'm talking about in public?” and all those things. Then, I came to Netflix, and it was the same thing. I was scared. I had a bunch of people convincing me it would be fine. It was the job that I wanted and I had some confidence I knew what I was doing but, at the same time, I was like, “I haven't been hands on writing production product code. I've been writing libraries and all these other things. How am I going to be able to –” I'm sorry. At the time, I didn't remember most of what use callback did, for example. Like, “I’m going to have to worry about this all day. I haven't touched Java in six years. That's what the backend is.” But it was embracing that fear that made it a good next step.

If I had been comfortable with the job I was going to, then I wasn't stretching myself enough, and I would have been bored pretty quickly upon arrival. I would learn their architecture. I would learn the way that their culture worked, and I would be good to go and doing the same thing I had been doing six months prior.

[00:08:01] JC: Yeah, yeah. So, the other job opportunity I had at the time was in my wheelhouse of wheelhouses; frontend architecture. It was such a carbon copy.

[00:08:11] LB: And here’s the problem. It was a great job. It would have been really fun. But you literally said you wanted to do something new. I'm like, “Then why are we considering this other thing that is exactly what you've been doing at all of your other jobs,” that you know how to do? That you know how to do better than 95 percent of people, and you talk about it at conferences, and you're well respected, and you show up in a freaking zine with your face illustrated about it. Come on! It’s time to push the envelope a little.

[00:08:40] JC: Yeah, yeah. I know. I know now. At the time, I was – So, normally, what you're talking about, that fear of the new position, for me, it’s more like a discomfort. It's just – I like to be uncomfortable in my roles. I like to be uncomfortable in the tasks that I'm taking on. And that's actually why, most of my job opportunities, I’ve gravitated towards doing certain things is because I want to be uncomfortable. Because if you're not that, you're not growing. You're just doing the same thing all the time.

[00:09:14] LB: Oh, I hate being uncomfortable. I don't like it at all. I know I have to. But I don't like it. It's not something that I seek out. In fact, when I get to those challenging jobs, for many months, I will take two-to-one tasks that I definitely know how to do over tasks that I don’t, just to get some level of baseline confidence. Otherwise, I'm just going to be flailing around a lot. I spent seven years consulting and flailing around. I need a better balance than that now.

[00:09:44] JC: Yeah, actually, that is a good point. So, we're talking about, one, we've left roles because we got too comfortable and we were not really advancing. So bored. I think that's a good thing to dive into, and then also, when you do take a role, where you are a little bit out of your depth, what can you do so that it's not so nerve wracking? What can you do so that you can have some confidence in the role?

[00:10:14] LB: I feel like so much of that depends on where you are in your career. Because the earlier you are in your career, the harder it's going to be to find anchor points in a new job. So, if you move from one thing to another, you're like, “Okay, I know how Git works. I know how to set up this IDE. But I don't recognize a lot of these patterns.” Versus, if you're further along in your career, it's less likely that you're not going to recognize anything.

A great example that I alluded to is, in my role at Netflix right now, we have a Java backend. We are writing this dashboard portal system situation that is a very nice mirror to the first system I ever worked on in my career. That was a Java backend and a Struts frontend, that Struts frontend became an Angular 1 frontend with the earliest, earliest version of TypeScript.

[00:11:09] JC: We don't talk about Angular 1 on this podcast.

[00:11:13] LB: But the parallelization ones are really interesting, because I'm now working with technologies I'm more familiar with. But I haven't touched Java since I worked in that first role. Seeing how Java has changed, but also knowing I have some anchor points in the language, but recognizing that the domain within which I'm working and the architecture of the system has some similarities. Remembering Kafka event streams and things I just haven't touched for a while, it’s easier to find anchor points even if they're a lot older than it would have been in my second job when I was working on a Python project and the biggest similarity and the biggest anchor point I had was a project I worked on in college, which is just not the same, and it's never going to be the same.

When you've amassed this variety of stuff, it is easier to recognize, “Oh, this is at least somewhat like this other thing I know about,” versus everything you look at is new. There has to be a balance. If you're looking at absolutely everything as new and you don't see anything familiar around you, you're going to panic. And understandably so. You need to be building on knowledge that you have in some capacity. So, try and find what that foundational anchor point is, and it'll be a little bit easier.

[00:12:28] JC: I agree with that. Even with this role, my foundational anchor point has just been, one, JavaScript, and then two, GraphQL. I'm comfortable in those spaces. I'm learning a whole bunch of things that are not my wheelhouse. I'm learning a lot of backend concepts that I have never had to deal with before in my life. But having those grounding points of, okay, but you know JavaScript really well, and you know GraphQL really well, and you understand that space really well has been good.

[00:12:55] LB: And you also get the benefit of, in a large company, if you know other people in the company, or there are common Slack channels, or whatever it is, sometimes you're answering a question in your old wheelhouse that has nothing to do with the job you do now, but you just remind yourself that you know what you're talking about. The second week that I was at Netflix, one of my colleagues CC’d me in a thread in the JavaScript channel for someone who was doing a code mod. I was like, “Oh, here's my article on the topic, and here's the AST thing, and here's this and this and this and this and this and this.”

Then, they asked me a bunch of questions, and they got to the solution and they were like, “Wait, you wrote that post you linked me in?” I was like, “Oh, yes. I am code mod dork. Nice to meet you.” It had nothing to do with my team. It was nowhere near my team. It had nothing to do with anything I'm now working on, but I was able to remind myself that, even in this company full of people that I think are incredibly intelligent and, when I started, way, way smarter than I am, I know things that can be valuable.

I do this to Jenn constantly, for the listeners. I just harass her about GraphQL client things all of the time, because I use it every day. I'm like, “Hey, Jenn, what about this thing?” And she laughs.

[00:14:05] JC: Hey, it feels good. It feels good to be able to answer the question when you ask me. It does.

[00:14:10] LB: See? Added benefit.

[00:14:13] JC: Yeah, it's a really nice benefit. I'm like, “Oh, I know what's going on here. Cool.” It’s so nice to be able to know. I had this experience early in my career, where essentially, I was just taking the same version of the job that I had done, but maybe with a slightly different – I did a B2B company. I did a more consumer product company. But the job wasn't different, right? It was a frontend engineer. I was working with React. There were some differences that I had to learn about on the way. But I didn't start to leave jobs because of boredom at that point. I left jobs out of boredom later.

I didn’t immediately – I was actually very interested in seeing different code bases and how they worked, and I learned a lot of patterns in React that way and got to see what people were doing. I think that was really valuable to me. But I was not leaving because of boredom yet. Were you leaving of boredom earlier in your career?

[00:15:09] LB: Yes.

[00:15:10] JC: What did that look like for you then?

[00:15:13] LB: My first full-time development role, we were sort of a unique techs consultancy. We were practically like an outsourced development shop, where we would build things for really large companies and hand them over. I did one of those things. Then, I did a second one. Then, I did the second generation of that thing, and it was a bunch of modules that all had similar technology stacks. They were just working in different domains.

I learned a lot about DNS, I learned a lot about DDoS, because those were the domains that these dashboards were designed to solve. Really useful information earlier in your career. I fought against it. My program manager at the time would sort of bootcamp us until understanding the domain we were working in. I was like, “When am I ever going to need to know this?” It turns out, really useful information.

Anyway, sort of beside the point. We were going to start on, I think, the third or fourth module for this, and I was like, “This is just going to be the same thing all over again. It's just going to be slightly different variable names, and slightly different API calls, but it's going to feel like the same thing all over again.” I'd been there for almost two years. I had learned a ton, a ton, a ton, but when I told my senior engineer that I was leaving, he was like, “I'm not surprised. You've hit a plateau of what you're going to do here.” Yeah, I mean, that was my first job, and I reached the point of being bored. I think it's sort of two things. It’s, one, I think I have a lower threshold than most people. I think there are a lot of people who would have found a bunch of other useful things to extract from that job and that role. But it was time for me to move.

I think the other piece of it, which is maybe slightly unfair, is that I am much more inclined to do something entirely new and force myself into another area of tech early in my career. So, a lot of people I know found an area of tech and learned it really deeply and then branched out. I did the opposite. I did a survey course of tech early in my career. I kept switching languages. I kept switching domains. I kept switching areas. I mean, I worked on hardware. I worked on DevOps. I worked on frontend. I worked on backend. I worked on database. I did whitepapers in architecture; All over the place. Life of a consultant. But at the same time, that is not a normal thing to do in your first five years in the industry. But that is weirdly what I did.

It was amazing because now I can say with complete confidence, “I like building things for other developers. I like doing it in a handful of these languages, as much as I have control over that, and I like being close to code.” But I want to have a say in the architecture of it and I want to be able to problem solve at a higher level, and be a big part of designing what all this is going to look like. But this is what I like to do. I don't really enjoy DevOps. I configure my way around it.

All of these kernels of [inaudible 0:18:12] that I have means I can look around and say, “Okay, I can sort of make this work. I can sort of do this thing. But also, if there's an expert in the room, please take it, because I really don't want to.” It's the opposite; it is literally the opposite from what most people do early in their career and I can't say it would be a path I would recommend for everyone or even anyone. It was a very unique journey.

[00:18:37] JC: Yeah, it is very different. Most people, I think, would go the way that I went, which is I went fully into JavaScript and React for years and years and years.

[00:18:44] LB: And that's in part because that's how you get jobs. Why people just gave me jobs to do things I had no experience in is sort of a question mark. What were they thinking?

[00:19:00] JC: They had the right mindset, though, is that you can grow and learn in a role. You can also take a role and then discover it's not what you want to do. I worked on open source for a year. At first, I was really happy to do that and then discovered I actually don't want to work on open source for the long term.

[00:19:20] LB: I did the DevRel journey of that, which is – I was doing all of this blogging and conference speaking and stuff in my free time. Supported. My company was fine with me doing it. I took the role at Gatsby, where I knew I was going to be able to do a lot of that. About six to eight months into that, I was like, “I cannot do this as a job.” When it's actually something I have to do, I hate it. I can't – No. This is not fun. Send me back to code full time. Not POCs. Deep, architectural, what the hell is going on sort of situation, debugging. They were like, “Okay.”

I also had this weird moment. This is going to sound pompous. So, I'm sorry for that. We might end up cutting out if it sounds too bad. But I had this moment of realizing that not everyone feels comfortable or enjoys being a senior staff level engineer. There are a lot of people who get to that point, and they're like, “Okay, I'm going to branch off into something else,” whether that's management, or technical writing, or community development, or any other thing. I found that I really enjoyed it. I really liked it.

I was like, “Okay, well, if not everyone likes to do this stuff, and it really needs to be done, why would I opt out of that just because there's something else that I think is more popular?” Basically, I had this realization that like DevRel is more popular, and it's cool that I can do it, and I enjoy it but, at the same time, I enjoy the coding aspect of it just as much, if not more. I don't know if that's as popular compared to the number of jobs available, right?

[00:21:03] JC: Yeah, well, okay. You see this a lot, where there is a career ladder progression that you're sort of supposed to follow, or it's unspoken. Like what you're saying. It’s kind of like it was unspoken. You would get to staff, and then you would branch out into something else. But often in companies, it's codified for you, right? It used to be, especially, you’d be a senior engineer, and then suddenly you go into management.

[00:21:27] LB: Right, which is changing.

[00:21:28] JC: Which is changing, thank God, because it's not how that's supposed to work.

[00:21:32] LB: Us looking at each other being like, “We do not want to be managers.”

[00:21:35] JC: We know. We do not want to be managers.

[00:21:39] LB: No.

[00:21:41] JC: But if we didn't have the experience of figuring that out for ourselves, we might have thought that because I did early in my career. I was like, “Oh, well, that will be the progression. I will get to a certain point where I'll then have to be an engineering manager and figure it out for myself.” Thankfully, at some job that I didn't have to do that. I could stay on the more technical staff side and not go into more people management and just realize my skills are not in people management.

[00:22:07] LB: And the funny part is, as you advance and you get more into the staff or principal levels of development, you're not doing as much coding, but you're still not managing people. There is a difference between ‘you don't get to debug the string parsing error’ and ‘you have to manage people’, which I think, for a long time, there was no in between. You're doing one or you're doing the other and I'm like, “That sounds unappealing.”

[00:22:37] JC: Oh, yeah. I mean, I do think when you're early in your career, you do not realize that, the higher up the rung you go, the less you touch the code.

[00:22:45] LB: Yes. Though, I think that is very company dependent. That actually is the thing that's probably been most interesting about my career thus far, is I started in the federal government, which is huge. Then, I left and I said, “Okay, small companies. I can't deal with bureaucracy. I can't deal with large anything.” Small, small, small, small, small, and then I was like, “Okay, time for the flip of this,” and I came to Netflix.

I had this vision based on small company work, frankly, that when you get to a staff level, you're basically the architect in the room. You're writing some code. I wrote a lot of PRs when I was at Gatsby. But that's because there were a lot of staff level people and it's a startup. It’s a very unique situation. When you're in a smaller organization and you're sort of the top of the totem pole, it is more likely that you will be mentoring and helping everyone who's coming up behind you. That is not true at large organizations necessarily. It is that some of them, but they're all really, really different and really weird.

I write code every single day at Netflix, and that's not common for someone –

[00:23:51] JC: Yeah, I don't.

[00:23:52] LB: Yeah, you don't. But plenty of people do. It's just – it's weird. I don't know. I've decided there are no rules. Well, that's a whole thing.

[00:24:02] JC: Literally, at Netflix, it’s the no rules rules.

[00:24:06] LB: Oh, God, we are so [inaudible 0:24:07].

[00:24:09] JC: We have been drinking the Kool Aid, and that's fine. We enjoy our jobs. We enjoy the Netflix culture. By the way, anyone listening to this that doesn't know this, Netflix does not have job titles like staff.

[00:24:23] LB: It has senior and lack of senior. Yeah. So, that’s it. You can be a software engineer. You can be a senior software engineer, and there are some distinguishing titles in terms of specialties. There are UI engineers or security engineers or that sort of thing. But, yeah, senior is as high as it goes. You have people who have been coding for 25 years who are still senior software engineers.

[00:24:42] JC: Yeah. So there's no delineation of your role like that. Your role is really based on your team, what your team does. The reason I don't code very much is, one, I'm still onboarding. I'm four or five months into this. I think I'm five months into this job. I'm still onboarding.

[00:24:57] LB: Yeah, I'm nine months in. When did that happen? I actually had this moment the other day, and I was like, “I'm sorry. I refuse to believe I can't play the newbie card.” I tweeted about it and people were responding to me and they were like, “Until someone newer comes to the team –” I was like, “Well, technically, there is someone newer, but he transferred from another team at Netflix. I'm still the newest to the company, so it doesn't count.” I have literally a month and a half until our new person starts, and she won’t be new to Netflix. I’m like, “Damn it!”

[00:25:27] JC: Okay. I feel like the onboarding process at Netflix is really, really long. What I've heard from most engineers is that you don't feel super capable of doing things until a year. So, I think you're new until a year. You still got three months.

[00:25:39] LB: I like it. I think I'm the one who told you that.

[00:25:42] JC: Oh, you and multiple people have told me that.

[00:25:45] LB: It's actually really nice, because, luckily, everyone is reasonable about that expectation. There's no, “Well, it's going to take you a year but we also expect you to know everything in two months.”

[00:25:56] JC: Yeah, it's not that situation at all. Thank God, because it is a lot. It's a lot. It’s the most information I've had to try and stuff in my brain.

[00:26:07] LB: Well, I think that's a large company thing. I think neither of us have really spent a lot of time in large engineering organizations.

[00:26:15] JC: No. I always worked for small startups as well.

[00:26:18] LB: Yeah, I think the large company thing is really interesting because there's so many tools they built specifically for their own uses. So, in smaller startups, I mean, pretty much everything you pick up is open source, or they're paying for a subscription to this one thing that they really, really need. But there's the expectation that it's something you may have seen in another job before, or you can look it up really easily. That's not really true when everything has its own lingo and its own name. Yeah, there are docs, but they're also referencing five other things with their own names and their own lingo and you're like, “Well, what is this thing?” And they're like, “Oh, it's our version of X.” I was like, “Can that be on the docs page?”

The problem is, sometimes, the open source solution actually surpasses what we have in-house because people haven't been able to maintain it. The number of developers on it isn't as large. But it takes time for the organization as a whole to decide, “Okay, we're going to move to the open source version. It makes sense. We're going to abandon this older version.” There have been areas where they're doing that. There used to be a whole GraphQL solution in-house, and now it's Apollo. It takes time for some of those [inaudible 00:27:24], just because there's so much that's built on top of these things, and so many moving pieces, and you all really get mad when Netflix streaming goes down. I’m just saying.

[00:27:34] JC: Oh, yeah. It's kind of a big deal.

[00:27:39] LB: Yeah, kind of a big deal.

[00:27:40] JC: Also, for myself. I remember yelling at Netflix anytime it was not working properly.

[00:27:46] LB: Well, I have a really big problem right now, which is I don't feel like I could talk about it publicly. But there are so many streaming services that are not named Netflix that crash constantly. If I didn't want to watch the show so bad, I would literally give up, because it's brutal. I was like, “But I can't complain about this, because it just looks really biased.”

[00:28:06] JC: We won't name names.

[00:28:08] LB: No. But there are so many now. I'm clearly not pointing fingers at anyone. There are four or five of them I could name that just crash constantly.

[00:28:16] JC: There's one that I'm thinking of in particular that does a weird thing on my TV every single time that I'm really mad at it about. We'll talk about it later. Yeah.

[00:28:25] LB: But anyway, this has nothing to do with the podcast.

[00:28:28] JC: No, this has nothing to do with the podcast. Wait. Okay, let's go back to the podcast then. Sorry. Laurie and I are good friends and we can't help it.

[00:28:37] LB: We went to Disney World together.

[00:28:38] JC: Laurie planned my Disney World vacation, and then just told me when to show up places.

[00:28:45] LB: And then made you walk for eight to 12 miles a day.

[00:28:48] JC: Which is fine. It’s fine. I got special shoes for it.

[00:28:52] LB: Yeah, this was adult Disney World. This was not – Small children would not have kept up.

[00:28:57] JC: No, no, no.

[00:28:58] LB: No. I feel like there is a direct corollary between someone who likes to play in the Rubik's cube that is Disney World and someone who enjoys coding. I feel like there's some corollaries there.

[00:29:10] JC: If you can plan a Disney World trip, you can be a software engineer.

[00:29:14] LB: All these moms and dads out there who have these incredible blogs, talking about Disney planning. I'm like, “You should go into development. You'd be good it.”

[00:29:22] JC: It is so complicated.

[00:29:24] LB: It’s so complicated.

[00:29:26] JC: It’s so complicated. Okay, going back to our original conversation, I do have a question for you, which is: what does boredom at a job look like for you? How do you know when you're bored? Because sometimes I haven't been able to tell until it gets to a certain point.

[00:29:41] LB: So, in that first role I was talking about, we would go through the backlog and we would be assigning things and I found that there were two types of tasks. There was a task that I felt was reasonably close to my level. Most of the time the answer was ‘I've done that before’, or ‘I’ve done that recently’. Or there was something that was just ridiculously out of reach, and I was like, “This is going to be taken by our senior level person.”

Even looking back on it today, I probably could have reached for those tasks, but it would have been really painful and not good for the team if I grabbed those. When there's nothing in between, the boredom sort of set in. When I was seeing the same patterns again and again, and, yeah. I would make bugs and I wouldn't do it exactly right and it wouldn't be done in two seconds. It's not the level where it's rote memorization but if there are tasks that I'm seeing that feel like they're going to move me into a new direction of growth –

I also think, sometimes you just get bored with people. That sounds bad. That sounds like “I'm over you. I don’t want –“ But these were people I still wanted to be friends with. Actually, there's a few people that I worked with back in that role that I am still friends with on a personal level. But the dynamics of the working relationships and the way things were going, it felt like things were really stagnant. People weren't really moving and everyone was really happy with where they were in the structure of the organization forever. There were people who had started there as junior, who had been there for five years, who were still sort of at that level. They were writing better code than they were when they started, but that was still their role in the organization and they didn't really have any intention of moving.

I was like, “I don't see myself doing that. That's not what I want to be.” So, if I don't see people moving in the direction that I would ideally want to move in, I think it's time for me to go elsewhere and try that trajectory somewhere else. It was a combination of tasks and probably people culture.

[00:31:43] JC: It sounds like, for that in particular, that you need to also be in a culture that really values people going into new positions and learning new things.

[00:31:55] LB: Yeah, it's not even necessarily a structural thing. I think, for me, a big piece of it was are there role models? Not even direct mentors, but are there are people within the organization whose path I would want to follow or who are even showing me potential paths? If there weren't people – and this has happened at a few different jobs, where I looked around and I was like, “There's nobody who's really following the trajectory I would like to follow.” A lot of people are very stagnant.

The next role I went to after that, I loved all that I learned. I really enjoyed my colleagues. They were all much older than I was. They were stable in their career and happy and just – They were learning new things, but they weren't really changing the way they engaged on projects. I looked around and I said, “I'm too early in my career to stabilize at this point. I need to go try something else. I need to grow in a different way. I need to do something.

I think only now, sort of 10 years in, do I look around, and I say, “Okay, if I stabilized at this point, that would be okay.” If this was where I took some time and plateaued for a little while and focused on other aspects of work, other aspects of life, etc., etc., that would be okay. But early in my career, I didn't want to be in an environment where it seemed like everyone was doing that, because that wasn't where I needed to be.

[00:33:21] JC: Yeah. I never worked somewhere with that much of a – I always worked at startups, and startups are super unstable.

[00:33:30] LB: I like ruthless.

[00:33:35] JC: Startups are ruthless.

[00:33:36] LB: It just feels like it describes all manner of sins.

[00:33:39] JC: I did have an experience at the one company where I was becoming unhappy in my role. We had a new person join an already really small team, and their enthusiasm for the role – it was so clear to me that I did not have that same enthusiasm anymore. It was one of the main reasons I was like, “Oh. Oh, no. I’m going to have to leave.”

[00:34:06] LB: I also feel like the thing that we're not saying is boredom is always a piece of the puzzle. It can be the only piece of the puzzle and be plenty enough reasons to leave, but most of the places I've been bored, not all of them, but many of the places I've been bored also came with a healthy level of like, “This is not a great environment for me to work in anymore.” I feel like that one's really obvious, because you no longer want to speak positively to candidates. That is the most obvious way to say, “I should not work here anymore. It would be hard for me to answer candidate questions in a way that would make them want to come take this job. I should not be an employee here anymore.”

[00:34:49] JC: Yeah, yeah, that happened to me.

[00:34:51] LB: It happens to everyone, I think. Sometimes, it's just that you've outgrown the experiences. I think startups are actually the place this probably happens most often. You'll see three versions of the company, and you'll still be thinking about the second version you saw when they're on version number three, and someone's coming into work on version number three, and you can't help but give them anecdotes and explanations from version number two, and they're never going to experience that because it's gone. It's turned over into something else. But it's really hard to recognize that when you're in it and you've lived through all those differences seasons.

[00:35:27] JC: Yes. That's one of the downsides to working in startups is the revisions of the culture happen pretty quickly.

[00:35:38] LB: Very quickly. I feel like startups are the opposite of being bored. If you're bored at a startup, I have a lot of questions. But at the same time, it can definitely happen. But I think you're more likely to get bored of the constant change, which is a type of being bored.

[00:35:55] JC: It is a type of being bored. But I will tell you, I have been bored at a startup before. There were two distinct times. One was because I was early in my career and I was not getting stretch assignments.

[00:36:10] LB: That'll do it.

[00:36:11] JC: That'll do it, right? So, stretch assignments, for anyone who doesn't know, is when they give you an assignment, a piece of work that is just a little bit outside the comfort zone. It's meant to make you grow as an engineer. I just kept getting the same thing over and over again. It’s like they didn't trust me to grow into something else in that role. I didn't feel like they were setting me up to advance.

[00:36:37] LB: That's a really dangerous position to be in, especially very early in your career. Because if you have three years of experience, but it really only boils down to the level of stretch assignments that they would give someone who's been in a role for one year, the longer you’d stay there, the harder it is to get what you're worth and get the next opportunity that you should three years in at that point. So, when you see that happening, leave sooner rather than later; if you can, if you have the privilege to do so.

[00:37:07] JC: Absolutely. This is something that is very important. Because you and I, when I say we, you and I literally talk about this all the time, which is that years of experience, is it a good measurement?

[00:37:19] LB: It's a terrible measurement.

[00:37:20] JC: It's a terrible measurement. Because you can be early in your career but have had tons of experience doing a bunch of things and you've just grown a lot as an engineer, or you could have been doing the same thing for seven years. Those are two different engineers.

[00:37:34] LB: I'm going to use some anecdotes. We're not going to use any names here. I have a colleague who has been doing this for a year, maybe two, who works at Netflix, and works in the UI code that I work in. All the PRs are great. You wouldn't know at all that they have any different level of experience than somebody else. Versus I was talking to a friend who works at different company the other day, and they just hired someone, eight years of experience from a really big company, had the resume, whatever, and really struggling with what they feel should be basic knowledge.

I question the basic knowledge thing. But a lack of autonomy? That is sort of strange for someone who has eight years of experience. So, there're certain types of using Git that they're not comfortable with. They're not comfortable answering those questions themselves or figuring out the solution to those questions themselves. They've been requiring a lot of one-on-one hand holding and pairing and stuff like that, which, for someone eight years in, is very strange.

It's entirely dependent on what you have done in that time. There are some people who are going to be able to pack a whole bunch of different patterns in their head really quickly and there are some people who are going to feel comfortable and confident and good doing the same thing over and over again. That's fine, but it means that it's not going to seem like they've been doing this for however many years they have.

[00:39:03] JC: Yeah. I have experienced the same thing. Yeah, years of experience, not a good measurement.

[00:39:09] LB: It's also strange, because it's all over the place right now. There's this missing middle. I don't know if people have seen it. I think it's because there was that period of time where there weren't senior engineers, there were managers. But you talk to people, and you'll get the people who have been doing this for 25 years, and you'll get the people who have been doing this for 10 years. The middle of those two numbers is a lot harder to find. They exist, but they don't exist in the numbers that those other two numbers do.

If you talk to someone who's senior and been doing this for a while, you're going to get an answer between 10 and 15 years almost every single time, which is so interesting to me. The numbers higher than that don't exist, especially in certain populations.

[00:39:55] JC: Right. Yeah, absolutely. I am very curious to see how that changes.

[00:39:59] LB: Oh, yeah.

[00:40:00] JC: Because I know that I've been doing this 10 years. I forget sometimes, though.

[00:40:06] LB: I was thinking about that the other day. It depends on where you start counting, if you count from my first internship where I was coding, that was thirteen years ago ish, 14 years ago. But if you count from my first job, that was a little over a decade ago now. I look around, and that – I mean, you and me both, that puts us in a category where there aren't a ton of other women, specifically. We exist. But we all know each other. We all know each other.

[00:40:43] JC: Or we know each other through friends of friends.

[00:40:45] LB: Oh, yeah. It's sort of funny, at this point, people are like, “Make sure you network,” and all of these things. That's a really hard thing to explain to someone how to do but, in a certain pool of people, you are one degree separated from everyone else in that pool. Probably connected by trauma. But it's really strange. Someone's like, “Oh, do you know XYZ?” And I was like, “No. But they're really good friends with this person who I talk to on Discord once a week, so I'm sure I can get to them. What do we need to ask them?”

It confuses the shit out of my colleagues, because we're always recruiting for various things and I've referred a lot of people at this point, and a lot of them have ended up being hired. It's a really weird number for the amount of time I've been here. I've been here for nine months and I think six of the people I've referred have gotten offers. Not everyone's accepted, but six of the people I've referred have gotten offers. Somewhere around that number. My colleagues all look at me and they're like, “I feel like the hiring team needs to give you a trophy.” I was like, “But it's not that hard. We have jobs. We pay well. We have good benefits. These are smart people with experience. I'm just connect – what is hard?” And they're like, “But I don't have a network that big.” And I was like, “Really? That’s not automatic? You don’t know 100 people have gone through the same exact trauma you've gone through? Weird. Weird.” Such a strange concept.

[00:42:08] JC: Oh, it's too real. It's too real. It got a little dark. Sorry, y’all.

[00:42:13] LB: Sorry.

[00:42:14] JC: Okay. We actually have to wind things down, which is sad, because you know I like talking to you.

[00:42:19] LB: Indeed.

[00:42:20] JC: I have one last question for you, which is: being that you have been at startups or small companies for a lot of your career, being that you are now at Netflix, which is much larger –

[00:42:32] LB: Just a bit.

[00:42:34] JC: Do you have a plan in place to keep yourself from getting bored here? Or do you not worry so much about it?

[00:42:42] LB: I don't worry so much about it just because, like you said, onboarding takes a year. I'll be a year in, and I still won't know what I'm doing, and then there will be plenty of time. But the other thing is – my colleague, who's newer to the team than I am, transitioned from another team in another area of Netflix. When you have an organization this big with so many different folks doing so many different things, I think it gives you the opportunity to just sort of move around. If you're happy with what you're working on, in general – I think it's really fun that I work in television and media and all of that stuff. I love TV. I love movies. It's really enjoyable, even if I'm very not related to it in terms of the stuff I code day to day.

If I like that, and I feel like, in general, I'm treated well, there's plenty of opportunities for me to move around and do other things and not get bored. There are people who have been here for 15, 16 years. I've been here for nine months. If you ask me in four years, I might have a different answer. If you ask me in two years, I might have a different answer. I have felt this way before about other jobs but they were also smaller ponds. So, I think a larger pond gives me more flexibility.

[00:43:49] JC: Right. In some of my previous startup roles, there weren't other teams or other projects for me to move to, because it was so small.

[00:43:58] LB: Yeah, absolutely. I have switched roles. At Gatsby, I switched roles and I still found that, after about a year and a half, I'd lived through three different cycles at the company and it was time for something new. So, I might feel that way in a larger organization, or I might be more shielded from that whiplash.

[00:44:19] JC: Okay, well, I'm going to put a calendar invite for two years from now.

[00:44:23] LB: Okay, we'll come back and we'll talk about this.

[00:44:25] JC: We'll see what happened. I'll be very curious to see what happened. Alright, Laurie, thank you for coming on. I'm so stoked I got to have you on season two, and that you are my first guest.

[00:44:37] LB: Thank you for having me. I hope I kicked it off in as random away as it feels like I did.

[00:44:42] JC: No, no, it was perfect. It was perfect. Everyone's going to love it.

[OUTRO]

[00:44:51] JC: Again, thank you to Laurie for being on the podcast. You can follow her on Twitter @laurieontech. A few little notes on this season of single-threaded, episodes are still going to come out weekly just like they did, 9 or 10 episodes. If you want to keep track of when we're releasing episodes and when we might be taking a break, I encourage you to follow our Twitter @single_threaded. That's also where we'll announce if we're doing any listening parties, so be sure to follow us there. I'm looking forward to your feedback as these episodes start to roll out and I will see you next time.

[END]

Single-threaded Podcast: Faduma Mohammed on Code Reviews & Compliments

Jenn Creighton — Sat, 06 Mar 2021 16:05:31 +0000

Jenn Creighton: Today’s topic is code reviews. I don’t know if you remember your first Pull Request, but I remember mine. I was nervous. It’s really hard to put your work up for review. And think of some of the language we use for code reviews. You’re asking for approval, you might get rejected or needs changes. Not to mention, you’re trying to communicate all of this in writing. It’s a lot. Now, joining me to talk about all of this is Faduma Mohammed. She’s a Software Engineer based in the UK. She’s witty and hilarious, and her views on code reviews are eye-opening. This conversation has it all, from nitpicking nitpicks to why GitHub is a volcano of miscommunication. So, we actually met at ReactJS Girls, what feels like many more years ago than it was.

Faduma Mohammed: Yeah, it feels like decades ago.

Jenn Creighton: Oh my God it feels like, decades. But it wasn’t that long ago. I had the pleasure of meeting you there. And unbeknownst to you, you were actually there for the beginning of a talk I decided to give that then turned into this podcast.

Faduma Mohammed: Really? I was not aware of that. That’s kind of cool.

Jenn Creighton: Yes. You were there at the inception moment. I don’t know if you recall this and it’s totally okay if you don’t. But we were talking with a gentleman at the conference and we were talking about decision making for some reason. And I remember him saying something along the lines of like, “Well, to make decisions, you really have to take all the emotion out of it.” And both of us were like -- [crosstalk]

Faduma Mohammed: Okay. I don’t remember this. Yeah. But that sounds stupid.

Jenn Creighton: Both of our reactions were like, “No, that’s not right. That’s not how this goes.” Yeah.

Faduma Mohammed: Yeah, that sounds like a trauma response. Like somebody hurt you before, like what’s going on?

Jenn Creighton: It totally is. It absolutely is. It’s like you just couldn’t handle your emotions anymore and so you’re just like, “Well, we just shut them down when we need to shut them down.” But it kicked off this whole -- [crosstalk]

Faduma Mohammed: We must be objective. Yeah.

Jenn Creighton: I’m rolling my eyes so hard at like we must be objective. Ugh, painful.

Faduma Mohammed: It is really painful. I truly hate when people bring that up. It actually makes me rage. And I really instinctively want to go into a rant about how it’s impossible to be objective. It’s just impossible.

Jenn Creighton: Oh, it’s 100% impossible. Both of our reactions to him saying this, we’re both just like, no, this is not a thing. And I think back to that moment so often, and I wrote an entire talk on your emotions are not an anti-pattern. They’re actually very useful to you. And it was because of him and also it was just so helpful to have you have the same reaction as me. Because then I didn’t feel so weird about how I feel in this field because this field tells you to stop having emotions.

Faduma Mohammed: It really does. I think it encourages people to really suppress who they are and follow a weird concept of what it means to be an engineer. Which is very heavy on being a man, being from a southern socioeconomic status, not being working-class. Because working-class people have feelings. We’re very emotional and maybe you would know about how you feel about things. But yeah, I definitely feel that at the time when I’m with another person, that’s a woman because we just have the exact same feelings, I’m really glad to be working in Conde at that time with so many women. And we sometimes leave from a meeting and look at each other and be like, “Okay. That was terrible. Did you feel that?”

Jenn Creighton: Yes. Yes. 100%. I have had that where I left a meeting and there was another woman in the room and we just kind of like look at each other too. We just like, no words are exchanged. It’s just a look of just like, “Can you believe the bullshit that went on there?”

Faduma Mohammed: It’s really like people feeling themselves, yeah.

Jenn Creighton: All of this actually, I think lends itself to our topic today, which is actually code reviews. I think a lot of this stuff actually comes up in them. I’m really curious. Do you remember your first code review?

Faduma Mohammed: I don’t exactly. But I do remember significant ones. So, the most memorable code review for me was when I was working more in a back-end service. And I had maybe 20 comments in my PR review. It was absolutely overwhelming. And I’ve never had that in my career. Yeah, so that one was most memorable. And it really impacted what I value in the code review, like what I want, what I do as a reviewer, I’m like what I expect other people to like be doing while they review my PR.

Jenn Creighton: Okay. About that particular code review, the 20 comments, was that all from multiple people, one person, like how many?

Faduma Mohammed: It was from multiple people and some people that were not even my team. So, some like, bunch of stuff engineers were just theorizing in my PR review just being like, “Oh, have you thought about this?” And like, you know, “This is a really interesting concept.” Like, “You can do this, you can do this.” And I’m like, “Well, I’ve done something.” Like, “I understand that you want to discuss options, but now I’ve actually coded an option. So, it’s not really the right time.”

Jenn Creighton: You’re like, “No, no, no, no. I made a choice, you’re reviewing that choice.”

Faduma Mohammed: Yeah, exactly. Yeah.

Jenn Creighton: That’s interesting. Oh, my God. Was this earlier in your career, or more recent?

Faduma Mohammed: It was when I was a mid-level developer. So, three to four years in. So, I was used to having code reviews, but still, I think, because I’m more of a front-end, like I do mostly front-end applications. Even though I say I'm a full second engineer, that’s really where I work mostly. So, working in purely -- The more you get away from user-centric like things and more into engineering, a world which is back-end and like infrastructure, the more higher people are with their reviews. That’s my personal experience. I’m not sure that’s what everybody experiences. But, so yeah, it was my first time. And because it was a back-end service, I was a little bit more insecure. So, I don’t think I would be like that, in my front end. Like I’d be very confident about what I was producing. So, I think with those kinds of PR reviews, it kind of spirals where you’re like, “Well, okay. Let me see if their comments are actually something valid. Let me actually think about it.

And I would not do that in front-end. I will actually know I’ve actually considered these things and this is the thing that I’ve chosen. And these are, we can discuss it offline, which is my favorite thing to do. I don’t like having long argu-- pseudo arguments on PR reviews. I think PRs are not where you make -- it’s not where you discuss options or talk about any conflict that you have with the review. PRs shouldn’t come as a surprise, if you’re working in a team. You should be talking about things that should have some alignment as to what you’re going to, like the results of the ticket. So, it shouldn’t come off the cuff, like a complete surprise as to what you’re doing. So, if there is something that’s quiet, like different, as a reviewer, I always go, “Okay. Let me pause,” and actually message them on Slack and maybe have a chat on Zoom or discuss it further. I wouldn’t -- if the comment is more than two lines, I think it’s too much. Unless it’s really nice. Unless you’re say something amazing. But if it’s super critical, just have a discussion with them.

Jenn Creighton: Yes. When I started out, I remember being -- I mean, for me, even now, when I put up a code review, I’m actually still very nervous all the time, you know. And now I work in open source, which means anyone can view my PRs, which is just, “Ohh, no.” It’s really nerve-wracking. I remember my first one being really really terrified and trying to emotionally prepare myself for criticism. And I think I also did think that those were where we went about the sort of like discussions. And they gave me so much anxiety that we were going to have that sort of back and forth in a PR and it was going to get contentious. Or, I don’t know, I was going to be totaled like how terrible my code was.

Faduma Mohammed: I was the same too. As a junior, it was really -- I would look at my PR, I would write my PR description over again and again and again trying to make it seem like write something nice. I was just super nervous. Yeah, each comment always seems like they’re being quiet like I haven’t done a good job. Like, did I do a mistake?

Jenn Creighton: Also, that like 20 comments, even if they were all legitimate issues, I do feel like the more comments on a Pull Request, the more likely I am to think that that Pull Request was a failure of mine.

Faduma Mohammed: Because like, even if you’re not doing something controversial, the mere fact that there are those comments makes it seem like it’s controversial. And I feel like those PRs never get resolved really quickly because it feels like you have to reply to everything. So, that’s some of the challenges I have as a PR reviewer. I’m like, “Is this comment even necessary? What do I expect them to do about it?” Like, that’s why I asked myself, “Is this comment going to result in something? Or is it just me saying something out of like, what I like [inaudible 00:11:38]” Because I feel like I should. So, that’s the comments I appreciate, ones that are actually about action. Like, “Oh, this should be changed to this. You haven’t done this pattern, and you haven’t done like, oh, you forgot about unit tests? Oh, look, there’s a typo that you missed.” Those are quite useful. But when it’s just chatter, I don’t think that’s useful. I don’t think it is helpful when you’re like, “Wow, this is really interesting. But have you thought about these things? Or whatever.” If it doesn’t result in you advising them to do something, I don’t think it’s a useful comment.

Jenn Creighton: I think that is a good metric to base your comments on. Like, is it actually actionable? And if you do want to have those bigger theory things, I do think it’s better just to ping the person. They usually have a lot more context than you do as the reviewer, and they probably have already thought of some things that you are thinking of. So, it’s better to have a quick chat, rather than have these overwhelming comments for them to then have to respond to. And there is nothing worse, well, actually there is but it is really terrible to have a Pull Request just sitting around, just work that you did sitting there.

Faduma Mohammed: Oh, my God. It’s the most frustrating thing because you can’t really move on because you can’t really pick up another ticket because it feels a bit weird to like, you’re doing half something else and half something, your unfinished work. But I feel like as -- I think with anything, you have to leave the trust as like a -- I always trust the person doing the work that they know more than I do. And I think that is always very helpful if you assume that they’ve done the research, that they are -- they’re your colleague so you probably know them, that they’ve actually thought about what they’re trying to achieve. I think that’s really helpful because it stops you thinking or maybe have they not thought about doing this thing. It makes it a little bit nicer when you actually believe in your people that you work with. People really sometimes, especially in engineering, they’re very distrustful of your technical skills, especially if you are a woman or especially even worse if you’re a woman of color. And I will lead as an example so always just everybody. Like, I’m just like, “Okay. Well, David is great. He does good code, he writes really well. I work with him every day. We kind of know what the problem is. We’ve discussed it in refinement, this ticket’s not something that’s unknown. So, yeah, I went on a tangent there.

Jenn Creighton: No, I was -- No one can see this, obviously, but I’m nodding my head so hard. I was like, “Oh, my head’s going to fall off.” But yes, because this thing that you’re talking about, this trust issue in engineering is, I think, one of the biggest issues that we have. It affects how we interview people. We just, naturally we’re like, you have to prove yourself to me. Code reviews, I remember them sort of being -- they’ve always been presented to me as like a code quality kind of metric. And I just don’t think that’s what they are actually.

Faduma Mohammed: I don’t think that’s what they are too.

Jenn Creighton: Yeah. No, they’re way more about like -- I don’t know, what if we instead thought about them as like quality control of like, well, people are just doing bad things, because they aren’t very good engineers or whatever? What if we thought about them as a communication tool to let people know what work has been done?

Faduma Mohammed: I see it more as like proofreading. Like, can you just like fine -- Like, sometimes I’m not -- I will miss things. Can you see why I’ve missed? Especially typos, I’m very grateful when somebody points it out. But yeah, there’s a huge issue of trust in the whole industry. So, a thing that I took from one of my tech lead was that he really wanted the team to be so in line with what we wanted as a team, and what we valued. But PRs were kind of, eventually, in an ideal world be pointless, where we would just be writing because we’re so aligned in our values that nothing will be surprising. And we could even merge to master because we were so aligned. Of course, that’s not something that we did. But I feel like you shouldn’t really see code reviews in the way that it’s sometimes presented by tech pros that are like, “Well, people are going to review all your code. I’m going to go hard on you. If you don’t write, you won’t [inaudible 00:16:38] How dare you. You have insulted your ancestry.” Like fully decimate who you are. And that’s not what they are. They are really communication tools to show everybody what you’ve done so people are aware of them, and also to help you out so that you don’t make -- so they can figure out the mistakes that you’ve made and been like, yeah, helpful tool.

Jenn Creighton: Yeah, it’s just supposed to be a helpful tool. It’s not supposed to be I can’t trust this person to do their job. I must look over every line that they did, and nitpick them to death about it. The same thing applies, I think, when you’re looking in a codebase and you see code that someone else wrote. If you change your mindset to have this idea of like, they were doing the best with what they could at the time with the information they had. Don’t just automatically assume, “Oh, they don’t know what they were doing and I can fix this.” Which I’ve seen a lot and I, early on in my career, picked up that bad, bad attitude and habit because there’s pressure to conform. And I think for a long time, my code reviews and how I worked in a codebase did, I was just trying so hard to fit in so that I could be thought of as a software engineer. I picked up some bad habits. I had to really go back over the past few years and cut some of that out.

Faduma Mohammed: And that’s how I think about this. Like, I think, especially when people are really critical or very glowing about some code, I think about what my bootcamp instructor said on the first day. And he was like, “All code is shit.” And I really think that it’s true. All code is shit. After you’ve written it, sometimes it is no longer use-- like you can critique it, like it’s no longer -- like you can always improve it. Yeah. So, I always take our motto like I don’t take -- I think Git Blame is really one of the things that kind of push this kind of narrative where people are looking at who wrote this line of code and I’m also guilty of that.

Jenn Creighton: I love that. All code is shit. It reminds me of when you buy a brand new car. As soon as you drive off the lot with it, its value decreases. And it’s the same thing with code. Once you’ve written that beautiful, shiny little code, and you’ve committed it to your codebase, its value just dropped. You’re going to look at it in a few months and be like, “Oh, wait. I could have done X or Y.” Or a year later, it’s not going to work for whatever has evolved from the codebase.

Faduma Mohammed: Or a new thing has come out because JavaScript is like that. So, it’s old now.

Jenn Creighton: I know. JavaScript is like new model in the showroom, new thing, new feature, React and all the other frameworks. New shiny things, Views coming out with stuff, like JavaScript doesn’t stay still.

Faduma Mohammed: No, it never stays still. So, you have to keep that in perspective sometimes. Like, it’s not that serious, honestly, it’s not that serious unless you are writing some code for a heart monitor thing, like where the patient will die if you don’t. Everything else is not that serious. Like, it’s basically a website. Like, please calm down. We are not going to bring the world down if I add this new code. Yeah, I do love to complain about architecture about software. But like, “Oh, did you see what they --” Why are using Angular? Like that kind of stupid conversation. But yeah, it’s not really -- it’s not serious. Like you can’t really think that it’s actually important.

Jenn Creighton: And speaking of jokes, I tend to add some brevity to code reviews by making jokes in them.

Faduma Mohammed: I do too. I love adding emoji. Like, if I’m being extra with my comments, just being like, “This is the greatest thing I’ve ever seen.” Just stupidity. But I love it. I think there needs to be more of that just like extra positivity because there’s always extra negativity. And like, just to balance it a little bit.

Jenn Creighton: I love it when people make jokes and code reviews, put in a funny GIF, or make a pun, and what you’re talking about also. Like, sometimes saying this is good work.

Faduma Mohammed: It’s really validating. Yeah.

Jenn Creighton: It’s very validating, very much so.

Faduma Mohammed: Unless you’re pairing, sometimes we don’t really get any feedback about things are we writing in a nice way. We are always very critical as like, how do we improve? What can we do better? And so I think it’s really important just to take a moment and to be like, actually, you did a really good job. You smashed it, you did the thing. You were tasked to do this, and you did it.

Jenn Creighton: Good job.

Faduma Mohammed: Good job. Yeah.

Jenn Creighton: I know, for a while, I got into a mindset that was very negative, and was really based off of the previous cultures I had been in where we take things very seriously, and your code reviews are meant to be distrustful of each other. Where I was like, “Well, why am I going to say good job just for doing your job?”

Faduma Mohammed: I see those people not just in engineering, like just in life where you’re like, “Well, it’s just, that’s the bare minimum. They’re supposed to do that.” Well, you can just say nice things. It’s not like you’re changing the bar or the expectation of their job. But you are being a nice human being by giving out a compliment. You are also taking it too seriously. Yeah, I love compliments. I like giving out compliments and I like receiving them. So, I’m used to having a nice cushy, soft review, code review enviro-- that’s my fav environment. And I was talking about the PR with the 20 comments, that was my first time and glimpse of that world where you are extra critical, where people are theorizing about architectural philosophical things about coding. And I would love to get involved in those conversations or I love having them. But sometimes I just want to do my job too. And, yeah.

Jenn Creighton: Yeah, it can get in the way of you just doing your job. And like you were saying, nothing wrong with the compliment. Compliments are free. I think I had this incorrect assumption that if I gave out compliments, that that person would get an overinflated sense of self. And it’s so ridiculous because one, like not my fucking job. Like not my fucking job to decide to hold back on compliments so that someone else doesn’t like get an inflated sense of self. But also, the likelihood that someone’s going to get an inflated sense of self is a ridiculous notion. Because just speaking for myself, I’m terrified all the time that I’m a terrible engineer. I always wonder if I’m in the right field. Compliments are things that keep me going in this field.

Faduma Mohammed: Yeah, I hate this with people with parenting as well, where they’re like, “You’re being too soft to your child. You need to harden them for the world.” And I’m like, “That’s not what you need to do. The world is already quite harsh, the environment is quite harsh. You just need to be kind and be there for that person so that they can have some sort of valid sense of self to go back to. And as engineers, especially with juniors, we have to remember that we need to build them up so that they can actually not have imposter syndrome, but feel validated in this weird-ass field that we work in.

Jenn Creighton: Yeah, you’re right. The world is harsh enough. We’re going to learn some really harsh lessons. Let’s make some more like safety for people to fall back on. Those compliments that people have given me over my career, literally kept me in this field at times when I felt like I really didn’t belong. You can do that same thing and you’re actually giving them a compliment for a good job. You’re not just doing it for funsies. Like you’re saying good job. This is actually a very difficult thing to do, to do some work, and then put it out for everyone to comment on and be critical of. And also, if you want to be critical of someone, there are ways of doing that, that are constructive and still very nice.

Faduma Mohammed: Yes. I think people need to realize that written word is a quite challenging form of communication. And you really have to try extra hard to make sure that what your intentions are actually being seen with the comment you’re making. Because I’ve seen people write really like so harsh comments on them. And I spoke to them, and they’re like, “Oh, no, I wasn’t really that serious.” I’m like, “I did not get that impression.” So, maybe in your mind, you were trying to be not serious, but I did not get that. So, you really need to work hard and how you actually communicate in writing. And we need to stop communicating in the Git comment like, “You need to finish this.” Or like three word comments where it’s just like, “Change this, please.” That’s not helpful. That’s not helpful. Like, I’m dyslexic, so a thing that I always get back to is a very formulaic way of writing because that makes it easier for me to communicate. But I work -- I know this about myself. And I take extra time in making sure my tone of voice and what I’m trying to communicate is actually [inaudible 00:26:54] through. And I’m always surprised that people don’t do that.

Jenn Creighton: This is a very difficult topic because I have struggled with -- I’m just very, like I tend to be very flat in my tone or what I perceive as flat. And other people will perceive it as being a little bit more harsh. And it has frustrated me in the past because I feel like men in our field can get away with that, but I’m expected to be softer. And at the same time, I had to have like a reckoning with myself where I was like, “Well, maybe though you do need to still adjust your tone, maybe I know it’s frustrating this gender part of it that’s coming into it that really frustrates you because you don’t want to add the emoji to seem nice. But you have to add the emoji to seem nice.” So, one of the things I started doing is I’m using Grammarly, which gives you a little bit of sentiment analysis. And I use that for like everything that I write now to try and -- I don’t want to have to add emojis to things but it does give me a little bit of like, I could say this maybe in a way that this sentiment analysis thing will like be like you’re being nice.

Faduma Mohammed: Or you’re being neutral. Yeah, I get what you mean about like the gender roles because I struggle with that because I am quite feminine. It’s just how I am. I’m a quite feminine person, and that’s completely fine. But I get what you mean about feeling like you need to not be typical, just like so that people can feel like you’re actually a software engineer, like you’re one of them. And I really hate that so much. And I actually rage against it. Like, I’m going to be my feminine self. Like, I will be my emoji-soft person. I don’t care if you see me wearing or having pink [inaudible 00:28:53] like that’s for me. And yes, I am being a typical person for my gender, but there’s nothing wrong with that. There’s nothing wrong with being feminine. And we shouldn’t really demonize anything to do with, like everything to do with femininity. Yeah, I think that’s quite sexist. I see that quite a lot.

Jenn Creighton: Earlier in my career, I really held back on a lot of things that are typically girly because I wanted to be taken seriously. And I knew, I noticed that if I came into an interview dressed very feminine, it was likely not to go well. It was weird. And if I came in dressed like jeans and a T-shirt, it tended to go better than just the perception of me like in the office and stuff. And then once I got some years of work experience under me, I started putting more pink around my desk.

Faduma Mohammed: Yeah, I have just accepted that I’m going to be a person that sticks out. I’m a black woman. I’m going to stick out. Everything about myself is going to be different. And honestly, there’s literally no point in conforming because I’m never going to get to the point where I’m fully accepted. So, why not just be myself?

Jenn Creighton: I’m so glad that you got to that place because it’s been -- you got to it earlier than I did.

Faduma Mohammed: No, it was really difficult. Like I’ve had a quite challenging experience in this industry. It’s been difficult. But I wanted to be a lawyer and that would have been difficult too. So, I really have to, like ground myself in the reality that the world is harsh anyway. But I’ve definitely had very challenging experiences, especially as a woman and a woman of color, and being the first all the time is very hard.

Jenn Creighton: Right. Because I’m sure you’re not just the one woman on the team, which is what I’ve often experienced. You’re probably the first person of color on your team, the first black person on your team.

Faduma Mohammed: Or in the whole company which I’ve had it before.

Jenn Creighton: Oh, shit. Yes.

Faduma Mohammed: Yeah. Like the only black person in the whole department, which I’ve had too. So, yeah, this comes with like major challenge. And one of them is definitely code reviews because people won’t take you seriously because they think you are like a token hire. Like people are only being nice to you. You are the person that is like here to make the company look nice and to increase the diversity scores. But I feel like I’m a really good engineer and the moment I start working, it kind of dissolves that, I think. Not entirely, but in my mind, I’m great.

Jenn Creighton: I’m sure also, what happens a lot is that anyone who is marginalized or underrepresented in tech, when someone who is overrepresented in tech looks at them, their automatic thought is that we have way less experience than we do. We’re automatically assumed to be a junior. Which nothing wrong with being a junior engineer. It’s just that if you keep being perceived that way throughout your entire career it makes it really difficult for you to get to your next level.

Faduma Mohammed: 100%. Like everybody assumes that I’m not the level that I am and I don’t know as much as I do. Because I’m a very studious person and I have so much anxiety about what I know. Still, I do study up too much and I definitely did that right in the beginning of my career where I was just coding a lot. Like, I was doing extra projects. Like I was just like, I knew about the latest everything. And now I just realized, like do you know how [inaudible 00:32:39] mediocre? Why do you sound really mediocre? And why am I trying this hard? Like, it’s not necessary.

Jenn Creighton: I did the same thing. I studied so hard, so hard, because I -- Oh, God. I just want it to be seen at the level that I was. And I couldn’t do that without studying way harder than my white male peers. And also, it did come out in code reviews. I definitely had people make comments in code reviews to me that were very dismissive. And I could tell why they were -- like, I knew why they were doing it. I had a particular code review when I was, I would say, like more mid-level easing up on senior by -- I had another partner on this team. I was supposed to be leading the project. He actually had less experience than me. I gave him some code reviews. Some of them were nitpicky, but some of them were valid and he ignored every single one. And told me no, he actually told me straight out no to all of my comments. And then if a senior dude would comment with the same thing, he would do it. And also no one believed me on why it was happening. I was like, he doesn’t think I have as much experience as I do. He thinks I am lower than him.

Faduma Mohammed: I’ve had that before. I’ve had, like me being a mid-developer and then on like, how many years and then I realized that my senior, the person that’s a senior developer has less experience than I do. And I’m just like, “What the hell? What the hell? Why do you have that title when I had to fight so hard just to be considered mid? I literally had to really go, like fight really hard to be promoted. And you just got that title because well, you did a computer science degree. Like what’s going on? Like, am I not doing the same as you did?” But yeah, I think there’s lots of misogynistic, alpha dudes that whenever you leave out like a weird comment on their reviews where you’re like, “Oh, can you change this a little bit?” They feel like it’s like a green light for them to be really hard on yours. It’s like going tit for tat. Just like you wrote a comment on mine, I’m going to do that for you and it’s not very helpful.

Jenn Creighton: No, it’s not. It does become like a little competitive thing that just serves no one in the end. Because again, code reviews are not about that. Right? They’re about communication. Speaking of that, tell me a little bit more about the code review kind of processes that you’ve worked with at companies. One of the ones that I worked with was very fond of labeling nitpicks as nitpicks. I don’t know if you’ve experienced it.

Faduma Mohammed: I’ve had. This is my pet peeve. This is truly my pet peeve. Whenever someone writes minor or nitpick, I’m like, “What am I supposed to do with this? Like, what are you telling me here? You’re just basically complaining? You’re basically complaining. I can’t do anything about your nitpick.” Yeah, I hate it so much. Just keep it to yourself. If it’s minor, then it’s minor, and it’s not worth commenting.

Jenn Creighton: That’s a very straightforward recommendation. There was a company, I want to say it was Netlify. But I don’t remember that they released their PR review guidelines. Which one, I do think it’s nice to have PR processes written down. A lot of times you go into companies and you just look at their PRs and kind of figure it out, or you’re told, but there’s no written thing. But they had a whole guideline that was like, “Oh, we put in like, how serious the comment is based off of like, it’s a pebble, it’s a stone, it’s a rock, it’s a boulder.”

Faduma Mohammed: Oh, God. Just add cute names to annoying things. Yeah.

Jenn Creighton: It’ll be fine if we call it a pebble. You won’t get so annoyed if we just call it a pebble and you have 20 pebbles on your code review.

Faduma Mohammed: That is basically a beach, pebble beach. Yeah. So, that tells me that they have bad code review culture. And when I see those, I definitely agree with you. Having a guide is really important, just so that newer people who are more engaged to your codebase or your team or your company can actually figure out how to contribute and [inaudible 00:37:21]. When I see those kinds of guidelines where they have to say that, it means that they have really struggled with their code reviews where people are adding way too much comments. And maybe some of them are not that serious. But yeah, I think it goes back to again, what are you trying to achieve, right? You want the code reviews about making sure that thing that’s been added is not going to create catastrophe. And you’re proofreading it to make sure there’s nothing extra wrong with it, making sure that they have the same value. So, if you’re testing is important, so making sure that there’s testing in it. But everything else I think is kind of not important. Like code styling, linting normally takes care of that. I’m sure -- just have Prettier, like that will help make sure everything is aligned.

Jenn Creighton: Thank God for linting. Before linting, our code reviews were just like, you need to put a semicolon here and this needs to be indented.

Faduma Mohammed: I love Prettier. Prettier, I think is one of the best things that came out in JavaScript. It literally just fixes everything, just makes everything just like perfect and I love it. Everything else, I think is not really -- Like if they are following [inaudible 00:38:37] pattern, then I think you should have a discussion with them and say, “Hey, let’s have a discussion offline. Like maybe there’s a reason why you thought of a reason why that you’re not doing it that way.” Yeah, I really like just mostly just having actual conversations with people if you have any worries about a PR. But having to leave a pebble or boulder, I don’t think it is an actual improvement or a good code review culture.

Jenn Creighton: These guidelines like that are I think indicative of people not talking to each other very much. We are really hesitant to talk to each other.

Faduma Mohammed: We really are. We don’t like to talk.

Jenn Creighton: We don’t like to have conversations. Is it because we don’t know how? I know with COVID, at least, I have forgotten how to socialize to a certain degree. But the best environments that I ever worked in were like we talked a lot about code reviews before they even went up. Or one of the things I really love to do with my code reviews is if I look through and I sense that there might be questions about something, I just go ahead and document it.

Faduma Mohammed: Me too. I add a comment straight that’d be like this is why I remove that. Or I think it’s confusing. Because sometimes you only see a snapshot of the files that you’ve changed so you don’t really have -- Like, unless -- [crosstalk] Yeah, you don’t have the full context. So, I like to add comments to mine, where I’ve like done something slightly different. Or if I have a question being like, “Hey, I don’t feel really good about this. I’ve done it this way. If you have better suggestions, let me know.”

Jenn Creighton: I think that is really, really helpful. One, just making sure your description explains things. Also, a great place to put in jokes, just a great place to put in jokes is the description.

Faduma Mohammed: Or screenshots, would be nice. Yes.

Jenn Creighton: Put in screenshots [inaudible 00:40:32]

Faduma Mohammed: Or GIFs, I love that.

Jenn Creighton: Oh, my God, I love. That changed the game for me when I was doing code reviews at previous companies; changed the game.

Faduma Mohammed: Just take a video of the thing that you’ve changed and then it makes my reviewing so much easier.

Jenn Creighton: It’s so hard if I can’t visually see what’s going on. Screenshots, GIFs, do them. There are really great little helpers that you can download to do these things really quickly on your computer, like just do it. It’s so helpful.

Faduma Mohammed: Because then the person reviewing has to like actually pull it down, run it, and see what you’ve done. [crosstalk]

Jenn Creighton: Oh, what a slog, you know.

Faduma Mohammed: And like it’s just -- Yeah. We are lazy engineers. We don’t want that.

Jenn Creighton: Even better as like a preview link. But still, then I think sometimes you just don’t know what section they’re talking about and you get kind of confused. So, screenshots, GIFs.

Faduma Mohammed: Screenshots, GIFs. Definitely, I think we have a problem with not speaking. And at the PRs, GitHub is where our failures come to light. Because it’s just like a little volcano of people misunderstanding and miscommunicating. And just -- [crosstalk]

Jenn Creighton: It’s a volcano of miscommunication. I love that. And I really want that as like a sticker or a T-shirt, volcano of miscommunication. I mean, that’s what happens when you push communication on to a certain platform. You know, we need these platforms to discuss our work and things like that. But you really do need to figure out when that discussion needs to happen offline.

Faduma Mohammed: Definitely. Like examples that I think I do all the time is that if I’m unsure, or I think there’s like a weird tech-death thing that I’ve encountered, or I’m having challenges, like the way that I have to do something is like ugly, I don't feel great about it. I’m like okay, I just add a comment in Slack saying, “Hey, these are things I’m struggling with. I want to have chats with. This is a meet-up link. Come have chats.” And I rather do that than have it as a surprise in my PR.

Jenn Creighton: Like you said in the beginning, a code review shouldn’t be surprising to you. You should have some communication beforehand about the ticket that you’re working on, or the piece of code that you’re looking at.

Faduma Mohammed: And also, if you’re not on the team, maybe code reviews -- don’t review somebody else’s stuff, like be careful about how you’re reviewing it. Don’t add weird comments like, “Oh, this is interesting.” Like, I understand. I understand that’s interesting. But I don’t know what to do with your -- you don’t have context. You have no context. But you know, I don’t want to say don’t review at all, but just be careful as to like what you don’t know. You don’t know what you don’t know. So, how can you review something when you don’t really know the full context?

Jenn Creighton: You also don’t know that person if you’re not on the team with them, and you haven’t developed any sort of rapport with them. When you have a rapport with someone, you take their written conversation way differently than if you don’t know that person. So, you really need to be careful. And if you’re joining a team for the first time, your first few code reviews that either you’re presenting your work, or you’re reviewing someone else’s, you need to be really careful about how you’re talking to these people that you haven’t built up a rapport with yet. Maybe even look back at old PRs from those same teammates and sort of try and figure out how they like to communicate before moving forward.

Faduma Mohammed: So, a thing that I love to do is PR pairing, just like PR review pairing. So, I would offer that to people just to like if you’re struggling reviewing my PR, I can walk you through what I’ve done and we can talk about why I’ve done it. I don’t mind doing that. So, just like ping me and we can do it. Or if somebody has a PR and they want me to review it but they’re not sure about it, we can review it together. I loved that as a junior when I was struggling giving reviews because I did not feel qualified to give reviews for a long time. Like I felt like I didn’t know enough about anything to be critical about like any code. And I loved reviewing things together with other engineers.

Jenn Creighton: That’s a great idea. I don’t think I’ve actually ever done a pair review before. Honestly, when I got into software engineering, I thought there would be more pair programming than there has been. I love this concept too of applying it to reviews. It’s also just a great way to build a rapport with someone. It also is a very nice way of getting you comfortable talking about your work, or getting comfortable asking people about their work.

Faduma Mohammed: And figure out how they problem solve because that’s really interesting too. So, you’re like, “Oh, I did not think about that. That’s really cool.”

Jenn Creighton: Yeah, what a great strategy. That’s really great. We have to wind it down now. I’ve actually kept you a little bit over time. So, thank you.

Faduma Mohammed: Oh, no, it’s been great.

Jenn Creighton: I love this conversation. I knew this was going to be good when I brought you on. We had such a good time at ReactJS girls -- [crosstalk]

Faduma Mohammed: That was fun. I really missed that.

Jenn Creighton: Oh, that was such a good conference. I had such a good time there. And meeting you, I was so happy to meet you. We got off really well. I just enjoyed talking with you so much.

Faduma Mohammed: Me too.

Jenn Creighton: And so when this came about, I was like, who do I want on this? Yes, yes.

Faduma Mohammed: I feel very honored that you invited me.

Jenn Creighton: It’s been great to have you and you’ve given us so much information. You know, this thought of maybe don’t say something if it’s not actionable on a code review, you know, that nitpicks maybe just don’t even bother with them. I think those are kind of standard in our industry now. And like, maybe we don’t, maybe we don’t. And I love this idea of pair review. I’ve never done that anywhere before. Fantastic.

Faduma Mohammed: Mostly, engineers need to chill and be nice to each other. I think that’s really the headline.

Jenn Creighton: That is the perfect headline. Thank you so much. So, happy to have had you here. Thank you so much.

Faduma Mohammed: Thank you.

Jenn Creighton: Y’all, how good was Faduma? How good was that? I am so happy she stopped by the podcast. She is definitely worth a follow on Twitter. I hope you had a good time. I hope you got something out of this. I will see you next week.

Single-threaded Podcast: Crystal Martin on the Value of "I Don't Know"

Jenn Creighton — Wed, 03 Mar 2021 22:25:49 +0000

Jenn Creighton: Today, I’m joined by Crystal Martin. Crystal is a software developer, conference speaker, co-organizer of the Strange Loop Conference, and a diversity and tech advocate. Crystal has amazing energy. And you are going to love this conversation. We started with a tweet she wrote about what happens when you discover you don’t know the thing you thought you knew. And from there, we explore why, as software developers, we feel pressure to produce in a vacuum, how to handle our mistakes, and the value of saying, I don’t know.

[intro music]

Jenn Creighton: I don’t think we’ve actually gotten a chance to speak in person since JSConf Hawai’i.

Crystal Martin: Yes, yes. It’s been a while.

Jenn Creighton: Yes. But I’ve pretty much been using this podcast as an excuse to talk to anyone that I’m like, “I just want to talk to them.”

Crystal Martin: That’s a great idea.

Jenn Creighton: So, I was like, “I’m definitely having Crystal on like, absolutely.” Also, your energy is like, so good. You always give off like really good vibes.

Crystal Martin: I’m so happy to hear that. I feel like sometimes I could be too much.

Jenn Creighton: No. Oh, my God, never. Never too much. Honestly. You were like such a fresh breath of air at JSConf Hawai’i. Like, as soon as I met you, I was like, “Oh, thank God. This is like --you’re so refreshing. And oh, just so funny. My God, you say the funniest things.

Crystal Martin: Thank you.

Jenn Creighton: So, into it. Speaking of funny things that you say. So, one of the reasons I wanted to have you on it is you have this tweet that I’ve gone back to actually several times now because I haven’t realized that I’ve had this experience multiple times. And you so succinctly in tweet format for me. And the tweet is, “You ever be writing JavaScript, and then realize you don’t fucking know JavaScript?” Yeah, yeah. Yeah, like multiple times in my career.

Crystal Martin: The amount of support that I got from that. When I tweeted that, I was like, “I’m not alone.”

Jenn Creighton: You’re not. Oh, my God, it brought up a lot of feelings. You can see everyone’s being like, “Yes.” So, can you go back to that, when you ask when you wrote that tweet, like what was going on?

Crystal Martin: It was like, it’s funny, you asked, I kind of go back to the moment and I almost remember like, what I wear, what I looked like on that day. And I was at my office really late because I had just gotten on this project to basically rebuild an application for one of our client partners. I work for Slalom Consulting in St. Louis. And we -- So, maybe I shouldn’t have mentioned that, because they’re probably going to be irritated anyway. It is what it is. So, like Lightning Web Components was something that had just come out on the Salesforce platform. So, I was working on the Salesforce platform, building custom components and interfaces. And we were doing a new implementation, rebuilding this app that was in their old kind of framework, which is Salesforce Aura components, Lightning Aura Components. So, we were doing this new implementation, basically, the idea was like, if we’re going to do a new implementation, we should just use the newest thing, right? Which makes sense, like, be early adopters. But really, like I was on the bleeding edge of this like, if that -- I don’t even know. Yeah. It was like, no one really, truly no one had really built anything from beginning to end in LWC, that I knew of because I also stalked -- Like, I literally stalked like Salesforce people to be like, “What’s going on here?” But I had been working on this, I was pretty new to work in this in JavaScript frameworks. I had done like I don’t need to talk about that before times when it came to that.

But basically, I was new to the idea of like, smaller components like what people were doing in reactive view, and angular and all that. I was pretty new to that. And the way that Salesforce did it previously was very different and didn’t really follow most of the patterns that most modern JavaScript frameworks follow. So, it’s just like, I was just like drinking from a firehose and it was a lot and I was the only dev working on this. I was just, I think I had gotten -- it was the end of the day and I had worked with one of my co-workers that had one experience with JavaScript and the framework, and he just showed me all these things that I didn’t know. Like all of these, like, you know how JavaScript ES6 has a lot more -- You know, there’s a lot more features that if you’ve been writing JavaScript like with jQuery, you don’t know about all this stuff. And so he was just showing me all the things and improve my code, made it better. And I just was kind of stymied, just like from that day, so many things had happened, I had so many meetings. I was like, trying to like, basically convince people that I knew exactly what I was doing when I didn’t. I had no fuking idea what I was doing. But it was kind of exciting, but also scary.

So, at the end of the day, I’m just like, I learned so much, I had done so many things. And I had worked on this one feature for the whole -- for that entire week. And I was literally leaving the office and nobody else was there and I just picked up my phone and I just tweeted that out. Kind of just be like, what the fuck was this? And what was this day? What happened? What is JavaScript? What is my life, and I kind of just literally, I tweeted it, put my phone in my bag, and just like got home, like drove home. Kind of just chuckled to myself and drove home. And I opened up my phone and I was like, “Holy shit.” And yeah, just like I got a bunch of like, it’s funny. It wasn’t just like retweets and likes, it was like people were talking in this thread, like, “Yes, I feel this all the time. Like, I’ve been a JavaScript developer for 10 years and I feel this way.” And so it's interesting to see and also pretty dreary, at the time, like it was still really, it was really nice to see the other people that have more experience in your life. This is like a normal way to feel about writing JavaScript, especially when you’re like diving into frameworks that everyone to a certain extent feels lost. And, yeah, so that’s kind of what happened.

Jenn Creighton: Yeah, that’s a very relatable experience. Definitely. Especially the, what is my life? What is JavaScript? What am I doing? I can’t tell you how many times I have that thought or that like, maybe even I don’t even know that I would count it as like imposter syndrome, though, it does seem to be in a similar vein of that. But sometimes, I’m like, “Am I in the right career? Is my brain really cut out for this?” But like you said, it’s so helpful when people admit that they also are lost.

Crystal Martin: Yes.

Jenn Creighton: I feel like we’re very, very hesitant to do that as engineers. Like, I think people, in general, have an issue. But I think it’s particularly difficult in this. Why do you think that is?

Crystal Martin: Well, it’s the myth of meritocracy, you might submit it like you’ve got to be able to -- like, the only way you’re valuable to the field is that by your contributions and like your ability to do something and deliver. I think, because the nature of programming is step-wise, and it is like you have to go through a process to figure things out that people think, well, if I just follow the process, I should be able to follow the process and solve a problem. And that I should be really good at that once I’m at this year mark. I actually just had this conversation this week with a colleague. I had another tweet that I tweeted this week where it was just like a message that I had sent to my coworker that was like she reviewed my PR and was like, “Yeah, this needs some work.” And I’m like, “It needs work? This PR is amazing. I can’t believe I just bang this out.” And look at what I did and I basically did everything right in the wrong place. So, all of my tests were wrong, all of my code was wrong as it were, I need to pass this parameter.

And she goes, “You know, I just want to say that I did offer to like, talk through this with you.” And I was like, “Fuck. [inaudible 00:08:40] And as I realized my mistake, I was like, Oh, my God. Fuck. What? LOL. Oh, my God. What the fuck? Like, I just like totally fuck this thing up. But I was talking to my coach about this and I was like, I just felt like I didn’t want to ask her for help because I wanted to figure it out on my own. And I need to be able to do that. Right? I need to be able to just take something on my own and not have to run it through somebody else and get feedback. Actually, just take the problem and finish the story. Right? And my coach has also been -- he was a software developer for like, God knows how many years at a variety of different companies and capacities. And he’s just like, laughing at me. He’s just shaking his head, nodding, and smirking. And I’m like, “What are you laughing about?” And he’s just like, “No, I hear everything you’re saying. Let me tell you --” He said, “Okay. I’m going to put on my developer hat. I’m taking my coach hat off and putting my developer hat on.”

And he goes, “You do realize my entire career after we talked about a story or a feature, and we had it on the board, and I was going to code it. I had a practice of always talking to another person on my team before I started coding it.” He said, “I did that with every story. Before I started writing code, I talked to a colleague about what approach I was going to take.” And I was like, “Well, fuck.” So, in so many ways, he was like “You’re wrong. Like, you’re wrong. You’re actually like, your idea of what you should be able to do is incorrect. Because how can you expect yourself to see all the corners and walls you can hit? How could you expect yourself to be able to just have it all in your head and then code it? That doesn’t make any sense. That’s like not how brains work.” And so, it was reassuring. I feel like I owe my colleague an apology because I was kind of like, “What do you mean, I should have talked to you about it before?” Because I just -- I really want to be -- I just had this hang-up on being helpful and effective. I think what would have looked helpful and effective for my teammates, is if I had just asked people to review this with me and talk about it so that I didn’t have to do the same work twice. Right?

Jenn Creighton: I do identify also with you being like in that PR, just being like, “No, I didn’t do anything wrong. What are you talking about?” I’ve made that mistake before. I did recognize that that was just me being like, very fearful that they were going to tell me that it didn’t belong. Like that was the end result was like this, building up of a case against Jenn. And I was like, but no one’s doing that, Jenn, why are you?

Crystal Martin: Nobody’s done that.

Jenn Creighton: Nobody’s doing it but my brain was like, “[inaudible 00:11:17] this. I don’t belong. They’re going to kick me out.” And then it was fine. It’s very hard, though. Another point that you brought up was this idea of our worth in tech being tied to our ability to produce and to produce, like in isolation. I think that is actually something that got stuck in my brain as a young developer of like, what a senior would be.

Crystal Martin: Yes, 100%. I think the funny thing is that I am learning that isn’t the case. But I can’t tell myself, I can’t let myself believe that because I feel like I have to keep myself on the hook to be this superduper programmer that doesn’t need anybody to come in and help me. And it’s actually hilarious because the whole foundation of my personal brand, if you call it, like on my website, you go to my website, and one of the first things you see is that people need people, right? Like, that is something I believe. I believe that nobody can do anything alone. You never -- even if you feel like you’ve climbed a mountain on your own, or you started this business with your own money and your own will, there’s always -- you can always look back and think of tons of names of people that helped you get to where you are. You never do anything alone.

And so I think in some ways, it’s like, we took a culture that I actually think is dying in technology and imposing it on ourselves because we thought that’s the only way we can actually be seen as a useful member of a development team. But it’s just not true. And like, honestly, I have to say that I have never been on a single team of people who had that expectation of me, right? And I used to even say to myself, I wondered if people’s expectations of me are just lower, you know? And that’s why they’re telling me that I need help, and that everyone needs help.But it just simply isn’t true. You actually really do need someone else to help you formulate ideas.

And I mean, there are people who can just write code on their own and it's great and that’s fine. But I think even engineering organizations and businesses are emphasizing teams more than ever. And where I work that’s definitely the philosophy like we don’t just send developers for a tech problem. We send solution owners or what we kind of call -- but they’re product owners, basically. We send designers, we send business analysts, we send QA, we send people who have expertise in different areas to create an overall well-rounded solution to the problem. Like, developers are not the most important part of a project. Right? Like, has anyone ever tried to work without a scrum master or product owner? That shit sucks. It sucks. It’s bad.

Jenn Creighton: Yeah. That’s why when -- So, I worked in some very tiny startups, and oh, my God, we didn’t really have product managers or -- it was just a mess. It was a mess. It was so hard and what ended -- like the developers would take on those organizational tasks. So, it wasn’t like the developers -- I don’t know. Developers, we do like to think like we’re the most important thing in the world and like we’re not doing anything that --

Crystal Martin: Revolutionary, no. We’re not changing the world.

Jenn Creighton: No. Yeah. You go up to a doctor and you tell them [crosstalk] that what you do is -- your work is real important. You tell them that. You do that for me because it’s not going to go well for you. Yeah, I don’t know. We always think we’re like curing cancer. You’re right that -- I do think this notion is starting to die out in tech, but you still come across it a lot. It still seems that a lot of organizations still really pride themselves on hiring that 10X engineer who goes off into a room, build something, and then brings it out. And I’ve just always found that to be incredibly toxic toward the entire team.

Crystal Martin: I have had the privilege of not really working with a developer like that. I’ve worked with someone that could have been that, but he just wasn’t. And we all got better as a result. That’s the cool thing about it is like, he could have easily been like, “Yeah, I’m a 10X developer.” Like he can just say, “Oh, you’re having problems today? I’ll just finish the story for you.” He could have taken everything that we were doing and just finished it. And it would have been like, really probably really good or at least done. But he just didn’t. And he didn’t like -- he didn’t give us any room to get off the hook for things. Like he provided help, but he was just like, “No, you got this, you know how to do this like this. No, that’s a normal mistake to make, that’s a normal thing to like assume, you’re good. You know, carry on.”

It’s like, to me, that’s what 10X developer is like you think about a multiplier. A multiplier is not like that you can finish 10 times more code in a short amount of time. Who cares about that, honestly? Like that doesn’t -- Speed does not provide any value to anybody, right? I mean, unless I get if you have -- Actually, no. Like, speed is not a priority. And I even -- I impose it on myself, I think that should be faster. But like, when you think about it, like the best developer going too quickly is going to fuck it up. So, like 10 times to me, is like you think about the actual notion of multiplication is that everyone around that person gets better, right? Like that’s being a multiplier. That’s being a 10X developer that now your skills and your ability have now rubbed off on everyone else on that team because of your leadership and your ability, not only to code and execute, but to also like be a part of a team.

Jenn Creighton: And you don’t have to be a senior for that. That’s the -- You do not have to be a senior to be that type of person on your team.

Crystal Martin: You don’t. And I think I’m learning that myself that -- I’m going to brag for a minute because like I just got a raise and a new title. I know.

Jenn Creighton: Oh, tell us more.

Crystal Martin: You can call me senior consultant. Yeah. So, anyway, [crosstalk] I asked for feedback as to how that decision was made for my boss. And he was just like, “We looked at your profile because we had to kind of do this whole like rundown of our careers and all the roles we’ve played, and how that plays into where we think we fall, title wise. And also the responsibilities we can take up on a team.” And he said to me, he’s like, “It’s not just about the technical skills. Like, have you been in the field for a long time? No. But what you bring to the table is your ability to work with people, your ability to mentor and coach, your ability to teach. Like, you were an educator before you came here and that means something.” It was so affirming to hear that. But I think that’s sort of a testament to me that businesses are actually paying attention to people that are not like these TEDx developers, and the way that has been defined. You don’t want a team full of those people. Right? That having a team full of 10X developers sounds like a fucking nightmare. I think that those folks that are fast and are smart, are important to our field, but they’re not the end all be all.

They shouldn’t be prioritized over anyone else to say is an ex-educator, a teacher, nonprofit worker going developer. Like that is equally as important to have on teams with people. Because at the end of the day, the hardest part of development, especially as a consultant is the people part. We can build all kinds of shit with our eyes closed. Do you know how much time we spend not coding and trying to figure out what the problem is? Like, what problem are we actually solving? And like, who wants it and who needs it? And what are they saying and read between the line? Like, that’s what being a developer really is. And maybe I’m thinking of this from my perspective because I am a consultant and developer. But, I imagine even on internal teams, like it’s the same thing. Even if you’re building a product for your company that you work at, it’s still the same thing. Like, is this the problem you want solved? Like, that’s what developers are spending a lot of time doing.

Jenn Creighton: You are correct. That does happen on other teams. Like, I’ve had this conversation multiple times with people about the evolution of what I thought a senior engineer was over my career. Because I think when you’re early in your career, what you think it is based off of what you experience is that it is a person who knows everything about the language that they’re working with, like everything about the tools and everything. Like they just, they don’t even Google. They’re just amazing like that super, super quick, and do things super independently. And that’s sort of the messaging that we receive around what a senior engineer is. And that’s based off of the people that we see who are getting raises and titles and promotions, the interviewing process that we are put through. Like, they look for how well you know the language, not accounting for the fact that we are all going to have those, “I don’t fucking know JavaScript moment.”

Crystal Martin: Or like, “Oh, this project actually calls for not JavaScript. So, go fuck yourself.” No, you have to do something else.

Jenn Creighton: Oh, yeah. A strange idea, figuring out the actual tool that you need, instead of just treating everything the same, an odd idea. Yeah. So, we just think that’s what it is. And then when I got to a certain point, I was like, wait a minute. It’s not because I know the language the best. It’s not because I’m the fastest engineer, because I don’t consider myself very fast. But I do have a better understanding of what the problem is that we’re working on, when a problem maybe shouldn’t be taking my attention and what actually is the priority, and how to decide the prioritization of things and how things should sort of be more like architected in a system. And I think that’s when you’re -- I was like, “Wait a minute. I am a frickin’ senior.” Give me my title.

Crystal Martin: Yes. Call me senior, bitch.

Jenn Creighton: I actually had the most wonderful experience that I wish on everyone in tech, which is that I interviewed at a company, they gave me a mid-level title. And within six months, I was able to get a senior title. The person who had interviewed me and said I was mid-level actually apologized to me. He told me, “I thought that the interview, I thought you were a mid-level, I think I put too much emphasis on this question that we’re asking in the interview cycle. I got it wrong. You should have come in as a senior. I’m sorry.”

Crystal Martin: That’s wild.

Jenn Creighton: Everyone needs something like that in their career to boost up their self-esteem. Because I was fighting for this senior title. And the whole time I was like I feel like I shouldn’t have to be doing this. And I got confirmation that yeah, I should have come in at this.

Crystal Martin: That’s so amazing.

Jenn Creighton: Oh, it felt so good. And he apologized too. I was like, “Thank you.”

Crystal Martin: Mistakes are fine, as long as you realize you made it and you don’t do it again.

Jenn Creighton: I mean, I don’t know what to do about the interview process that we like, really index on language and we can’t really index on other things ‘cause -- [crosstalk]

Crystal Martin: You know, I’m just thinking about this last year. And basically, I feel like I spent just the whole year just yelling. Just like being a broken record and any opportunity, I got to say something that I felt like was true and needed to be considered. I just said it everywhere I went in my organization, like I just said it all the time. Any conversation I had with anyone, especially leaders I just said this, I have a script, basically, where I said the exact same thing again, I just continued to say it. And I think people -- you know how you hear that people say you have to hear something three times in three different ways to get it? And I think that really is true. I think changing organizations, you can’t go to people and say, “This is wrong. This is how you should be doing it” and just expect them to take it at face value. And it’s not because you are like, the reason they’re not listening to you could be, could be based on the fact that you're young and female and feminine and black or whatever [inaudible 00:24:00] you are that could be the reason.

But a lot of times just like there’s been no trust built, they don’t know you, they don’t know your intentions, they don’t know what you’re saying. They also just don’t know how to act on it. And so I have taken this approach where like, I would just send emails with articles about things. And instead of being like, our organization needs to do this thing because it’s the right thing to do. And you’re out of alignment and you’re not doing the right thing if you don’t. It’s like an invitation to get curious. You know? Like, I’m not going to beat you over the head with -- Okay. Well, I should say, I’ve already beaten you over the head about equity, especially this summer around black people in our organization. I’ve done that over and over again. Yes, you’re going to hear me beat you over the head with that until the cows come home. But, also, maybe I can give you something to consider without you even having to talk to me right now. Like here’s just some food for thought, read this article. And if you’re interested, give me a call. We can have a call about it, we can talk about it.

And so I say that to say there are ways to -- Like my friends said this actually like during the summer when the world was exploding. And we were just talking about what it’ll take for organizations, especially tech organizations in these big companies to really have -- to take a stand on Black Lives Matter and that it just be like a [inaudible 00:25:28] diversity theater. I don’t know if that’s the term people are using. But what it would mean, and something my friend said that I think was so profound, and I say it to other people, I think I could say to you, she’s just like, “The notion of perfection. And these companies getting it right on the first try is white supremacists. Like the actual concept of perfection is a part of the system of oppression that we all basically have fallen prey to. And like, by expecting organizations to just get it right on the first try, is, in a lot of ways, buying into that without even really realizing it.” And that was really, I didn’t fully understand it, I think it can be interpreted in a lot of different ways. But it was a helpful reframe for me, in how I wanted to approach change within the tech field and within my organization. It’s just like, kind of managing expectations, still pushing but manager expectations and like, trying out different strategies to get the point across.

Jenn Creighton: Different strategies I think is something that I have struggled with when it comes to wanting to push forward change in organization. And sometimes I’ve gotten to a point where honestly, I was like, maybe I just sit down, shut up, do my work. One, to like, self-preserve, because it’s exhausting. And two, that’s how you build credibility, and I hate it. I hate it. But it is true. Before you get to like make noise, you need some social capital. Even then it may not buy you what you want. So, sometimes I’ve just like gone into an organization and be like, we need to do this and gotten burnt the fuck out from nobody listening to me. But I also, I did not change my messaging to try and fit what was going on. And sometimes it actually like I’ve been like, “Okay. I will earn X amount of social credit by doing these things. And then I will try and spend it and see what happens. Then I will go back to doing that and I will try to spend it again.” It does help me build up also some reserves for what I do try and do that spending step.

Crystal Martin: Yes. I have no comment because I 100% agree. Yeah, but that’s basically what the end of last year was for me was like the fight, fight, fight, fight, fight. And then you just realize you’re like swinging and there’s nobody in the ring anymore. You’re just flailing your arms and you’re just like, wait a minute. Okay. I think. All right. I’m going to just take my gloves off and go over here and code and see what happens.

Jenn Creighton: Yeah. Sometimes you have to like reserve the energy. It can be very hard. At a time when the world is going through a lot of chaos, people are actually starting to say things that you are like, “Yes, I’ve been saying this my entire life.” And it makes you want to be like, “I said it so many times. Why didn’t you listen?” Still, the response is going to be maybe disappointing. When you’re talking about also these corporations like not getting it right and this idea of perfectionism being, you know, it really is this white supremacy idea of white being perfect, things being perfect, not being muddied, we get things correct the first time. Where do you also maybe draw the line between, we’re not going to get it right the first time, and also using that as an excuse to not really do the work?

Crystal Martin: I mean, I’ve definitely seen that happen. And I think what I started trying to like reach for was -- I feel like when that started happening, it felt like it was just bullshit, basically, I think that what I started trying to do is actually get at the heart of the organization and like, the leaders themselves, like where are your head’s at? And I talked to one of the leaders in my organization that I feel like I have a lot of trust with. And I just went to him and I was like, “You know, I really like breakups. And you know why I like breakups? Because you know exactly where you stand with somebody.” Like I love breaking up with people. I love to go and be like this is not working for these reasons, and we have a clean break. You know why, I know why, and there’s no hard feelings. I mean, yeah, it’ll be hard, it’ll be painful, but we both know where you stand.

And so I was, like, “I say all this to say, I kind of just want you to tell me, like, for real, for real, where do we stand on this stuff? And where do you stand and where do you think the organization stands? Because then I feel like then I can disassociate. Like, I can break up. I can break up in a way that makes sense because now I know that I don’t need to be like fighting anymore for this relationship. I don’t need to be fighting anymore for what this is if I’m just like spinning my wheels.” And like, that was kind of like, what I did. And it was just like, where do we actually stand? And I think what I began to see is that people actually just didn’t know what to do. They did not know what to do. And they were scrambling and getting advice from diversity consultants and things like that, just trying to get it right. And I also think that our organizations kind of did think they were going to get it, right, by doing all this stuff, they’re going to be able to be like, “See, look, what we did. We donated it to this and did that.”

But what I was trying to -- [crosstalk] It didn’t work, it didn’t work. And I’m just like, I feel like I broke down from a human perspective of like, when I tried to get [inaudible 00:31:17] my leaders were just like, “If you don’t think this is your problem, then we’re not going to get anywhere. If you don’t feel like injustice and the mistreatment of black people is your personal problem as another human and human community that lives around black people in the same country that you have friendships with, and you work with, if you don’t feel dread in your heart, because this thing is going to impact your life as well. If you cannot see the connection of that and if we’re not having those kinds of conversations at these levels where we make a lot of decisions about how we’re going to interest this, then we’ve already lost. We’re done. We’re done for. If you cannot articulate to yourself, why this is, like terrifying. And why this is bad, not only for black people, but for you and your human community, we are not going to get anywhere.

And so I think that’s kind of like, what I kind of want to see more of what success looks like for me or what movement looked like for me is not like policies or like us getting MLK day off, which we don’t. That’s not what I was really looking for. I didn't really care. I didn’t care about us donating to causes, to be honest, like I did -- Well, I did appreciate when there was a local focus. We were like, okay, no, we’re going to give to things. We’re going to like talk to consultants here in the city to understand where should we be given our time and money, so that it’s rooted in our community, like that stuff was good to me.

But what I wanted to see is leaders at my company and other companies articulating how they were thinking and where they were stuck and what they didn’t understand and what they were trying to understand and what they did think they understood, that’s what change looks like, for me. That’s what useful change looks like. So, that’s like, to me, like a parameter of change for me is like, how often are we talking about these issues out in the open with not just like a plastered on smile and being like, look at all the things we’re doing. But, the time that -- like, seeing people in leadership take the time to think about what needed to happen, or not just organizationally, but within their own hearts.

Jenn Creighton: It’s so interesting, that we started this conversation having like, admitting that you don’t know everything. And we were just talking about JavaScript, right? Just JavaScript, like, not going to save the world with that, right? But, we’ve kind of pulled this thread all through this conversation of like, admitting that you don’t know something, and what that can get you when you say it out loud, admitting that you weren’t sure what you were doing. Look what that can get you? We do, we put a lot of emphasis on getting things right in tech, in general, it’s very pervasive, right? We do not really, I think, talk enough about technically or personally, or in a bigger humanitarian way the value of incremental progress, seeing how something worked out and trying again. Or knowing that, like, the old way of doing things just isn’t going to keep working forever. You have to go back and take another look, you cannot say, but we always did it this way. That doesn’t work in tech, and it doesn’t work in our world. Like it just doesn’t work. But yeah, we’ve really pulled through this narrative to of like the ability to say, I don’t know, I don’t have the answer. Can I get some help?

Crystal Martin: Yeah. And everybody needs to do that. Yeah, at every level. And it’s such a hard thing. And I think you’ve probably experienced this, as a woman is just -- it feels like giving up sometimes. It feels like giving up. Because I don’t know how you got socialized, but I got socialized at, like, I had to be the best. And I had to kind of come [inaudible 00:35:24] and basically, like you, as a woman, a black woman, you get the message, like, basically act like a man. Like act like a man so you can get what you need and so you don’t get hurt. I think that’s a big part of it, it’s a protective thing. It’s a safety thing, first and foremost, which I think is why we get socialized that way, especially when we go into environments that are full of white men. It’s hard to like -- it’s like in your heart of hearts, you extend this grace to other people and you know that’s what everyone needs to be able to thrive and not just survive something and to be, so feeling that you’re a part of something, that you belong. But at the same time, I feel like I just imposed this thing on me, but like everybody else can do that. But not me. Like I gotta be -- Like, I don’t need nobody.

Jenn Creighton: Oh, it’s so easy to be graceful with other people in that way and so difficult to do it for yourself. So, that when you do fuck up, or you do need to say, I don’t know, oh, it makes it so hard.

Crystal Martin: So, hard. And I realized that like working with my coach that one of my like beliefs about myself, and basically, the foundation of what I thought of who I am, was that my value as a person in the world is only so far as how much I can provide for other people. And if I cannot provide monetarily or support or emotionally, then I don’t have any value.

Jenn Creighton: Yeah, just what about your value as a human, as a person?

Crystal Martin: Because I’m here, and I’m on earth with other humans. Yeah. And I have been working on this for almost two years. And I still dip back into that. I still just, I mean, literally last week, I was like, my value to this team is that I could finish work fast, and I don’t need help. Even if that’s going to hold my team back and make work late because I fucking did it wrong the first time and I didn’t have to because it wasn’t a matter of my skill. So, that’s the thing, me getting that wrong was not a reflection of my development skills.

Jenn Creighton: No, it wasn’t.

Crystal Martin: It was not. I did the right thing in the wrong place. It wasn’t like it was broken. It was working, tests were passing for the wrong thing. You know? Where I failed was communicating, where I failed was asking for help, where I failed was leaning on my teammates who said that they would help me. Like, that’s where I failed. That’s bad developer behavior, right?

Jenn Creighton: You’re also bringing up this point of like, as we just said, doesn’t have to be perfect. We got to iterate on things. That also means you gotta know where you need to iterate. You have to be able to identify and you were like, it actually wasn’t my developer skills that needed work. It was my communication that needed work this time. So important to like, look at what happened and be like, “Oh, actually, that was the problem. I see.” [crosstalk] [inaudible 00:38:32] sorry about that. Oops. Sorry. Yeah. And I struggle with this idea that if I have a setback that that means all the progress I made meant nothing.

Crystal Martin: Yes. Are we the same person? ‘Cause I definitely have that. Do you know, like, there’s that meme with the girl who’s trying to kombucha she makes the face like, “Oh, this is good. Oh, no, this is good.” I feel like that’s been my year of just being like, “You’re great. [inaudible 00:39:01] There you are. I’m actually good.” That’s just been the entire year. And I honestly had to be like, I had to make myself laugh when I realized I made that mistake. I had to be like -- ‘cause it was pretty funny. Right? It was funny.

Jenn Creighton: Yeah. If someone else had done it, you would not have thought -- [crosstalk]

Crystal Martin: No, I would have laughed. I would have been like, “Yo, this is beautiful. It’s just in the wrong place. You did everything right.” And that’s what my colleague said. She was like, “You didn’t get it wrong. You just did it in the wrong place. Like everything is right, it’s just wrong.” Because I was like, “I fucked this PR up.” She’s like, “No, you didn’t fuck it up. You didn’t fuck it up. You just put it in the wrong place.” And that was good to hear. And I was able to -- and I literally started dipping into that like, “Oh, fuck. Like, you’re never going to be able to -- like this is so stupid. How could you like…” And it’s like I just had to -- This is actually just legitimately funny and like, it is more effective for you to laugh about this and get to work than be dejected and like, feel like you’re going to have to say to your client that you did this thing wrong. You should have done it right. It’s like, everybody’s fucking up, right, because that’s what happens when you work at enterprise software. There are so many different changes happening. You could do something flawlessly, and then realize that no one wants it and you got to do something again, do all this stuff. Actually, roll it all back because we don’t want it. You’re like, wait a minute. So, we’re all just learning and figuring it out. So, why do I think that I’d have any expectations that are different on me than anyone else, but it’s just so hard to [inaudible 00:40:38] that.

Jenn Creighton: It truly is difficult to extend to yourself, the grace and humor that you would extend to someone else. It’s really hard.

Crystal Martin: It’s really hard.

Jenn Creighton: You just, you hold yourself to such a different standard, and other people you’re like, that was funny, “Oh, you’re fine. It’s totally fine, whatever. You know, like the number of times that I’ve been convinced that there was a bug, and it was just a misspelling, you know? And it just, I honestly just need someone else to look at it for five seconds and be like, “Hey, this word is not the same as the other words.” “Oh, fuck.”

Crystal Martin: And I think when you don’t do it, you actually block yourself more, right? You become caught, and emotionally hijacked, and you can’t be effective. And then you’re upset because you can’t be effective. It’s like a vicious cycle of nonsense.

Jenn Creighton: Emotionally hijacked, that’s a very good description of what it is. Because you’re not going to make any progress.

Crystal Martin: You’re not. And actually, I think it’s what’s fascinating about this is like, it’s an actual neurological thing, right? Like you actually are hijacked because you can’t access your higher self. Like your prefrontal cortex is there for executive functioning is offline. And you are totally dealing from like, your fear center, your like, reptile brain is like, “There’s a tiger coming.” And it’s like, you just have to do a story. Your story is not a tiger.

Jenn Creighton: There is no tiger.

Crystal Martin: Your prefrontal cortex is just sitting there waiting like, “Dog, there is no tiger, can you please just do this story again?” And your reptile brain is just like, “Oh, no. Like, I’m gonna die. Do you see the teeth on that story?” And your prefrontal cortex is like, “Listen, I’ll be here for you when you want to come, but I don’t have time for this shit so I’m just gonna sit here.”

Jenn Creighton: How do you get your prefrontal cortex back?

Crystal Martin: I think mindfulness and taking a break and saying to yourself, like, okay, I messed up. It’s okay. People mess up. I’m going to go get a puff pastry. That’s been my way of coping lately. I’m going to go for a walk, I’m going to take a three-minute breather on insight time or whatever, and come back to the tasks with self-compassion. I think that’s something that I’ve been reading. I’ve been reading this book and a lot of [inaudible 00:43:02] talk about is I may be saying it wrong, a Sanskrit word Maitri. And basically, what it means is unconditional friendliness. And I’ve been thinking about that a lot of just like, extending unconditional friendliness to other people, but also to yourself. And I think that’s why if you don’t take yourself so seriously, and you can’t just laugh, and also you know how you hear people say, if you laugh, even if you don’t think it’s funny, it still raises your frequency and gets you out of that space.

And so I think that’s kind of what I have to do. I have to just, like, laugh myself into being like, yeah, but like, it’s actually not that serious. And that’s kind of how you check back in. I think it’s different for different people. But taking a moment, taking a beat, and breathing, honestly. And maybe just saying it, like writing it or saying it out loud to someone else, to your rubber ducky on your desk, and then getting on with your life. And then whenever that voice kind of comes back just being like, that happened. It’s already in the past. It’s done. I’m now moving forward. And it’s hard. It’s a mental exercise. And I feel like last week, part of the reason I was so tired was because of this, like trying to rewire this like negative self-talk and this, you know, self-deprecating sort of attitude towards myself and my skills that it’s like a mental exercise of just being like, “Okay. Feel the feelings, right? Feel the feelings all the way through, but then you gotta like, take a break, breathe and let it go.

Jenn Creighton: I do want to emphasize that feel your feelings part. Because I do think a lot of people just go, “Nope,” and try and put a little wall up. But all you’re doing is like the feelings are still really happening. They’re leaking out into things that you’re doing and you’re just not aware of them anymore and it can have really terrible repercussions for the people around you.

Crystal Martin: Absolutely. And your own body.

Jenn Creighton: Oh, yeah. Oh, the stress that collects in your body. Like my shoulders have not released I think in a couple of weeks now.

Crystal Martin: Yes.

Jenn Creighton: I want them to stop, but they’re all up in my ears. I’m like stop. [crosstalk]. It’s okay. We’re going to be okay. Honestly, I don’t even know, my struggle lately has been knowing when I’m stressed. And my partner is very sweet. He knows when I’m stressed. And he was like, “Hey, you seem stressed.” I go, “No, no, no, I don’t think I’m stressed. I just feel like a tight, tight ball.”

Crystal Martin: Also known as?

Jenn Creighton: “What do you think stress is?” I was like, “Oh, okay.” Okay. So, as we wind down any final thoughts, you want to leave people with? Anything you want to share about what you’re doing right now or where they can follow you?

Crystal Martin: Yeah. I felt that was kind of wrap-up like it’s hard right now. Don’t be so hard on yourself. Try to extend that unconditional friendliness to yourself. You are your own best friend at the end of the day. As far as things that I’m doing, I don’t know. I’ve been really tinkering a lot, which I think has been kind of like raising my vibrations to like just play and dabble in different things. And I want to encourage other people to do that. Like, try things you haven’t done before and haven’t done in a long time and see how you feel doing that. It really has been super helpful for me to connect to my essence, and to who I actually am as a person, and not identify so much of me as a developer. You know? I don’t know. Yeah, just follow me, I guess. I’m on Twitter, if you like cats follow me on Instagram. That’s like a lot of my content. My tinkering in different hobbies and stuff, I’ve been just posting there to try to encourage myself and other people to just play with things.

And I’m actually really interested in what people are doing right now with their time and how they’re tinkering and how they’re doing self-exploration or just like exploration. So, like, if you want to share that with me on any of those platforms. I’m actually truly interested. Like, you have sort of inspired me. I’ve been thinking about doing a podcast around something like that, just to kind of see like, what are people doing and playing with? And like -- you’re never too late. It’s never too late. You’re never too old. You’re not too young. You’re not too short. Like there’s all these kind of things you could be doing to connect with yourself and with the world around you. And I will stop babbling.

Jenn Creighton: I love that idea too. That podcast idea sounds wonderful. Do it. Please. Thank you for coming on. To everyone listening, make sure you follow Crystal on Twitter. Her handle is @CoderMeow. She is a cat mom after all. And I’ll also list some links in the show notes for you to follow. I’ll see you next week.

Single-threaded Podcast: Erin Fox on Interviewing

Jenn Creighton — Sun, 21 Feb 2021 19:57:50 +0000

Jenn: Y'all! It's the first episode. And I couldn't have asked for a better first guest than Erin Fox. Erin is a software engineer at ConvertKit, a frequent conference speaker, and an active member of the react and React Native communities. Today, she joins me to talk about one of the most stressful parts of being a software developer: interviews. we talk about why interviewing in tech is particularly stressful, how to handle rejections and why like dating, you should never commit too early.

[intro music]

Jenn:
I thought it would be fun if we did a what I want to call a Boolean interview, which is where I'm going to ask you a question. and end it with "true or false"? And you're going to tell me your answer if it's true or false. So the first one I have is: technical interviews are the worst, true or false?

Erin:
True. The quickest true, I can get to you.

Jenn:
There was not a remote hesitation, just to say, absolutely. It's miserable.

Erin:
There's so many variations of them as well. And there's some that are less on the true spectrum. But the first one that came to mind when you mentioned that was like parse the string, or what would you do with this data? Do it now in front of me? And that is, yeah, even you're stressed out.

Jenn:
I feel my heart rate start to rise as you even talk about it.

Erin:
Yeah, I think, especially when you're applying for jobs, even one of those is a stress ball. And when you're applying anywhere and everywhere, because you need a job, or you just need to get out of the work situation that you're in, and to just have to do those one repeatedly. It's very soul crushing, because it's not valid of my skills and who I am and how I work on a team. It's, it just makes me feel like worthless, stupid, even though I'm not.

Jenn:
Oh, and we we are going to get in that with some further questions. Absolutely. I do want to hit on a point, though, that you and I both did not come into tech from a computer science background. You and I both worked in other fields before this. And I don't know if people who came in with a computer science background have ever interviewed in a different type of situation, a different world. But we have. Tell me tell me how different the interviews are from your previous experiences to now when you have to do a developer interview a technical interview.

Erin:
So my work history before switching careers to be a software engineer was primarily social media and paid distribution campaigns online. So I would a B test different headlines and a B test different pictures to see which one was more clickable. It's like, you know, those really annoying ads at the bottom of an article that nobody clicks on that was new to me. So maybe you clicked on but so yeah, I remember for that job, I had to come up with by read article and wrote 10 headlines and found a couple of splash images that I would use, and I got the job. And it was more of I want to say real world. It's exactly what I did. After that, and it was the interview was just a conversation of like, my history, like my writing philosophy or my social media philosophy, and it was more of a conversation of me and how I work. And then if you were to flip it and do it for a software engineer, it's it's almost like, like, it makes me actually have this weird vision of like you like pull out your brain. And just like set it aside, and like, that's all they want. Like, they just want to know if you can solve this algorithm. They don't want to know everything else about me like they don't want to know how I work or what my goals are. That was kind of a tangent.

Jenn:
No, that's, that's what we want to hear. Because they are, they're very different. And what you just said about you just take your brain out, and they just want to see that, they don't care anything about your personality. Which leads me to my second Boolean question, you can accurately determine a developer skill level in an interview, true or false?

Erin:
False.

Jenn:
False. I agree.

Erin:
So I just - the pressure is real. Like, when I'm a - what is it fight or flight? I'm a flier. I fly far and quick. Like I'm not a fighter.

Jenn:
It's fight, flight, or freeze. Oh, yes. I know, there's a third one that I think explains a lot of what happens in technical interviews for me, which is that my mind goes blank. Do you have that experience?

Erin:
Absolutely. Yeah. You freeze, you forget your name, you just like, don't know what a string is. It's just it happens. And some people are so great under pressure like that. But a majority of people aren't, and I'm one of them. So absolutely false on that one.

Jenn:
I also am not good. being watched. I'm not good in that sort of like unnatural pressure setting. I'm not good without access to Google. I'm just not like, I will forget things. And I need to remember how they work. Because our field, you could never remember all of it in your head. But interviews kind of act as if you're supposed to. I do remember one time sort of bringing this up to some other engineers, who were at the time they were interviewing at Fang jobs, which are like really difficult interviews, and not indicative of who you are your skill set as a person. And I brought up that I wasn't a very fast, like coder in that way that like it takes me a little bit longer to gather my information, and then write something out and then decide if I like it or not. And their response to me was that, then I was I was worth less. Actually, it was they were like, well, they need you to be able to perform under pressure.

Erin:
It's tricky, because people will want to work at at those places. But in reality, you just have to, I don't know, my philosophy with that is your first step of knowing about the company is their interview process, because hiring should be the most important thing any company does? And if that's what they're putting off, and then there's the challenges that they're doing, then they're going to attract those kind of people. And if you're not that type of person, it's not a good match. Yeah,

Jenn:
that is a very good point. I also from my own experience, I've been in this field, eight-ish years. And I have never had to work with an algorithm under a high pressure, pressure like situation.

Erin:
Yeah, like put a flashlight on you. But like solve this now.

Jenn:
Lives depend on it.

Erin:
Yeah, it's like move this pixel three times now.

Jenn:
Tell me the O notation of this. The big O, come on. Yeah. If you don't tell me the correct one, children will die.

Erin:
Oh, my gosh, yeah. And another thing I was going to mention is, I haven't worked for a company where it was like a life or death situation, if you couldn't figure something out, like, worked at Major League Soccer, worked at The Wing, and I'm now at ConvertKit. It's like, I'm not writing code to save lives.

Jenn:
It's not like you are not in writing the code to someone's pacemaker.

Erin:
Exactly. Yeah.

Jenn:
And if prod went down, like, well, one, we probably didn't have anything to do with it. Because it was it was more likely, like something happened on the back end. But if it was a front end issue, roll it back, man. It's not that hard. It wasn't rocket science. Just roll it back. We were - it was fine. Yeah, exactly. I don't I don't agree with the high pressure situation of interviews. I think you're, I think you're just testing for the wrong things. If you're if you're relying on that. Completely.

Erin:
Thinking about it stresses me out because

Jenn:
This might be a stressful conversation. And I'm very sorry.

Erin:

Yeah, it's starting to get there. You're just bringing back all the memories. You're feeling it all come up again, and you're like,

Jenn:
Oh, no, we're reliving all the bad experiences. Don't worry. I think we'll get to also maybe a cathartic place later on this conversation, something where we feel like a release of the stress Also, neither of us have to deal with this right now. Thankfully, we're gainfully employed.

Erin:
Very fortunate. But isn't it so sad? That even talk about it you get stressed out about it?

Jenn:
Yes. Like, you are correct. That is sad. That is so sad because other people in other industries do not get this stressed about like, interviews are always a stressful situation, I don't think they have the type of responses that we do to them. And also, like, what you said earlier about, like, they don't really care about your personality, or who you are. If you can go into an interview and just be yourself, it relaxes you.

Erin:
Absolutely, yeah, I think. Yeah, and if you if you do feel relaxed, and have that connection with the people that you're interviewing with, then it's like, a member of this company. And now I want to, like you, like, move them over on my air table to possible

Jenn:
An Airtable - So that's what you use for tracking?

Erin:
Oh, my gosh, I, I have a souped up air table, I can't share. Because there's ratings on companies like five star, one through five star I know it gets into Wow. But I was just interviewing with so many people I needed to keep track of who was who from what company, their name, like their Twitter, sometimes the job posting will go down and I didn't have the link or the text to it. And I they would contact me and be like, we want you to plot our we'd love to talk to you. And I'd be like, shoot, what? Who are you? So yeah, air table, I think, yeah, they helped me manage the stress level of my interview.

Jenn:
It can also be stressful in terms of this is a this is actually a good problem to have. But there are many opportunities. There's there's no lack of opportunities, I do think it's harder. Obviously, if you are new to engineering, and you're just getting your first role, that's a different experience, obviously. But once you've been in the field for a little bit, once you're open to a new company, you tend to get a lot of responses, that doesn't mean that they all work out or that they're all a good fit, or that they're even really looking for a person of your skill set. But you get a lot of opportunities thrown your way that you have to like, figure out where you actually want to interview.

Erin:
Yeah, absolutely. And you also need to think about what direction you want your career to go in. Like, if you are bored of on the front end, don't take another front end role, or piggyback enroll and see if you actually like it. I think having somewhat of a little bit of a future plan, I'm not the type of been like what's your five year plan, but have some kind of an idea of what you want to learn. And I think a lot of people that are companies that I've interviewed for are also looking for that as well of getting your aspirations and match up with what they need. And what's like a big key thing that I learned.

Jenn:
Absolutely, they're they're looking for, if you're going to fit into where they're going as a company tech wise to. I also think that five year plans for tech is just a will for front end, in particular, a five year plan is just come on, what we don't know, we don't know what's gonna be happening in five years, this whole thing could go under we don't know,

Erin:
My goal? In five years have five more years of experience.

Jenn:
In five years, I will just I will have been a developer for five years. I don't know what you want me to say. Okay. Another question. take home coding assignments are better than in person coding challenges, true or false?

Erin:
You mean, like, you go and chat with someone, I guess now. But or you would go into the office and do it? Yeah,

Jenn:
Yeah. Anytime that you're doing like an in person, just coding. You're coding someone's watching you code or your pair programming together, or whatever it is.

Erin:
Yeah, no. I mean, unless you're going into a workplace where you are pairing with someone, every single minute that you're working, then maybe you have to do that kind of interview. But more than half, I wouldn't say like 80% of the day that I'm coding. It's just like me and my laptop like searching Google in copy and pasting. I mean, learning on your own is, it's like that's, like the description of a developer. I think it also, if there's no time limit, which is another story, but if there's no timeline on that takeover, it's usually you can do it at all. Like the right pace for you. So if it's like, if I'm using if I need to hit the Twitter API, like, let me get an hour to read it and understand it, where it's like, someone's watching me read the Twitter API for an hour. I'm not comprehending anything. Like,

Jenn:
I'm just watching you trying to figure out the Twitter API that sounds like a horror movie to me.

Erin:
Yeah.

Jenn:
it's a public API, figure it out in front of me.

Erin:
Hmm, it's just an added layer of pressure. And then you also have to like, talk, your thought process? And it's like, I haven't even done the thinking yet. Like, how can I tell you what I'm thinking before I even think it and it's like, yeah, so take homes are gold for me. Usually, they don't have it, I asked for it. And if they don't have it, then I move on. Because I know I don't thrive or want to be in a place where people don't respect the way that I learn and the way that I like flourish in my code. And so definitely take all this are, for me.

Jenn:
Those are all such great points. One that the take home resembles the real work way more. And then to that you could ask for a take home. I think not enough people know that you can, you can do that you can ask for a take home, I certainly have interviewed at jobs where later I found out that other candidates got a take home just because they asked. And I just assumed that was the process. And like, I didn't realize I could ask for like a quote unquote, exception. And it's not really an exception. A lot of more companies are doing a thing where you can choose between the two to accommodate like what you want to do. I will say the only thing I don't like about take Homes is the time like either they put a time limit on you, which by the way is always bullshit. Ignore the time limit. Always ignore it. They are lying. "This should only take two hours." False. That is a false statement. No.

Erin:
Yeah. Or it's like, take up to four hours on this. And then when you're writing in the description, yeah, I spent about four and a half hours in reality. I was like, I spent 12 hours on this, I didn't sleep.

Jenn:
Yeah, totally four. Definitely. I definitely did four. Don't pay attention to when these commits were done. Yeah, it was four of them. [exhales] Sorry, I'm, I'm reliving so much pain as we talk. Where like, I, I did what they asked, I only spent X amount of time and then I would get rejected. Because they were like, oh, it wasn't fully X. Well, yes. There's only so much I can do with four hours of my day. Most people at their jobs, I don't even I think four hours is probably like max actual coding that I would do in a day before I get burned out. I do I wish there was a service where I could do one take home and submit it to multiple companies, though. Because every company wants to give you their own unique take home that will only take you four hours. Lies. You know, at the end, like how many of those can you reasonably do if you're also working full time? Especially if you do 12 hours? And also do you...do you tell them it was fun, even if it wasn't?

Erin:
Probably, I think "it was a good fun challenge". Or, you know,

Jenn:
I feel like you have to say something like that. You're like, "this was fun. I didn't mind doing it."

Erin:
"I really enjoyed it." Yeah, I mean, that is true. I probably do that a lot. It's just like a little bit of butter.

Jenn:

What a great challenge. I really enjoyed spending my evening and weekend doing this, instead of all the other things I could be doing. I had fun.

Erin:
Feel free to add it to your codebase already, it's all done for free. Here you are 12 hours of labor.

Jenn:
We should be paid for tech homes, you should definitely get paid for take homes, they take up a lot of your time they take up your weekends and your evenings. Sometimes I will pick an in person coding challenge if I really like the company, but I have too many take homes on my plate or I'm burnt out from it. And I just kind of cross my fingers and hope it goes well.

Erin:
Yeah, and sometimes it's great practice. Yeah, I know when to fail. This will like why not like let's try out and at least I'm learning to get better at this. So

Jenn:
One one thing that I almost always tell people, which is that I plan to do some interviews that are just practice interviews. They're companies that you're not really sure About It could change if you went in there and you did well, and you really liked the people. Certainly Don't. Don't do it with anyone that you're absolutely not interested in. You need to have some bit of a drive to do it. But it absolutely helps with later interviews.

Erin:
I'd also add, but don't do your favorite company first. Do like two or three. Okay-ish ones, and then do your favorite.

Jenn:
Never do your favorite company first. It is never, it's not gonna go well, and never does. You're rusty, it doesn't matter how much you've been cracking that code interview, you know, cracking that code. It's not gonna go well, please don't do that. If you really love a company, you just wait till the end for them.

Erin:
Yeah. And if they want you, they'll wait too like any good relationship.

Jenn:
It's true. It's a relationship I have called interviewing, like a dating scenario before. But it's like your date, pulls up a whiteboard, and says, could you solve this algorithm for me while we're at dinner, and then maybe, you know, we'll be together. It's a bit of a it's a weird dating thing. But it is like dating. It is.

Erin:
And I'll even add to the dating metaphor is I always do interviews on Thursdays or Fridays. Because one, people just feel better on Thursdays and Fridays. So if they're interviewing me, they're not as like, Oh my god, it's Monday or Oh, my gosh, it's only Tuesday, though. Like, it's Friday. Like, I'm feeling good. So like, maybe I'll write a little bit nicer thing for this interviewer.

Jenn:
Oh, what a hack. What a hack we're learning here. Do it on a date night.

Erin:

Yeah, it's a date. So might as well make it a Thursday or Friday.

Jenn:
And then you go into the weekend with all of your interviews. And people are probably like, a little bit more relaxed, because they also like they're probably about to go out with friends or something that evening.

Erin:
Yeah. Or on an actual date. Yeah.

Jenn:
So they've got maybe good vibes coming. This is. That's fantastic. I had never thought about not scheduling on like a Monday because people are just sad.

Erin:
Yeah. Right. Everyone's sad on Mondays.

Jenn:
Particularly now. Particularly now people get real sad on Mondays and I love my job, but still some Mondays.

Erin:
So particularly now. No Monday interviews.

Jenn:
Okay, you heard it from Erin. No Monday interviews. Don't do that. You're setting yourself up already at a disadvantage.

Erin:

Yeah. Just try doing Thursday, Friday.

Jenn:
Okay, another question. And a really important one: being rejected for a role means you are less valuable as a developer, true or false?

Erin:
Oh, yeah, no.

Jenn:
A company saying no to you really has nothing to do with your actual worth as a person or a developer.

Erin:
Absolutely. It feels like it 1,000%.

Jenn:
Oh, it feels like it. Absolutely.

Erin:
It's like dating, you get dumped. The company broke up with you. It's like, we're no longer in contact. Like, I'm going to keep your number. But we're never going to call you like I'm gonna keep your resume.

Jenn:
Oh, yeah. They always say that, don't they?

Erin:
Yeah. But then it's like, and then you start to reflect on yourself of like, I'm not I guess I'm not that smart. I guess. I'm not a good engineer, when it's just one company. That wasn't a good fit. But that's the heart I think, essentially, this is like, the hardest part about interviewing is a rejection. Because it is soul crushing. Especially if you like hype up, you're like, "Oh, this would be my commute. This is like where I would eat for lunch." You know, like when you get that far in?

Jenn:
Going back to the dating metaphor. You meet someone, there's a spark. There's a spark and you're feeling like this could be it for you. And then they don't like you. What did you do wrong? Did you have something in your teeth? We don't know. Because often you don't know what you did wrong.

Erin:
Yeah, you asked for feedback and they like are ghosting you.

Jenn:
Ghosting is really hard from companies and very bad, very bad manners.

Erin:
Especially if you want to learn and grow and be better or if you really want to apply for the company, again, actually, the past two companies I've worked for I applied to twice. That's right. First time I I got rejected. But I still, at the time, respected the companies and wanted to work and knew like what they were doing, but it still hurts.

Jenn:
And sometimes it's it's actually for a good reason. I remember so you interviewed at the wing before I was there. And the only reason that they said no to you was because they needed someone really, really senior to come in and they had they just had no one Senior and that's what they needed. And that's fair. I've definitely been rejected from companies because I wasn't quite at the level that they needed. It felt shitty, but it was fair.

Erin:
Yeah. But then if you take a step back and think about it, if I were to get hired there, oh, you would have had no support Exactly. Like, there was no one above me to ask questions to like, I have to like, figure, figure it out when I was just two years out of a boot camp. Wouldn't you take a step back and think of it that way of like my life? Like, thank goodness, my life wasn't miserable. Like, at least someone knew that this wasn't good timing.

Jenn:
Yeah, sometimes when you get rejected, it's actually someone looking out for you. Which is a strange sort of feeling. It's hard to also think that way when you get rejected because you just assumed that you did something wrong. But it could just be not a good fit. Not right now. This person knows that you need something else at the time.

Erin:
Absolutely.

Jenn:
Oh, do you have like a vent buddy? Or like a hype person?

Erin:
Oh, I have a playlist.

Jenn:
Oh, you have a playlist?

Erin:
Yes.

Jenn:
Tell me more. Tell me more.

Erin:
One time I just tweeted out on Twitter. I was like, I need some like, before interview like pump up beats like, I've just I've been doing like so many interviews lately. I just need to be happy. And like, people sent me like, incredible. And I'll share it with you incredible pump up beats.

Jenn:
Yes, send it I will put it in the show notes.

Erin:

Oh, it's like, the "Eye of the Tiger" is like one of them. There's, it's great. Like, there's a lot of Britney Spears. I mean, it's pumps you up so that I don't really like chat with a person.

Jenn:

How do you handle when you're not feeling so great, like when you don't need to get hyped up. But you just need to be less sad about like a rejection or an interview didn't really go very well, oh God, or you're waiting, you're waiting for the response.

Erin:
Other than, like, constantly checking your email. I think, for me, what really helped, at least the second time was the way I prioritize my day when I was applying for jobs. So this is what I got laid off from the wing, and had an abundance of time at home because COVID and I needed a job. So I really, for me, what works really well is time blocking. So I would say from like eight to noon every day I would apply for jobs, do interviews, because I'm a morning person and I there's like a form of that time. And I talk really all the time. And so for those four or five hours, I would just do that. And then on the second block of my day, I would do like really fun things to me, and things that I'm good at. So I think I'm really good at baking and cooking food. So on the second half of the day, that's how I would cope with like, I had a really crappy interview in the morning, I'm going to do something that I know that works and that I know that satisfying, like kind of fills that I'm worthless gap in you.

Jenn:
Oh my god, I love this.

Erin:
For me, it works really well.

Jenn:
You're You're This is you're describing a thing that I try to get people to understand, which is that when you're going through a rejection or something that went bad, you do have feelings of worthlessness, and you have to then go do something that will fill like you said that gap. If you feel worthless, you have to go do something that will make you feel worthy. Again, that's what you're doing. That's amazing. You got to accomplish something like whether it's a workout or like I got so obsessed with sewing, like I would just sell masks. And I'd be like, I'm gonna sell 20 mess right now. I do remember you on Twitter sewing a lot, which is one of my hobbies, too, and also how I gain back some of my like, No, I'm actually like a creative person that can build things.

Erin:
Yeah, I mean, you kind of just have to go back to your roots or like, make some new root stuff. Like, what? for you as a person, like, genuinely makes you happy. And like makes you feel like you're good at something and you're just doing a completed thing. This is so emotionally healthy.

Jenn:
I want you to know, you figured out like a very emotionally healthy way to deal with this in a way that I think a lot of us could really benefit from.

Erin:
It does come from a lot of dark places. So it took me a while to figure out like, Oh, this banana bread, this perfect loaf of banana bread. makes me so happy. Like,

Jenn:
Oh, now you're making me hungry. Can you can you mail me some banana bread? Thank you.

Erin:
Yes. Well, I have variations of what kinds you would like because I've had a lot of time. But anyways, yeah, it takes a while to figure out one, like what does complete you and makes you feel like you're worth it and worth something. But it also, you have to realize, like when it's like I need, like, snap out of it like this is like you mentioned like, this is not me. I need to like, bake some cookies. I need to sell a mask, I need to make a wood project. I don't know.

Jenn:
Did you already have this emotionally healthy coping mechanism when the layoffs happened at The Wing? I wasn't at The Wing when the layoffs happened. But I hadn't. It hadn't been very long since I left the company. I got a message that they were happening. You were unfortunately one of the people caught up in that. Let's talk a little bit because I think especially right now, during this a lot more people have been getting laid off and dealing with the feelings that come with that.

Erin:
Yeah, it's definitely heartbreaking. I think my dark "no job" period though, was between MLS and The Wing. I also moved across the country. So I moved from New York to California. And just everything was new. New city. So like looking for a job. I just - I feel like I went about it the all the wrong. All the wrong things here. So let me just list them off for you. I got too attached. So I found one company loved them. I was like, Oh my gosh, like this is my commute. Go hop on BART.

Jenn:
You had that spark.

Erin:
I had the spark. And then the spark dies with one little email. And I would do that. But when I was applying I would - what is it? I don't know. It's not serial dating. What is it when you date more than one person at a time?

Jenn:
Uh, dating?

Erin:
Normal dating?

Jenn:
You don't commit right away.

Erin:
Okay, well, I am a committer. I would commit to my first person and then stick with that person and not date anyone else. So that was my mistake is that I needed to keep dating around. I needed to keep applying to other companies and not get attached to the first one that like popped in my inbox. Keep your options open.

Jenn:
There are more there are more fish in the sea as they say.

Erin:
Absolutely. And I hate the same but I'm going to say it anyways is "gotta keep the ball rolling."

Jenn:
Oh, God.

Erin:
I know right? Old woman. But it's true. Like, you gotta you just gotta you gotta keep moving. Like, I think the first three months of looking for a job I like I wasn't dating around. And I needed to keep doing that. And so it was just a lot of like a huge roller coaster like yes, this is it. And then I crash if it didn't work out. And so fast forward to got a job with The Wing. I knew I was on the chopping block for the layoffs, because I was the only remote engineer on the west coast.

Jenn:
You were also one of the newer hires, and they tend to be unfortunately, part of layoffs.

Erin:
Absolutely. So it was just easy. I was easy. You know, like, she's, she's one of the 50% that were were laid off.

Jenn:
Yeah, it was a big big layoff.

Erin:
It was I like remember getting the phone call. And I was like, when I first got that I saw like the strange number. I was like, this is it. This is it. And I like remember, like pacing around the room. And I'd like answer and I didn't cry. And I was like very professional. But then after it's just like the rejection, it feels like a rejection. But it was just so much going on at that time. So getting laid off. And it's been held it was nobody really knew what to do and what was going on. And a ton of layoffs were happening. And so I remember for a few days, I was just like, sad. But also, like ready, like, because the last time I had like my air table, I had my rating system. I have great outlet on Twitter, where I can utilize and increase my network. And so since I already had everything kind of like geared up from the past, this time, it was like, let's do this dating around and applying to a lot of places. So it just gets better with those gaps in between for me. I just like learn from past era and like, nope, don't not just one kick go into a couple more and was able to get a job within I think four weeks.

Jenn:
Oh wow.

Erin:
Really great. Yeah.

Jenn:
And you got to I believe you picked up with a company that you were interviewing with them somewhat around the time that you were also interviewing at The Wing. But the processes like just didn't line up. So you came back to them, right?

Erin:
Yeah, I interviewed at ConvertKit I think it was before. And then I think they just ended up being somewhat more experienced on a different team. They were super great. I really liked them. So I kept them on my like, little spreadsheet and like, brought them over to my new one, and then saw that they were hiring again and applied and just worked out swimmingly, and perfect. it's weird to say that, like, sometimes you work at companies where you think it's great. But then you work for a company that's like...

Jenn:
No shade on The Wing. But yeah, you were like, you were like The Wing is great. And then you got laid off. You're like, oh, sad. Okay, but here's this new job. And you're like, Whoa, why did why was I even with that other company?

Erin:
Yeah, that happens. Here's another thing that I hate out. All these old woman saints are coming out right now. But like, "it's a blessing in disguise". When I got laid off because just like the opportunities I've had now, and for me for right now. It's exactly what I need. And so when you do get laid off, it is terrible, but it works out.

Jenn:
Sometimes it can be ultimately, a better thing for you. It can it can release you from a situation you didn't even know you wanted to be out.

Erin:
Yeah, exactly. "A blessing in disguise."

Jenn:
Oh, how about "one door closes, another one opens"?

Erin:
Yeah, that's good.

Jenn:
We'll just keep keep thinking of these old sayings that nobody uses anymore. A blessing in disguise. Oh, ok. You are interviewing them just as much as they are interviewing you. True or false?

Erin:
That's like a mind switch. You have to get into I think, when you first like when I was first interviewing, like for my first ever engineering job. I didn't know that. I didn't know anything about that. I just would take any job that would get Oh, same. Yeah.

Jenn:
Same. And and by the way, if you are interviewing for your first role, and that's how you feel. And that's what ends up ends up happening. Sometimes you just have to do it. You just have to get the title, the first role, and then you can move on from there. It is really tough.

Erin:
Yeah, absolutely. You got to come prepared. So they come prepared with questions. You better come by here. But there are questions. I have a list that I ask every company that I can share with you as well. And they're just like, killer questions. They're like sneaky questions that you can learn about the company. So like, asking, like, what do you value most in your company? or How would you describe diversity on your team? Like, it makes them feel awkward, like some of these are awkward questions to ask. But if they respond in an awkward way, then it's not a good fit.

Jenn:

In particular, that diversity question.

Erin:

Let me tell you a little story about that one. That's a good one.

Jenn:
Oh, I love stories.

Erin:
So this was just like some. I don't know. I don't even know what they did. small company. I -

Jenn:
Don't even remember, all I remember is how much they fucked up this one answer.

Erin:
So much. So I asked him, I was like, what's the diversity on your team? And are you looking to change? And he goes, What do you mean about when I mean, diversity? I was like, Oh, so like, who you have representing your team? Like I wanted him to define it to see if that is. That is sneaky of you. Yes. I know. It's bad, but good. Oh, it's good.

Jenn:
It's not bad at all. It is just straight up good. What does diversity mean to you?

Erin:
Yeah. Yeah. Watch out. You interview Jenn or I in the future. It's coming. So I asked him and his he was silent for a while. There's just a lot of phone call. And then you said, Well, we have a couple white guys. Standard. The female Oh, V male, female woman, a female, female, and some, some Asians. I was like, in my mind, I was like, Wow. Okay, then then I just like knew, like that was such a huge red flag. They wanted me to go on to the second round. But I said, I found interest in other places. And he actually emailed me back the next day, where he said, I was really struck by the question that you asked, and I went to my CEO and wanted to know what his views and like opinions on it were and he sent me like this huge paragraph back Have what the CEO would have said and things like that. So I think it did help. I hope it helped their interview process, but it helped.

Jenn:
Helped them actually consider that this is a value to some candidates.

Erin:
Yeah. That I think I wrote about that story on one of my blog posts where I have interview red flags that I look for.

Jenn:
you have a fantastic article on red flags that you experienced firsthand from companies. And it's, it's, it's very hard to know what those are, until you have gone through the process and maybe even made a mistake by joining a company that you shouldn't have.

Erin:

I should point out that like everyone has their own definition of what a red flag is. And these are just a list of mine.

Jenn:
That one question about what is the diversity of your team? What does your team look like? I have asked that multiple times over the years, I think it was pretty early on after maybe my first or second job that I started to ask that question you get you get a little bit more like ability to ask those questions when you have more opportunities in, you know, play. And I do remember it narrowing down where I was going to work, because people were unprepared to answer that question, which meant they hadn't thought about it, which meant their team likely wasn't diverse. Or they would say something like, like the female thing. And I was like, no, no thank you. Please don't refer to us like we're a species, the female of the species. Very weird.

Erin:

Yeah.

Jenn:
I also think sometimes it's maybe maybe lost me like roles, which is fine. In the end, you know, if it did, there are certainly people who don't like you asking that question, or making any sort of joke about it. I interviewed at a company for a software engineering position. And they were showing me around the office. And it was it was two white men who were interviewing me. And I think they were it was a really small startup at the time. So they were pretty much the team. And they took me to a room where the marketing team was, and they were like, here's the marketing team, and the room was just full of women. And I made the joke: Oh, this is where you keep the women? I don't think they liked it. I don't think they liked that joke.

Erin:
It's a good joke though.

Jenn:
It's a good joke. But no, I don't think that would have worked out anyway. But I do think that didn't help me.

Erin:
I mean, then it's not a good match. That's just,

Jenn:
especially if you don't like my sense of humor. It is not a good, good match.

Erin:
Yeah, you don't laugh at my jokes. I'm not. No.

Jenn:
I need people to laugh at my jokes. Yeah. Requirement.

Erin:
Required.

Jenn:
Yeah. Okay, so I will, we'll start, we'll start to wind it down. Even though we could talk about this for a very long time. So a lot. I could do multiple shows with just you talking about this. I got more if you want to. I do. And maybe maybe we will schedule like a follow up. Because I do think people are gonna really enjoy hearing about this, especially from your perspective, you have such great advice. I would love to have you on again to talk about this again. Because there's so much we didn't cover. Absolutely. Okay. My last question, or my last Boolean, interview style question is, you should only interview when you're absolutely certain you want to leave your current company, true or false, or false.

Erin:
Unless you work for like local government, you can get laid off at any time. And especially now in these times of COVID. You just need to be prepared. Or even if something happens in all your favorite best people. And while you're at a company, leave the company, and then you're still there. It's just time. And so those moments can happen so quickly, and you need to be prepared. What I do now is anytime something sounds so conceited, but anytime anyone says something good about me at work, or all the accomplishments I do, or I learned something new, I've just throw it in a note. And so eventually, I know I'm going to add that to my resume.

Jenn:
You're like prepping as you go for like, what your resume will look like the next time.

Erin:
Yeah, absolutely. I often have people saying that they do an interview once a month, just to like, keep them on their toes.

Jenn:
Once a month. Sounds like a lot that would that would stress. Yeah, but I agree with the sentiment behind it.

Erin:
Yeah. Again, let's bring it back to dating. It's like if you haven't dated in two years, you don't know what's new. You know, how they do it now like,

Jenn Creighton 44:50

How they do it now. It's changed. We don't do it the same, though. That's true. Because I don't know how dating apps work.

Erin:

Yeah, exactly. Like have you heard of "kitten fishing"? It's when you like, make yourself look younger, I believe, like with their images, like instead of catfishing, it's like kitten fishing.

Jenn:
Oh, I get it. How clever.

Erin:
So it could be like something along metaphorically like that could be in this new software engineering, interview land and you're just getting like blindsided and it could take you a year. And by that time you're like, absolutely hating life in your current position. So I haven't updated my resume since my new position. But I do have a list of things that are like all of a sudden the company ended or something terrible like that. But I think you should always be expecting something.

Jenn:
Always be on your toes, danger at any moment. never feel comfortable. No, that's not what we're saying. You're just saying, Don't think that what you're where you're currently at is just where you're going to be forever. And sometimes sometimes dip your dip your toes in other waters. This is where the metaphor for dating does break down. Because if you were to do this in a long term relationship, and you have not okayed this with your partner, then you're cheating on them. It's not the same thing with companies though. You can you can dip your toes in other waters and check out what's going on, you might find out that you are actually ready to leave your company or you might find out what you have is really good and you want to stay there.

Erin:
I was thinking of a metaphor of like you love this one type of wine. And you just like, like me, there's this one wine called Poppy at Trader Joe's. It's like $12. I love it. I have to like it's stolen. I go there, I buy a bottle. But like, sometimes I want to try something else. So I'll grab a new, a new little, a different kind of wine. And maybe I like it a lot better than Poppy and no longer get Poppy anymore. I'll get this new other one. But I think you have to be open to knowing that like, Poppy can change or the job can change and just be prepared. Keep track of your accomplishments, I think is a big thing that will help.

Jenn:
Yeah, and if something interesting comes your way. Please don't feel like you can't explore it. You You should. When I was actually at the wing. I kind of knew I was gonna leave but I thought I would leave later. And then Apollo came up. Suddenly. I was like, yeah, I'm I'm gonna talk to this company. And I'm so so glad that I did. So happy that I did.

Erin:
Yeah, it's like "a blessing in disguise". Bringing it back to corny sayings.

Jenn:
Full circle to old lady sayings. A blessing in disguise. I think we will - we'll leave it there. Erin, thank you for joining us. So happy we did. We will probably do this again. Thank you.

Erin:
Absolutely. Anytime.

Jenn:
Again, Erin, thank you for being here. This conversation was wonderful. To everyone listening. Make sure you check out the show notes on how to follow Erin and her work. I'll see you next week.

The Antipattern Antipattern

Jenn Creighton — Fri, 17 Jan 2020 14:07:32 +0000

One common antipattern in software engineering is the Antipattern Antipattern:

Thinking that the term "antipattern" means "never use this pattern."

"An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution, but isn't one."
Andrew Koenig, Journal of Object-Oriented Programming, April 1995

Antipatterns are disguised as good solutions. The danger is when the pattern is applied without evaluating the alternatives. Antipatterns become antipatterns when:

The patterns results in unintended and undesired outcomes and another pattern exists that is a repeatable and effective solution.

That means that antipatterns are context-dependent. Antipatterns can be the best solution when other patterns do not exist or are not effective solutions. The context of the problem you want to solve and the system you are working in can change an antipattern into a pattern.

So, what's the fix to the Antipattern Antipattern?

Understanding that more often than not the antipattern will not be the solution you want. But if the evaluated alternatives are not effective, the antipattern can be used with the knowledge of the potential desired and undesired outcomes.