S08E15 59mSeason 8

Episode Summary
This week on The Modern .NET Show, Jamie Taylor welcomed Ben Bowen to discuss TinyFFR, a passion project born from a desire for a more accessible approach to 3D rendering in C#. Ben, a software engineer with experience in both enterprise and game development, explained that TinyFFR aims to fill a gap in the market – providing a lightweight, modern .NET library that allows developers to quickly create and experiment with 3D scenes without the overwhelming complexity of full-blown game engines like Unity or Unreal. He highlighted the appeal of a ‘software-first’ approach, enabling developers to build up scenes from a blank C# project and retain complete control over the rendering process.
The conversation delved into the importance of side projects for developers. Both Jamie and Ben emphasised the need for creative outlets outside of daily work, describing these projects as sources of enjoyment and a vital means of preventing burnout. Jamie drew a parallel to the concept of ‘play’ as a recreational activity with no specific end goal, allowing for relaxation and a refreshing change of pace. Ben shared how building TinyFFR has been a consistently engaging experience, contrasting it with the potential slog of working on large, pre-existing codebases.
A significant portion of the discussion revolved around the exceptional documentation for TinyFFR. Jamie praised its clarity and design, noting the inclusion of collapsible sections which cater to users of varying levels of expertise, allowing them to delve deeper into the underlying theory as desired. Ben explained that this approach stemmed from a belief that good documentation is crucial for the success of any library, and a conscious decision to prioritise user experience, particularly for hobbyists with limited time. He also attributed the quality of the documentation to the freedom afforded by working on a personal project, allowing him to invest the necessary time and effort.
The pair explored the challenges of cross-platform development, with Ben detailing his experiences supporting Linux alongside Windows and macOS. He highlighted the complexities of catering to the fragmented Linux landscape and acknowledged Apple’s restrictions regarding virtualisation, requiring him to rent Mac hardware for testing. However, he remained committed to cross-platform compatibility, recognising the benefits of .NET’s versatility and the growing popularity of platforms like SteamOS. Both agreed that while cross-platform is hard, the modern .NET ecosystem makes it significantly more manageable.
Episode Transcription
For me it’s born out of, I mean the old phrase right, that necessity is the mother of invention. And I want to make games actually, but I think there’s a missing middleware in the industry at the moment for certain types of game developers.
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 Ben Bowen to talk about TinyFFR - a cross-platform library for .NET which allows developers to render 3D models. TinyFFR came from Ben spotting that there is a gap in the Games Development tools market: somewhere between 3D modelling software and a full-blown game engine.
I, personally, believe that a library or software middleware is only really as good as the documentation that comes with it. You probably drive away 90% of the potentially interested parties if you’re just saying to them, ‘hey, if you want to learn how to use this, you’d better go spelunking through the source code or looking at examples.
Along the way, we talked about the importance of really good quality documentation. And it should come as no surprise to you that we talked about this because the documentation for TinyFFR is fantastic. Seriously folks, when you’re done listening to this episode, go check out Ben’s Hello Cube tutorial for TinyFFR and you’ll see what I mean.
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
Ben
Jamie
Because it is so easy, and we’ll get into this later, to fall into the trap of ‘I do the thing for work and therefore I will only do this one very specific part of the thing.’ Whereas I actually think that having some fun project to work on outside of all of that makes life worth living, right? Variety is the spice of life, as they say.
Ben
Jamie
Ben
Like quite a lot of programmers, I’m a hobbyist game dev as well, which is where perhaps TinyFFR comes in. I do have a game on Steam I wrote about 10 years ago. It was on a custom game engine. It took me like two and a half years, and I sold about a hundred copies, so in terms of commercial success, not a success. But I did learn a lot, so that’s something.
Most recently, I’m an author of TinyFFR, which is my C# real-time rendering library and very much a passion project at the moment.
Jamie
Ben
Jamie
Ben
Jamie
It doesn’t have to be related to computers. There’s this wonderful—I want to say it’s McEwan has this book out called Play—and they describe play as an activity which doesn’t necessarily have a means to an end, right? Anything which doesn’t necessarily have a means to an end can be seen as play and therefore is recreational and just chills us out.
Even though with this particular project you’ve spent lots of time building it and writing software and writing documentation, which we’ll get onto in a moment—because the documentation is ace, spoiler alert—you’ve put all this effort in, but I have a feeling from the way that it’s been built up, it’s not been like a slog. It’s not something that you’re like, ‘Oh God, no, I’ve got to work on TinyFFR again.’ You know, it’s not that. It’s like, ‘Oh my goodness, the day has ended and I have half an hour—let’s do this thing with TinyFFR,’ right?
Ben
Jamie
I also fully appreciate that, ‘Oh no, I’ve got to do this PR because I promised someone that this would get out there.’ You know, past me is the worst because past me made the promise, but present me has to deal with it, you know?
Ben
Jamie
Ben
Jamie
Ben
Jamie
Ben
Obviously, you’ve got your game engines. Everyone knows that—you’ve got Unreal, Unity, Godot, and others. They’re great. I mean, obviously for certain types of games, if you’re like a AAA studio or you’re perhaps primarily art-driven as a studio or developer indie, then these tools—they’re massive, they’re behemothic. They have a lot of tweaking, a lot of functionality, you know. They cater not just to the game development industry often, but also like movies, film, TV. So they have a huge suite of tools for building up these really amazing scenes, if you like.
I have tried to use these engines. So, for example, imagine something like Minecraft, right? Imagine you wanted to make Minecraft today. The creator of Minecraft when he did that, he wrote it in raw Java, and there’s a reason for that. He could have done it in a game engine. There’s absolutely no reason he couldn’t have. But I think that there’s a certain type of approach that some more systems-driven designers maybe want to go with. For me, that’s the software-first approach. I think a lot of software engineers like to approach a project from the ground up rather than trying to integrate something into an already existing huge project like a game engine, right?
For me, when I want to think about making a game, I’m often thinking, I just wish in the industry, in the world out there, there was a library—I could just tell it, ‘Hey, render—I want to load a tree asset or I want to load like a gun or whatever it is, right?’ Just render it here. I want to build up my scene and my rendering and my game logic from a blank C# project. It’s not for everyone. I don’t think it’s ever going to replace a game engine. I don’t think it’s for everyone. But that for me was actually what I’ve always wished existed. That’s why I started building it.
Yeah, it is a passion project. I’m probably a better software engineer than I am a game designer, so it’s probably a good place to be. But yeah, for me, it’s delivering a need of something that we don’t currently have in the ecosystem.
Jamie
Because otherwise, what you’re going to end up doing is—I don’t know if you’ve seen them, but there’s a wonderful series, and I think it’s still going, and it has been going for I want to say ten years, and it’s called Handmade Hero.
Ben
Jamie
Ben
Jamie
Ben
But yeah, I think that there’s a space. I mean, there’s other advantages too, actually, of having a library like TinyFFR. If we broaden our scope out of perhaps game dev a little and look at maybe the wider industry, like scientific and industrial applications or 3D modelling and perhaps even tools that are built for games or game engines. I think that there’s probably a really nice space there.
For example, let’s say you wanted to build like a 3D model viewer into your tool chain, right? You could build a little Avalonia app—TinyFFR integrates with Avalonia or WPF—and you could write some tool that could inspect your exported models from Blender before you put it into your engine within, you know, that would be like a night’s work. Whereas before you would have to have some expert in OpenGL or DirectX to write all of that rendering scene for you. So I think there’s that portability of the library, which I also think is quite useful. But as a game dev, me, I’m always envisioning using it for making games as well. But yeah.
Jamie
Whilst it isn’t maybe as rapid as that, if you have a 3D asset and you have the right lines of code, you write maybe 20, 30, 50 lines of code, hit run, and there’s your thing with some lighting applied to it and maybe if you’ve got one, a texture as well, right? You’ve gone from zero to that rapidly, very rapidly.
For me, regardless of whether you’re from the 3D modelling space or just a dev trying something out on your machine, that ‘go from zero to that that quickly’ is the dream, right? Because then I’ve gone past the point of the toil and the setup.
We were talking offline about how the last time that I did stuff with 3D was back at university and we did it with OpenGL. At that point, we were pulling in a DLL and dynamically loading it, right? We had to do P/Invoke to get to it. This particular library wasn’t—this was .NET Framework, right? .NET Framework 2.0. This was, I think, before NuGet as well, right? So you had to put the DLL in the same directory as your EXE and hope that it worked. But then there was loads of setup required. You had to P/Invoke a bunch of stuff. You had to create a window handle. You had to do all this stuff.
Once you had the 200 lines of requisite code—not including all the other cruft that came with it, like all the namespace declarations and the braces and all that—once you had the 200-plus lines of code, you’ve got a black screen. Then you started working, right?
Whereas this, it’s like dotnet new, copy-paste 10 lines of code, boom, you’re in.
Ben
Yeah, that’s basically it. The nice thing about where you start from there is you have a lot less out of the box than maybe you would with a game engine or something. But you’re in full control of what you’ve got. You know everything that’s happening. You’re rendering everything as you’ve written out in C# in those 20 lines, and you can build on top of that. For me, that helps me keep that context window of what’s going on a bit lower, which I quite like as well. But yeah, I’m really, really pleased to hear that you had such a smooth and rapid experience with it. That’s definitely part of the point for sure.
Jamie
Ben
I went through about a year of just playing with the effects processors rather than making any music. I think actually once I sold a lot of my gear and reduced it down, I actually became quite a lot more productive. I think that’s probably similar to what you’re saying there, I think.
Jamie
Ben
Jamie
The big one for me is the documentation. So when it comes to reading through documentation for libraries, for me it’s always a big thing about how do I get started quickly? But also—and you can tell where I’m coming from with this—how do I get started securely? Now we don’t have to worry about the secure thing with TinyFFR, because it’s a fun 3D application—you don’t have to worry about, ‘Wow, this is going to steal my credit card numbers and stuff,’ right?
Ben
Jamie
We were saying—I was saying offline—how you can read through the documentation and there are sections that are collapsed. If you don’t expand them, you don’t necessarily need to know what’s in the collapsed sections because it’s like, ‘Here’s some of the theory behind how it works,’ or ‘Here’s what we’re actually doing,’ right? So if you expand them, your knowledge increases a whole bunch, right?
I feel like a lot of library maintainers and documenters don’t do that. I feel like they should. Rather than just going, ‘Oh yeah, just put the number three there and it’ll be fine,’ it’s like, well, why am I doing that, right? What’s going on here, right? Oh, this is our default. Right. Why is it your default?
I genuinely feel like the documentation there is designed. I mean, you said yourself, right? You’ve come from a games development background, a games design background, a musical background as well. So all of that will be mixing in as well. This is why I always say to people, have an interest outside of development, because you can bring it back to your own practice.
So I just want to talk to you about and ask you some questions about the documentation, right? I can imagine if you’re elbow deep in something, taking the metaphorical step away so that you can see where a new user is coming from is actually quite difficult, especially with a topic that is—mathematics and 3D rendering go hand in hand.
I suck at maths and I used to teach it, right?
Ben
Jamie
Ben
Jamie
Ben
Jamie
Ben
Jamie
Ben
Jamie
Ben
Jamie
Ben
Jamie
Ben
I mean, I think we all do it to some extent in our day-to-day work. You need to have that skill. But I think if you’re trying to appeal to the evening hobbyist who’s got an hour after they’ve put the kids to bed and cooked dinner and, you know, I think you need to go a little extra for that.
Yeah, in terms of taking a step back and putting yourself in the eyes of someone who maybe isn’t au fait with what you’re working on, I—yeah. It’s almost like a form of empathy, I suppose, but for me, the reason you don’t see it as much is probably not because people aren’t capable of that or want to do that. I think probably the reason most documentation out there is poor is because software engineers just aren’t given enough time to make it good, right? I mean, management don’t really care, they don’t see the tangible benefits, so yeah, that’s typically the way these things go, right?
But again, with a hobby project I get to be my own manager. Frankly, it’s taken me an awful long time to get to this point, so maybe there’s a reason people don’t do it this extensively. But yeah, it’s one of the benefits of it being completely under my own control, I suppose. Yeah.
Jamie
Whether that is an end user of the software, you know, your grandma or the butcher or someone like that, right? Or your best mate using an app, right? Or whether that’s another dev or anywhere in between, right?
The idea of taking a step back and trying to empathise with what is it that they’re trying to achieve. I’ve said to them, right, and this is an implicit thing that is provided throughout all of open source software is: I’ll make this easier for you if you just do this, right?
I don’t think many people realise that that’s the contract you’re giving out to the consumer of your library or the consumer of your API is: I will make this easier for you if you just do this. Putting yourself—reversing the roles and saying, if I was in that position, what would I want? What help would I need? How would I get started? That to me is like—that’s the pinnacle, I think, of how to come up with helpful documentation. So I think you’ve hit the nail right on the head there.
Ben
I think that’s—it’s almost like another form of documentation when thinking out loud, but it is another huge part of that for me. But yeah, I do—yeah, it’s definitely an empathy thing. It’s being able to step outside and put yourself in the shoes of someone else.
I think, you know, what you were saying about why WinForms was so popular. I can’t remember if we spoke about that offline or online, but you mentioned how one of the reasons why WinForms took massive hold when C# first came out was because it was so easy, right?
Even if we look at it now from a technical—we put our technical hat on and we say, well, actually there’s a lot of problems with WinForms, you know. You really should be using WPF or something like that. You know, it’s far superior in the way it’s built both in the back end and the way it forces you to structure your programs. That doesn’t stop people still in 2026. People will be making new WinForms apps, I guarantee it. Because it’s just—it prevents that initial intellectual hurdle that something like WPF, which is definitely a better technology, but you need to put in the effort and the work to learn XAML and the way that WPF does things and arguably it’s not that well communicated. So I definitely think there’s value in something being designed with empathy.
Jamie
Ben
Jamie
Well, okay. I can grab Tkinter or Tk or I can grab WinForms or I can, you know—I’m going to upset some people, maybe not modern Angular or React because I feel like they’ve gotten way too complex. But you can grab something like that, right? There is a file picker component. That glues in with the UI component. Then that can be glued together with the ‘here is where my block of custom code in perhaps a thread exists,’ right? All of these things are taken care of. Just give me the ability to select a file from—because maybe I’m not building it for me. Maybe I’m building it for, you know, my mum. Or maybe I’m building it for someone who is—you know, my neighbour or someone like that who isn’t really technically au fait. They just—they’re never going to want to see a command-line interface, but they’re going to want to see a window, right? They know what to do with a window, right?
Even the youngest people in my extended family, they know what to do with windows, icons, menus, and pointers. But if I give them a black screen with a blinking cursor…
Ben
Jamie
Ben
They reach for WinForms every time. It’s not a failing. They’re very, you know, extremely competent, accomplished, intelligent, educated people. It so it’s not a problem that they couldn’t learn WPF. It’s just they’re going to ask, well, why should I, right? When there’s something that works so much easier. Not every application needs to be that complex.
Circling back to TinyFFR, I think it’s analogous to that perhaps where, you know, not everything needs a game engine, perhaps, to render stuff in 3D. Or the alternative is that, you know, if you want to take your command-line example, right? You’ve got your raw DirectX or Vulkan or OpenGL or whatever. That’s like your command line, and then you’ve got your game engine, that’s like your WPF or something like that. Then there’s this missing—there’s no WinForms in the 3D world. So that’s, you know, perhaps where TinyFFR maybe is aiming at.
Sponsor Message
Today's episode of The Modern .NET Show is brought to you by RJJ Software: strategic technology consulting for ambitious SMEs.
You know me as the host of this podcast, but here's what you might not know: I'm also a former Microsoft MVP who's helped businesses from Formula 1 teams to funded startups transform technology from a cost center into a competitive advantage. At RJJ Software, we specialize in three things that matter to growing businesses:
- AI that actually delivers ROI: not hype, just practical implementations that pay for themselves
- Developer Experience optimization: we've helped teams achieve 99% faster deployments and 3x productivity gains
- Strategic technology decisions: from architecture reviews to fractional CTO services
The difference? We don't just advise. We ensure successful implementation through knowledge transfer to your team.
If you're an SME leader wondering why your technology investments aren't delivering, or you're facing critical decisions about AI, modernization, or team productivity, let's talk.
Visit rjj-software.co.uk/podcast to book a strategic consultation.
Now, let's back to today's episode...
Jamie
All those—the compiler and all of the language that you have to learn and all of the raw APIs. Like you said, yeah, there’s a space in the middle for: I just want to draw something on screen that looks really cool, and then I can start applying different lighting effects to it or figuring out what a camera is.
Because I can imagine that something like TinyFFR would be really good in an education setting, right? Because you’re not having to leap directly towards a game engine and go, ‘Right, cool. Here’s a camera that you don’t need to know about yet. Here is a projection map, which you don’t need to know about yet. Here is a rotation matrix you don’t need to know about yet. Here’s a shader that you don’t need to know about. Here’s a million things that you don’t need to know about yet. We’re going to change this one tiny thing and then draw a person on screen.’
Whereas if you dial it back far enough that you get to TinyFFR or something similar, you can be like, ‘Cool, here’s 20 lines of code that sets everything up, and here’s a model. Guess what? It’s on screen,’ right? Now I can talk to you about how a camera works and now I can talk to you about what a scene is. You know, by stripping things back—like we said about your example with your journey recently with being a musician, right? Stripping things back actually opens things back out for more creativity sometimes than actually ‘Here’s a million billion squillion buttons that all do something different.’ Well, actually, like you said, I’m going to be distracted by the choice.
Ben
But you know, for me definitely, I get overwhelmed by all of that configuration. I also find that large game engines, because they are catering to all—they tend to have multiple ways of doing the same thing and I find it very frustrating to try and work out, you know, I get stuck a bit, you know, trying to work out well what’s the right way. You know, they’ll often have documentation that’s a few years old and you start going down that road and you realise, ‘Oh, actually, we—you know, they’ve completely changed their scene graph since then and you should be using this new method,’ right? So that’s like DOTS in Unity.
Ben
Jamie
So I was playing Clair Obscur: Expedition 33 or whatever earlier today. That is like—it is gorgeous. If I could have shown my six-year-old self that and said, ‘Guess what you’ll be doing in 30-odd years?’ it’d have blown his tiny little mind, right? Right. But also that six-year-old is also looking at Super Mario Bros. 3 and seeing almost the same—they’re interpreting it as almost the same graphical quality, right? Because your brain’s doing part of the work too.
Ben
Jamie
Ben
Jamie
No one starts out their life of being really into cars by buying spanners or wrenches, right? Nobody starts there. They start with, ‘I’m going to buy the car and then I’m going to look into what I like about it, what I can improve on it, what I can modify with it.’ You don’t start by buying the ratchet set that you will eventually use to modify your car, right?
That’s where people I think fall over when they start with, ‘I’ll start with an engine, build my own and build up.’ Whereas actually what you want to do is start with something like an XNA, like you did. Build up from there. Because then all of the fundamentals are taken care of. You get to do the fun bit, which is make a game, right? That bit is fun.
Building an engine, and I’m sure there are people out there who absolutely love building video game engines. But building video game engines is like enterprise software development, right. There’s loads of boring bits and there’s loads of bits that are really tough and loads of bits that just—it gets you down and you can’t figure it out and then suddenly you figure it out. But in games dev, you’re moving pixels around on screen immediately, right? You can actually feel the sense of enjoyment while you’re doing it. Then you throw it to someone to play and they’re like, ‘Oh my goodness, you made this, this is awesome,’ right?
Ben
Jamie
What I always tell myself at that point is that when the impostor syndrome starts to come out, I always tell myself, you’re only feeling it because you care. You don’t—what was it? I once read an article about this chap who said these words exactly. He says, ‘You only get impostor syndrome about things that you care about. If you are making a microwave pizza at 2 o’clock in the morning because you’re hungry, you don’t get impostor syndrome. But whatever you do for work matters to you. Or whatever you do with, like if you have children in your life, in your family, or whatever, right? You’re looking after them, maybe you feel a sense of impostor syndrome, but that’s because you care about what you’re doing, right? You don’t feel impostor syndrome about stuff you don’t care about.’
Ever since I read that, I was like, ‘Wow, that has completely changed my attitude on that whole thing, that whole oeuvre of modern pop psychology.’
Ben
Jamie
Ben
Yeah, both the README on the source and the documentation site—if you don’t even want to read the Hello Cube tutorial, if you scroll to the bottom of the page there’s literally a condensed example of the whole thing and you can just copy and paste it into your IDE or your editor. You just need one NuGet dependency and you can copy-paste those 20 lines, hit run, and all being well, you should see a cube that you can spin around by holding the spacebar, I think. So yeah, I mean, go for it. If it doesn’t work, please raise a bug and call me an idiot, but let me know and I’ll try and fix it.
Jamie
Ben
If you’re angry about that—there’s no v-sync support, for example, in TinyFFR on macOS at the moment. It’ll come one day, but if you’re mad that it’s not there now, point your fingers at Apple because I don’t want to spend another 90 quid to rent a Mac for a month until someone really, really needs it. So that’s the way it is, I’m afraid.
But yeah, the Linux support was probably the more technically challenging, but only because—and I’m not the first developer to ever say this, but Linux is more fragmented, so when we talk about Linux support, that’s not really a thing. You’re actually asking which distros am I supporting, which desktop environments am I supporting? You know, the compositor, Wayland versus Xorg or things like that. So it’s more like supporting three or four different additional environments to some extent.
Jamie
Ben
Jamie
Then on top of that, you have a whole distribution of software, which is why it’s called a distribution of Linux, right? You might have Debian, which has a whole bunch of software built on top of the Linux kernel to give you a desktop that you can interact with. The problem with that is that every single person who could possibly ever come up with a desktop idea, an idea of a desktop, has created it, right?
There are desktop environments that map onto Windows, desktop environments that map onto macOS, desktop environments. One of my favourites was from Compiz, which was a cube. So on macOS with the trackpad, you can move three fingers up and you’ll get what used to be called Mission Control. I don’t know if it’s called that, where everything zooms out and you can see your whole desktop all at once with all of the different apps. Well, you could do something similar to that, but what would happen on Compiz is your screen would zoom out and you’d see the side of a cube and you could rotate the cube and that’s where your other desktops were.
Which was really cool, but really hardware-intensive. The problem is that because each one of these acts differently, they all have their own set of libraries that they use. Some of them use the same libraries but different versions, and those different versions are only available for certain types of machines, right?
When you say ‘support Linux,’ what you really mean is ‘support absolutely everything that’s ever been built ever,’ including the one person who lives in their house and never leaves their house and has built their own distro that is specific to them with their specific choices. Because they’re going to find your library and they’re going to say ‘doesn’t work on my machine and therefore it sucks.’ That’s not very nice. So ‘supports Linux’ is a whole world of things.
Ben
But yeah, I’m also moving on to Wayland and I currently support X11. I probably will backseat X11 for the foreseeable future, just because it seems like things are slowly finally moving onto Wayland across most of the distros, but yeah, it’s not an ideological decision for me, just a practical one.
Jamie
Jamie
Ben
So far I’ve no desire to go back. But yeah, one of the biggest strengths is I get to choose. So for me, KDE—I should mention, so for again for the Windows and Mac users here, so obviously I think probably most of them will know of Ubuntu, but Ubuntu ships by default with a desktop environment called GNOME or Unity, depending on how far back you go.
It’s very bare-bones to me. It’s actually a little bit Mac-like, which maybe, you know, probably why it’s the default, because that’s probably the preference for a lot of users, but I prefer a little bit more configuration and power, so I’ve configured a Kubuntu distro with KDE. So even if someone who was previously 20 years a Windows user and has just switched onto Linux, I’m already off the default path. So yeah, which is great. But yeah, it just shows that how fragmented things have become very quickly. Yeah.
Jamie
The idea was, if you built and sourced all of the pieces of software for your machine, it would, A, be tailored to you, but also it would be optimised for your hardware, right? Which is fantastic. But also, you know, you need to be Zen Monk level of computer science to be able to do that.
Ben
Jamie
Ben
Ben
Jamie
Ben
Jamie
Ben
Jamie
Everybody was saying it will never catch on, but also it will never be fast enough to do anything useful, right? I love to turn to people and go, ‘Look at what you can do,’ right? We’ve got TinyFFR on one side, we’ve got Blazor on the other. We’ve got Unity and Unreal, which both have .NET-y things built into them. You’ve got Godot, which also has .NET-y things built into them, right? Look at where we are, folks. This is amazing.
Ben
Jamie
Ben
Jamie
Ben
Then yeah, if you want to talk to me, I am probably easiest to reach these days on Bluesky. I’m trying to stay off some of the other social media sites. So yeah, Bluesky and at—I think at XenoPrimate is my current name. I’m sure Jamie, you could put it in the link there somewhere.
Jamie
Ben
Jamie
Ben
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.
Useful Links
- TinyFFR
- Ben’s links:
- Supporting the show:
- Getting in touch:
- Podcast editing services provided by Matthew Bliss
- Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show
- Editing and post-production services for this episode were provided by MB Podcast Services