Josh Goldberg (8:11)

Excellent. So now you're a staff engineer at Slack. What does that mean?

Shruti Kapoor (8:16)

Okay, so 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. So when you start a huddle with two or more people, you will 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 artwork and I was a part of it. Right now I'm working in the Slack Kit team, which is actually the kind of like a design systems team. And 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.

Josh Goldberg (9:13)

So 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?

Shruti Kapoor (9:21)

Yeah, so 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. So we're using Typescript, React and then our style sheets are in less, I think front end at Slack. One of my favorite features of or like 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 kind of 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. So 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 and 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 and everything is synced automatically. So you really have to do nothing except just one line of code. And this developer experience makes it so easy to get code shipping fast and have your development set up like reduced to just a few minutes instead of having to pull down and do Node modules and set up. So 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.

Josh Goldberg (10:44)

That's great. So 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?

Shruti Kapoor (10:55)

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 GraphQL 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 like people who are super kind of focused on one tech and then that's the tech we adopt and 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. So that's definitely a big consideration in adopting a new tech.

Josh Goldberg (11:34)

So 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 the kind of the strategy you'd suggest I take to help the team evaluate whether it actually is the latest and greatest.

Shruti Kapoor (11:48)

Oh, that is a great question. So at Slack, one of the things we do is we are very prototype heavy. So the first thing that we'd check is or like, so, 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. We don't ask you, we build a prototype in that language. So, for example, if you were to adopt GraphQL would build like a prototype app in that. And then because Slack is a monolith, we don't really have kind of like this, like separate apps. Really, everything is kind of part of the same monolith. So even though you're building components, it's part of the same app. And so we think about, like, 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 like GraphQL, for example, and 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. So 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 kind of view from it and what are the kind of pros and cons for it. So 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?

Josh Goldberg (13:20)

Yeah, for a while, Slack was one of those apps where when people brought up Electron and 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. And 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 app accessible. Can you talk a little bit about how you've been able to do that?

Shruti Kapoor (13:50)

Yeah. You know, 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 kind of like an afterthought or just kind of like a hacky slap. Like we need to make sure that it's accessible so we don't have legal fines. And 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 through an accessibility audit.

Josh Goldberg (14:33)

So, Shruti, before we dive too deep into accessibility, let's cover what is accessibility?

Shruti Kapoor (14:39)

I love that question because it's such a wide scope of things that accessibility covers. So 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. And 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 sighted users, but also anybody who has other disabilities or like 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. So 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. So 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. And 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 sighted users, and so opening up your site to this new funnel or like this bigger funnel of people as well with disabilities.

Josh Goldberg (16:25)

So yeah, there are kind of multiple reasons why one might become accessible. There's the 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 and then there's also the financial reasoning. Right, so there are all three of these coming into play here.

Shruti Kapoor (16:45)

Yeah, definitely. And I think when people think of accessibility, they usually think of the moral reason, which is that we have to make it accessible because, you know, 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 like you are now opening up your funnel to more people and also the legal aspect that if you don't make it accessible, you are going to get sued and there's going to be fines.

Josh Goldberg (17:09)

So I love the old carrot and stick there.

Shruti Kapoor (17:13)

The stick, yeah.

Advertisement Voice (17:15)

Introducing height, the only autonomous project management tool. Backlog grooming, bug triage, keeping documentation up to date. Those aren't why you got into product building, right? Well, height handles all that grunt work for you. Using a first of its kind AI approach, height proactively takes care of time consuming workflows without you lifting a fingerprint. Height recognizes when you've agreed to trim, scope and handles, mapping the necessary edits back to your product brief. When new tickets are added to your backlog, height comes through them, adding feature tags, time estimates and more. And it's not just you. Everyone on your team manages projects, tracking updates, scoping work, balancing priorities. But whether or not your product succeeds shouldn't depend on project management. With height, autonomous workflows handle that mundane upkeep so your team can focus on building great products. If you're ready to stop managing projects, it's time for height Join the new era of product building where projects manage themselves. Visit Height app sedaily to get started.

Josh Goldberg (18:11)

So, 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?

Shruti Kapoor (18:26)

Right. So one of the things we do is we try not to act as like the, what is it called, role police or whatever. We try not to police you too much and so we kind of try to like gently nudge you in the right direction. So first of all, I think what makes Our job a lot easy is we have linting tools in place. So if you were to add a div as a button, the linter would complain. So it makes our job easier that we don't have to actually tell you what the problem is. And it comes with documentation and everything. So you know exactly what the problem. 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 kind of the process by which we educate people on why this may not be a right approach. So 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 like what the accessibility implications might be. So at this point our team goes through the design and the designer will usually the designer or the front end developer would usually walk us through the feature, talk about what it does and then we kind of have a discussion on if this is the button, then why do we need a div on it. So the front end developer would kind of talk about why they're using a div and then we would kind of do the job of explaining to them like this is the reason why we want to use a semantic button which is like the button HTML element itself instead of adding a roll of button to a div. So I talked about the linting tools, but we also have our Slack Kit design systems button itself. And this is an accessible component that we've built. So we'll nudge the folks to use an accessible component that we've built. And this is not, I'm saying accessible component, but it's just a design system component that we have. So 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. So in conclusion, if you were to use a div with the roll of button first, we would invite you to our office hours. Actually the linter itself would throw errors at you. And 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 like div of roll of button versus an Actual, but. And then we'll nudge you to use the button component itself that we have developed at Slack, which already has accessibility baked in.

Josh Goldberg (20:56)

How difficult is it to create a button component that's accessible in a design system?

Shruti Kapoor (21:01)

Yes. So 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 out 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. And 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. So 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. And I think that's just a 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.

Josh Goldberg (22:02)

Yeah, there are some things that you can lint for. Like 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?

Shruti Kapoor (22:24)

You know, that is a hard problem and it's a hard problem to solve as well, because, like, 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 slackit design system and add it to their design. So 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 kind of like 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. And at that point it is our job to kind of guide the team to make sure that the experience is accessible. So 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 kind of ensure that the components that are going out there are part of Slack Kit because we ensure that the designers are actually choosing components from the slackit design system itself. So 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.

Josh Goldberg (23:38)

You know, 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 step into the staff role? Is that something that happens as you get more and more towards the senior parts of your career?

Shruti Kapoor (24:11)

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, we're like a small team, we can't go and check every team's work. So it's become so important to kind of help people when they come ask for help. And it's also part of our team's requirements and team's goals as well. So I think when I was a junior engineer, I was working more independently and more on the stories that were given to me. So my job was to like deliver the story and call it a day. As I become more senior and step into a more kind of technical leadership role, my job is to enable others and to make sure that my, the need for me implementing something is reduced and I can help them develop it themselves and guide themselves. So my job really becomes more of a technical mentor than somebody who is actually implementing the code. So that could involve, you know, like 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. So I guess my job just becomes me kind of not doing the technical coding, but helping myself remove from the equation.

Josh Goldberg (25:31)

You're coding yourself and processing yourself out of a job, so to speak.

Shruti Kapoor (25:35)

Out of a job. Exactly, exactly. Thank you for putting it so succinctly. That is what I was trying to say.

Josh Goldberg (25:41)

Do you ever miss the days when you were just banging out code and features and fixes?

Shruti Kapoor (25:45)

I'm still doing a big part of that as well. Like just I was talking about the list that I'm implementing. It's still very technical. It's still a lot of feature development, a lot of writing code. I think sometimes being on the forefront like this, where you're just like helping and you're always available for help, can become really stressful because sometimes you may not know what the solution could be. But I think that's the reality of this accessibility world. Like the problems do not always have a clear solutions. So sometimes it's a lot about like talking through different options, doing a lot of user testing. We actually at Slack do a lot of user testing with real users who kind of give us a lot of feedback on what could be a better experience. And 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.

Josh Goldberg (26:36)

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?

Shruti Kapoor (26:53)

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. And if I can explain it to somebody through an article, it helps me write better documentation at work. And if I can explain it well to somebody in a video, it helps me talk about it during a meeting. So building these site things has definitely helped me communicate better at work and understand technical stuff better as well.

Josh Goldberg (27:32)

I want to put you to the test here. I keep seeing this thing, React Compiler, this phrase and 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.

Shruti Kapoor (27:44)

Team, I love this question. I personally am very excited about React Compiler. React Compiler is actually a plugin that is introduced in the most recent React conference and the idea behind this plugin is to auto memoize code or auto optimize your code and why you 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 kind of rendering. And so what you do is you add a use memo to it or you add a use callback to it, which is actually a good solution right now with React the way that reaction has kind of proposed it. Like you add use memo to optimize any static values, or you add use callback to optimize any functions. But 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. So it's a bit of like tweaking yourself and kind of like 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 will go through your code and memoize the values and the function. So it will do that for you automatically. Why I like it a lot is because I have had so many situations where I'm going through or like I'm building a component. And this has happened when I was building a video recording feature at Slack and I was building this feature and I saw that it was slow. And so 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. So you have to manually kind of 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. So those are the two things that you don't need to worry about. So for my app development, so like 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 like manually tweak it out. And it was so such a big headache to just figure out why the component was slow.

Josh Goldberg (29:57)

Must have been bittersweet to see after you did all that work. Oh hey, the next version of React will do that for me.

Shruti Kapoor (30:01)

Actually, I was pretty excited. I was like, thank God I don't have to do it again.

Josh Goldberg (30:05)

And by going through all that pain of adding and removing all the use memos and your callbacks, you probably gained a lot of Good insight into the performance characteristics of your code and standard react code.

Shruti Kapoor (30:14)

Yeah, yeah. I think adding usememo and usecallback was super helpful because it made me understand which components or like which functions were causing the rerender. And one good thing about use callback is actually one good thing about these functions is that it asks for a dependency array and then these components or like these folks will be called again if anything in the dependency array changes. So 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. So actually maybe putting the object itself in the dependency array and that object could be changing or like re rendering the entire callback function itself. So by going through this exercise of having to manually add use callbacks, which I've. What I figured out was that my. One of my dependencies was actually pretty unstable and to kind of remove that dependency as a complete object, but to introduce it as a more stable version of that object or like 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 and I wish I didn't have to do that.

Josh Goldberg (31:35)

I think there are a lot of tasks in coding that are common things we have to do now that are getting automated, and in the future we may look back at them with kind of sad fondness for the times we spent on them.

Shruti Kapoor (31:47)

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.

Josh Goldberg (31:54)

Yeah, we'll be angry. And you know, the old man points at cloud meme.

Advertisement Voice (32:00)

Cool.

Josh Goldberg (32:00)

I want to move on a little bit to kind of 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?

Shruti Kapoor (32:11)

So 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 and 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. And 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. And why I love this tool is because you get to upload a video, and this tool can show you where the pauses are, and it can show you how to kind of edit the videos by just looking at the transcript. So you're not just, like, watching the video. You can just edit the transcript and the video gets edited automatically. And 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. So my work has reduced to like 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. So I love this tool. If anybody is looking to make content using, like, video content, I would highly recommend Riverside.

Josh Goldberg (33:37)

Cool. We are not sponsored by Riverside at the moment. Maybe this will help.

Shruti Kapoor (33:42)

Maybe next time.

Josh Goldberg (33:44)

Next time. There's an interesting kind of 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 used memo or, you know, 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?

Shruti Kapoor (34:12)

Yeah, I think one of the things that I find super fascinating about all of these AI tools is that it's kind of helped as a. An assistant for you, and it's able to do these jobs that would take you so much longer, like editing a video or like 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. So 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. So, for example, if you're somebody whose goal is to create content three hours a week or like, go work out 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. So this way, it's proving out to be like this helpful assistant for you.

Advertisement Voice (35:10)

Really.

Josh Goldberg (35:11)

Are there any AI tools that you're particularly fond of for code or general development work?

Shruti Kapoor (35:17)

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? And I'll set this to send this to ChatGPT, it'll tell me, this is how you need to write your type. So easy, so much better.

Josh Goldberg (35:42)

Fascinating. We've got only five 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?

Shruti Kapoor (35:55)

So I love dev jokes. The reason I created these dev jokes is because I love nerdy jokes and I love this kind of like pun intended humor. And I would share this like dev jokes to my friend just through Instagram messages and she'd be like, hahaha, you're so nerd. You're so nerdy. And I was like, wait, I'm sure there's a group of people who like nerdy jokes like this. And so 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. So I created this GitHub repository, I added a readme file and every Hacktoberfest. I create this as a kind of like a Hacktoberfest competition for folks to go and make a pull request and add their funniest dev jokes. And I love it. There are so many great dev jokes in that repo and it's a community driven effort.

Josh Goldberg (36:41)

Prove it. What's a good dev joke?

Shruti Kapoor (36:43)

Huh? Okay, I have some dev jokes.

Josh Goldberg (36:45)

Disappointed that you have to look this up. I would have thought you'd just have one.

Shruti Kapoor (36:48)

You know, I have so many memorized. Okay, who won the debate for the best name for Loop variable?

Josh Goldberg (36:58)

Who?

Shruti Kapoor (36:59)

I won.

Josh Goldberg (37:02)

Nice. Good one. So wait, let's talk about the practical benefits of this dev joke repo. Because on top of being fun, there are actually a lot of really cool useful things to it. So you mentioned that this is how you got into open source. How does that work for someone? Like, why would this be useful for someone who's trying to get into open source?

Shruti Kapoor (37:19)

So 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 kind of 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 and I need to make sure that there are bots installed that can detect conflicts and they can auto merge it and make it easy for me. So 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. So from like technical perspective, it's very simple, but it teaches like 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, because it looks simple but really what it is is a markdown file. And so it helps to kind of understand when multiple people are working on it. What are some of the things that you need to make sure, like for example, how do you kind of organize your code? This is a huge markdown file. So where do you input your code? And that's I guess, same as, you know, where do you input your JavaScript comp. Like get react component in a huge file as well or in a huge report as well. So it kind of teaches you how to work with others and how to, how to work with. In a repo that may not be actively looked at. So you have to be, you have to learn to be patient. Sometimes your pull request may not be accepted. So it also teaches you how to take feedback as well. So it looks pretty simple, but I think it's a really great introduction to open source.

Josh Goldberg (38:52)

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.

Shruti Kapoor (39:01)

There you go.

Josh Goldberg (39:03)

There's a broader thing here too, right? That it can be very scary for people to enter the industry. Like it's serious. There are a lot of terms that get confusing or banded around that are, are hard to get onto for programming like loops and memoizing and all this. So anything that can make it a little more approachable is helpful for people, right?

Shruti Kapoor (39:20)

Yeah. When getting started with open source, we recommend people get started with documentation, which typically comes in readme files. So and this repo is a readme file as well. It's a simple markdown file. So this is a simple yet fun introduction to open source. And 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.

Josh Goldberg (39:50)

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?

Shruti Kapoor (40:00)

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 kind of 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. So it also shows you kind of that you're willing to learn and grow as well. So I think it's also kind of like a transferable skill as well. When you work at fun projects outside of work, it shows your passion and excitement for tech.

Josh Goldberg (40:42)

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 end? What are some of the strategies you would take to make me feel a little less impostery?

Shruti Kapoor (40:57)

I think one of the things that I, 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. And 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. And it just set this context. Like it just made me feel like, and I love this person. He's somebody that I respect a lot, I admire a lot. And I felt like if somebody who I respect a lot and I admire a lot and I look up to can 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. And so if somebody feels like an imposter, one of my first things to share with them is, like, I feel this way as well. And it's not uncommon to feel this way. Second thing I love, I loved when I think it was from one of the conference talks I attended, is if you're scared to do it, do it scared, you know? And 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 kind of feeling this way and I'm not alone in feeling this way has helped a lot in kind of setting that context. And 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. And so 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 tasks that they can easily achieve and incrementally kind of make progress and gain confidence from, it has been really helpful. So 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. And three, to find a person who can kind of walk through what you're feeling and what you're scared about and kind of break it down into smaller things so that you incrementally make progress and get more and more confident because 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 will become easier to manage it.

Josh Goldberg (43:43)

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?

Shruti Kapoor (43:50)

The string and the number break up. Their values didn't match close.

Josh Goldberg (43:55)

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?

Shruti Kapoor (44:16)

You can find me on Twitter hruthikapur08 or you can find me on my Discord as well, which is bitly Shruti Discord.

Josh Goldberg (44:25)

Awesome. Well, for Software Engineering Daily, this has been Shruti Kapoor and Josh Goldberg. Cheers all. Have a good one.