Kent C. Dodds (00:00):
Hello friends. This is your friend to Kent C. Dodds, and I'm joined by my friend Daria Caraway. Say hi.

Daria Caraway (00:06):
Hey everyone.

Kent C. Dodds (00:08):
So Daria, I'm excited to join you. Actually, this is the first time we've actually talked, but I've been following you on Twitter for a while, and it's been just a pleasure. And I'd love for our audience to get to know you. So could you just give us an intro to yourself?

Daria Caraway (00:23):
Sure. Yeah, my name is Daria. I'm a software engineer currently at Workday. I guess I'm a full stack software engineer. I've been working as a software engineer for about six years now. Previously got a computer science and business degree at university, and had to choose between which one of those I wanted to, and ended up in software engineering and been here ever since.

Kent C. Dodds (00:48):
Well that's cool. I actually did information systems as a major because I felt like it was a good mesh of business and computer science. So yeah, that's interesting that are... related interest there. So when you first got into the industry, I'd love to hear about what that experience was like for you, switching from school to actually getting your first job and stuff.

Daria Caraway (01:16):
Yeah, it was interesting. So my major at my university... My college had four different computer science majors. We had computer science games, computer science, computer engineering. I did computer science and business. And so I took the whole CS curriculum and then a couple elective shy of a business curriculum as well. And so a lot of people in my major were deciding what they wanted to do. A lot of my friends ended up being product managers, or manager managers, and I decided to go software route, and so I did the whole interviewing at all of the companies for new grad positions, but I really wanted to... I'm from Boulder originally in Colorado. And I went to school in California, and I really wanted to come home. So I ended up working for an ad tech company close to where my family is in Boulder, and it was a pretty small company. So I got to work on a bunch of different types of technology while I was there.

Kent C. Dodds (02:20):
Cool. Yeah, And so naturally that led to the full stack idea for you where you're at a small company, you wear lots of hats. What was the tech you were working in?

Daria Caraway (02:30):
Totally, yeah. At the ad tech company, it was in PHP at the beginning and JavaScript. It was like a PHP server and JavaScript on the client. I was there and helped move their big JavaScript client to TypeScript, and then we also moved it from AngularJS to Angular 2. And we also moved the PHP server to Scala. So it was like all in flight while I was there, which contributed to having to work on many different things. And that was a cool experience to just get exposed to so many different languages and learn them with all of my coworkers.

Kent C. Dodds (03:07):
Yeah. Wow, that's awesome. That opportunity that you had to experience that migration. Most companies I think as long as they live long enough are probably going to have to migrate at some point and having the opportunity to migrate both the frontend and the backend all at once, I'm sure that you learned a ton from that.

Daria Caraway (03:32):
Yeah. A lot. And it was interesting too, because it wasn't like we had a whole bunch of experts on our team of the technologies we were moving to. So we all had to figure it out together, which was a really nice learning experience.

Kent C. Dodds (03:47):
That's very cool. And so would you say that... you're not on that company anymore you're at Workday, right? Is that right? Workday?

Daria Caraway (03:56):
Yeah, yeah.

Kent C. Dodds (03:57):
Yeah, and so at Workday, was that your next company or do you have a couple of companies in between?

Daria Caraway (04:06):
Yeah, no. I went from the ad tech company to Workday. The ad tech company was... I want to say about 300 employees, so it was pretty small. And then Workday is... I don't know, somewhere around 12,000. So it's a much bigger jump.

Kent C. Dodds (04:20):
Yeah, yeah. And I'm guessing with COVID you've been full-time at home. Did you start at home or?

Daria Caraway (04:26):
No, I've been at Workday for almost three years now. So I got some good time in the office before we all had to pack up and work from home.

Kent C. Dodds (04:34):
How have you liked working from home?

Daria Caraway (04:38):
It's not bad. I definitely miss seeing people in the hallways I guess. In Boulder, there's a big culture of going out during lunch to go rock climbing or on a hike and I definitely miss that aspect of it. But it's been okay. I'm definitely adjusted to it now. I say that, but we're a year in and my partner and I just rearranged our house so our desks could be in different rooms. So I don't know. I think we're still getting used to it.

Kent C. Dodds (05:06):
Yeah, yeah. It definitely... so just the other day I was meeting with some people and we're local, but we have to meet virtually. And one of them said, "Hey, maybe we should start doing these meetings in person again." And originally, when we had first gotten started, I was like, "Man, I just love this. It's so convenient, just do it over Zoom and everything's great." But when they said that, I actually thought about it for second and I'm like, "No, no, I really want to meet in person again. I'll wear 12 masks if I have to, I just need to be in person." So I'm definitely the type of person... I don't mind being in my box down here in my basement, whatever but yeah, I'm totally ready to meet up with people again. So hopefully you'll get to go back to the office here pretty soon.

Daria Caraway (05:57):
Yeah definitely.

Kent C. Dodds (05:59):
I definitely prefer working remote full-time, but I just want to be able to see people. So anyway, when you switched over from the ad tech company to Workday, what were you hired to do? I mean, you have experience with PHP with Scala, with Angular 1 Angular 2. What did they hire you to do?

Daria Caraway (06:26):
Yeah, it was kind of a jump. So I had been doing all of those full stack things for a while. And then I got hired at Workday to be a Frontend React Engineer. I had a little bit of experience with React. When I was in college, actually I interned full-time at a startup that was also doing a little bit of React. But it had been a while. So, I got hired at Workday to be a React front-end engineer. And it was interesting. I had been used to seeing the full scope of the stack. Not necessarily just backend, frontend, but all the way into data consumption and then data processing and then feeding that data back to the client so that your users can see it, and moving directly into React.
But it was interesting because the team I started on at Workday, they were actually also in the middle of migrating their AngularJS application to React. So for that reason, it felt familiar, they were migrating also from JavaScript to TypeScript. So it was another one of those instances where the code had been around long enough and they were ready to clean it all up and get it a little bit started over.

Kent C. Dodds (07:39):
Yeah, totally. So I'm sure your experience really came in handy with that migration too. Because there good ways to migrate and not as good ways. I'm sure that you could... if you haven't already, you could put together a talk for migrating code basis. Because you seem to have quite a bit of experience with that. It's not always fun.

Daria Caraway (07:59):
Yeah, yeah. It's a different kind of challenge I think. It's one thing to write your own code. It's another thing to be thrown in there in I don't know... a 10 year old code that has passed through hundreds of people's hands and try to figure out what is going on.

Kent C. Dodds (08:17):
Yeah, I can only imagine. So I actually had a similar switch over from AngularJS over to React. I never built anything in Angular 2. I was starting to get into it and give talks and stuff, but I never really actually had the experience that you did with Angular 2. But I did decide "I'm done with AngularJS, I want to move on to React." And so I had switched companies and switched frameworks in the process. But most of my career has always been consuming backends. So I never really wrote much backend code, I did some in school for little projects that I would do. At PayPal, I did write plenty of Node and backend code stuff there, but it was always like this middle tier. So we had the [inaudible 00:09:10] down backend, they were doing database stuff, and we were just marshaling calls to them.
So we were basically frontend, just a little bit on the backend side, and we would make some of our own APIs to hit, but I spent most of my time on the frontend, and I decided I wanted to be primarily frontend. I would grab all of the things, all the tickets and stuff that were front end. I'd volunteer for those. What's it been like for you? You had plenty of experience on the backend and front end and you come into Workday doing mostly front end. Has that been a pleasant change for you or where do you feel you prefer spending more of your time? You like to specialize just in React or would you like to be more general?

Daria Caraway (09:51):
Yeah. So it's funny. I'm actually on a different team in Workday now doing full stack work again. So I think that I definitely learned that I prefer to be more general and see the whole picture. But at the same time, even though I've worked on backends and frontends in different intervals of my career, JavaScript is always the common denominator. Right? I've worked in I don't know... five or six backend languages, but the frontend is always in JavaScript. So in some ways I feel like I'm special... like I'm a little bit of a specialist in JavaScript, which a lot of my content and talks and stuff will be, catered towards the frontend. But I definitely prefer being able to see the whole picture and architect the solution from the top to bottom. I found myself getting a little bit antsy, just consuming things that I have no control over if it wasn't in the best format for the client, like instead of going and making it work from the full stack, just having to make it work on the client. I definitely prefer to kind of architect it from the whole, the whole picture.

Kent C. Dodds (11:00):
Yeah, it definitely is frustrating from a consumer standpoint to work with APIs that aren't great. And not really have too much to do about it. You can file a ticket or something, but who knows when that's going to get prioritized? So being able to just fix it yourself, I'm sure is nice.

Daria Caraway (11:19):
Yeah. And I don't... this isn't everyone's experience, but I've just found that when I can speak both languages, it makes the collaboration a little bit easier. There's less of trying to translate from what this person cares about to what we care about. It's more of like we're all building it together. And that might just be from the circumstances I've been in, I'm sure that you can be a front end specialist and also have that great open collaboration. I've just found that it's easier for me when I can fully speak to everything that's going on.

Kent C. Dodds (11:54):
I think that's really critical. I'm definitely on the specialist side of things, I made a conscious decision to specialize and I feel like... I've actually said this on another podcast where I feel like being a full stack developer is very difficult to do because you just... you can't go as deep on whatever part of the stack, you have to be more... yeah shallow sounds bad, but that's not what I mean. But yeah, you can't go as deep. And so that's been my reasoning for going as a specialist. But even regardless of whether you decide to specialize or generalize, I think that it's really important that you understand your level of abstraction and then one level below it, and then all the levels... at least the connection points of all other things that you talk to.
And so that means for a JavaScript developer, you understand React and then you also understand the DOM. And have at least a conversational idea. And then you also understand HTTP. And so you know how to integrate with whatever it is that you're talking with. So I totally agree with you. It's really important to at least be conversational. It sounds like though being a generalist has been really effective and useful for you. So can you speak to I guess a little bit on some of the reasons that you feel like it's really useful to be a generalist? Or maybe there's engineers listening in, or even new engineers listening who are trying to make this decision on whether they want to go deep in something specific or be general. So what are some of your thoughts and experiences?

Daria Caraway (13:37):
Yeah, I think for one, I just prefer it. It keeps me interested. I feel like whichever one is more interesting to you, that is the more important one, because that means that you'll be more curious and you'll be willing to dive in deep. Even if you're only learning a language and you're only going to use it for six months, you'll be more willing to do a deep dive in that six months as opposed to just getting the job done and moving on. So that's something that I've had to learn is even if I'm picking up a language for six months a year. The server I work on right now is in Kotlin. And that is a completely new language to me. And I've been working on it for about a year now. It's important to take the time, even if it's a short pass by, to really understand how things work.
And then in that case, you can almost become a mini specialist in lots of different areas. Also too I mentioned how JavaScript has always been the constant. So it's not... when you're a generalist, you don't have to just know everything. You can pick a couple of things to know better than the other things you know. And for me, that is JavaScript and in the most recent past been React. But yeah, I think it just helps me in general to be able to communicate with everyone in a way that everyone else understands. I've been in a lot of situations where it feels like we have frontend people, or backend people, maybe we have data people and machine learning people, and it feels like we're all having six different conversations, and nobody can really find that common ground with each other. I've figured out that one of my strengths in my career is being that person in the middle that can communicate with the ML team and connect them with the data team. And connect the data team to the frontend team and the backend team. And it's been great. Yeah, it's been fun.

Kent C. Dodds (15:39):
That really sounds invaluable actually. And you mentioned that you don't mind, even if it's going to be a couple months really learning and understand. For me, if I have to do something that's outside of my specialization, it's basically like I'm shopping, where I'm in and out as fast as I can possibly be. And I really don't feel comfortable outside of my specialization, and I just don't want to be there. And I don't want to be the one to do it. And so I often wasn't. And luckily for me, any company that I worked at, there were other people who could fill that space and I had plenty of stuff to do. Now, it could have gone the other way where, "Oh, well, if you're not willing to do this, then what are you even here for? What would you say you do here?" But yeah, for me, that's actually worked out.
But I can see how being a generalist and just having a generalist mindset, being willing to say, "Okay, it's only going to be for a few months, but I'm really going to get this and I'm going to do a really good job with this." I think that's valuable. Maybe a lot of my problem has been just a character weakness of being impatient and wanting to move on, do what I want. But you also mentioned something else I thought was interesting, is that because you have a pretty great understanding of these different levels, you're able to facilitate communication and help everybody get on the same page. To me that sounds a lot like the sort of thing a manager would do. And I'm interested to know whether that's ever something that you're interested in in the future, or if you really just enjoy being a coder all the time.

Daria Caraway (17:21):
Yeah. It's interesting. I watched a pretty popular talk where I finally for the first time, it clicked what my role was and it is described as this idea of doing glue work. Right? And I think in some ways, pushing myself to be a generalist, I've almost made myself the glue between lots of different groups of stakeholders and maybe not even technical. In the same ways that I can communicate to people in different parts of the stack, I also find myself pretty good at talking to non-technical stakeholders. I'm my team's Scrum Master, so in my role, that means being able to talk to all of these different stakeholders, managing timelines between different groups of people, which does sound a lot, like being a manager. I think I'm on that path, and I think I'm on that path in some ways because of how much different type of work I've picked up. But yeah, I think probably in a year or two years, I'm probably looking at becoming an engineering manager, which I'm excited for but that is a whole other adventure I think.

Kent C. Dodds (18:26):
Yeah, yeah, absolutely. And I think the interesting thing that I'm taking away from what you're saying is, it sounds like this has been pretty intentional for you. Or you've been at least thoughtful about the type of work that you pick up. I think that you could probably be a generalist and still be a coder all the time, but it sounds like you have intentionally put yourself in the way of these different opportunities to be the glue between these different layers.

Daria Caraway (19:02):
Yeah, that's very kind of you to say. I think it didn't feel like that at the beginning, I think in the same way that you mentioned just always picking up the frontend tickets because that's what you felt most inclined to do, I have a character flog never being able to say no. So when my manager would come to me and be like, "There's this integration we have to do, nobody knows anything about the code. It's not documented anywhere, by the way it's in Scala. I think you should do it." I can't say no. I have to do it. And so after enough of those experiences, I ended up where I am and then realized that I like it.
And if I didn't like it, I maybe would have been better at saying no to some of these opportunities. But yeah, yeah. I think there's definitely cognizant decisions that you can make on a daily basis to guide yourself in whichever path that you want. When I'm doing scrum mastery things for my team, I always try to make sure that we have work in our sprint that interests everyone. And if there's someone who wants to take on more backend work and maybe they haven't done, so we give them space to pick up a backend ticket and feel like they can take it all the way through and be successful. And so there's definitely depending on your situation room to make these decisions, to figure out which one you want to be.

Kent C. Dodds (20:24):
That's a great point. And something else you mentioned makes me think of something else I think is important. And that is, you just said "If there's somebody who wants to do more backend, then we'll give them some more of that." How would you possibly know that that's what they want, unless they're communicating with you about what they want? So is that something that you have done you maybe through actions? It sounds like at the beginning you were just mostly, "I'll just do whatever." And so you were the go-to. Or do people tell you, "Hey, I want to get more into the front end stuff. Can you give me more of those tickets?" Or how does that typically work?

Daria Caraway (21:02):
Yeah, sometimes it's tricky because... like I was when I started, I don't think people necessarily know which they want to do especially if it's a language you've never used before. Like maybe you're on my team and you're doing a lot of TypeScript, Kotlin seems like a big jump. And so it can seem scary and maybe that person needs a little bit of a nudge to get over there. And then once they are, they really like it. I try to just flat out ask when we have new people on our team, like, "Hey, we're a full stack team, but you don't have to do anything. We can find work that you enjoy, whether it's on the backend or the frontend." And I'll just flat out ask.
And a lot of times they'll be like, "I mean I really... I think it'd be cool to do backend work, but I'm a little bit nervous and I don't want to slow the team down." And just making sure that they know that that's not an issue. We have enough time, we have enough resources to help them learn. And I think that's not the case for everybody. That's a really... I think our team is in a really privileged situation to be able to take the time to learn something new that we're not necessarily familiar with. So if you are interested in being a generalist, maybe being on a team that has space for you to be able to pick up new technologies, I think might be an important feature to look out for.

Kent C. Dodds (22:24):
Yeah, that's a feature of a team. Yeah, that makes tons of sense. And I think that it's really awesome of you as a Scrum Master to take time and ask... I've had Scrum Masters and also managers who were really interested in me and what I wanted in my career and everything, and others that just... I'm sure they were well-intentioned, but they just obviously did not care at all. Our one-on-ones were basically status report, it was just not useful at all. And so yeah finding a... it sounds like you'd be a great manager. I guess is what I'm trying to say.

Daria Caraway (23:02):
Thanks. I'll tell my manager you said so.

Kent C. Dodds (23:04):
Yeah, that's great. Yeah, so communicating I think is really valuable. Especially when we're trying to be intentional about our career choices and what direction we go. Whether we want to be a generalist or a specialist. Has it ever been... Have you ever tried to make the decision or make a change in the direction your career is going like, "Oh, I'm starting to go in this direction, I actually don't want my career to go that way."

Daria Caraway (23:33):
Yeah, yeah. When I first started on the frontend only team at Workday, I was on that team for about a year. And so that's where I racked up on my React knowledge and newer features of TypeScript or JavaScript that I hadn't seen before. And so I spent a year really in React land. And I liked it and I liked being able to do a deep dive and become more of a specialist in that area. But at the end of the day, I went to my manager and I was like, "Hey I don't know that I want to be a frontend engineer for much longer. This has been really great, but I just personally feel like I am much more interested in being more of a generalist."
And I got to look for a new position on a different team that was structured a little bit differently at the same company with full support from everyone around me. And so that was a really nice opportunity because I love the company that I'm at and I didn't have to jump ship in order to change my direction. But I'm sure that that wouldn't be the case for everyone. And sometimes maybe it is necessary to jump ship in order to change direction. Because depending on what company you work for, what organization you work for, sometimes the way teams are structured just might not be the way that you want it to be in order to be happy and successful.

Kent C. Dodds (24:56):
Oh, that's a great story. Thank you for sharing that. I'll share one of my experiences that made me think of and it was the first company that I worked at, I'd been there as an intern for about a year and a half before I graduated from college and converted to full-time. And it was very difficult. I was only there for four months after I graduated. In large part because it was very difficult for people that I worked with... who were all amazing by the way. All of the engineers that I worked with were amazing. I should say. But it was just very difficult for me to get any of the really interesting tasks. Because I was always seen as the intern, even if they like, "No, no, you're not an intern. You're great." But I was just seen as... and aside from that, there were just some really brilliant engineers that if there was a hard task, it was always going to go to the brilliant engineers.
And maybe there was also a little bit of fear on my part of even asking, and I might've been able to make my way around asking. But part of the reason that I left so soon was I realized, "Here I am never going to be able to do the really awesome stuff that I'm seeing them all do." And so for me I had to make a job change to start leveling up and different things like that. So yeah, definitely, I think it's a good idea to occasionally just stop and think about, "What do I want? And are the things that I'm doing now going to get me to where I want to go?"

Daria Caraway (26:26):
Definitely. Yeah, that's a good point. I've definitely been in, and seen situations like that where you feel like the seniors or principals on your team are getting all the cool work and you're just also there doing things sometimes. That's why I feel like having space to learn and being in an environment that really supports learning whether or not you choose to be a generalist or a specialist is going to help you go in either one of those directions. Something too that came to my mind, you were talking earlier about being on the frontend, but doing the frontend of the backend in some ways. And for a long time, I saw myself as full stack, but I didn't really do the front, frontend of the frontend. I was more of a backend of the frontend.
We were both maybe in the middle, but in different ways. And so even within being a backend or frontend, there's so many different things that you can specialize in or generalize in. Is that the word? Also too, it doesn't even necessarily have to be a backend language or a frontend language. I just spent a month on my team working on our continuous integration pipeline and learning Groovy for Jenkins and Gradle, which is a build tool. There's so many parts of what we do as software engineers that is so much broader than just being like a React expert or a Java expert. There's so many other pieces that always need to be done. And if you're looking to put yourself out there, like working on the CI pipeline might be a good example, or trying to spiff up the test automations might be a good example. There's just so many opportunities in what we do to step out of your comfort zone.

Kent C. Dodds (28:12):
And I think it's really useful, especially early on, but even at any time, because this industry changes so fast, to step outside of your comfort zone. Admittedly, I'm very bad at that. I really like my comfort zone and I like to stay where I'm at. I don't mind being on the edge of whatever... I'm talking specifically about React or testing stuff. I don't mind being on the edge of that stuff, but it's still within my specialization. And there's probably... I know I would benefit from reaching out beyond my comfort zone a little bit more. So maybe this is a reminder to me too.

Daria Caraway (28:49):
Maybe. But honestly I don't... I feel like it's up to you. There's no right answer. People might try to convince you that there's a right answer but I feel like it's just about if you want to be in your comfort zone, you feel like you're successful in your comfort zone. Maybe that's a nice place to live.

Kent C. Dodds (29:06):
Yeah. I like it pretty well here so. Cool. Well, Daria, we're reaching the end of our time. Is there anything else that you wanted to talk about before we give folks their homework?

Daria Caraway (29:19):
No. This has been really great to hear it from your perspective as someone who's more of a specialist. And I hope that anyone listening has heard something that made them analyze or think about what position they're in and what position they want to be in.

Kent C. Dodds (29:39):
Awesome. Yeah, very good. And that leads in perfect to our homework. So we're not saying that you should be one or the other, but we are saying that you should be intentional. And this can change over time. None of this is set in stone, but here's your homework. We want you to take five minutes to think about whether you want to be a generalist or a specialist, and then write down the three things you can do to get your career to go in that direction. So if you're not already getting yourself all of the backend only tickets or whatever it is, write down some specific things. And one of those things, just as an idea, is to talk to your manager about your career goals. Then I think they can help you a lot. If they're a manager that's worth their salt, they will help you accomplish that goal. So anything to add to that Daria?

Daria Caraway (30:26):
Yeah, yeah. I love that. Even just sometimes, like you said, just starting the conversation, because there might be space for you to do whichever one you want, but if you haven't verbalized it... there might be an opportunity sitting there for you that you don't realize yet. So just starting that conversation is a great first step.

Kent C. Dodds (30:42):
Absolutely. There could be a thing that your manager's like, "My goodness, who am I going to get to write this Groovy, great old build pipeline thing, man." And then you come around and you're like the answer to their prayer so.

Daria Caraway (30:53):
Exactly.

Kent C. Dodds (30:55):
Very good. Well, Daria it's been a pleasure chatting with you. We have another episode that we're going to record, so folks look forward to that. We're going to talk about TypeScript and It'll be fun. But for now, we'll just say ta-ta. Thanks, Daria.

Daria Caraway (31:07):
Ta-ta.