EPISODE 1758

[INTRODUCTION]

[00:00:00] ANNOUNCER: Slack is a team communication platform that originated as an internal tool within Tiny Speck, a game development company. When the company realized that their game would not achieve commercial success, they changed direction and repurposed the communication tool into a new product which eventually became Slack. Slack was launched in 2013 and is now ubiquitous in workplaces around the world. 

Shruti Kapoor is a lead member of the technical staff at Slack. She's worked on features including huddles, the recent redesign of Slack, and currently works on accessibility. She joins the podcast to talk about her path into front-end engineering, the front-end tech stack at Slack, the developer tooling, how Slack evaluates new technologies, and more. 

This episode is hosted by Josh Goldberg, an independent full-time open source developer. Josh works on projects in the TypeScript ecosystem, most notably typescript-eslint, the tooling that enables ESLint and Prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on Bluesky, Mastodon, Twitter, Twitch, YouTube, and .com as JoshuaKGoldberg. 

[INTERVIEW]

[00:01:27] JG: Shruti, how's it going?

[00:01:29] SK: It's going pretty good. Thank you for having me on the podcast. 

[00:01:32] JG: We're excited to have you, Shruti, can you tell us a little bit about yourself? How'd you get into tech?

[00:01:37] SK: Yes. Actually, I got started into tech pretty early. I would say I was the kind of weird kid who wanted to do HTML when they were in grade eight, mostly because my dad forced me into it. He said, "This would be a nice exposure for you to see how to build websites." I was like, "Okay," so I took an HTML course, and I actually really liked it. I remember like I created my own web page, and it had a marquee tag which said, "Welcome to Shruti Kapoor's homepage," and it scrolled past the screen. I had really bad color for choice, but it was fun. That's how I learned HTML. 

Then I learned what I think is jQuery. Or was it JavaScript? I don't even know. Maybe there was a dollar sign in there. I don't even remember. I just remember seeing gibberish, and I was like, "Okay, this is where I leave this course." I ended up leaving that HTML course after learning HTML and CSS because I did not want to go further. This was grade eight. 

Then I had no inclination of learning computer science or computers or whatever until I actually entered university which is when we are supposed to choose our major. In Canada, which is where I went to school, you're supposed to choose your major in the second year. In the first year, it's more general. 

I was taking this course called Introduction to Computer Programming in C. I think big props to the professor because when I was doing this course - the professor's name is Paul Carter. I think he still teaches at UBC. Big props to the professor because while I was going through this course, he explained it in such an easy-to-understand way. You know what made it more fun was he would talk about this program. You know what we were writing? We were just writing for loops. 

He would talk about these programs, and he was like, "You can do something, and then you just make it run 100 times without you actually having to do it." I was like, "What? I don't have to do the actual work, and I can just make the computer do the work. That's awesome." I was so fascinated by that simple for loop. It was so simple. It was just printing like hello world to the console, but I was so fascinated by it. I was like, "I want to do more. I wonder what else we can do." 

I started thinking like where else is tech used. I asked a very stupid question in class which is like, "We have these trains in Vancouver. It's called SkyTrain." I was like, "Do you think that uses computers, too?" He was like, "Yes. I'm pretty sure it uses computers, and I'm pretty sure there's some code in it, although much more complicated than just a for loop that says hello world. But I'm pretty sure it has some code." 

That was my introduction to code, but that was first year. I wasn't really sure what I wanted to do. It was very different from doing front-end engineering. Then at the end of my first year, my dad was trying to build his own business, and he asked me if I would be willing to do a website for him. He's like, "You're an engineer. You can build a site." I was like, "Dad, I have no idea what needs to get done to build a site." He was like, "I'll pay you $500." I was like, "Okay, I can learn for $500. I don't care what needs to get done. I'll do it. So just throw some money at me and I'll do it." 

I found out about this no-code tool called Wix. At the time, I had no idea that Wix was such a big deal, but I just knew that it can build a site for you, and I didn't have to write any code. I was like, "$500 and no code. Hell, yes, I'll do it." It was just a drag-and-drop editor. While building this site, I was introduced to these widgets that Wix has. Basically, you can drop in any HTML code in it. I was like, "This is pretty cool. I have a drag-and-drop builder. But if I want to actually add HTML, I can add HTML through these widgets." 

That was my first kind of like wetting my feet with HTML. Once I built that site, I was like, "Okay. It wasn't too hard, and I can still build a site and earn money for it. So maybe I should do more of this." Then I started looking in Craigslist who was actually hiring for web developers. I actually had no idea it was called web developer. I thought it was called like a graphic designer or like a web designer. I was just looking for everything. I had no idea what I was doing. I was in year one. I had no idea. 

I started looking up on Craigslist, and so I found some people hiring for web designers/web developers. I saw the amount of money they were willing to pay for web designers, and I was like, "I need that money." It was $1,500 to build a site. I was like, "I could probably do it." All you need is something similar to what my dad has, like a homepage, so I could probably do it. 

I reached out to them and asked them if they'd be willing. I sent them a site that I already built which was my dad's site which was already in production. I went there and I talked to them and I sold them the idea of building a site where they can just maintain it themselves because I was going to build it on Wix or WordPress. They loved that idea. For the first time, I was able to sell my services without even having any credentials for $1,500. I was like, "Okay, this is what I want to do." 

Then I did second year and third year and fourth year. Then I graduated from college. But somehow, I ended up finding a job as an automation engineer. I was like, "Okay, I don't know what automation engineers do." This was at TELUS Digital which is a telecom company in Canada. I was like, "I don't know what automation engineer does, but I'll find it out." I was really interested in building stuff because I'd build stuff before.

But then when I got at work, they were onboarding me. They said, "There's these things, and there are these features. What we're going to be doing is writing test suites to make sure that these features don't break." I was like, "Wait. So we're not actually building the features." They're like, "No, no, no. We're testers. We're going to test the feature." I was like, "Oh, my God. This is not what I wanted to do. I wanted to build the feature." 

I convinced my manager eight months down the lane to help me become a developer from an automation engineer. So much gratitude to that manager for taking a chance on me and letting me do that because he gave me a small task to do, and that was just adding a paragraph to the site, just a paragraph tag in React. Through that, I learned React, Angular, and Redux on the job. That's how I got into front-end development. Long story but somebody took a chance on me, and that's how I got into front-end development.

[00:08:11] JG: Excellent. Now, you're a staff engineer at Slack. What does that mean?

[00:08:16] SK: Okay. My actual title is Lead Member of Technical Staff. I don't know what that translates to in simple language, but what it translates to at work is I build features for the Slack UI. Some of the features that I worked on that you might have seen is the huddles. When you start a huddle with two or more people, you'll see that there is a grid. That is the grid that I worked on. 

I also worked on the redesign of Slack, which a lot of folks may have already seen it. Slack looks different now as compared to last year. We did a really big redesign at work, and I was a part of it. Right now, I'm working in the SlackKit team which is actually kind of like a design systems team. I work on the accessibility team at Slack which is the team that is responsible for making sure that Slack is inclusive to everyone, including people with disabilities. 

[00:09:13] JG: Before we dig into some of the user-facing aspects of that such as the accessibility points, could you give us a brief overview? What's the tech stack you're using over there? 

[00:09:21] SK: Yes. Actually, our tech stack is pretty interesting. We use React, TypeScript, and Redux for our state management. Is it interesting? I don't know. That's the tech stack we use. It's pretty simple, no fancy libraries. We're using TypeScript React, and then our styles sheets are in Less. 

I think front-end at Slack, one of my favorite features or favorite things of front-end at Slack is the fact that the tech stack is simple enough that you might have learned it at other places, and it's easier to move to Slack with that knowledge. But also the ease of development with the front-end experience that we have, and specifically being we use this thing called remote dev environments for building. 

Basically, if you need to spin up a new branch or if you need to spin up a new environment to work on your code, all you need to do is just one line of code. You write one line of code, and you've got your Visual Studio running with all of your node modules installed. You've got a remote dev environment working. Everything is synced automatically, so you really have to do nothing, except just one line of code. 

This developer experience makes it so easy to get code shipping fast and have your development setup reduced to just a few minutes instead of having to pull down and do node modules and setup. It's super easy to set it up which I love. I've never had this kind of smooth development experience before, and I love it. 

[00:10:45] JG: That's great. You mentioned that the skills are transferable from other places. Let's say React and Less and TypeScript. Is that an intentional choice that the team made when evaluating the tech?

[00:10:56] SK: The tech has been like this for a long time, even before I joined, so I can't really say to why that is the choice that we made. But one thing that I know is that when we do evaluate new technologies, we were evaluating graph code for a long time. This is something that we do consider, like how easy it is going to be to hire people who already know that technology and maintain it. We don't want to end up in a situation where we find people who are super focused on one tech, and then that's the tech we adopt. Then we're not able to find people who know that tech, and it's hard to maintain it or find new folks who are going to maintain it. That's definitely a big consideration in adopting a new tech. 

[00:11:35] JG: Let's say that I was a new developer on your team, and I was all excited. Oh, my gosh. Insert buzzword here is the latest and greatest thing. What would be kind of the strategy you'd suggest I take to help the team evaluate whether it actually is the latest and greatest?

[00:11:48] SK: Oh, that is a great question. At Slack, one of the things we do is we are very prototype-heavy. The first thing that we'd check is or like - for example, I wasn't involved in the GraphQL evaluation. But when I joined, this is something that we had already done, so that's something that I can speak to. 

What we do is, first, we ask you to kind of - well, we don't ask you. We build a prototype in that language. For example, if you were to adopt GraphQL, we'd build a prototype app in that. Then because Slack is a monolith, we don't really have separate apps really. Everything is part of the same monolith. Even though you're building components, it's part of the same app. 

We think about how we're going to maintain it and how it's going to integrate with the rest of the services, and rest of the apps that we have, and whether or not we'll have to transition those to GraphQL, for example. What is the benefit? What is the performance benefit? How many people are maintaining it? How many people will need to move to it? 

For example, we're currently moving from React 16 to 18. This is one of the things we thought about, which is which components need to transfer to React 18. What are the performance implications? Can we do an example, or can we show people how it needs to be done? Can we set up examples for people to view from it? What are the pros and cons for it?

One big thing that we definitely focus on is what are the performance implications? Because we're a giant monolith, we don't want to slow it down. But what are the performance implications of introducing something new and if it's going to be worth it. 

[00:13:20] JG: Yes. For a while, Slack was one of those apps where when people brought up Electron in slow performance, that was an example. But that hasn't been as much of a topic lately because I think you've gotten a lot faster. Let's switch topic a little bit. You have a large monolith with a lot of developers working on it and a lot of areas of code. But you've also been heavily involved with the accessibility of Slack. Speaking from experience, I know it can be very difficult to make sure a large group of people keeps a front-end or full-stack act accessible. Can you talk a little bit about how you've been able to do that?

[00:13:50] SK: Yes. I came to Slack as a front-end engineer who's worked on apps that are not really focused on accessibility. Accessibility usually would be an afterthought or just a hacky slap. We need to make sure that it's accessible, so we don't have legal fines. Coming to Slack has been really a great learning opportunity in that way because Slack really takes the time to do accessibility right and put a lot of thought into it and a lot of focus into the way we build a feature to make sure that it's accessible from the get-go. We may not succeed 100% of the times, but we do make sure that everything goes to an accessibility audit. 

[00:14:34] JG: Shruti, before we dive too deep into accessibility, let's cover what is accessibility. 

[00:14:39] SK: I love that question because it's such a wide scope of things that accessibility covers. Basically, what does accessibility means, and what does it mean to create accessible web applications? When I think of accessibility, I think of inclusivity. Building with accessibility in mind really means building with inclusivity in mind. 

What it means is that your features, everything that you push out or everything that is existing, should be navigable by somebody who is not just using mouse or not just our sited users but also anybody who has other disabilities or anybody who has disabilities such as people who may not be able to see very clearly or may not be able to see at all, people who may have motor disabilities, people who may have cognitive disabilities. Making sure that your features are inclusive to not just a small group of people, which is able-bodied people, but also people who may have other disabilities or people who may have disabilities is building with accessibility in mind. 

For somebody who's working at a big corporation or somebody who's not really building features, what accessibility really means is from a UX perspective, it means making a better experience for everyone, including people who have disabilities. From a financial perspective, it also means that now you're improving your user experience so that you're not just including people who are able-bodied and who are able to navigate your site through the conventional means, but also opening up your site to other users who may not be using the conventional means of mouse or sited users, and so opening up your site to this new funnel or this bigger funnel of people as well with disabilities. 

[00:16:26] JG: Yes. There are multiple reasons why one might become accessible. There's moral reason of if someone, let's say, doesn't have a left hand or hands. Or let's say that they're on a really old laptop that can't work or whatever. They can still use the website. There's the legal reasoning, so you don't get sued. Then there's also the financial reasoning, right? All three of these coming into play here. 

[00:16:45] SK: Yes, definitely. I think when people think of accessibility, they usually think of the moral reason which is that we have to make it accessible because there are other people who may not be able to access your site, so we have to make it inclusive. But there is a financial aspect as well which is you are now opening up your funnel to more people. Also the legal aspect that if you don't make it accessible, you are going to get sued, there's going to be fine. 

[00:17:10] JG: Love the old carrot and stick there. 

[00:17:13] SK: The stick. 

[00:17:14] JG: Yes. Shruti, let's say I am yet again a very excited developer who's new to your team. I've pushed a pull request, and I'm using, let's say, a div as a clickable element. Can you walk me through some of the steps you might take to help me get code that's a little more accessible?

[00:17:29] SK: Right. One of the things we do is we try not to act as the, what is it called, role police or whatever. We try not to police you too much. We try to gently nudge you in the right direction. First of all, I think what makes our job a lot easy is we have linting tools in place. If you were to add a div as a button, the linter would complain. It makes our job easier that we don't have to actually tell you what the problem is. It comes with documentation and everything, so you know exactly what the problem is. 

I think there's multiple reasons why you wouldn't want to put div as a button, but what I would talk about here is the process by which we educate people on why this may not be a right approach. Typically, the way we do things at Slack is if you are building a new feature and let's say you're the designer or you may be the front-end developer on it, once you're building the feature, we ask you to come to the office hours of our team through which we talk about the feature, and we talk about what the accessibility implications might be. 

At this point, our team goes through the design, and the designer or the front-end developer would usually walk us through the feature, talk about what it does. Then we have a discussion on if this is the button, then why do we need a div on it. The front-end developer would talk about why they're using a div. Then we would do the job of explaining to them like this is the reason why you would want to use a semantic button, which is the button HTML element itself, instead of adding a role of a button to a div. 

I talked about the linting tools, but we also have our SlackKit design systems button itself. This is an accessible component that we've built. We'll nudge the folks to use an accessible component that we've built. This is not - I'm saying accessible component, but it's just a design system component that we have. We'll nudge folks to use a component that's already been built with accessibility in mind and has been tested with accessibility in mind to make sure that we are not reinventing the wheel. 

In conclusion, if you were to use a div with the role of a button, first we would invite you to our office hours. Actually, the linter itself would throw errors at you. If you're still unsure about what the error is about, we'll invite you to our office hours. We'll talk about the design. We'll talk about what makes a better experience and why do we need to use A versus B, which is div of role of a button versus an actual button. Then we'll nudge you to use the button component itself that we've developed at Slack which already has accessibility baked in. 

[00:20:00] JG: How difficult is it to create a button component that's accessible in a design system?

[00:20:05] SK: Yes. What I love about this question is that somebody might think like, "Oh, it's such a simple thing," which is what I thought. I was a feature developer. I look at a button, I know what needs to get done. But there are so many different things that needs to go behind that component in building that component. First thing is it needs to be accessible, and it needs to be accessible in a way such that when other client components use it or when a developer of a different team uses it, they're able to embed it within their component, and it still works with the props that have been supplied to them. 

The second thing is because it's not just a component that's going to be used in your feature, you also have to think about what other developers might need. On top of just interactions, there's also a bit about making sure that it is extendable for somebody who might be using it as part of design systems. I think that's just the part of building a design system component itself. You have to make sure that it is debuggable, it is extendable, and it is embeddable within their component. 

[00:21:06] JG: Yes. There are some things that you can lint for. You can lint for someone using, say, a div instead of a button for a button or clickable element. But people doing the same thing that already exists in the design system because they don't have the time or interest sometimes in learning the reusable button, that's a little harder. How do you make sure people are using the right thing when there are different things that might exist?

[00:21:27] SK: That is a hard problem, and it's a hard problem to solve as well because we're a small team, so there's only so much auditing we can do. However, when a component is being built or is being designed, it's the designer who is - we have a design system that I talked about. A designer's job is to pick a component from the SlackKit design system and add it to their design. 

Really, the work comes down at this point where we want to make sure that all of the design, all of the components that we are using are our vetted components. Sometimes, it happens that the component might not be already part of the design system and maybe a completely new design, maybe a completely new component. At that point, it is our job to guide the team to make sure that the experience is accessible. 

To answer your question, it's not always possible that all of the components that are going out there are part of the design system. But we do our best to ensure that the components that are going out there are part of SlackKit because we ensure that the designers are actually choosing components from the SlackKit design system itself. I think basically the point is that at some point, we need to make sure that the components that are being picked are part of the design system. 

[00:22:42] JG: I find it interesting that you've touched on a lot of interesting and tricky technical points like configuring linter settings that work for everyone and building a design system which is no easy feat at scale. But you've also talked about a lot of what one might call soft or non-technical tasks, even though they're actually quite difficult, hard, and technically oriented. Things like setting up systems where people go through reviews and have office hours and all that. 

How would you say that that balance has increased over time as you stepped into the staff role? Is that something that happens as you get more and more towards the senior parts of your career?

[00:23:15] SK: I think one of the things that I learned being part of the design system teams is helping others is the main job of this role because this is such a special team where we're like a small team. We can't go and check every team's work, so it becomes so important to help people when they come ask for help. It's also part of our team's requirements and team's goals as well. 

I think when I was a junior engineer, I was working more independently and more on the stories that were given to me. My job was to deliver the story and call it a day. As I become more senior and step into a more technical leadership role, my job is to enable others and to make sure that the need for me implementing something is reduced. I can help them develop it themselves and guide themselves. 

My job really becomes more of a technical mentor than somebody who's actually implementing the code. That could involve being part of the office hours and helping teams understand what needs to get done or what could be the problem, or it could be reviewing code, or it could be writing documentation. I guess my job just becomes me not doing the technical coding but helping myself remove from the equation. 

[00:24:35] JG: You're coding yourself and processing yourself out of a job, so to speak. 

[00:24:38] SK: Out of a job. Exactly, exactly. Thank you for putting it succinctly. That is what I was trying to say. 

[00:24:45] JG: Do you ever miss the days when you were just banging out code and features and fixes?

[00:24:49] SK: I'm still doing a big part of that as well. Just I was talking about, that list that I'm implementing. It's still very technical. It's still a lot of feature development and a lot of writing code. I think sometimes being on the forefront like this where you're just helping and you're always available for help can become really stressful because sometimes you may not know what the solution could be. 

I think that's the reality of this accessibility world. The problems do not always have clear solutions. Sometimes, it's a lot about talking through different options, doing a lot of user testing. We actually at Slack do a lot of user testing with real users who give us a lot of feedback on what could be a better experience. That has helped a lot because the answers are not always clear when we are just implementing it out. But getting feedback from folks who are actually dependent on these tools helps a lot.

[00:25:39] JG: I want to transition a little bit. In addition to all that stuff you're doing at work, you also do stuff outside of work. You're a content creator in the web dev ecosystem. Do you find that making videos and recording your own podcasts and such on things like React Compiler and AI tools is helpful in your day-to-day job?

[00:25:57] SK: I think it's really helpful because what I make videos on is very related to the stuff that I do at work. For example, React Compiler, React 19 things, React 19 actions, React Hooks. Making videos and writing blog posts has helped me understand these things better. If I can explain it to somebody through an article, it helps me write better documentation at work. If I can explain it well to somebody in a video, it helps me talk about it during a meeting. Building these site things has definitely helped me communicate better at work and understand technical stuff better as well. 

[00:26:36] JG: I want to put you to the test here. I keep seeing this thing, React Compiler, this phrase. You've made a bit of content on this. Can you tell us what is the React Compiler, and why would I care as a member of the Slack engineering team?

[00:26:49] SK: Oh, I love this question. I specifically or I personally am very excited about React Compiler. React Compiler is actually a plug-in that is introduced in the most recent React Conference, and the idea behind this plug-in is to auto-memorize code or auto-optimize your code. 

Why you may need it is because if you look at your code right now, you may see that it is super slow, or it may be having issues where you see the component rendering. What you do is you add a useMemo to it, or you add a useCallback to it, which is actually a good solution right now with the way that React has proposed it. You add useMemo to optimize any static values. Or you add useCallback to optimize any functions. 

The problem is that when we are looking at the app, it is something that we have to manually go and do. We have to know that this function could be a problem and then add a useMemo and check if that problem was actually solved. It's a bit of tweaking yourself and manually optimizing the app. With React Compiler, you don't have to do that anymore manually. React Compiler will actually go through your code, understand. It understands the rules of React and understands JavaScript, so it'll go through your code and memorize the values and the functions. It'll do that for you automatically. 

Why I like it a lot is because I've had so many situations where I'm going through or I'm building a component. This has happened when I was building a video recording feature at Slack. I was building this feature, and I saw that it was slow. There are multiple places of why a component could be slow. There's multiple reasons. Maybe your API is slow. Maybe your calculations are expensive. Maybe you are rendering too many times. You have to manually tweak each of these things and figure out why it could be slow. 

With compiler, the re-rendering bit is taken care by it, and the expensive calculations bit is taken care by it. Those are the two things that you don't need to worry about. For my app development, for my feature development, I had to go and put useMemo in all of my places, and then remove in some of the places, and then manually tweak it out. It was such a big headache to just figure out why the component was slow. 

[00:29:00] JG: Must have been bittersweet to see after you did all that work. Oh, hey. The next version of React will do that for me. 

[00:29:05] SK: Actually, I was pretty excited. I was like, "Thank God I don't have to do it again." 

[00:29:09] JG: By going through all that pain of adding and removing all the useMemos and callbacks, you probably gained a lot of good insight into the performance characteristics of your code and standard React code, yes?

[00:29:18] SK: Yes. I think adding useMemo and useCallback was super helpful because it made me understand which components or which functions were causing the re-render. One good thing about useCallback or actually one good thing about these functions is that it asks for dependency array. Then these components or these folks will be called again if anything in the dependency array changes. 

I think it sounds simple. But if you put an object with the dependency array, you may not know or you may not notice that that may be a very heavy object, which means it has a bunch of properties, and those properties could be pretty heavy themselves. Actually, maybe putting the object itself in the dependency array, and that object could be changing or re-rendering the entire callback function itself. 

By going through this exercise of having to manually add useCallbacks, which what I figured out was that one of my dependencies was actually pretty unstable. To remove that dependency as a complete object but to introduce it as a more stable version of that object or splitting the object down into a more stable version helped in optimizing the performance a lot. It was a big headache. It was a really great learning experience, but it took a lot of time. I wish I didn't have to do that. 

[00:30:39] JG: I think there are a lot of tasks in coding that are common things we have to do now that are getting automated. In the future, we may look back at them with sad fondness for the times we spent on them. 

[00:30:51] SK: Remember that time when I used to do it manually. I knew everything that needed to be done. Kids these days, blah, blah, blah, blah, blah. 

[00:30:58] JG: Yes. We'll be angry and the old man points a cloud meme. Cool. I want to move on a little bit to broader things. You do a lot. Are there any particular tips or tricks or tools you use to help yourself reduce admin or paperwork time for all your content creation and stuff at work?

[00:31:15] SK: One thing that I really love is creating videos and creating blog tutorials as well. But one of the biggest hurdles of creating a video is editing it. A lot of people have outsourced editing videos. I love having some help in editing because I feel like the biggest hurdle for me is not recording but actually the post-production part of it. 

This is why I love a tool that I have most recently started using which is the tool that we're using right now which is Riverside. Why I love this tool is because you get to upload a video, and this tool can show you where the pauses are. It can show you how to edit the videos by just looking at the transcript. You're not just watching the video. You can just edit the transcript, and the video gets edited automatically. 

It has made my life so much easier because now I can create a video. I can add chapters to it. I can add subtitles to it. It automatically gives me descriptions. It automatically creates these clips for me which I can upload as video shorts. My work has reduced to 10 minutes of just uploading in Riverside and letting AI do the job for me, instead of me having to manually watch the video and just write notes which would take two hours, and it would be such a painful process. I love this tool. If anybody is looking to make content using video content, I would highly recommend Riverside. 

[00:32:41] JG: Cool. We are not sponsored by Riverside at the moment. Maybe this will help. 

[00:32:45] SK: Maybe next time. 

[00:32:47] JG: Next time. There was an interesting overall theme that I love talking about in the industry which is that we're figuring out the common tasks, the manual stuff, let's say, adding a useMemo or making a video short, cutting out transcript pauses. A lot of that is powered by AI. Some of it also is not powered by AI. What is it about AI that you think means so many people are using it for so many different things, regardless of whether it's actually the right solution for that task?

[00:33:16] SK: Yes. I think one of the things that I find super fascinating about all of these AI tools is that it's helped as an assistant for you, and it's able to do these jobs that would take you so much longer like editing a video or creating chapters and things like that, which you would have to manually do. But AI is able to do it for you in a much shorter time, so you can now use that time to create more content or do something more productive. I love the fact that it's proving out to be this helpful assistant, and I love the tools that are making my job easier as well. 

Another example is how this app called Motion is able to automatically schedule time in your calendar. For example, if you're somebody whose goal is to create content three hours a week or go workout every day, you tell that to this app, which is Motion, and it's able to do that for you automatically and schedule time in your calendar. It's one less thing you have to worry about. This way, it's proving out to be this helpful assistant for you really. 

[00:34:15] JG: Are there any AI tools that you're particularly fond of for code or general development work?

[00:34:21] SK: I think a lot of people are super fond of GitHub Copilot, which I'm super excited about. For coding, ChatGPT, so helpful. One of the things that I love about ChatGPT is that when I'm battling with TypeScript and I'm like, "How? What? Why? Why can't I just use any?" I'll send this to ChatGPT. It'll tell me, "This is how you need to write your type." So easy, so much better. 

[00:34:45] JG: Fascinating. We've got only 5 or 10 minutes left, so I want to get a little more personal here. You're a big fan of dev jokes. Can you talk a little bit about why that is incredibly useful and powerful and awesome?

[00:34:59] SK: I love dev jokes. The reason I created these dev jokes is because I love nerdy jokes, and I love this pun-intended humor. I would share these dev jokes to my friend just through Instagram messages, and she'd be like, "Ha, ha, ha. You're so nerdy." I was like, "Wait, I'm sure there's a group of people who like nerdy jokes like this." I created this GitHub repository which is an open source repository. This is how I learned open source. This is how I contribute to open source. 

I created this GitHub repository, I added a README file. Every Hacktoberfest, I create this as kind of like a Hacktoberfest competition for folks to go and make a poll request and add their funniest dev jokes. I love it. There are so many great dev jokes in that repo. It's a community of an effort. 

[00:35:44] JG: Prove it. What's a good dev joke?

[00:35:47] SK: Okay. I have some dev jokes. 

[00:35:49] JG: Disappointed that you have to look this up. I would have thought you just have one at the ready. 

[00:35:52] SK: I have so many memorized. Okay. Who won the debate for the best name for loop variable?

[00:36:01] JG: Who?

[00:36:03] SK: I won. 

[00:36:06] JG: Nice. Good one. Wait, let's talk about the practical benefits of this dev joke repo because on top of being fun, there actually a lot of really cool useful things to it. You mentioned that this is how you got into open source. How does that work for someone? Or why would this be useful for someone who's trying to get into open source?

[00:36:22] SK: It's a very good introduction to open source. Why? Because, first of all, as an open source maintainer, I need to know how to create this repo so that it's easy for folks to contribute, which means I read a README file. I need a way to merge conflicts. I need some maintainers. I need to make sure that there are bots installed that can detect conflicts and that can auto-merge it and make it easy for me. 

As an open source maintainer, this was a very nice introduction. It's a very simple repo if you look at it. It's just like a README file, and then there's a bunch of image assets. From technical perspective, it's very simple, but it teaches the basics of open source. Then as a maintainer or as somebody who is contributing to this open source repo, it's a really nice way of adding your code and getting feedback on your code as well. 

It looks simple but really what it is is a markdown file. It helps to understand when multiple people are working on it what are some of the things that you need to make sure. For example, how do you organize your code? This is a huge markdown file, so where do you input your code? That's, I guess, same as where do you input your JavaScript or your React component in a huge file as well or in a huge repo as well.

It teaches you how to work with others and how to how to work in a repo that may not be actively looked at. You have to learn to be patient. Sometimes, your poll request may not be accepted, so it also teaches you how to take feedback as well. It looks pretty simple, but I think it's a really great introduction to open source. 

[00:37:56] JG: A lot of those skills are transferable. If I were running a team, I might require someone send a PR and get accepted to this dev jokes repo within their first month or two if possible. 

[00:38:05] SK: There you go. 

[00:38:06] JG: There's a broader thing here, too, right? That it can be very scary for people to enter the industry. It's serious. There are a lot of terms I get confusing or banded around that are hard to get onto for programming like loops and memoizing and all this. Anything that can make it a little more approachable is helpful for people, right?

[00:38:24] SK: Yes. When getting started with open source, we recommend people get started with documentation, which typically comes in README files. This repo is a README file as well. It's a simple markdown file. This is a simple yet fun introduction to open source. If somebody's looking to make contribution as to the documentation, this is a pretty nice way to understand how that process would work because you're making contributions to a README file, which is typically what the documentation would be in as well. 

[00:38:53] JG: Do you find that there is a noticeable difference in team experience for people who are new joining a team that has fun stuff like a dev jokes repo versus one that doesn't?

[00:39:03] SK: I think it makes people more approachable, and it makes people more empathetic. When they've done something that is for fun, they seem to be more excited about work and more excited about learning how to learn something new. I think building something for fun also shows that you're passionate about it outside of work as well, and you're not afraid to do something that's new or something that is new but something that is challenging. It also shows you that you're willing to learn and grow as well. I think it's also a transferable skill as well. When you work at fun projects outside of work, it shows your passion and excitement for tech. 

[00:39:44] JG: If I were the same new developer joining your team and I was suffering from imposter syndrome, feeling like I didn't belong or everyone else is way better than me, what could possibly be done on my ends? What are some of the strategies you would take to make me feel a little less impostery?

[00:40:01] SK: I think one of the things that when I mentor people and they share that they are suffering through imposter syndrome, one of the things that I love to share is that you're not alone in feeling like an imposter. 70% of the industry feels like an imposter, which means majority of us are feeling like an imposter all the time. 

One of the things that really helped for me when I was going through the same thing is my mentor told me that he was feeling like an imposter at the time. It just set this context. It just made me feel like - and I love this person. He's somebody that I respect a lot. I admire a lot. I felt like if somebody who I respect a lot and I admire a lot and I look up to is also feeling the same way. It means it's not just me. It's not just somebody who's junior, but somebody who's super senior can also feel this way. Somebody who's at the staff level also feels this way. It means it's a very common feeling to have. 

If somebody feels like an imposter, one of my first things to share with them is I feel this way as well, and it's not uncommon to feel this way. Second thing I love, I love when - I think it was from one of the conference talks I attended is if you're scared to do it, do it scared. It made a lot of impact on me because I feel like when I'm about to do something, it feels very scary. It feels very daunting. But just knowing that everybody's feeling this way and I'm not alone in feeling this way has helped a lot in setting that context. 

I think one of the big things about feeling an imposter is that, especially for me, what I felt is that you feel like an imposter because you feel like you don't have support. You don't have somebody to look up to, or you don't have resources when you need help. Helping somebody set up a mentorship or set up a mentor or set up somebody who can guide them technically or can walk them through the process of breaking a thing down and creating smaller stories or smaller task that they can easily achieve and incrementally make progress and gain confidence from it has been really helpful. 

To conclude, if somebody feels like an imposter, my three tips would be that, one, we all feel this way, and you're not alone in feeling like an imposter. Two is to know that even your mentors are feeling like an imposter, and people who you look up to are also feeling like an imposter. Three, to find a person who can walk through what you're feeling and what you're scared about, and break it down into smaller things so that you incrementally make progress and get more and more confident. 

You feel like an imposter because you feel you can't do it. But as you start getting more and more proof that you can do it, that feeling will start to fade away slowly, and it'll become easier to manage it. 

[00:42:46] JG: That's an excellent note to end the interview on, but instead we'll end on a bad joke. Why did the string and the number break up?

[00:42:54] SK: The string and the number break up. Their values didn't match. 

[00:42:59] JG: Close. They weren't each other's type. It's a TypeScript joke. Shruti, this has been absolutely phenomenal. Thank you so much for coming on. We talked about accessibility, front-end engineering, team practices, the new React Compiler stuff, imposter syndrome, all sorts of great things. If there is anything people wanted to ask you or if you just wanted to point people to where you are on the Internet, how could people find you?

[00:43:20] SK: You can find me on Twitter @shrutikapoor08. Or you can find me on my Discord as well which is bit.ly/shruti-discord. 

[00:43:29] JG: Awesome. Well, for Software Engineering Daily, this has been Shruti Kapoor and Josh Goldberg. Cheers, all. Have a good one. 

[END]