The Modern .NET Show
A blurry image of source code, too blurry to read, take the place of the background. Layered over that are the headshot of Jeremy Sinclair and a purple robot holding a microphone; these are on either side of the centre of the image. Above both is the heading 'THE MODERN .NET SHOW' in bold, white text.

S06E06 - Unearthing the Secrets of Open Source and Collaborative Development with Jeremy Sinclair

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

S06E06 - Unearthing the Secrets of Open Source and Collaborative Development with Jeremy Sinclair
The .NET Core Podcast

S06E06 - Unearthing the Secrets of Open Source and Collaborative Development with Jeremy Sinclair

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

The Foundation of Effective Development is one recurring theme in this episode; it is the vital role of understanding code in troubleshooting and implementing new features. Jeremy, a Windows development MVP and a Windows Insider MVP, firmly believes that developers cannot fix code that they don’t understand. This insight is crucial for developers facing complex codebases or encountering bugs. Having a deep comprehension of the code, its underlying logic, and the libraries used is essential for effective troubleshooting and debugging.

Sinclair also emphasizes the importance of collaboration and collective learning in the software development industry. Rather than viewing development as a competition, he encourages developers to work together, share knowledge, and collectively level up their skills. By approaching software development as a collaborative effort, developers can collectively improve projects, create new solutions, and contribute to the growth of the overall .NET ecosystem.

The podcast discussion also delves into the significance of open-source contributions and their impact on the .NET community. Sinclair shares his personal experience of contributing to the .NET Runtime, highlighting the sense of accomplishment and increased confidence it brought him. He encourages other developers to contribute to open-source projects, as it not only helps to drive the direction and future of the .NET ecosystem but also provides opportunities for personal and professional growth.

Troubleshooting is identified as a critical skill for developers, enabling them to identify and resolve issues effectively. The speakers stress the importance of reading through code, analysing stack traces, and utilizing debuggers to understand the context and path of the code. Additionally, reading documentation is crucial for developers to align their implementations with specifications and identify potential bugs or areas for improvement.

The podcast episode highlights the importance of communication between open-source contributors and maintainers. Opening issues, having discussions, and providing feedback before submitting pull requests is vital for maintaining a healthy and productive collaboration. The speakers also acknowledge the challenges faced by open-source maintainers, emphasizing the need for users to understand and respect the limitations and sustainability concerns of these projects.

Episode Transcription

Welcome to The Modern .NET Show! Formerly known as The .NET Core Podcast, we are the go-to podcast for all .NET developers worldwide and I am your host Jamie “GaProgMan” Taylor.

In this episode, I spoke with Jeremy Sinclair about how it’s vital that developers understand the code that they are looking to fix, especially when the code they are fixing is complex. Sinclair also emphasises the importance of collective learning and collaboration in the workplace - it’s never a competition. But the one of the biggest things, says Sinclair, is our ability to learn in the open, using open-source technologies.

We can apply this over here, if we want this to work together as a full solution. I’ll take this part and we need to upgrade this. I’m like, "wow, this is awesome." It was like full collaboration because there was so much stuff that I figured out by reading through the docs. I can’t tell you how many times I’ve built the project, debugged, stepped through.

- Jeremy Sinclair

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, Jeremy, welcome to The Modern .NET Show. Previously The .NET Core Podcast, but [now] The Modern .NET Show. Welcome, welcome. It’s great to have you with us.

Jeremy : Hey, it’s great to be here and I appreciate you inviting me on here.

Jamie : Hey, no, thank you very much and I appreciate you being on the show. The one thing that I want to say ahead of time is that Jeremy is one of people that’s kind of Internet famous in the .NET space. Everybody knows Jeremy because he’s on Twitter and very popular in the .NEt space and in the Windows-dev space and things like that.

Jeremy : Thank you.

Jamie : It’s true, man. It’s true. We met at MVP Summit this year, 2023, and I was like, “oh, hey, it’s Jeremy. I’ve got to go say hello.” And that whole thing, I remember you telling me loads of people kept doing that, right?

Jeremy : Yeah, that was a pretty interesting experience. Know, I see myself as just Jeremy, but having that little mini star treatment at MVP Summit was it felt pretty.

Jamie : Cool. I mean, it’s well deserved of my friend. Well deserved, I have to say.

So cool. Would you mind giving the listeners a bit of an introduction to Jeremy, everything he does and all that kind of stuff?

Jeremy : Sure. So, everyone, I’m Jeremy Sinclair. I am a Windows Development MVP. And Windows iInsider MVP. And I am a application and security architect at a law firm. Is that good enough? Do you want me to spice that up a little more?

Jamie : Well, I mean, you’re one of these MVPs, right?

Jeremy : Oh, yeah.

But if you don’t actually, here’s something even more if you don’t know who I am already, sinclairinat0r. That’s my Twitter handle. Sinclairinat-0-R. And I’m one of the people who likes to tweet about Windows on Arm, and like to tweet about Windows development, and just about every cool new thing that I can get my hands on.

Jamie : So this is the thing, right? I’ll make sure that there’s a link to your Twitter in the show notes - or whatever we’re calling it now because we’re recording this during the great rebrand or attempted rebrand, but we’ll try not to talk about that. Yeah, I’ll get some links to your socials and stuff, put those in the show notes so people can click through and see what we’re talking about.

But I feel like before we get on to the main topic, I feel like because .NET Core, then Modern .NET went cross platform, I feel like there’s this big push for, “we have to cross platform all the things.” Whereas actually, from a business sense, it might make more sense to stick with the Windows. Which is why I really appreciate your point of view because you’re like, “hey, look at this Windows development thing that I’ve done.” Or, “hey, check it out, I’m using the Windows Insiders and stuff,” like that.

Jeremy : Yeah, Windows is my primary operating system. All my devices for the most part are Windows based. That’s where I grew up with even though it’s not the only platform I use. I also use macOS and Linux from time to time. Windows is just that’s my thing. It keeps me excited and everything I see just seems to really align with how I work.

Jamie : No, totally, I agree. I tend to flip and flop between the different operating systems because I see them as like tools. It’s the Abraham Maslow quote. He’s the guy who came up with the hierarchy of needs if you know anything about that. He said quite literally, “when all you have is a hammer everything looks like a nail.” So if you are a Windows user then the processes you will use will match the Windows setup. If you have to use a Linux machine then maybe you then have to rethink how you’re doing things. If you’re then having to use an Apple Computer of some kind you might have to rethink things then and I think whilst I don’t ever say that it’s required for devs to use all the different operating systems I think it’s useful for devs to just sort of know that they exist and maybe to try them out.

Jeremy : I completely agree with that and like you said I think it’s important to at least try out these different operating systems mainly because there’s something that’s always going to come in handy especially when it comes to developer tooling. How many people if you’re using git there’s git-bash and runs off of I always pronounce this wrong, I think it’s MinGW; but it’s more of that type of Linux type of shell emulator so you get those same type of applications that you would be used to dealing with on Linux, and even going to macOS it’s almost the same exact commands. So if you have that experience across those different OSS and you can kind of go everywhere.

Jamie : Totally 100%. I’m not sure this is an example that crosses over to the US. Because I don’t think many US drivers drive stick but I guess it’s kind of like learning to drive a manual transmission and an automatic: in that then you can use any of the cars or indeed if you drove a Toyota and then somebody gave you a Nissan to drive or a Ford to drive right. It’s the same thing. Just the user interface is ever so slightly different.

Jeremy : Correct. Yeah there’s there’s surprisingly a decent amount of people who can drive with the manuals. Me, I’m more of a “I want to hop in the car and roll.” That’s just me though.

Jamie : I mean that makes perfect sense right? Because the whole job of the car is to transport you from place A to place B, and if driving automatic gets you to place B then let’s do it, right?

Jeremy : Yeah, absolutely. And I just hope I don’t get stranded somewhere in the apocalypse and the only car I have left to get out is a manual because I can try to use whatever knowledge I’ve gained from playing racing games. Hope it gets me from point A po point B.

Jamie : “Where’s the R2 button?"

You could still get away in first gear. You just won’t get away very fast, that’s all. Let’s hope it’s just zombies, right? Because then they can just travel at a shamble. You’ll be okay.

Cool. All right, so I also happen to know, because we had a chat about this peeking behind the curtains, that one of your first ever commits to the .NET runtime was for something pretty cool. Do you want to tell the folks about that? Are you okay telling the folks about that? Are you interested in telling the folks about that?

Jeremy : About yeah, to talk about this.

This was around well, it was prior to .NET Six release, but in that time frame, I think this was actually part of the Hacktoberfest and for some reason that year, this was during the pandemic and I was overjoyed and felt like I needed to actually contribute something. So I saw that there was open issues that anyone could commit, know, take on their own. And there happened to be one for implementing something for Apple Silicon and I just so happened to have one of those little devices. So I’m like, you know, “let’s give this a shot."

It was an interesting thing for me because the code that needed implemented was more C-based and I could pick up a lot of what needed to happen. But I got about, I don’t know, maybe 90% there and someone I knew who had worked on and made commits to .NET runtime. I decided to reach out and ask for help to see if my logic was on or what I was missing. We worked together and first commit to .NET runtime was for Apple Silicon. And I was like I felt really awesome because this was something that I’d always wanted to do since I became a .NET developer. And really, since .NET became open source, I can see all of the source code. A lot of it. I have no idea what it means. But reading through, following the breakpoints and some of the solutions and just reading. I thought, “it would be really cool if I personally got to the level where I think I’d be comfortable to contribute something directly to .NET."

And just seeing that PR exception and code merged in, that kind of kicked me up a gear and I’m like, “okay, I can do this. I can contribute to things that I would normally be afraid to.” So yeah, that’s gave me a lot of the confidence. That awesome.

Jamie : Awesome. I’ve yet to do any contributions towards anything in the Microsoft open source space.

Jeremy : I’m telling you, this is one of my biggest suggestions. If they always tell developers, “hey, this is open source, we’re looking for contributions.” That’s one of my biggest things. Well, now is you have any sort of code, if you’re looking at something and it jumps out to you and you’re like, “I mean this should work like this.” Or, “I’d like for this thing to have this extra feature, it’d be cool if we could do this.” I said go for it, go for it and show it off. Because like that you’re contributing to open source and you’re helping out the .NET ecosystem. Why not?

Jamie : Yeah, I mean that’s how we got span and I guess that’s one of the ways that we got .NET on Apple silicon, right?.

Jeremy : I mean it takes everyone to make that success. And that’s why I’m really happy that Microsoft and a lot of the .NET just decided to really go the route of doing open source and allowing the external contributors to make a difference.

There’s always the .NET drama that typically occurred a few years back. But I think the really interesting thing is the community was able to help drive the direction. And that speaks volumes. So if the community is enough to help drive a direction then they’re able to contribute and help with the future of .NET. And I find that just huge. It’s not the legacy .NET, everyone who hasn’t touched it for ten years seems to think it is. This is the new .NET. This is what everyone felt like it should have been and I definitely have a lot of faith in it.

Jamie : Oh 100%. Because without the input of the people who are using it day to day, the engineers at Microsoft aren’t going to know. “What are you actually building with it? What would be a good tool or feature for us to build?” Right? Because the folks now I’m presuming this next bit, right? I don’t know how Microsoft works internally, but the feeling that I get from the very public conversations I’ve had with .NET people or people on the .NET teams is that whilst they may work on things in their own time, their full time thing is, “I am going to write .NET."

And so they may not know of the features that need to be requested or of the bugs or of the issues that us. I’m wary of saying “in the trenches,” but those of us who are working day to day with .NEt, we know a bunch of stuff that they don’t know because we’re using it day to day. They’re using it for stuff perhaps internally, but it might not be that it matches what we’re doing day to day. And so reaching out and just saying, “hey, wouldn’t it be cool if we could do this or have this feature?” I 100% agree with you. Absolutely.

Jeremy : Yeah. And you brought up something that is a really great point. As developers and even people who are users, we see things from the standpoint of how we use them. The open source maintainers, Microsoft, .NET, they see things: “Here is a feature feature,” they may have gotten from a PM or feature that they’re implementing based off of community feedback, and you have to use it to really know if it actually works or not. So you have all these tests and they’re using it the way it’s intended. But when others, like developers and external users, once they’re interacting with it, they may have a different workflow. And the most important thing is, if something is wrong, those developers and users need to let the maintainers know: you need to file feedback.

And that’s one of the things that’s kind of become my thing since becoming a Windows Insider MVP, is feedback. So many people are like, “oh, I hate the way Windows is. I hate this thing. This thing isn’t working.” Okay, you’re telling random people who are complaining, but did you file the feedback? Did you take that time to put in that information? How do you reproduce this? What were you doing to let them know like, oh, okay, this is an actual problem for this specific type of thing, or this system, oh, they were using this library and it happened to create an edge case we didn’t think about.

But that’s where that collaboration and community contribution comes into play. Feedback is, I say reasonable feedback, too, because I know a lot of times when there are issues, developers and users may become disgruntled and just approach it in the most unhinged manner to a state where I’m like, “okay, if I were working on this portion, I wouldn’t even look at this.” Because if something’s going wrong, you at least have to approach it from the standpoint of getting the point across, at least in a respectful manner, because we’re all.

RJJ Software’s Podcasting Services

Announcer : Welcome to “RJJ Software’s Podcasting Services,” where your podcast becomes extraordinary. We take a different approach here, just like we do with our agile software projects. You see, when it comes to your podcast, we’re not just your editors; we’re your collaborators. We work with you to iterate toward your vision, just like we do in software development.

We’ve partnered with clients like Andrew Dickinson and Steve Worthy, turning their podcasts into something truly special. Take, for example, the “Dreamcast Years” podcast’s memorable “goodbye” episode. We mastered it and even authored it into CDs and MiniDiscs, creating a unique physical release that left fans delighted.

Steve Worthy, the mind behind “Retail Leadership with Steve Worthy” and “Podcasters live,” believes that we’ve been instrumental in refining his podcast ideas.

At RJJ Software, agility is at the core of our approach. It’s about customer collaboration and responding to change. We find these principles most important when working on your podcasts. Flexibility in responding to changing ideas and vision is vital when crafting engaging content.

Our services are tailored to your needs. From professional editing and mastering to full consultation on improving the quality and productivity of your podcast, we have you covered. We’ll help you plan your show, suggest the best workflows, equipment, and techniques, and even provide a clear cost breakdown. Our podcast creation consultation service ensures you’re well-prepared to present your ideas to decision-makers.

If you’re ready to take your podcast to the next level, don’t hesitate. Contact us at RJJ Software to explore how we can help you create the best possible podcast experience for your audience, elevate your brand, and unlock the vast potential in podcasting.

Jamie : Absolutely.

This may not have happened to you, Jeremy, but it’s definitely happened to me a lot. But this may not have happened to you, Jeremy. I’ve built software in the past where I’ve gone, “I think this is how the user interface should work. I think that the process should be step one, step two, step three, step four,” and then put it in front of the user. Because all I know is the business case, the business rather all I know is the business case, as has been explained to me. So I’ve gone, “right, okay, so step one, you want to import this CSV. Step two, you want to do this thing. Step three, you want to store it in the database. Step four, lovely printed, wonderful report.” And then I put it in front of the user and they’re like,“no, I want to see the report first.” And I’m like, “what? And it’s the same thing, right? I don’t know how someone who is meant to be using this is going to use it.” And so I’m going to make assumptions.

And it could be that these assumptions are indeed quite wrong. I mean, they’re often wrong when I make assumptions, so that’s not a problem. I’m happy to be wrong, but it could be that especially on the Windows Insiders. It could be that maybe you’re doing something not you specifically. Maybe the listener, maybe the invisible. You, the person who’s using a specific feature of Windows Insiders. It could be that someone is doing something that the folks at Microsoft thought, “no one will ever do this. We know it’s a bug. No one will ever do it.” And the it turns out that 25% of all the users ever do it. Right. They don’t know that until people tell them.

Jeremy : Right? And I can tell you from experience, there have been many things that just solely because of the way I do things as my workflow. For instance, many times I’ll use keyboard shortcuts for everything. I don’t use the mouse unless I absolutely need to. And there have been things that I’ve found bugs that were keyboard based or based off of how keyboard interaction works with the desktop that you would normally never find it because people are used to okay, they right click on this, they click there, and you wouldn’t be able to reproduce it. But because of the way I work, I’m just okay, win+r, enter, control-shift, control A, control… And it’s those things where I was able to reproduce this because of how I work. And I followed it. So I let them know. And even from different devices that I own, which all every single device I have running Windows is running an Insider build. I’m on that level.

Jamie : You like to live dangerously is what you’re saying.

Jeremy : You say I do. Because I feel like for me, the more dangerous I am. I enter into the Insider program. I think I have all but two devices on the Canary, and the other two are on the Dev Channel. And I do this because, one, because I do like a lot of preview builds for everything because I like to test and there’s always a possibility of me running into some bug that shouldn’t even exist, but only happens to me. So I like being able to track that stuff down, be able to troubleshoot it. For some reason. That just gives me a little rush when I’m like, “ooh, there’s a bug. What’s going on with this?” But that’s why I do it. I do it because then if we can get things captured up in the clouds before it gets down on the ground, it’s handled.

Jamie : Yeah, 100%. Feel like because you mentioned troubleshooting, that gives me a chance to really badly segue into one of the things that we were thinking of speaking about, if that’s all right.

Jeremy : Yeah, go ahead.

Jamie : And I think that is that troubleshooting is something that I think a lot of Devs don’t get taught how to do. I’ll give you some of my experience, and maybe you can share some of your experience as well.

I work with a lot of junior devs. I work with a lot of people who are coming into the business and a lot of times when something goes wrong, they’ll metaphorically or quite literally throw their hands in the air and walk away and say, “I can’t do it because it’s broken.” And I’m like, “what’s it say?” Right? Because we’re really quite lucky, especially in the .NET space, when something goes wrong, it will literally tell us what the problem was. “Oh, you got a null ref on this line in this character,” right?

Jeremy : Yes, I completely agree with that.

.NET is probably one of the languages where you’re going to see what happened, why it happened, and where it happened. Troubleshooting is, I say one of the most important skills for developers, and this goes back to being able to read through code. Even if you don’t understand it, troubleshooting helps you to understand what’s going on. So looking at the stack traces from a lot of the errors. If you’re not copy and pasting or copying little substrings of that error and popping that into a search engine, you need to do that. Because I can tell you almost nine out of ten times I’m troubleshooting or helping someone else who’s running into an issue, the answer is right in the error. And people are, I guess, kind of used to things just either working or not working. That’s the game of the element. Things are not going to work the first time, every time. But the most important thing is to fall back and step through. Step through your logic, step through your code. Debug.Breakpoints galore that’s I do. But being able to use that debugger, look at the entire context of what you’re doing and follow the path that is so useful for understanding anything.

And I know there’s many times where it could be a pretty severe bug, where it’s something that you can’t really fix on your own, and it has to go back to either the third party vendor or .NET. But being able to reproduce something, follow through and understand, “okay, how can I reproduce this? What’s actually going on?” And determining whether it’s a logic issue or that could be fixed by fixing your logic, or if there’s a problem with just the whole workflow of that individual runtime or framework.

But that’s still important if you’re having an issue with, say, like a web form or something in Blazor or MVC, you’re getting null reference, something’s not coming back. Being able to step back and think your logic from your steps from one to 20 or however many steps that will define what you’re trying to do, is going back and looking through all of those, making sure it’s logically sound, does it match up with what the documentation states?

Because that’s another thing. Reading the docs nine times out of ten. I’ll say this again. Reading documentation before trying to implement something will save you time because it’s so easy to see a lot of precanned code that can be copied, pasted, and flipped around. But it’s only useful if whatever the developers are trying to create is doable. If it follows the spec of how the methods or classes they’re using. If it follows that spec, then they’re good. But if it if it doesn’t, then you’re on your own and just wasted a lot of time without it could have been saved by reading the docs, maybe contributing to them if something’s wrong.

That’s another thing. This all goes back to that whole contribution and kind of feedback workflow because it’s all troubleshooting the entire issue. “Is this thing wrong? Am I seeing a different result than what the documentation is saying, and I’m implementing it this particular way that they said, maybe the documentation is wrong, maybe there is a bug,” but it’s being able to step back and get that full picture.

Jamie : Absolutely.

Jeremy : How you do it, that’s at least how I do it. At least my mind works a little wild because I have ADHD, but that’s something that’s kind of brought in.

Jamie : I think it’s good advice anyway, because there’s something that you said, again, drawing back the curtains a little bit in our sort of pre recording chat. There’s something that you said that has stuck with me since listeners, we do the pre recording chats, like, a couple of weeks ahead of time so that then we can sit and let ideas percolate for a little bit. And there’s something that you said to me, Jeremy, during that pre recording chat that has sat with me, and that is “you can’t fix code that you don’t understand."

And you’re 100% right. Like, if I’m staring at a code listing and it’s in a coding standard, I don’t recognize it’s in a language, I don’t recognize it’s using a bunch of libraries I’ve never heard of, and it’s doing something that I don’t understand. There is absolutely no way that I can even begin to figure out where a bug is or show to fix it. So I just want to say that even if we don’t talk about it - I really hope that we do - but even if we don’t talk about it, I want to thank you for saying that during our planning session, because it is 100% right, and I never really thought about it. Like, it hadn’t crossed my mind that, “oh, I’ve got to understand this code before I can fix it,” and you have to understand the code before you write it too. Right? Like you were saying, go read the documentation. You got to understand the library you’re going to interface with before you actually use it.

Jeremy : Yes, that’s just it. And it’s something I’ve really learned over the years from a lot of the great developers. I see a lot of the presentations. I see a lot of the demonstrations of libraries that were created to solve an issue that an issue of something not existing in a main library. And just seeing a lot of the just thought process. It’s like, “okay to be able to even do this. You have to understand that code. You have to understand the underlying implementation, the logic even behind it, to really be able to take that next step."

And so that’s what I’ve been doing over the years, because I can say personally, with my own development and even at work, the amount of troubleshooting and just time spent understanding the frameworks and libraries, I do that prior to putting my hand on the keyboard. I need to know what I’m jumping into before I can say, “oh, yeah, cool. I can get this done. I can do this in a week or a few weeks.” If I don’t know at at least some functional level understanding what I’m working with, then I can’t fix anything. I can’t implement anything.

Like I say, if you go back and think about it from the standpoint of understanding the library, the framework, the underlying thought around said thing, if you don’t do that, the all that’s going to happen is, “I don’t get this. I need to search something else, somewhere else for this. I need to try going to another site.” If you fall in line with simply searching for the answer, the answer is not there, obviously, yet. You got to create that answer. You got to find those building blocks and understand how they tie in together, or how you can create those blocks and make them tie in together. That’s where it falls back to just the understanding.

And there’s so much that I’ve been able to understand, reading the docs source code, open source has probably been one of the most amazing things, just be able to see how certain things are implemented and like, “oh, what is this? What is this thing?” And I just get that desire to go in research, this one class, this one library, this one C++ implementation that it’s involved with this thing that I’m using, but I don’t get it. So I need to have some sort of base functional level understanding so it resonates. So I can say, “okay, I get that because it’s doing this, that means if I do this thing over here, I can make this do that.”

Jamie : Maybe because I feel like we’re sort of cut from the same cloth here. Jeremy I feel like maybe it’s an age thing, a maturity thing, maybe. You mentioned earlier on about ADHD, I’m not sure. But what I’ve noticed is that my practice has become a lot like yours, where I’m like, okay, before I do anything, I’m not touching the keyboard. I’ve got to collate a bunch of information. Whereas a lot of the juniors and apprentices I work with, “they’re like, I want to be at the keyboard because this is where I live and I need to type and type and type, and I’ll fix it then.” To the point where a couple of times when I’ve been trying to help people debug a problem. I’m like, okay, let’s have a look at line seven. They jump to line seven, then they start typing. And I’m like, “whoa, stop. I’m reading. Don’t change it while I’m reading.”

Jeremy : Yeah. And just that because I help people and I get the going to look at that line and like, “whoa, whoa, stop. See what is this going? Okay, go back. Go into that class. Why is this being done?” And many times it’s, “oh, because it was there so and so implemented this way.” And I’m like, “okay, so it’s kind of going off of what someone else has done, but the there hasn’t been any there’s been no exploratory looking at how and why the other person added that code or implemented that way.” And you need to have that little bit of curiosity, because I can hand code to anyone and say, “oh, yeah, it does this, it does that,” but does it actually do this or that? I can chat describe it, but does the code match what I’m saying? It does? That’s one of the parts that I’d say a lot of developers need to focus on is being able to one, fall back at times. Because even for me, there’s a lot of stuff where I might say, “yeah, I know this enough, and might try to get ahead of myself.” But if there’s something, someone’s helping me, I know I need to fall back a bit, walk through the person that’s helping. At least try to make them understand where you started and where you ended up, to the point of asking for the help to fix to help you fix a bug. Because you can’t just start jumping into the code and thinking that by being helped or looking at a problem together that the other person is going to fill in the blanks for you.

I think I’ve seen too many times where that could be an expectation of, “oh, I’m asking so and so for help. They’re going to help me by fixing it for me.” But you don’t learn that way. You see that, “okay, here’s the result of this thing, but you haven’t understood the what and the why.” So that if you run into a similar issue, you have those troubleshooting steps to fall back to and think outside of the context of entering this method into the method body, because it fixed this particular thing the last time. Now you got to fall back to the mindset, the steps to get you to that point, because then you’ll know, “okay, I need to think of it from this standpoint. I probably shouldn’t need to be using this, I shouldn’t be using that.” It’s learning the steps of how to troubleshoot, how to break things apart, and to see it in that little disassembled form, as I like to say, I break things down when I’m looking at it. I’ll use ILSpy if I need to. I’ll use everything like, “okay, what is this thing doing?”

Jamie : Totally.

That leads me to two separate thoughts, if you’ll allow me to interject for a second here, Jeremy. And that is, one, the tools exist for a reason. And guess what? All the tools are cross platform. Whichever IDE you use, all right? If it’s Visual Studio, you may have to invest in another different IDE, but they’re all cross platform. But also that software development is not a competition, it’s a collaboration. Because I feel like and I’m happy to keep talking about troubleshooting. I’m happy to talk about either one of these two other topics, but I feel like - and I just want to say this because I don’t feel like it gets said out loud a lot. And I’m not the person who should be spreading this message because I don’t think I’m a big enough person to do this. But I feel like we have spent so much time, maybe because of recruiters, maybe because of our egos as an industry, trying to be the smartest person in the room, when in actual fact, it isn’t about show smart individuals feel like they are. It’s about all of us working together. Right?

If I’m working on a team and I need some help for something, and someone says to me, “wait, don’t you know this?!” I’ll be like, “right. I’m not coming to you for help any more. Who else can I talk to?”

Jeremy : Exactly. It’s all about levelling up collectively, because there’s a lot of things that I could learn by myself, but it’s not doing anyone any good. If i’s just a me me. It needs to be just kind of feeding off of everyone. So I might know this, and I’m helping you out, mentoring, sharing this, “here’s how I did this. Here’s what I used to get to this point.” And it should be of that level of passing that along and helping everyone grow, because there’s always something that you’re going to learn from someone else that you don’t know or you thought about it this way, but you didn’t think of this one particular thing that they happen to, and you get that, “okay, that makes sense. I didn’t think about that. Yeah, let’s do that."

But it’s all about collaboration. You can’t sit at the top of the throne and then automatically think that things are just going to carry on, because what happens when you’re gone, all that knowledge is gone. So it’s important to work together as a community and to build each other up. There’s a lot of stuff that I’ve accomplished because of that.

One of my favourite things I’ve done. This goes back to my fun. Windows on Arm days is my contribution to Power Toys. So Power Toys is running windows unarmed because I took initiative to jump in and see if I could make it work. It was fun. I didn’t know a lot. There’s a lot I didn’t know at the time. I was digging in and there were some things that I had to reach out for help on. And I just took initiative to say, “you know what? I want this to run natively. Let’s see what I can do.” So I did what I could. I made a few things run and said, “ha, look at this.” But there was a lot more that needed to happen.

And the core Power Toys team, they went through my pull request, and it was so amazing to me because I’m like, “what? They’re actually checking my code. They’re finding things. It’s like they’re finding things I didn’t even see.” It was like, “oh, this thing I sort of got working. It’s like, oh, no, this is cool. We can apply this over here. If we want this to work together as a full solution, I’ll take this part and we need to upgrade this.” And I’m like, “wow, this is awesome."

It was like full collaboration because there was so much stuff that I figured out by reading through the docs. I can’t tell you how many times I’ve built the project debugged stepped through. I had so many what I want to say scratches, so many things. Like, I’d check in to my scratch and the pop off of it after I got the latest, just switching around different branches. I was trying a lot of stuff, but it was just seeing all the rest of the team appreciate that contribution and seeing the work they put in, like, wow, they are brilliant.

But it was something like that. It wasn’t me holding it to myself because I built it. I had it running, and I just decided to post on Twitter, I was like “hey, look at this. I mean, just run an Arm.” I didn’t keep that to myself. I one wanted to see this work, and I wanted everyone else to be able to have this, because that means there’s that possibility for more people to make the contributions, which then comes into more people using it, actually being able to use it in Windows on Arm, which then turns into, “oh, this thing has been working for me. Oh, but it doesn’t work for them. Why is that the case?” So there’s finding fixing bugs in the product that could fall back to, “oh, these were bugs in the OS that maybe get fixed.” So it’s like all that collaboration is helping things come together and to improve just the state of the application, the tooling, and the OS. And I just find it so fantastic that a thing like that is enough of a catalyst to really get the community rolling.

Because I like to learn. I like people to introduce me to things that I’m just like, “okay, this is really cool. I want to use this. I want you to use this thing, and I want you to improve it and show me what you can really do,” because there’s some stuff that I don’t know, but I like to know it. I like to see it. I like to keep myself engaged and excited with the development communities because I like to create, I like to see creations unfold.

A Request To You All

If you’re enjoying this show, would you mind sharing it with a colleague? Check your podcatcher for a link to show notes, which has an embedded player within it and a transcription and all that stuff, and share that link with them. I’d really appreciate it if you could indeed share the show.

But if you’d like other ways to support it, you could:

I would love it if you would share the show with a friend or colleague or leave a rating or review. The other options are completely up to you, and are not required at all to continue enjoying the show.

Anyway, let’s get back to it.

Jamie : Sure. And I agree. I’m very similar to you. I’m like, “hey, I’ve started with this blank. I don’t even have a file. And now several hours later, I’ve got some kind of binary or some kind of library or some kind of executable that does a thing."

But I feel like there’s a combination of, “I want this to exist,” and kind of bravery involved in that, and bravery not in the sense of, “I’m going to forge ahead and make this thing happen.” It’s more a bravery of being able to reflect and go, “I have no idea how to do this. So I’m going to go talk to my collaborators or talk to someone who knows, and read the documentation,” and spend like you said, spend a couple of maybe an hour, maybe half an hour, maybe a couple of hours just reading and watching tutorials and reading through documentation to figure out, “wait, is that how this works? So if that works like that, then I can glue this together in this way, and then it’ll just work,” right?

Jeremy : Exactly. And even furthermore, I’ve learned that it’s even necessary to be able to be okay with being told, like, a feature or something isn’t going to work or even be included. So it’s like, “hey, this is cool, but I don’t think it’s something that is needed or that needs to be a part of this.” That’s something that I’ve been working on. I have a quirk of, I want to create stuff. I got these wild ideas, and I go off on the deep end at times. I think it’s awesome to have the ideas, but it’s even more important to see and to know whether it really fits in, really fits into the product, really fits into where things are at that point in time. Because any user, any developer is like, “well, I want this. We should have this. It needs to be done now,” and get really upset that it’s not there or it’s not on the roadmap. Or it’s, “hey, we’re not looking at this at this time.” Being able to okay, there’s a reason for this. There’s a reason why it’s not going to be added. I’m cool with that. That’s something that is important.

Jamie : Yes.

Jeremy : There are some things you fight for. There’s some things that you can’t force, and you have to be able to be okay with that, because if you’re not, that’s where you start going off the deep end and being angry for no reason.

Jamie : 100%.

I feel like it’s easy to fall into a trap of - and this isn’t what you were talking about, I just think it’s kind of related - I think it’s easy to fall into a trap of, “but I’ve spent so many hours working on this thing, and I’m going to see it as a personal attack that you’re not going to bring this into your library/product/whatever.” And there’s also, like you were saying, right, look at it from the other point of view: Imagine you are an open source contributor, you’ve got some kind of library that is really cool. Jeremy and I come along and I submit a PR and say, “hey, here’s this feature that I’ve been working on and it is amazing. It’s taken me six months to make, but it will make things better.” And you go, “that’s awesome. But also I can’t support it going forward, so I’m going to choose not to include it. What about if you include it as an extension library or something?” Right.

And I feel like that’s also a relevant way to do that collaboration stuff because it’s also worth noting. And open source pull requests on stuff, at least on my stuff, I can’t speak for everyone, are always welcome, but they’re not always going to be merged in because once you supply me with some code, I have to then look after that code for the life of that product.

And so it might be that I create a pull request for something you’re working on, Jeremy and you go, “awesome, except I can’t support that for whatever reason.” So it’s important to know that too. But obviously I feel like I have to say that because I feel like we’re told as devs, go do open source stuff and go contribute towards open source projects and they’ll always let your contributions in when actual fact, they’re not always going to let your contributions in.

Jeremy : Right, right.

And I especially like that idea of, okay, that’s cool, I understand it’s not going to be checked in. Maybe I make an extension library where I can plug that in for myself or allow it so that others can use that extension on top of the product. But yeah, that’s really important just to be able to still use it but know and be fine if the maintainer isn’t going to accept the pull requests or not accept it at that time, because it’s still important to have that communication with the maintainer. And there’s a lot of times where open an issue, there’s a lot of the contribution documentation open an issue, see if this is something that’s going to be applicable to the roadmap of the library of the product and then it’ll be addressed then and there. And I know a lot of people just kind of skip past that and, “here’s code, I’m just going to do pull request,” and it’s like, “yeah, this is awesome.” But sometimes it might be welcomed and sometimes it’s, “hey, this would probably be better if you had your own extension and it lived there. It’s still worth it, it’s still worth it.” But still that communication needs to occur and have to be willing to all right, that’s fine. Even though the didn’t accept this into the library, I still did something and I could probably still find a way to use this code.

Jamie : 100%. Or indeed it could be that the maintainer has, without announcing it, walked away from that project and said, and is saying, rather, “if you want to create a pull request, why not just keep your own fork of it and just do it there? Because it’s way too much effort for me to maintain."

Because… how do I put it? We’ve been given this idea that open source will fix everything. But open source is also sometimes done in people’s own time with their own money. And whilst there are much smarter people than me who are working on this problem, open source maintainers need to be able to eat. And maybe before they’re going to take your pull request in, my pull request in, the listener’s pull request in, they need to make sure that they can eat first. And that’s me going over the top and being a bit silly because I don’t want to put anyone off. But the point I’m getting at is that maybe this open source maintainer does not financially have the ability to support your code. Because maybe, and again, I’m using “you” as the person who’s putting the pull request in. Not specifically you, Jeremy. Not specifically the listener, but maybe the pull request creator is probably the worst way to put it. Maybe they don’t realize that the open source maintainer doesn’t have the ability because maybe when they bring this in, it’s going to affect any kind of support contracts that they have with other people. So like you said, the best way is sometimes to maybe raise an issue and say, “hey, I think I’ve spotted this gap in this repo and I have a working implementation and it may be good, it may not be good. Is this something you’re interested in? Because here’s the code,” right? And then they can go, “oh cool, that’s awesome, bring it on in.” Or the can have that conversation. Like you were saying, it’s all about that communication, right?

Jeremy : Yeah. And open source projects, sustainability is a huge topic.

Jamie : Absolutely.

Jeremy : I think it’s going to be an ongoing topic and there’s still so much that has to be addressed. There’s a lot of questions. I think personally it’s important for a project to have that ability to continue being a project people simply use. There’s a lot of users, but sometimes not a lot of contributions. It’s kind of the “hey, this thing is cool, I need this. What are you going to do? Are you going to add this thing for me?” It’s open source, you can use it. I’m sure you can understand how to fork create your own.

But then even at this, like you said, the maintainer, a lot of the open source projects, they’re doing it on their own time and a lot may not even have the funding to make it sustainable for them to do. So it’s, “when I’m free from the rest of my life’s duties, then I can look at this, “and that’s something needs to be understood across the board, across the board especially. And there may be maybe one person, one or two people maintaining a huge project. And that kind of has to be put into consideration.

Jamie : 100%.

I’ll bring this up as a last example because I’m worried that people are going to think, “oh, he’s going to get all political and talking about funding open source software.” And that’s not what I’m aiming to do. Because like I said, there’s much more smarter people than me working on this. That’s a bad sentence, but you get what mean.

But like, if you look at Identity Server, the folks who wrote that the reason that the spun off their own company and now charge people for it is because Identity Server allows .NET devs to make a boatload of money - like a country’s worth of money, right? So much money you can stuff it in your ears and go blows a raspberry until you pass out, right? It allows you to make a shed load of money. But almost no one provided any kind of financial support or even open source contributions. And so they closed sourced it and made it a paid product because it was the only way that they could make money doing it to support the development of it. Not make money so that they could make loads of money, but make enough money to support the development of it. Because like we’ve both said, these are people who are working on open source projects in their evenings, on their weekends, rather than maybe spending time with their family or rather than doing chores around the house. They’re like, “I’ve got to get this patch done. It’s got to be fixed because there are 1001 commercial applications that rely on my code working and it’s not working,” right.

Just real quick, all I’m saying is support your open source developers, folks.

Jeremy : Take care of the open source developers. If you’re using a package, there’s ways to contribute back to the developers. Because open source is really awesome. It’s helped me to learn so much and helped me to level up professionally and personally through collaboration.

Jamie : Yeah, me too.

I’m not old enough to have been around at the beginning of the industry, but at the beginning of the industry, when everything was closed sourced, the only way to learn was to go to a university. And that cuts off a lot of people. That stops a lot of people from learning and joining our industry, having to go to university, college, whatever. But everything being open source means that, “hey, you know what? If you’re in your browser and you hit F12, you can see the stuff that makes the page work,” right? Knowing that that exists and knowing that that’s a resource that you can look at to figure out, “oh cool, now I understand how HTML is put together. Oh, cool, There’s this stuff called CSS,” that helps me choose how to the wrong word, but how to draw it right, how to make the colors appear and what fonts to use and where to position things.

And then you look at JavaScript and you’re like, wow, this adds some interactivity stuff. Then somebody tells you, “you know that JavaScript stuff? You can run it on a server and you can write your app in it,” but guess what? You’ve got everything on your computer in order to learn HTML, CSS and JavaScript. You just don’t know. Without that kind of open source ability, no one’s going to learn. So, yeah, support your open source developer, friends, people.

Jeremy : Yeah, you just brought up another point too, because I remember at one point I was in college or even yeah, even probably the summer going into college, I wanted to learn so much. I’ve learned PHP back in high school and I first learned ASP way back, we’ll say way back in the day, just because I wanted to create a Dragon Ball Z website - also obsessed with anime, but - there wasn’t really any resources. It had these expensive books that you had to buy. And I’m like, I’m barely in college, I’m not paying $200 for that. How can I get this stuff? And then you see a lot of the documentation open up, especially, I’ll say, big ups to the docs at Microsoft. My goodness, that documentation has grown significantly. I feel like it’s now. Like you said, since everything’s really becoming open source, you can actually learn without needing to drop two, three grand on just to learn the basics and everything’s becoming more accessible to everyone to learn.

Jamie : Yeah, I agree. And I’m all for it because the more accessible we can make the industry, the more accessible we can make the learning and the knowledge, the more people will get into the industry. Which means we’ve got more voices, more opinions, more experience, more backgrounds, more ways to fix things in different ways, more ways to approach the same problem, but with brand new perspectives. So I am all for that. But it all sort of requires everything to be open source, but then without the support, they can’t continue. So again, it’s for smarter people than me to figure out. But where does that line go? I don’t know, but there you go.

So Jeremy, thank you so much for spending your time with us today. I’ve really appreciated it. I feel like I’ve learned more as both a person and as a developer, and I feel like the listeners are going to learn more as well. But what about keeping in touch with you? I know that we’re going through this period of time at the moment with Twitter and everything is going on. That’s a place where people can find you. We’ll put that in the show notes. But where else can people sort of learn a little bit about the stuff you’re working on or the projects you’ve got or anything like that?

Jeremy : Yes, so with me being the social media person I am, I’m pretty much everywhere. I’m on Twitter. Mastodon blue sky just all over. But I also have a GitHub. My GitHub username is Snickler, which here’s a fun fact about that. My stepdaughter, she saw my name tag and had my name on it and she’s like, w"hat does it say? Snickler instead of Sinclair?" And that’s how I laughed at it. I laughed at it forever and I’m like, this is going to become my username.

Jamie : I love that story.

Jeremy : But yeah, you’ll find me on Twitter - we’re still calling it Twitter - and that’s pretty much one of the primary spots GitHub and I have. My website is sinclairinat0r.com. So yeah, you’ll find me out on the interwebs, you’ll see me randomly doing some MVP related stuff, some insiders related stuff. You’ll just see me on the internet now if you haven’t found me already, I’m sure you’ll see my name and you go, “oh him.”

Jamie : Awesome. Well I’ll put all the links to all of that stuff in the show notes and there’ll be a couple of other links as well. Like I’ve got your MVP profile and stuff like that, so that’s on there as well because those link out to a whole bunch of other places that I could list them all in the show notes but the might be a better place to send people to so I’ll send those over as well. Awesome, thank you ever so much. Jeremy, like I said, I’ve really appreciated our chat and I appreciate you taking the time to talk with me and to talk with the listeners. It’s been a lot of fun.

Jeremy : Likewise. I really appreciate you reaching out to me and definitely so fun to do this podcast with you. I’ve been really excited waiting for this. So yeah, I hope everyone enjoys this and remembers to be excited about doing development to help others out and just to collaborate and build each other up. That’s what makes me happy and that’s what I try to do out there. I try to ensure that I hype everyone up and remind them that you can do this.

Jamie : Awesome, thank you ever so much.

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, Jeremy Sinclair, for graciously sharing his 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 out 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