The Modern .NET Show

S08E02 - Compassionate Coding: Safia Abdalla's Insights on Empathy in Open-Source Development

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

S08E02 - Compassionate Coding: Safia Abdalla’s Insights on Empathy in Open-Source Development
The Modern .NET Show

S08E02 - Compassionate Coding: Safia Abdalla's Insights on Empathy in Open-Source Development

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

In this episode Safia Abdalla, one of the many Microsoft developers working on ASP .NET Core, discussed the importance of empathy, compassion, and psychological safety in open-source work. She emphasized that these skills are just as crucial for technical success as they are for social success. In her experience, good engineers create an environment where others feel empowered to contribute their ideas and implement them.

Safia highlighted the value of role models who excel at creating psychological safety in open-source spaces. These individuals uplift others’ ideas, make people feel heard and understood, and provide a sense of empowerment that encourages collaboration. She acknowledged that developing these skills takes practice and recognized that they will become increasingly important as technology evolves.

One key takeaway from Safia’s conversation is the need for developers to focus on interpersonal skills, such as listening, understanding, and crafting effective problem statements. These skills are essential for effective communication with colleagues, collaborators, and users of software products. By prioritizing these skills, developers can create a more positive and productive work environment.

Safia also discussed the importance of treating machine learning models like humans, particularly when it comes to training data and feedback loops. She noted that we often tend to treat LLMs differently than we treat our colleagues or co-workers, which can lead to suboptimal results. By acknowledging these differences and adapting our approach accordingly, we can improve our performance and create better outcomes.

Ultimately, Safia’s conversation emphasized the importance of creating a supportive and inclusive environment for open-source collaboration. By prioritizing empathy, compassion, and psychological safety, developers can foster a culture that encourages growth, innovation, and success. Her insights offer valuable guidance for anyone looking to improve their skills in these areas and create a positive impact in the open-source community.

Episode Transcription

I think, regardless of how technology evolves, it’s very important and us the most important thing is for us to be decent and understanding of each other and to be willing to like work towards a common goal.

- Safia Abdalla

Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I’m your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem.

Today, we’re joined by Safia Abdalla. Safia is one of the engineers at Microsoft who works on ASP .NET Core, meaning that most of her work is in the open. We talk about Safia’s journey in development, what it means to work entirely in the open, and what it’s like to read through and triage issues on the ASP .NET Core repo.

I have certain people in my open source career who I have met and interacted with on a number of different projects, And the ones that stand out as great mentors and role models for me were people who were so good at creating psychological safety in open source spaces so that people could present their ideas. And they were really good at uplifting other people’s ideas and pushing them further

- Safia Abdalla

We also talk about the importance of interpersonal skills in modern software engineering (whether you’re working in open source or not), psychological safety, and the importance of self-reflection in our day-to-day work.

Before we jump in, a quick reminder: if The Modern .NET Show has become part of your learning journey, please consider supporting us through Patreon or Buy Me A Coffee. Every contribution helps us continue bringing you these in-depth conversations with industry experts. You’ll find all the links in the show notes.

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : So, welcome to the show, Safia. There’s lots to talk about, but we’ll get to that in a minute. Welcome to the show.

Safia : Thank you so much for having me, Jamie. Eight years is very exciting. I’m super happy to be a part of season eight and super happy to be here chatting with you.

Jamie : Amazing. Thank you very much. Can you tell that I’m still really bad at doing intros eight years in? I just. I try to wing it and then just completely destroy everything. It all goes off off the guardrails and we end up with me just rambling. Just nonsense. It’s brilliant

Safia : It’s totally fine. It’s like a car. You just gotta wait for it to warm up, you know? I know you don’t have to do that anymore, but.

Jamie : So I thought you were gonna say it’s like a car, it crashes.

Safia : Straight to the catastrophic version. No, it’s a car. We’re going to warm it up and then we’re going to go on a wonderful scenic ride.

Jamie : That’s exactly it. That’s exactly it.

Safia : Yeah.

Jamie : So I guess whilst the car is warming up, Safia Would you mind giving the folks listening to the show a little bit of an intro to yourself? Like, I know you work at Microsoft, I know you do lots of ASP .NET stuff, or rather ASP. NET Core stuff and lots of. NET-y things, but that’s about as far as my knowledge goes. So I can’t really give you a better intro. I do apologize.

Safia : No, you’re totally good. You know, it’s so interesting because I was Thinking a little bit before we came on about how I would introduce myself, and this is the Modern. NET show, and obviously, I’m on the. NET team. I work a bit on ASP .NET Core and Aspire at the moment. But I feel like my identity or my like history as a programmer has started much before .NET. And I think one of the things that maybe people who are part of like the. NET ecosystem and whatnot might not know about me is that: gasp, I was actually previously for a very long time primarily a JavaScript and Python developer. I got my start in the world of tech at a young age, but I feel like I really kind of like cut my teeth into it at the start of my years in college, university, contributing to open source projects. And those open source projects were primarily Python and JavaScript. And so I worked in that space for a number of years up until actually I joined Microsoft and then I joined the. NET team about five years ago. So when I think about my identity as a programmer, it’s not so much centred on like . NET, but actually my experiences as an open source contributor and maintainer have been really foundational for me. Because that has kind of been the one consistent theme through a lot of the work that I’ve done in the past, gosh, almost decade. been primarily open source. And so that’s kind of one of the things that excites me about working on. NET in this particular moment and some of the other projects that I’ve worked on in the past. So I guess one way to introduce myself is: Safia, longtime open source contributor/slash maintainer, presently playing around in the. NET universe. Thank you for having me. But I’m really motivated primarily by the kind of ideas of building software in the open, collaborating with others, iterating on things in public spaces, public discourse about ideas and knowledge sharing. All of those are kind of my core values, and I happen to be bringing them to.

Jamie : NET at the moment. Right. I like that. You know, if it weren’t for closed source software, none of us would get paid. But we all… a whole bunch of us like to produce a whole… but like the world runs on open source software, right?

Safia : Let’s not right.

Jamie : Let’s not beat about the bush, right? It runs on open source software. There are lots of closed source bits that sit on top of it. But like sharing that knowledge and giving stuff away for free and collaborating in the open is one of the best ways to learn really quickly, I think, right? Because like, just go to GitHub and just type in a language name, and guess what? You’ve got a babillion repos that you can learn from, right? Right. What could be better? It’s all free. You don’t have to pay anyone. You don’t have to. I mean, yes, if you go to college or if you do some book learning, you’ll understand the why, but obviously, learning those soft skills. I do not like the term “soft skills,” but learning interpersonal skills, learning the language, but not just like, “this is an if statement, this is a for loop,” but like. The. NET way of writing. NET, or like I guess the better phrase would be the Pythonistic way to write Python One of the best ways to do that is just to look at how people are doing it, right?

Safia : Yeah. Oh gosh, there’s so many things in there that I want to like plus one. The first is I think what’s really great about open source in particular is you get exposed to a diversity of ideas. I find that if you work at a certain organization or even a certain team long enough, you kind of start to adopt the norms and the modes of thinking of that team. And that could be a good thing because that’s kind of like the cohesion that makes your engineering team or your immediate peer group really productive. But one of the things that’s kind of great about open source is there’s less of that inclination towards kind of a team developing a particular monoculture. Some projects or ecosystems can develop monocultures, but you can travel between projects and ecosystems and platforms to kind of get exposed to different ways that people are building things. So you can go to the Go universe or the Rust universe and take a look at what those folks are building. You can take a look at the Python ecosystem and say, “hey, how are they thinking about how package management should work?” or, “how are they thinking about how the API experience should work for their applications?” So that ability to be able to travel very easily between different areas, I think, is super valuable

Jamie : Yeah, 100%.

Safia : And then the other thing that I think is super compelling about open source and was really important for me as someone who was just getting into it when I was at university is it gave me access to such high-class developers and software engineers at a really critical stage in my kind of like education and learning as a software engineer. I’m not going to rag on university or college. You know, I went and got a computer science degree. I don’t think it’s completely necessary to do that in order to have a career in the industry, but the fact that I was able to supplement my formal education with interactions with professional software engineers who are really intelligent and passionate about what they worked on in a kind of real world environment where in open source, you’re like actually shipping software and people are actually using which if you’re in university, it might take you a while to get exposed to that reality of shipping software for actual users, which is a very big scary thing. And so getting exposure to that super early on. Was really key in my development and something that I always appreciate about open source.

Jamie : 1000% agree. There is a a world of difference between any kind of college or university or any kind of formal education task or assignment And, “here is a GitHub issue or a Jira ticket or something like that,” right? There is a world of difference between the two.

Safia : Yeah.

Jamie : And I think that it’s super important for folks to get experience with what the real world looks like as often as they can and as early as they can in their journey. I think Like when you’re if you go down the education, the formal education route, there’s only so much time that your teachers, lecturers, professors, whatever, can actually devote to teaching you the stuff, right? Because they’ve got to go do other things And so that becomes super difficult for them to cover everything. And then my own personal opinion I mean, I have a comp sci degree myself, right? But my own personal opinion of hiring someone with a computer science degree to do software development or software engineer is a little like getting someone with a PhD in fluid dynamics to fix the fuel injection system in your car, right? They can do it but it’s like a huge amount of other things that are going into their knowledge, if that makes sense, right? It’s one tiny piece of that person’s knowledge and experience. But that’s my own opinion. You know, everybody’s got their own opinion. It was very valuable to me, and I can jump between languages, and I can see at a glance how I think a system works. “Oh, right, that’s probably and I think that’s 0n, or that’s 01, or that’s this, that, and the other, and I could do that.” But does that help me every day when I’m pulling data out of a database and showing it on a form? Probably not.

Safia : Yeah. And you know, I concur. I think the ideal situation is to be in kind of like the best of both worlds. Have a little bit of formal education and then have kind of like that informal real-world experience as well. I think one of the things that formal education lacks that is super crucial in real-world environments is. Formulating problem statements, which I think is like 90% the work of an engineer, Which is you get kind of this abstract like business requirement or business goal, management wants this, customers want that. The infra team wants this, you get all of these kinds of requirements and expectations coming in, and you have to synthesize a problem statement that is clear, accounts for the various like perspectives and requirements that are coming into play, and sets up an engineering team to actually be able to execute and solve whatever like the problem or goal that you’re trying to achieve is. So it’s actually, I think, remembering all of my different experiences in open source, it’s often that challenge of like, “we roughly know the direction we want to go in, or we roughly know this like big technical problem that we want to solve. But from point A to point B is like a great big chasm.” And we need great engineers to be able to fill that chasm by creating kind of like that clarity or that like perfect description of what the problem is so that people can actually start to act on it. And so you don’t actually spend a lot of your time, I think, writing code, or you do some days, but most of it’s kind of that work of just formulating those problem statements that other people can take and get excited by or go and solve.

Jamie : Absolutely agree with you there. And I think in the era in which we find ourselves with things like LLM tools and coding agents and things. I think that that’s an even more important skill, because typing was never the problem. That’s how I put it to people, right? Typing has never really been part of the problem because I don’t think… I don’t know whether they’re in the same departments as you, but I know that there are a couple of amazing engineers at Microsoft who are completely blind, right? They don’t need to be able to type, right? Accessibility controls have always been there. It makes it really easy for or rather reduces the barrier to entry. I don’t know how easy it would be, but reduces the barrier to entry for folks with all sorts of different requirements and abilities and I’m probably using the wrong words there. I do apologize, everyone, but the typing, the actual production of the words in a file. That was never the problem. The problem was, “how do we solve this thing? You know, how do we get this group of people to figure out how to solve this problem?”

Safia : Yeah.

Jamie : Code is one way of solving the problem, right? You don’t always have to use code to solve the problem. If a spreadsheet works, then a spreadsheet it is, right?

Safia : Oh, yes, major plus one to that. I know it hurts for me to say as somebody who loves to write code, but it’s not always, you know, it’s not the hammer that you want to use to hit every nail. And so I think there is something to be said for not overfitting this one particular solution, coding to like every problem statement that comes your way. I wanted to jump off because you brought up the topic of LLMs and things like that. And the interesting side effect that I have seen in my own workflows as I’ve kind of started to incorporate LLMs and chatbots and things like that. And I’m curious to hear if you’ve felt the same difference is I have become so much more intentional about thinking about how I actually describe what a problem is. Like, I think I’ve always been a pretty good at like writing really clear GitHub issues. If you go on the ASP .NET Core GitHub, you will probably find a number of comments from me responding to people who have reported issues, and like the comments are multiple paragraphs long explaining exactly why something’s happening and different ways of possibly fixing it. And you know, I love to share details and knowledge about things. Like I think that’s another reason I get kind of geeked out about open source is there’s no barrier to you being able to share why you think something happens or how you think it should be solved. But more recently, just having to like interact with LLMs has forced me to really double down on that skill of like, am I doing a good job communicating what problems and issues are textually? If I am responding to somebody on GitHub, or if I’m putting a like a useful piece of documentation together, or you know, just creating a GitHub issue to like explain what a problem is. And so I’ve kind of enjoyed that side effect of using these tools of kind of becoming a lot more intentional about the way that I describe problems. And strengthening the language that I use to talk about, you know. X-bug or X-feature. So that’s I think that’s been a pretty neat thing.

Jamie : I mean, we’re going to end up agreeing with each other all day here, Safia, but you’re absolutely right. I feel like I’m more concise when I communicate with one of my co-pilots or Gen AI systems about how I want to approach something. Even if it’s just, “I’ve had this crazy idea, help me just to sort of bounce these ideas backwards and forwards. We’re not going to write any code. I just like I want to make Uber but for, you know, oranges” or something like that, right?

Safia : How do I do that?

Jamie : Just going through that process, I think it makes me feel like I’m being more concise way better than I’m doing right now. And then the double whammy being that then I can bring that to, like you said, how I interact with other people, like in open source things or in my client work or you know, even just like communicating with folks at home. You know, I’ve noticed that over the past few years, I’ve started to have to say, “no, I’m sorry, let me just be clearer. What I meant was X, Y, and Z.” And I feel like, and this might be recency bias, it might be some nonsense about maybe I’m just pretending, but like I don’t feel like I need to do that as much. I feel like I’m a little clearer every now and again. And I totally blame, in inverted commas, LLM’s generative AI for that because It doesn’t know any of the context around what I want to do. All it really knows is what I tell it. And I mean, we’ve known that for years. That’s what computers do, right? They only know what we tell them. But for some reason, having some kind of like a chat interface makes it more obvious to me that like I need to be more intentional with my language. And it’s made I feel like it’s made me a better person.

Safia : Yeah. It’s so interesting because I feel like it’s brought the same level of intentionality that we would have around computer language syntax to natural language syntax. And there’s various amounts of non-determinism in these LLM systems. So to some extent, the same natural language syntax might bring you different responses. But I think it kind of forces that same focus on like, “how am I structuring what details are actually important for a given like problem that I’m trying to describe? What pre-requirements are actually important?” Like, I think it’s just It’s so fascinating how putting this like natural language-based interaction model on the side of your editor, or you know in another window on one of your monitors can influence your your workflows or the way that you interact with your communication patterns so much. It’s kind of it’ll be interesting to see how that evolves long term as these tools change and the way that we interact with them does.

Jamie : Yeah, like as as maybe as context windows change and grow, or maybe as the ability to pull more files in as like a to help with with with that context. You know, so like a copilot in VS Code, right? I can say, “I’m having a problem with this file” and then sort of attach, as it were, the file That I’m having a problem with, and say, “I think the problem is between these three lines,” and then have my copilot or my LLM, whatever Help me figure out that problem, how much information to give it. And I personally would love to see a correlation study between and I don’t think it could possibly be done because we’re way too far past it now, but like how people used to start their debugging journey five years ago, ten years ago, versus how they debug now, right? Because my thing throughout my career, I’ve noticed that at the very start, it feels like juniors have problem figuring out, “what does this compiler error ah message actually mean,”" even though we’re really lucky with .NET and JavaScript these days, and Python these days, it will literally say, “this line, this column, this character right here. This is the problem right here.” And I found I felt like lots of people had trouble first grokking those the first time that they saw them. I mean, it’s easy for me to say, “oh, yeah, it just says that, look, line seven of this file.” But that’s because I know what I’m looking at, right? But then it was pointed out to me today, because I was using one of the LLM tools, that just watching it do its thinking process you can learn a whole bunch more. So, I would be, I would love to hear about like juniors and people first learning how to do this If they are watching the LLM, watching their copilot, watching whatever they’re using, tell them, oh, right, perfect. Now I know the problem. It’s on this line with this thing. Let me just double check. And it goes and double checks and runs a tool And it obviously this requires an agentic workflow, but it’ll go run like a git diff. Yep, yep, that happened in this commit and it happened over here, and this is why like watching it think that and pull all of this context out. I really hope that those who are early in their journeys or folks who are new to languages and techniques and tools and frameworks can then use that as like a, “wow, this is how perhaps an engineer would look at this and work their way through it.”

Safia : Yeah.

Jamie : I feel like it’s a fantastic learning tool, not just a solve the problem, but show me how.

Safia : Yeah, absolutely. And it’s so interesting that you’ve kind of brought up using some of these things as learning tools for junior engineers, because I think one of the things that I envy a little bit about people who are maybe starting their careers or starting to dabble in the industry now. Is that back when I was a young one It’s really challenging for you as a junior engineer to seek out help or ask a question to someone more senior on the team if you like need guidance or direction. Some juniors are really lucky to be on teams where their senior engineers are kind and approachable and understanding. But I mentor a number of junior engineers who share with me that they struggle to figure out how to connect with senior engineers. They feel like senior engineers don’t, you know, remember or understand the challenges they’re going through. They might feel like their responses are like dismissive or they’re just unapproachable, which is totally a thing that someone new in the industry might experience. I think one of the interesting things about having some of these agents is you have kind of have a trusted, generally judgment free counterpart to flesh out or ask questions to as a junior. So that when you kind of do approach someone more senior on your team for guidance, it’s a little bit more practised and you kind of established comfort having some sort of back and forth discourse. And you know, obviously, you have to, as a junior, you have to be able to like verify the results that you get from your interactions with the chat bot or whatever. But I kind of just like it as a learning tool for some juniors who get thrown into these environments where you’ve got tons of new code and senior engineers who are super busy with things and, like, you might feel like they don’t have time for you. And it’s a really hard part of going into the industry to figure out, “how do I make progress and establish knowledge and authority and just experience in an area when you know I know nothing, and maybe my formal education didn’t prepare me 100% for Some of the things I’m dealing with now.”" So, yeah, I’ve been guiding a few of my mentees through: hey, here’s this question that you need help from a senior engineer about. Maybe you’re not at a position where you’re comfortable just approaching this person and getting help directly. Here’s kind of some like precursor interactions you can have to build familiarity with whatever question you’re trying to pose. So that when you do go up to the senior engineer or whoever it is on your team, there’s kind of a little bit more practice and comfort there. So I think that’s another kind of like interesting side effect of them as a learning tool, particularly for people who are new to the industry?

Jamie : Oh, yeah, absolutely. I like I remember when I started, first job I ever got, getting started, getting onboarded, figuring out what the code was, what the tools were, or like we used some kind of SVN system where there was like Mercury SVN or something like that, right? It was named after a planet. I remember that, but it doesn’t really matter. But it like going from you know university, college, school, that kind of place where everything is provided for you and you don’t have to worry about it. All the training wheels are there. We’re doing you know, relatively simple projects. Yes, we’re pushing you, but actually don’t worry about using git, don’t worry about using best practices, just solve show me that you can solve the problem. of you know how to do bubble sort or something like that. Going from that into, oh my goodness, this is an enterprise and the wheels are spinning and I don’t know where you know what’s going on.

Safia : Yeah.

Jamie : That is a hard enough step as it is. My feeling is that it’s getting easier because I feel like the idea of having knowledge silos is slowly being pushed out the door by a lot of companies. It’s taking a long time But that’s being pushed out of the companies. And then with your LLMs, your co pilots, your whatever, your AI systems, hook them up to what used to be the knowledge silos, which is your internal wikis or your documentation. Guess what? You’ve got your onboarding right there, right? You can actually have an onboarding LLM, an onboarding bot. I don’t know, right? That would you know, that’s kind of like that feels like that’s the future. And then maybe someone can then ease their way in without having to go, “oh my goodness, I don’t want to ask the senior person this question because it’ll make me feel like I’m really stupid and I want to show them that I really want to know what to do when I don’t know what to do. How do I do it? Safia, how do I do it?”" You don’t have to worry about that, right?

Safia : Yes, absolutely. You know, it’s so interesting. We’re talking about our experiences as junior engineers and kind of how, how difficult that process can be. I feel like I have to share a funny story about a junior engineer moment for me that always stands out. And I think it kind of reflects in hindsight how I’ve grown as a engineer slash developer over the past decade and some of the things I think are like important strengths to have as like you progress in your career Okay, so story time, Jamie. This was, I think, my second engineering internship that I had ever had, and it was in a financial management startup. It had kind of like a really interesting setup for how the product was developed and shipped to customers. But the key bit is that I would have not been able to figure out anything about how we deploy to production from like any publicly available sources. There was like sort of like this like internal proprietary, like, this is how we deploy our stuff to production or to customers. So, I am supposed to be working on a feature and I’m happily developing la la la la. You know, actually implementing it is pretty easy for me I think it was like Python or something. And I needed to test it in a real world environment. So I needed to go and push the change to my local like dev staging environment. They kind of had it set up To where each engineer on the team had a staging environment target that they would deploy to that was their own, and you can kind of use it to test your feature branches. Jamie, tell me why, instead of pushing my feature to my specific staging environment I push it to production.

Jamie : Oh no.

Safia : Oh my gosh. I push it to production. First of all, why that system was built to make it so easy to push to production? Is like, you know. The second most stressful thing is this feature I was working on actually happened to kind of be like a big feature that they were gonna be intentional about pushing and they had like a whole like marketing and PR moment around it and whatever. So I pushed to production, and I’m like anxiously trying to figure out how do I roll back. They didn’t really have a good experience for rolling back production deployments in this. And I’m like freaking out. And I think it’s like Tuesday evening that I have like made this mistake. I double down on this by like not telling anyone that I made the mistake because I was like, “oh, I think I can fix it. I think I can fix it before anyone realizes that I’ve deployed it to production.”

Jamie : Oops.

Safia : I’ll eventually figure out how to do the rollback and what have you. I did not figure it out in time. And I think I had literally stepped out to, like, get lunch for five minutes, and I come back, and there is a post-it note from the CTO on my monitor to come talk to him. And he was like super understanding. Like, he was stern about it. He, like, appropriately expressed the severity of this mistake that I had made to me. But, you know, he wasn’t. If I can curse, he wasn’t an asshole about it, which was nice. But I bring up that story often when I talk about my journey as an engineer. Because, first of all, Getting exposure to like deployment infrastructure is probably like the hardest thing to go through as like a new developer. I think it goes back to what we were talking about earlier: like, there’s writing code and then there’s shipping software. And Dealing with deployment infrastructure and understanding, like, “oh, there’s different deployment environments, and like things go through progressions from like staging to pre-prod, to production or whatever tier system your organization has set up. And there’s like rollbacks, and you have to do rolling deployments. And holy cow,” that’s like a whole thing that no one ever tells you, right? They just tell you that, like, “hey, there’s There’s these algorithms, go figure them out. Computers do things,” and no one tells you how you get like the software you write sometimes to everybody in the world. And so. That was kind of my first tiptoe, and me getting burned a little bit by how difficult infrastructure can be to understand. And it’s completely separate from, you know, implementing the feature, because I was saying Implementing the feature, testing it locally, super easy for me. Dealing with the deployment infra was super scary.

And then I think it’s just like another interpersonal thing I learned is like Yeah, people people make mistakes. I really like beat myself up at the time about how I made such an awfully stupid mistake. To deploy to production, I was just in my feelings. I think I might have cried that day. I was just like, gosh, I’m not cut out for this industry at all. And then, you know 10 years later, like this accidentally deploying to production or accidentally deploying something to an environment that it shouldn’t be in has probably caused so many outages, like so many, so many engineers of varying levels of experience do that. And it’s not really an indictment of the engineer. It’s an indictment of the infrastructure that is set up to support deployment. And then the last thing, to tie it back to like the onboarding/slash LLM thing: God, I would have killed to have an agent or some sort of chat bot that I could talk to because I was so, you know anxious about having to admit this mistake and trying to figure out this like deployment infrastructure, I could have probably maybe avoided the problem had I had better access to documentation or just guidance on like how this how this deployment stuff works. So yeah, that was that’s my fun engineering intern story from, I think, this is almost 11 years ago now. So a lot’s changed.

Jamie : That’s a super interesting sorry. Thank you for sharing. But also, I feel like it’s something that I feel like folks should not necessarily go through with the emotional side of it, but like making a mistake, but having the safety net there of “you’ve made the mistake, don’t worry.” We unfortunately, in your case, they didn’t catch it, but You know, you’ve made a mistake. Let’s okay, now you’ve made the mistake. Let’s carry on, right? You’re not a bad person, you’re not a horrible person, you’re not a bad engineer. It’s actually, you know, you’ve exposed a gap in our system, right? Our system shouldn’t have allowed you to push directly to production. How do we fix that? For someone else, right? And that goes into the whole psychological safety stuff around interpersonal relationships, and work relationships, and that kind of thing. And how do you get engineers to work together That psychological safety of being able to go, “actually, I think I just messed up. How do I fix it? Can I have some help?” Which, as a junior, maybe your first job, or like you said, maybe first or second internship. I can’t even imagine how that feels to actually have to go, “oh, dang it, I’ve broken something and I don’t know how to fix it. Please help,” right?

I mean, You shared a story, I’ll share a story, right? There was a time when I remember this very, very distinctly. And this wasn’t an internship, this was a couple of years into my journey. So I’ve graduated, I’ve gone through a couple of different jobs, growing as I’ve gone. And I remember working on this system where the customer had asked, “can you just check some data in the database?” So I’m like, okay, cool. I’m on a call with them. I pull up SQL Server Management Studio. I start doing selects left, right and center Yep, cool. I can see the issue with the database. I make loads of notes. Excellent. “I’ll call you back when I’ve finished and I’ve fixed it.” Click, put down the phone. Start typing out a query, and I’m like, “hmm, maybe this will work. I’ll just run it.” And then, you know, a whole bunch of stuff happened that I didn’t see. And then suddenly I felt really ill and had to rush off home. I was like, no, this is no good. Then the next day that I came into work, there’s a little post-it note on my computer saying, “learn how to use transactions, please.” Oh, right, okay. But from that day onwards, right, if I’m ever interacting with any kind of database, I figure out how to do a transaction first. So begin transaction, rollback transaction before I’ve even written anything else. That way, if I run it. And if it’s syntactically correct, it’s never going to affect the database. And then I start with my where first. So I go from instead of doing select from or drop from or whatever, start with the where. Grab this table. “From this table, do this thing, right?” And do it in my head that way. That way, I can’t accidentally drop all of the rows, or drop a table, or delete everything everywhere. I can just do like you know, begin like if I’m in SQL, begin transaction, rollback transaction, from table T where id = 7, it won’t run until I do the select or the delete or the update. But that way I know that even if I hit that F5 or I hit Control T or whatever it is that makes it run, I can’t break it. Because even if it does somehow get to running, it just immediately rolls back Had I not made that silly mistake, I wouldn’t necessarily know about transactions, right?

Safia : Yeah. Trial by fire.

Jamie : That’s it. And because I had the safety net of someone stepping in and fixing my dumb mistake afterwards I could then use that as a learning experience. And I think that’s a super important thing for folks to realize is that, you know, when you were learning to walk, okay, right, that’s probably a bad example. But like, yeah, no, we’ll use it still. For those who have the ability to walk, I apologize. For those who have the ability to walk, when you were learning to walk, you fell on your butt a whole bunch of times. At no point did you think, “I can’t do this, I’ll just stop.” No, you got straight back up and did it again, and carried on walking till you fell over, and then you got up again and carried on walking. You don’t It’s fine. Everybody makes mistakes. We just need the safety net around us so that if we do fall, people will help us out. And I feel like with all of the tools we have in place now, we have the ability to make that so much better for those around us, right?

Safia : Yeah, absolutely. And you know, I wanted to connect this to something else because I think I mentioned that I’m currently playing around in the .NET space, but open source is one of the things that I’ve kind of been active in for a number, number of years I think another area that’s been a consistent theme for me is working in the developer tooling and the developer technology space, even prior to working on ASP .NET Core and. NET. A lot of the open source projects that I worked on were, you know, by virtue of them being open source projects, primarily aimed at a developer audience And I think one of the things that I have really tried to keep as a principle in my own interactions as an engineer is to be really mindful with the way that I interact with my developer tools. And when I experience a little bit of friction in the way that a tool is designed or something that I built is designed, trying to be intentional about like taking that friction and figuring out, like, how can the tool be made better?

So, you know, we were talking a little bit earlier: like, “hey, maybe your deployment infrastructure or tooling should make it very difficult for somebody to push to production or graduate something from staging to production without any additional checks.” The same if I ever like use an API somewhere and I’m like, “oh, this API is kind of rough, or I’m struggling to figure out what parameters I should give to what and how I should structure this API and kind of a larger set of calls.” Really, kind of internalizing that feeling of pain and then turning it into a productive outlet, either by making that API change or building a tool that improves it, et cetera, et cetera. So, I think that’s one of the things that I really enjoy about being a developer who works on developer tools and technology is that you are uniquely empowered to solve the problems. And then, if you kind of maintain your empathy and awareness of what you’re going through, you’re also uniquely empowered to see the problems and formulate the problem statements really well about what you’re going through.

Full circle moment back to our discussion about problem statements and how important it is to describe them. But yeah, I think all of that is kind of one of the funner parts of working in the developer tech space

Jamie : I will have to take your word for that because I’ve never worked in the developer tool set or frameworks or I mean, I’m an app and MVP for DevTech, but that doesn’t mean I worked in DevTech, but I’ve never worked in that space.

So, what about if we open that up a little bit? You’ve talked a little bit about the working in the open, working on GitHub, leaving lots of documentation, helping folks learn by responding to their issues, their pull requests and things like that. What is that like as a I mean, you’ve kind of just said it’s great because you feel empowered to do that. But like, what is that like on a day-to-day basis, right? So maybe we’ll use one of the .NET things that you work on As an example, right? How does that work as a as a as a journey for yourself, right? What does that look like?

Safia : Yeah. I guess we can talk a little bit about ASP .NET Core.

Jamie : Yes.

Safia : Since that’s where I tend to play and probably a lot of your listeners are or users of it or working in the space.

I think one of the interesting things, one of the hardest things to do on any open source project, ASP .NET Core in particular for me now, because that’s what I tend to play in the most, is: keeping up with issue triage. Keeping up with issue triage is a really hard thing to do because I have kind of this philosophy around issue triage where I focus over on quality over quantity. So my goal when I set aside some time to go look at user reported issues on GitHub is not necessarily to like close as many issues as possible, or tag things with all of the right labels, or like stick them in the backlog, or anything like that. My goal is really to kind of drive things to a quality resolution. And that is something that takes a huge amount of like mental and time investment, too. Because the first is you get a bug report from somebody, and the bug report is going to have varying levels of detail and specificity. Some people submit really great bug reports that have complete repros, the exceptions, the stack trace, and they really set you up for success with the amount of information they give you about the issue that they’re running into. Some bug reports. are not so great. They might not have a repro. They might mostly be an expression of frustration over a problem than an actual like description of a problem. And you kind of have to take both spectrums of issues like in stride and process them.

And so, you know, for somebody who’s like really frustrated with a problem and like You know, maybe they’re not able to provide a full-fledged repro because they don’t actually have an understanding of the system to see like where the issue is coming from. They’re just observing a behaviour that does not make sense to them And so their reality does not meet their expectations, and that causes frustration. And you kind of have to start from that vague set of details and then drill further, kind of understand the exact problem they’re describing. Figure out what their workarounds are for them or how it can be solved in the system or not, etc. etc. And you know, for on the other spectrum, if you get a really good quality bug report, sometimes you can just you can be, you can pretend to be the LLM that has just received a really nice prompt from somebody, and you can go solve it. So for me, sometimes the hardest part and the thing that’s hardest to dedicate time to is like that issue triage of like synthesizing all of these bug reports that are coming in into something that is actionable and quality and making people feel like, “it might have taken me a while to post my like three paragraph response to your bug report, but that’s because I spent a little bit of time really trying to understand what you were getting at. Or, what have you."

So, I don’t know if that was a good answer to your question, but I feel like one, and I actually like this aspect of open source is: people will come at you with all sorts of feedback, and some of it’s legitimate. Some of it you might not think is legitimate, they might think it’s legitimate. And you just have to process so many inputs about how people feel the system you’ve built works. And then you have to change that input to something actionable. And so like day-to-day, if I’m doing triage, like that’s one of the interesting things is processing all that user signal into something like actionable that aligns with like the opinions of the framework.

How did you feel about that? Was that kind of where you were heading with that question?

Jamie : Yeah, yeah, that was where I was heading with it. I do apologize, I did a really… I actually wrote down in my notes as you were talking, “wow, I did a really bad job of asking that question.”

Safia : No, it’s totally okay.

Jamie : You were able to understand what I mean. So, maybe a half point for me. I don’t know. But yeah, so personally, I’ve always told developers that I’ve worked with, engineers that I’ve worked with, that regardless of who it is that’s communicating frustration with you, you need to have that empathy. You need to be able to understand The empathy, the sympathy, compassion, all of that to be able to understand, “what is it this person is trying to achieve and how do I help them to achieve that?”" And sometimes that is, “hey, that really sucks that that happened. Let me look into this for you. And here’s,” you know, a as you said, maybe a three paragraph version of what I think the problem is. perhaps, and I will look into it in a moment. I’m just firing up the editor. And sometimes it’s no, what you said was you forked the repo, you deleted the code and then you hit build and it didn’t build. Because there’s no code there. Maybe there’s something deeper there, right? And it’s everywhere along that spectrum. And I’ve always tried to tell the engineers that I’m working alongside of, whether I’m mentoring them or not. That, like, whoever it is that’s complaining at you, they are paying your mortgage, right? They are paying for your lifestyle. They paid for your last coffee, right? So do them the solid of saying, “I totally hear you, I get where you’re coming from, let me have a look.”" And rather than saying, “you’re a stupid user, that’s not how it’s supposed to be.” Maybe you’re not supposed to use it that way, but maybe they found a reason that they have to do it that way. Well, okay, then maybe I’ll try and help you out, right?

And I wonder like how Is that is that well, I guess it is, but I’m going to ask whether it is or not. Is that draining on a daily basis? Like, “no, we solved this, it’s in the documentation, go read it.” Like, should we have an LLM that makes that easier to do? All of that triaging that just says, “no, this is a common issue, go read the documentation.” Or should we always have humans say something like, “that’s that sucks? I hear you, but please go read docs.”

Safia : Yeah. You know, it’s so interesting that you bring that up because, well, to answer the question, yes, it is draining. And I think for a large majority of open source maintainers, particularly those who do not have the ability to have the time that they work on open source be supported by a corporation. I’m going to like privilege check myself here. and say that you know in like the decade plus time I’ve spent in open source, there have been time periods where I have done open source in my spare time on paid labour to the world. And there have been times where I have done open source work that has been supported by some sort of like financial benefactor. And those are completely different experiences. I kind of want to call that out of like dealing with issue triage when I was doing open source unpaid was a completely different dynamic than in my current position where that open source work is funded. And I think we can have an interesting conversation about funding for open source and all of that fun stuff.

But Regardless of whether you’re paid for it or not, it is a very emotionally draining thing to have to deal with issue triage. Again, we talked about the spread in the quality of issues. There’s also degrees in the graciousness and the like kindness of people who are reporting the issues. I think many open source maintainers will probably agree that some people can get rather antagonistic and frustrated when things don’t work the way that they expect, and that frustration can kind of be channelled in unhealthy directions. So, yes, emotionally draining, particularly if you are in a position where that emotional labour that you are contributing is uncompensated in every sense.

I guess the other question is like, how much can automation help with this? And I’ve in the various open source projects I’ve worked on, there have been various degrees of automation that have been incorporated into the issue triage process. So, there have been projects where we had automation that would look at every new issue that came in on behalf of the maintainer team And it would kind of tell somebody, “hey, we saw you filed an issue. Check that you’ve got a repro. Check that you’ve given a stack trace.” Like do the bookkeeping around figuring out has somebody created a quality issue so that when a human comes in to examine it, They have all of the necessary information to be able to make a decision on that. I think lots of open source projects have some kind of infrastructure like this set up, and people seem generally fine with it. There’s also infrastructure and automation that will like. you know, tag and label things or immediately backlog them or immediately put them in categories. And people are fine with that. I’m really curious to see where the LLM space comes in to see if there is tooling that can kind of maybe take it further and provide you with the guidance that says, “hey, we saw you filed this issue. We’re able to figure out that problem is actually something that’s documented. You need to write this code. Here’s the pointer in the docs,” and all of that can be done without a human in the loop. I think there are legitimate cases for that.

I will say there are some issues that people file where human interaction is really important to get at a problem statement that is like very clear and well specified, or just to kind of lend the person who is reporting the issue or more specifically sometimes proposing a feature or design, like the time and reciprocation that they deserve for it. So I think there are cases where automation has been used in the issue triage space in the past for open source. There are places to take it further with LLMs. But I think what it’s just the most important things for me about open source is there is that like human-to-human exchange of ideas. Embracing the diversity of someone’s perspective and what they bring, and seeing if, in the back and forth, we can synthesize an approach that is maybe better than what we would have both come up with independently. So yes, I think automation can help But certain things just, we just need people to do the kind of idea exchange and the talking.

You know that moment when a technical concept finally clicks? That's what we're all about here at The Modern .NET Show.

We can stay independent thanks to listeners like you. If you've learned something valuable from the show, please consider joining our Patreon or BuyMeACoffee. You'll find links in the show notes.

We're a listener supported and (at times) ad supported production. So every bit of support that you can give makes a difference.

Thank you.

Jamie : I like the direction you went in there, that to sort of repeat what you were saying, that automation can be useful in that sort of categorization. But actually speaking to a human and saying, “hey, fellow human, I’m having a problem. Can you please help me?” I mean, anyone who’s ever had to call use any kind of phone system in the last maybe three years. You know, yelling into the phone, “speak to a human, speak to a human,”" right? Or just mashing the buttons to try and get through the uh, you know, “our new options are now changed. You used to press one, but now you’ve got to listen to all of the options and then press nine because the last one is the most common feature.” And can you can you tell I’m getting a bit uh antsy about that? That’s it just it yeah riles me up anyway. But yes, um, getting to a human is the super most important thing

Safia : I was going to bring up that exact phone system analogy and you know, just echo: hey, we all experience frustration with dealing with our bank or internet provider or whatever. So Back to the empathy thing, I think it’s a tricky balance of like keeping the empathy and making sure that technology always has a face to it. And there’s a sense that when you’re interacting with ASP .NET Core, or you’re interacting with .NE, or anything, like there is a person, or there are groups of people who are working in this technology who do care about your experience being better. And I think that is the value that you bring when you interact with somebody personally is people who work on open source do care about the thing and they want you to have a better experience. And that’s why someone is taking the time to kind of have this discussion with you and kind of try and really understand your point of view. Yeah, I think to go back to the earlier point I was having, it’s that sense of like understanding that I think makes open source so powerful because you kind of have the ability to exchange these ideas in a way that’s like really unrestricted and really hone in on those things.

Jamie : And I guess you get more direct communication with the consumers of the thing that you are making if you are open source than you could possibly ever get if you are closed, right?

Safia : Yes, plus one. I am so glad you brought this up because I think this is another thing that I’ve really enjoyed about my decade plus working in open source is: get the chance to talk to the people who are actually using the code I write, like in a very literal and direct sense. And I have had job experiences in the past where I’ve worked on, you know, like formal SaaS software or products that were shipped to consumers where I never really directly interacted with the customers. They maybe interacted with a support team, and the support team would only come to me for certain things, or, you know, there was kind of like layers of support or product management between you and the customer. One of the things I love about open source and developer tooling in particular is those barriers just don’t exist. It’s like developers talking to developers about problems that we can kind of understand. And that’s like a really unique and fun thing to be able to do when you work in the open source developer tooling space. So, yeah, I always try and remind myself and be grateful whenever I am interacting with a customer or anything like that. I’m like, “this is actually pretty freaking cool that someone is able to engage with me with this level of detail about this feature that I built or something like that.” It’s like, “hey. People do actually use the code I write. That’s kind of intense and scary.”

Jamie : Oh, yeah, absolutely. I mean, I. create a very small open source project myself. But interacting with the folks who use it, it helps me to be a better engineer, I think. Because like being able to understand like I created the thing for the one problem I wanted to solve, right? And it was a very small niche problem, but I can see how other people they’re not using it in that way. And so then I have to really change the way that I think about it, change the way I’ve architected it, change the way that it’s presented, maybe the API space, that kind of thing.

And I think there’s there’s something that I don’t think you’ve actually explicitly said, but I think it’s worth say one of us saying it. There’s a there’s a brilliant thing by Bréne Brown And she says that it is much better to go through life assuming that everyone is trying their hardest than it is the opposite And I think that is like the root of compassion, right? “I understand that you are trying your hardest to help me, and so I will change the way that I interact with you in an effort to maybe help you, to help me.” Maybe that’s what’s missing in a lot of a lot of discourse.

But I really do like the idea of being able to directly interact with the people that are using what you’re building. Like most of the most of the stuff that I’ve built have been productized. So like you in your earlier parts of your career, I never spoke to the people who used The things that I make. But speaking to the user directly, speaking to the consumer, whatever word you want to use, it’s a completely different ballgame, right? You’re like, no, you’re a techie, I’m a techie. Let’s figure this out. It’s amazing.

Safia : And I think I’ll also plus one to that and add that it’s also about really listening and understanding. And I think that can be a very challenging thing sometimes when Somebody presents you a view of the tool or the API that you have presented or delivered, but it’s kind of opposing to your own, or they are presenting you with like a scenario that you’re trying, they’re trying to do, and you’re just like, “I don’t get it. Why are you doing this?” And when those interactions happen, it can be very tempting to kind of become antagonistic or dismissive. But I always try and remember to lean into those moments and think, “hey, like this one person is coming to me with this scenario or this situation. There are probably 20 people who are doing the same thing that are not engaging with me on GitHub or on open source or wherever, we’re going through the same thing. So, how can I kind of pause, listen and understand, and really like internalize what they’re saying instead of having kind of an antagonistic reaction to it?"

You know, it’s so interesting, kind of so much of our conversation has been about the ways that open source forces you to be a better engineer, sometimes by stretching your technical skills. You get to be a really good programmer if all of the code you write is eventually going to be on the internet for everybody to see. But it also, like, you know, stretches those interpersonal skills of like, listening and understanding and kind of communicating back with people. And I think that’s most of the great things in open source come when that listening and understanding is there and it is kind of held up by like a strong technical foundation, too. And then also some of like the drama and the toxicity in open source can come when there are breakdowns in that listening and understanding. So, yeah.

Jamie : Yeah, because there is a difference, isn’t there, between listening and waiting for a chance to talk.

Safia : Yes, yes, yes.

Jamie : And I feel like a lot of people jump on the second rather than the first. They’re like, “I want to talk now. I want to talk now. And so I’ll just breeze. I’ll just was it railroad over what you’re saying? Because I want to get my point across.” Right. And and and And I feel like a lot of people don’t take the time to really think, “wait, what was it? The person actually said, what is the core point? And if I don’t feel like I understand it.” I’m going to ask for more information, right? Let me just vibe check with you. Did I understand this correctly? This is what I think the problem is, but I’m not you, so I don’t, and I’m not in this situation. What is it that I’m missing? So that’s where I can help you.

Safia : Yeah, totally. And I think one of the things that is kind of interesting in my own experiences in open source is I have certain people in my open source career who I have met and interacted with on a number of different projects. And the ones that stand out as great mentors and role models for me were people who were so good at creating psychological safety in open source spaces so that people could present their ideas, and they were good at uplifting other people’s ideas and pushing them further. Like, I think it’s a very special and amazing kind of engineer who can not only listen to you and understand you, but when you present them with a solution or your idea for something, they make you feel empowered to do something about it, to open the PR, to go spend time making the code contribution or writing the design doc or whatever it is; and kind of Change that thing that was like sitting in your head and in your heart that you wanted to do and bring it out into the real world, and make you feel more powerful in the process, not less than.

So I think about the engineers that I’ve interacted with in my time in open source as I was coming up Who have created that feeling in me of feeling more empowered to push my ideas forward? And kind of like, how can I be that person for somebody else and help them push their ideas forward, no matter how big or small. And I think, like, listening and understanding is one angle to it. Another is kind of like the knowledge sharing and the support as you implement your ideas and not making you feel like you know, you’re making stupid mistakes or anything like that, but creating that sense of like safety so that people can actually like contribute their part to to the whole. So Yeah, I hope I do a good job emulating some of my role models. It’s something that I’m constantly working on.

Jamie : I think that is an amazing point that you’ve made there. And it really is. the core part of what makes a good engineer a good engineer, in my opinion, because to a greater or lesser extent, anyone can learn to do the actual day-to-day typing and and understand why RAM is laid out the way it is. And you know, we made a joke earlier on off off recording about everybody thinks we have an infinite supply of RAM. You made that joke, actually. And then I followed up with, “yes, but you know, if you have an infinite amount of hard drive space, you can happily swap in and out as long as you don’t mind waiting.” But if you don’t have, you know, anyone can learn that. What it feels like not everyone can learn is the interpersonal skills that are required for, like you said, to allow that psychological safety, to actually listen to what someone’s saying, to really grok what they mean. And like I said, I feel like I do a dreadful job of it, but I’ve done it for eight years, so hopefully I’m getting better.

Safia : I think it’s also like a skill that you practice like any other skill. And I think, you know, we had some conversations about LLMs and them as learning tools and whatnot. I’m kind of interested to see The easier it becomes to acquire knowledge or acquire bits of code that you can modify and what have you, the easier that part of the process comes with some of the tooling that’s coming out, the more important it is, those interpersonal skills and that, you know, the communication. How well can you craft a problem statement? How good are you at making somebody feel like, hey, I’m actually gonna go write the code, like, I’m excited to do the thing because somebody has made Me feel empowered and excited about this problem that I’m going to kind of go and do the mechanics of you know writing code and tests and features? I think those interpersonal skills and those aspects of engineering. Really, it’s like engineering leadership. Like, how do you be a good leader to a group of engineers? It will become more important. The actual, like, here’s how you write like a really performant linked list or really performant whatever become a little bit easier to do with some of the tooling that comes out. So, yeah, we’ll all have to be a little bit better about practising our engineering leadership skills in the future because they’re going to become way more important, in my opinion.

Jamie : Absolutely, 100%. And I feel like that’s partially because we’ve just run out of time, but also I think because it’s a really important salient point. I think that might have to be the point that we leave the episode on.

Safia : Ooh, I think it’s a good one.

Jamie : Oh, absolutely. A thousand percent. I agree completely.

So, Safia, it has been absolutely amazing chatting with you today. I feel like that, not just me, but I feel like everyone who’s listening to this is going to be learning a lot more about how to interact with each other a little better, how they can maybe use LLMs to practice, or maybe getting people to stop and really think, “wait am I treating the LLM differently to what I treat how I treat my colleagues or my co-workers or” you know, and maybe go have a look at some open source repos and see how the communication is going there. Have a look at the ASP. net core repo and see what’s happening and maybe raise an issue, but be friendly about it. You know, that kind of thing.

Safia : Yeah, absolutely. I think regardless of how technology evolves The most important thing is for us to be decent and understanding of each other and to be willing to work towards a common goal.

Jamie : 100%. I absolutely love that, Safia. Thank you very much for being on the show. I think we’ve discussed something that is super important for all developers to really think about. And I know that I’m going to be going away and really focusing on “how am I coming across to people? And how can I make it so that the folks around me realize I’m trying my best?” Or maybe I’m not trying enough. Maybe I need to try harder. I don’t know, right?

Safia : Yeah, totally. This was a great conversation. And I’m going to. continue to do my best to listen and understand and try and build developer tooling and technology that works for and with developers instead of against them as much as possible

Jamie : Amazing. I usually ask folks if they’re interested in listeners following them.

Safia : My handle is Captain Safia on everything. I do not post as much as I should, but I would say I’m most active at the moment on GitHub, obviously. And then Bluesky is kind of the playground I’ve been in.

Jamie : Nice. Well, I’ll get some links to at least GitHub in Bluesky so folks can go and have a look. And I’ll put a link for folks who are listening into the show notes for the ASP. NET Core. Issues part of the repo, so folks can go and have a look and see how you are triaging and working with folks to figure out solutions to issues.

Safia : Absolutely.

Jamie : Excellent. Thank you ever so much, Safia.

Safia : Thank you, Jamie.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places