Sponsor Message

This episode is sponsored by Rider from JetBrains.

Have you heard about Rider, a cross-platform .NET IDE developed by JetBrains and based on IntelliJ Platform and ReSharper? If not, it's time to give it a try! Develop .NET, ASP.NET, .NET Core, Xamarin, or Unity applications on Windows, Mac, or Linux. Get Rider today at RiderIDE.net and try it free for 30 days!

Embedded Player

Supporting The Show

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

Episode Transcription

Hello everyone and welcome to THE .NET Core podcast - the only podcast which is devoted to:

  • .NET Core
  • ASP.NET Core
  • EF Core
  • SignalR

and not forgetting The .NET Core community, itself.

I am your host, Jamie "GaProgMan" Taylor, and this is episode 31: The Liberal Arts and Levelling Up Your Career with Thomas Betts. In this episode I interviewed Thomas about some of the ways that you can use the teachings of The Liberal Arts to enhance your career and make you a better communicator; we also discuss some of the things you should talk about with your customers when they want you to use a new and untested technology for their next, mission critical application. Some of you may know Thomas from his work at InfoQ as lead editor of the architecture and design queue, or his work IHS Markit. My thanks go out to Arlene Andrews for helping to set up this interview with Thomas.

So lets sit back, open up a terminal, type in dotnet new podcast and let the show begin.

Thomas's Introduction

Jamie
Thank you so much for taking some time out today, Thomas. I know that obviously, you must have a very busy schedule anyway, you're high in demand, I would say, and it's great to be connected with you and talking to you today on the podcast. So thank you very much for that.

Thomas
Yeah, thanks for having me on. It's good to be here.

Jamie
Before we begin, I thought it would be a good idea to, if you could just sort of introduce yourself to the listeners, in case they don't know much about you or haven't heard of some of the work that you do.

Thomas
Yeah. So if they know me publicly, is probably through my work with infoQ, I'm one of the editors. I'm the lead editor for the architecture and design queue. So I've written a lot of news and written a few articles and reviewed a lot of articles on that. I've been doing software development professionally for two decades. Personally, I started you know, coding when I was a kid on an Apple][. So yes, it's one of those things that just started as a hobby and and became a career.

Jamie
It's a topic that comes up a lot when I talk to developers both on the show and you know, just sort of in person is that sort of origin story, if you will, for each developer. Because you know, every developer is different. And, you know, there's the common origin story of, I guess, people of maybe of our generation, yours and my generation have, "I had a computer when I was younger, and I started playing around with it. And I made a thing, and then I got really hooked on it." And, you know, early in the, in the show's history, I talked to a few developers, and they were sort of sort of along the same lines. But I've talked to a lot of people recently, who are maybe transitioning from one career to another and going to code camps or teaching themselves. So it's, it's useful to sort of when, when interacting with another developer, on in a professional environment, I guess, to know this sort of a little bit about the backstory like, "Oh, you came from a computer science degree, right? Okay, I know that I could talk to you about," we mentioned off-air, Fast Fourier Transforms, I know that I can say that to someone who has maybe a computer science degree, but I may not be able to have a full end outcome for about FFTs with someone who's come from maybe a coding camp, or maybe I can I don't know, I don't know, what the code boot camp education system is like, I only know from my own experience of having done a computer science degree that I know what an FFT is.

Thomas
Yeah, I think it also is good to, you know, get rid of some stereotypes. I think for a while, there was always the, especially now I'm one of the old white guys, and in programming. So there's a lot of people who look like me and have my story. But working on a very diverse team, with everyone having a different background and a different story of how they got there. I've worked with a few people who came from a teaching background, and they still bring some of that teaching mindset to the project they're working on as a software, you know, coder, and so they're always wanting to learn more, and they want to help other people grow. And that I think helps boost the team. Very, I'd actually say there's probably a smaller percentage of people that I've worked with on the teams that I've really enjoyed over my career, that have a traditional computer science background, I came from an engineering degree myself, so I, I don't really have a whole lot of formal computer science training. I've taken a few classes, obviously. But it's kind of that how do you approach a problem? How do you solve this, and just having, you know, the ComSci chops, if you will, how to write clean code, science doesn't bring you enough that you... It helps to have other people's perspectives to help come up with the best solution for you?

Jamie
Definitely, definitely. And I think I was saying this to someone on an earlier episode about how, you know, your solution to a problem may be slightly different to my solution to the same problem. But they are both equally valid, as long as they solve the problem. And you know, I can learn from your solution, maybe a new technique, or a different way to use a sort of pattern or anything like that. So it's incredibly useful to exchange that information, I think to say, "Oh, cool. So you've written FizzBuzz in this way? Well, I wrote it this way. And let's look at the differences." Not in a critical way. But in a, "let's see what I can learn from you and, you know, not trying to be presumptuous or anything, maybe there might be something you can learn from me," you know, it's all about sharing that knowledge.

Thomas
Yeah, I like the idea of egoless programming that, "yeah, let's let's talk about the code together. Because we can both understand that." And let's talk about that. And let's talk about the problem at hand and get away from, "Well, you're not a good programmer, because you didn't write it my way." So yeah, it's good to go do things differently.

Jamie
Definitely. And then, you know, that links into something that we were chatting about off-air just earlier, when we were talking about how a recent blog article that you've written about how liberal arts education, I believe it was can help engineers to break a problem down. And I'd said that, you know, the UK education system is completely different to the American one, in that, you know, we don't tend, when we're a university or college level, sort of, we tend to pick a curriculum to study. So I studied Computer Science. So my degree is Computer Science, I don't have a major or minor, I guess I do have a minor because I studied Japanese language at the same time. Whereas I believe, in the US, when you go to college, you have to pick a major and a minor and, you know, you work towards a, "I will have a Bachelor of Science in" is that kind of the case?

Thomas
Yeah, so I'm different from some universities in the US, but a lot of them do have a Bachelor of Arts or a bachelor Bachelor of Science and and there's certain degrees like mine, that is a Bachelor of Science in Mechanical Engineering. So that's different than a Bachelor of Science with a major. But it's a subtle difference. I think what I was really trying to express in that article was the idea that you can be a good programmer, and you can be a good software engineer, because you need to have those ideas of, "how do I write code," it's good to know different languages, it's good to know different architectural patterns. But there's a lot to solving a problem and writing good software and software that people want to use that traditional hardcore Computer Science doesn't teach you

You know, and in the US, we have a big push right now for STEM education - science, technology, engineering, and mathematics. And people are saying, "Oh, we need to get more kids to go into that. So we have them prepared to do these high tech careers." And it's almost coming to the detriment to the arts, the studying of the liberal arts, in general, which covers, you know, not so much, "I'm going to go to school to study Computer Science, so I can be a programmer," or "I'm going to study biology, so I can go and be a scientist." Liberal Arts is kind of the "What does it take to become a good contributing member to the free society that we live in? How are you able to interact with other people? How can we teach people to have empathy and understand someone else's perspective, and realise that everything you know, isn't the scope of everything that there is to know?" it's a lot of understanding your audience. So if I'm talking to you and talking to your listeners on your show, that are probably a technical audience, we can engage in those technical topics. But if I'm going to a conference and presenting, and it's a broader audience, and it's not just technical people, I'm probably not going to use the same technical language. Same thing, if you're writing an article, and you want to have just technical people read it. And that applies throughout everything you do in life. If you're writing software, you're not writing that software for other computer programmers to use, you usually have customers and being able to understand them, and realise how they're going to use the software makes you write better software; makes you better at testing it; makes you work better on a team, because you're all on that same goal of , "what is it that's going to delight our customer, that's going to make them want to come back and keep using our software every day?"

Jamie
Most definitely, most definitely. And I think the same can be said, when talking to any kind of non technical person, whether that's a customer or a family member, or someone in the street, although what you're doing talking to people in the street about programming, I'm not sure. But you know, the same thing can be said, I guess you need to kind of, and I don't want this to sound condescending at all. Because we all have different experiences and backgrounds, you need to find the sort of common language that fits with your background and your target audience's background, I guess, and speak to that, rather than, you know, like I said earlier, and I mentioned Fast Fourier Transforms. If I'm standing in a room full of healthcare professionals talking about how I'm using that to help their system do something, maybe it's an ultrasound or something, then, you know, they're not going to want to know about the nuts and bolts of how I've done that how I've implemented at FFT in C# or in F#, they want to know, "how do I use the thing they use to get the data that I need to make the decision that needs to be made for this specific situation?" You know, and I think you're right, I think it's it's something that's lacking from especially from the the current push, we have a similar push in the UK. They're saying that, "every every child under the age of 16, needs learn how to program and to write code, because," and then they sort of ditch out of the sentence very quickly. I mean, it's a valuable skill to have most definitely, but I don't think it's for everyone. I mean, I worked as a teacher for a little while. And I did run some sort of after school classes for people to learn how to go. And, you know, maybe it was because it was after school. So we're talking 4pm, you know, and they've had a full day of being at school, they've decided, actually, I want to go home and relax now. So trying to force people to do that, even when they've elected do it is hard. So like forcing people to do it, when they don't want to do it. I'm not so sure.

Thomas
No, it's one of the things that can almost be, you know, counterintuitive to get people to think differently. In fact, I was just reading this morning, there was a New York Times magazine article about Rick Steves who's a travel guide, he's on PBS out here. It's been talking about travelling to Europe for 20 years, taking people to Europe, it has a whole following to read his books and watches TV shows. And the the premise of the article is, "to become a better American, you need to go to Europe," that if you are the type of person who just wants to, you know, stay in American hotels, and your idea of a great vacation is always going to Disney World, you really need to step outside your comfort zone and see the other people and how other things are, you have a better appreciation for your life. And it'll make you want to go and meet other people, you know, kind of get out of your own bubble.

And I think one of things I was talking about in that article is, you know, if you're in the engineering, like my campus for college, really had engineering and sciences for on the south end of campus. And the rest of the core classes are on the north end of campus, there was actually this, you know, street that kind of divided them. And so you knew I was walking over to take my English class or Philosophy or Economics, whoever it was and over here is where I take my science classes, you kind of acknowledge that you're going into this different world. And I don't think there should be such a hard line, like all those skills, you're learning one subject can carry over to the other one, even if it's not obvious to how you're going to use it. And being able to expose yourself to that and find other opportunities to learn things that are outside of your technical field. Like it's easy for a developer to say, Oh, I want to learn F# because it sounds really cool. And I think there's times when I could, you know, benefit from using functional programming paradigms as opposed to object oriented paradigms. So I'm gonna go off and learn F#, it's much harder for someone to say I want to spend, you know, a week taking a class in poetry or, you know, philosophy, like how does that affect my day to day job as a software programmer, and in fact, it usually does, like, you'll get some insight, it's going to be indirect, but you'll come out of that, and having a new experience or a new perspective that you can use in your your day job. As an engineer.

Jamie
I found that, so really, really badly play bass guitar. And, you know, just knowing about the musical notes, and how a few of them sort of link together to make music gives me a greater appreciation of the music. But it also helps me to sort of understand the engineering process - because it is an engineering process, I guess, maybe I'm thinking about it from an engineering perspective - but the engineering process of writing a song or coming up with a melody or recording something, you know, when I'm thinking about recording something that I've written, I have to think, "right, okay, I have these modules, and I plug them together, there's an interface." And you know, so my bass guitar doesn't connect directly to the computer uses dependency injection, the version of control, sorry, to connect to a DAW, a digital audio workstation, which knows how to connect to the computer and it converts all of this stuff for me; in the same way that a lamp uses inversion of control to plug into the socket in the wall, rather than wiring it directly into your electricals in your house. But then that's because I'm an engineer. So I'd say again, from these weird points of view, but I can understand why they exist.

Thomas
Yeah, I think, you know, we speak in metaphors in day to day, life all the time, it's complicated to understand some new concept. So I'm going to use a concept that everyone does understand that's different, but at least says, "Oh, I understand how that works. And this is kind of like that." One of the comes up a lot: we were using a metaphor of ordering coffee to be asynchronous and message driven programming, that you walk into Starbucks, wherever the coffee shop is, and you place your order, and they write on the cup, but drink you want. And then you stand back and wait for someone else to pick up that cup, they read the message on it, they say, "Oh, I'm supposed to make this, you know, latte with a shot of caramel in it." And they go through the process and put it through to the end. And then they raise an event that says, "hey, this coffee for Thomas is now ready," and they set it on the counter. And I respond to the event pick it up. And you know, I wouldn't explain event driven architecture to a layman outside of software engineering, but I can talk to them about ordering a drink at Starbucks. And they get that and then I say that's how our software works. :Oh, okay.: You have that understanding.

Jamie
I have to say, I really like that coffee metaphor. I really like it. I may have to steal that.

Thomas
Someone did a lightning talk at Explore DDD one or two years ago, I think it's available online. I don't know if they came up with it, or they just shared it. But it was, it's always stuck in my head. It's a great, simple way to talk about how communication is one of those things that humans do all the time. And we talk about software as having all these complex communication patterns. And "oh, I have microservices. And they've got to be better than my monolith right?" Well, have you just introduced a different communication problem? Because you have all these things are trying to talk to each other? What have you we're in a crowded room, and everyone's trying to communicate, is that more chaotic than only one way for the messages to go through the system? So stepping back from the software to think about how would this be modelled in the real world is sometimes a really good exercise.

Jamie
I like that.

The Use of Metaphor

Jamie
Definitely, folks should check out your your article on the liberal arts and how they can help with breaking down a problem because at the end of the day, we're communicating a problem. At the end of the day, that's kind of our bread and butter as engineers, you know, okay, so we do write the code, but we take what somebody else has told us, is their a problem, we create a solution, we communicate with our person, the solution we have, we are going to create, we agree on that. And then we translate that into code for the computer. So we're almost like we're acting almost like a translator. So yeah, you need to be able to sort of context switch - I dont know whether "context switch" is the correct word there, but being able to sort of go, "Okay, for you, the business owner, the project manager, the problem domain person, you have the expert knowledge of that, and I'm going to converse with you and figure out how we're going to solve this, I'm then going to go away and create forms-over-data. But I'm not going to tell you that I'm going to use messaging systems, or I'm going to use whatever tools I have. But I'm not going to tell you about the tools that I'm going to use, I'm going to tell you the information you need to know to understand it." Whereas with your example there about the coffee shop, "I don't want to tell you about microservices and message queues, and retries and all this kind of stuff," because it's way too complex. But if I can tell you like you say, "hey, you go to a coffee shop, you order a coffee, this is what you do. This is how our software works. That's all you need to know." And then I translate that into code for the system.

Thomas
Yeah, I think that gets to I think started this conversation between you and me. My first start getting connected was using .NET. Core in the early days, how do you convince you know, the business people involved that, "hey, we're going to try this brand new technology, because it has all these advantages." And if you go too much into the "well, it's it's a different framework, and it's got all these..." you know, they don't care about that, you know, as long as it is back it up into the economics like, "oh, we're going to save money," or "we're going to be able to do containerization. And that's going to be great." Well, why would I want to do containerization? What, what does that mean for me as a business? And you say, "Well, we've had this problem in the past, where we haven't been able to be agile enough and respond to, you know, when we have scaling events, or whatever it is, that when we have peak load on our system, we can't respond quickly. And this is one thing that makes it easier for us to do that. Oh, so remember that time back in April, where we, you know, had whatever happened on a server went down, we This will help us avoid that in the future." So put into their perspective, and then you can say, "and because of that, we think it's worth it for us to go off and invest the time to learn this new product. And this can help you be how we write software in the future."

Jamie
Definitely, I really like that. So yeah, definitely. I'll put a link in the show notes. So listeners, click through to the show notes, please. And definitely check out Thomas's article on the liberal arts. And maybe there's a way that you can study the liberal arts in your own time, I don't know, I haven't got a clue.

Thomas
Some of it is simple things like pick up something that's not what you'd normally read: find a book in the library that you'd have no interest in reading the and just be surprised that you get someone else's perspective. You know, go go take a trip somewhere, go to a different colour, a town that you don't usually go to and meet other people. And then talk to people talk to people you work with and find out what is their background, going back to we said earlier. Realise that, especially if you get outside your software development team, you're going to have a lot more people, how did you get to where you are today, and having that, you know, learning about empathy, and learning about just other people's background. And some of that is those intangible stuff. And then if you want to, you know, find a community college and and take a course that says hey, I want to study, you know, Russian literature or something really random, just because it's often that you know, a different part of your brain.

Jamie
I know that I mentioned playing bass earlier on but I think that learning a different language whilst I was at university helped. Because I noticed that I would, I'm not still not very good at it now at communicating using my voice. But I noticed that I would take a step back and think about the words I was about to say before I would say them and make sure that they are in a good enough grammatical sentence that the other person could parse it because a lot of the people that I was studying with, we're studying Japanese in English, but they spoke a completely a third or fourth language. So anything that I could do to help them understand what I was trying to say in Japanese helped, and then anything they could do to help me understand what what I've gotten wrong, in English, when I was trying to speak in Japanese, although it was their third or fourth language helped as well.

Thomas
Yeah, yeah, there was a really good presentation I enjoyed last year. Again, Explore DDD, it's a conference, it's in Denver. There's DDD conferences all around the world - Domain Driven Design is the acronym - but it was a Laura Savino, and I wrote an article about it for InfoQ. And her presentation was on readable code. And she actually had before she was in software had been a French language instructor. And so she made all these parallels to not just how learning a language can help you become a better software developer, but looking at how you write code, and how you learn a new language, like when you learn a new language, that first stay in class for you're able to have a conversation with your classmate and say, "My name is Thomas, and I would like to go have a cup of coffee." And then eventually you get to the, "hey, let's just meet up after class and we'll go have coffee." And it's just more casual.

And seeing someone learning C# or some new language for the first time, their code reads differently than someone who's been writing code for 15 or 20 years, you start writing a lot more that shorthand in the way that your speech becomes more shorthand, you don't have to go through the very, very structured language you've learned is like a first year foreign language student. And I love that parallel of "Oh, I understand that the way I right now is not the way I would written this 20 years ago." But is it harder now for someone who hasn't got 20 years of experience to read my code, like if I start talking in shorthand, because that's how people talk now, someone coming into the conversation is gonna, or someone who doesn't have English as their, their first language is going to come in and be really confused about some of the idioms I'm using. So you know, for your code to be readable, you kind of want to step back and say, "I can still make this understandable, but I don't have to spell everything out. And I don't have to shorten it." There's a happy medium in there.

Jamie
I like that. It's almost like, I guess you could compare it to informal language and formal language, I guess. So when you first and studying a foreign language, you're actually learning the formal version of that - at least if you go to a class, take a course go to college or something - you're learning the formal version, the proper version, as they were

All of the grammatical constructs and making sure you're not, if you like, if you study English, you have to learn to not split infinitives, or things like that, making sure that the right adjectives are used in your sentence structure is correct. But then like you say, in 10 years time, you can be throwing out sentences that don't make no sense And like you say, you can do the same thing with code. So like, if you're a first year, or if you have no experience, you're looking at any kind of code, you're not a tech worker in any way. And somebody shows you some C# that has inline lambdas, and ternaries, and calling LINQ and using FluentAPI's and all that kind of stuff, they're going to be overwhelmed. Whereas if you show them a Console.WriteLine("Hello, World!");, or Console.WriteLine("Hello Thomas!"):, or Console.WriteLine("Hello Jamie!");, it may take a few minutes to for them to parse it. And they may need a little gentle prodding in the right direction. But you say to them, "you're using the console, you say write a line. And here's the line." Whereas you know, you're not having to do a lot of crazy stuff around it. But then maybe in 10 years time, you're used to writing huge enterprise apps. So then you write the Hello World enterprise version that has dependency injection, and it has unit tests, and it has all sorts of crazy things. There is a big difference there. And I think you're you're definitely Right, yeah.

How To Talk About New Technology

Jamie
So we're not just here to talk about liberal arts. As much as I love to talk about that kind of thing, all day long. It's very useful for helping to communicate with people. But I thought that we could talk about your approach you you mentioned earlier, and you touched on it earlier on, when you'd said about when .NET Core came out and you know, you don't go to your boss and say, "Hey, this new technology has come out, I want to build this brand new business line application in the new technology, because I want to learn the new technology," you have to come up with a business reason. But before you get to that point, how do you specifically as the person with as much experience as you have - because I'm presuming you've had this at least once or twice through your career, where any framework or a new medium or a new language or a new system comes out, and you go, "Wow, I think that would help me solve some problem in my current project." How do you, as a person, get to that point? Is there a gut feeling? Is there lots of reading and experimentation? What's your process?

Thomas
Yeah. So some of it starts with knowing what's out there. And I'd say the the number one way that I keep up with just kind of knowing the surface, what's available now is listening to podcasts, and you're listening to .NET Rocks, I'm sure most of your listeners have tuned into once or twice, for decades, or I guess, 15 years or so since they came out. And so that, that doesn't get you deep into anything. But it lets you know, "oh, people are talking about this .NET Core thing. And they're talking about Angular and whatever else." So I've been doing this since before those those podcasts were out. I've been lucky enough to have at different times my career been around other people who would also go off and explore things and try new stuff. And everyone was curious. And you, if you're in a culture of that curiosity, people will go off and find little bits of new things like, "oh, I heard this new .NET thing's coming out, it's still in beta. Let's try and write you know, the hello world or do some little sample app, just to see what it's like." With .NET Core, I think when we started on our project, about two years ago, I think .NET Core ASP. NET Core, 1.0 was out .NET Standard hadn't yet really been announced. And we had wanted to do good separation of the front end and the back end. So we knew we wanted to have just a straight API. And we didn't need to be creating web pages from our backend servers, we wanted to have a JavaScript, you know, SPA style front end. And so that already had a scope to which of the JavaScript frameworks we want to play with. And I had a little bit experience with Angular 1.x, and so Angular 2 all completely different is still familiar enough. We didn't really do a whole lot of broad research into Vue and React, one of my other co workers had done some of that and said, "hey, let's stick with Angular, as we know it pretty well."

The decision to go with .NET Core really was, "well, what are the trade offs? If we stick with the Framework, which we know it has these dependencies that we have to have, you know, an IIS server to deploy it." And while that wasn't a problem for us, maybe we wanted to have the flexibility to not do that. I think the early days of .NET Core, you didn't have everything you needed, it's gotten a lot easier over the years. And some of it was I guess, gut feel of Microsoft seem to be pretty committed to this path and was encouraging people to go down this path for doing future development, and especially after .NET Standard got, you know, announcing, "hey, if you write stuff that is compatible with .NET Standard than anybody who's on the standard can consume your library," that made it a little easier to say, "oh, there's going to be future improvements. So if we go down this path, and we keep updating it on a regular cadence, then we'll get those features that might not be there on day one."

So we saw, you know, some of the things like if you did, ASP .NET, Core 1.0, just the the Startup method used to have, it was a fluid API, but used to have like, you know, seven or eight things, you had to chain together. And everyone saw the same Getting Started examples and copied and pasted it. And then pretty soon, they said, you know, with default binding and like, "Oh, that's what I needed. Why didn't I just write that method?"

Some of it is finding out what's out there. And kind of doing a, you know, what are the other options? How much of this that we can tell right now meets our need? Is there a way to do a small sample application?For that application, I don't know if we did for the one I'm thinking of two years ago, I don't think we did a, you know, proof of concept first to find out if there are going to be any roadblocks. But we knew some of the major integration points like we were going to have to have security, "Well, what can we do to implement that? Do we need to roll our own because nothing exists, or can we use identity server?" Which was also being available for now the .NET Core version. So we were using Azure for all of our hosting. So what's available in Azure?

We also tried to swing closer to the buy versus build, we had a small development team. So we didn't have the ability to just throw a lot of developers at the problem and build a lot of stuff, how much of it already exists? It's definitely become easier over the years when I was doing this 15 years ago with a project that we were writing on .NET framework 1.0. And it was a crazy idea to say, "Oh, are we going to write this brand new mission critical application on something that's unproven and just came out from Microsoft." I think it had just been released when we started working on it. And we knew that we were going to have some some issues. And we'd have to keep, we had to allocate enough time to pay down the technical debt that we knew we were writing in. And management bought into that because we've done enough, we did one small trial application, like a two page proof of concept. And that was enough to give them the to say, Oh, well, if that's going to work, you guys can figure out the rest. So you have to have the right team to be confident that if there are some unknowns, you're going to find a way to get through it. And the internet's really helpful now. So we didn't have Stack Overflow 15 years ago, you didn't have code getting posted to GitHub. So if you want to know how something works, inside .NET now you just can go download the entire source code, say, "Oh, that's how they implemented that." You know, you don't need to, but it's nice to know that everything's open source now. And so you can kind of go and see "how did someone maybe much smarter than me solve this specific problem?" And can I use that for my, my needs? I know that's kind of a wandering example, not quite on your yet, like seven questions you asked me. So I gave kind of seven answers.

Jamie
That's absolutely fine. That covers a whole bunch of stuff. Because, like you say, there's, there's no quick answer to that question. And there's no real way to go, "right, yes, let's use this technology that no one's used, without knowing it's around." So, for instance, one of the things that I do is I help to manage a bunch of WordPress based sites. Now, I don't know that first thing about PHP, or WordPress, really, I don't tell my people that I help.

Thomas
No one will hear this

Jamie
Exactly. But you know, what I do to get an idea of things that are coming up in the WordPress and PHP community, as I you know, I go to PHP meetups in my area, just so that I can sort of ask silly, what I think are silly questions, because I'm the the person in the room who hasn't got a clue. But then I'm also learning about the new versions of things that are coming out or don't use this particular method or function. And, you know, if you're going to do this particular thing that say you having to access the database, you know, it sounds silly to have to say it, but you know, there have been times when I've inside of this meetup where someone will say, for goodness sake, sanitising room, but don't just write inline SQL queries, because someone will SQL, inject[ion] attack your website, you know, and just knowing that other people need to know this, that, you know, there isn't a, me there isn't a default way to protect against that in any language or framework. But knowing that, you know, other people have these issues, kind of helps you to think, "Oh, right. Okay, so this is an issue in PHP as well." I mean, I can't even imagine if we had to write a RESTful API web service that was a micro service that deal with asynchronous calls in C++. But knowing that there are libraries that are out there, there are languages, there are the systems around that you can use. kind of helps, I guess,

Thomas
Yeah. And I think, you know, you kind of touched on the idea of going to meetups and talking to other people, you almost have to get over that fear of, well, I'm going to sound stupid. Well. The only reason you sound smart is because you know things about one specific domain. But there's a lot that you don't know about a lot of other stuff. And everyone was just a stupid at some point. The answer is always obvious once you know what the answer is. And I think that the counterpoint to that is, after you've got a few years of experience, you kind of have this expectation in the community to go back and help out, go back and be the person who can answer that question and encourage the newbies to not feel like they're an idiot, because they're going to ask a question that should be obvious. Well, it's not obvious because it was they wouldn't be asking a question. And again, that kind of goes back to the idea of empathy and like, put yourself in their shoes. Like, you only know it because you know it now. But, you know, a year ago, two years ago, I wouldn't have known anything about .NET Core. And, you know, I can now give the explanation of, "Well, I'm confused between .NET Core and .NET Standard, what are those two things mean?" I was in that that boat for weeks, you know, trying to read it. And every time I read a little bit more, I'm like, I'm not sure I still grok this. And now I think I do have, you know, in my head, I understand it. And I hope that I'm able to convey that, that type of idea to someone else. So yeah, feel free to ask questions all the time, find those opportunities, go to the meetups, and say, "Hey, I'm looking at doing this," finds people online, read the blog articles. You know, keep learning,

Jamie
Definitely. I believe that it was Claire Sudbury on .NET Rocks! not too long ago actually said that there is no such thing as a stupid question. For the same reasons that you've just said there. You know, if you're not born with the knowledge ingrained, then you're not going to know what it is. So although it may feel like a silly question to ask it, it's not because someone else's had to ask it before you know. Do you think that say, let's say Donald Knuth, do you think Donald Knuth just knew everything about Computer Science before he took his math degrees at MIT or wherever? I believe he was MIT or maybe Stanford, you know, did he know all of that stuff before going? No. Let's pick Scott Hanselman, did Scott Hanselman know all of the stuff he knows before he started doing all of the work and asking questions? No. Did Alan Turing know how to effectively help to break the Enigma code in a much faster way by inventing a programmable analogue computer? No, he didn't, you know. You've gotta ask these questions. And like you say, you were to be brave enough to sort of step out. And it's not easy. Especially, you know, there are a lot of folks in our communities and in our industry, who, for want of a better word, don't have the greatest confidence and are not as outgoing as some people. And that's perfectly fine. I'm not saying that's a problem at all. But, you know, maybe trying to spot that someone wants to ask that question as well. And try to bridge that gap from the other side.

So one of the things that I do when I try to explain something to someone, when I'm explaining something to my kids, is I'm almost constantly asking, "does that make sense?" Because I don't know whether what I've said makes sense. So I try to help the the other person that I'm talking to, to understand what I'm saying, and then I'll switch up the metaphors or switch up the information. I'm attacking it from the other side, because I know that, you know, with with my son, he's, you know, he's seven years old, he's not going to be confident enough to stand there and say, "so how do computers work then?" You know, I've got to sort of goad into it wanting to know that knowledge, you know, but yeah, being able to, to actually stand there and go, "I think I get this Is this right?" You know, it's a difficult thing to do the first few times you do it, but it does get easier.

Thomas
Yeah, I think that's, you know, going back to the one of your questions about how do you decide to go with the new technology, I think I'd be much more hesitant if I was working just on my own. Like if I didn't have at least one other person that I could bounce ideas off of. Because you're walking down a new dark path, and neither of you have been there before. You kind of want that reassurance like, "I did this, does that look right to you? I have no idea. Let's find where the edges are, oh, we should have gone this way." It's very easy, when you're, you know, heads down writing code all by yourself to go down the wrong path. And it's hard to take a step back and look at that, I think simple stuff. Like I've had very formalised code reviews, where people would print out code and go into a conference room and review them. And change that to doing pull requests over git makes it obvious that somebody else can come by and read code and just say, "I don't understand why you did this here. Can you explain it to me?" And hopefully that turns into because they're just looking at the code on their screen, they have to type a comment and say, "What's this about? Maybe they can come and ask me." But it seems like taking the person out of the equation makes it easier for people to say, "Hey, I don't know what I'm doing here any more than you do. Let's figure it out together, we're on the same path." And then it can be, you know, rewarding when you get to the solution, say, "hey, we've used this. We didn't neither of us knew this a month ago. And now we have saying it's up and running,"

Jamie
Of course. And I think that accepting the fact that everyone is coming to new technologies with different skill sets is also quite important.

Thomas
Yeah, and realise that other people may not have had the same opportunities and background and chances to learn the thing you learn. I've walked into the room and show someone who has many years more experience than I did. And they were just amazed, like, "how did you do that? It's magic." I mean, I worked at a defence contractor. And there are people who have been, you know, writing software for 20 years, and I had, you know, a fraction of that experience. But I knew .NET, I knew WinForms. And their idea of writing a Windows application was frightening because I had to, you know, write in C++ and I had to design like, "Where's the box? And how big is the window," and they had to write all the click handlers, like, "No, I just, you know, create new WinForms app that I dropped this button on there." And like, "wow, it's amazing." And, you know, creating a Windows application in the meeting to show them it's really this easy. And they thought it was going to be weeks worth of work just to get started. Because they had never had to do that before, they had no reason to do it in their background. It wasn't they were stupid, they were very smart people, they just had no reason to go off and explore or no opportunities to, to go off and explore what had changed since the the time when they had to make a decision five years earlier of what they were going to do. And so some of that bias, you know, can linger around. That's why I think it's important to always be that lifelong learner and find out. What don't you know, and what should you be, you know, keeping up on even if you're not using it every day, just to be aware that something else is happening.

Jamie
I personally think that there's a world of difference between someone who spends 10 years working, but also looking into new technologies, versus someone who does exactly the same thing for 10 years,

Thomas
"One year of experience, 10 times," that's how I like to say that.

Putting the Liberal Arts to Use

Jamie
One of the things that I found has always helped me was showing something off via a talk. It doesn't have to be polished, finished, because it's about the journey, not the destination. Plus, teaching someone else really helps reinforce the ideas your own brain, right?

Thomas
Yeah, I think it's good to come up with that and say, "Hey, here's what I did. Let me share it." And besides you know, there's a, the Microsoft Office puts on a Colorado developer day, once a year: it's Denver developer day, whatever. But um, one of my friends wanted to speak at the event, submitted an abstract about here's how to do this new thing in, in .NET. Core, and she had no idea how to do it. And she got accepted. And she's like, "now I've got to figure out how to do it." And that act of having to force yourself like, you have that goal, if you have to be able to give a presentation showing how to do this thing, forces you to learn it. Especially if you're going to, if the plan is, "I'm going to communicate this to someone else." It almost raises your bar, "like I'm going to do a better job because I know it's not just I figured out how to do it. But I have to be able to explain that to someone else. So can I document the process kind of document my my thought and it's helpful to say, here's the end result. But here's the wrong path that I went down a few times." Like show people there's a dark corner over here, that didn't work. And yeah, there's so many meetups now you can find someone willing to have you know, you come in. A lot of them do like lightning talks even so it's like come in and just talk for five or 10 minutes about one little thing. You don't have to give an hour long presentation, because it can be very daunting to say, "Hey, I did this cool thing. I just want to share it," a lot places for what, but you come in and talk to them.

Jamie
Changing topics slightly. What would be your advice to someone who's technical director or client says something like, "hey, Thomas, let's build our new mission critical application in this brand new, largely untested technology?"

Thomas
My first question is why to make sure that that's understood. Because if you can get to "Well, it sounds cool." Well, that's not enough justification, there has to be some good, you know, business reason or technical reason that say it comes down, "to the existing system isn't working for us. It doesn't have this flexibility that we didn't need initially. But we need now." And sometimes that takes a little bit deeper dive to understand, "well, you might have this legacy system that's been written for three or four or five years, the technical decisions that you made, at the beginning, might no longer apply, but they were the best decisions you could make at the time with the options you had. So if you're going to go to something else, can you find why things were decided on in the past? Do they still apply? And what's the decision go forward?"

When it comes down to doing the work, I actually kind of did a consulting, internal consulting project for another team, in my job where, because I had done our system that was you know, Greenfield, if you will, brand new application that's got .NET Core. And then we had to modify some of our shared and NuGet packages. And we said, "well, we have all the shared code and the .NET Framework, and we need to make it available to our .NET Core API, I don't want to write those NuGet packages, I don't want to write that code in my application, it should still be a shared package." So how do we convert it? That was the first little step of I have this small DLL that I need to just rewrite. And how much do I need to rewrite? Do I make a new version side by side? Is there a way to compile the both and learning how you can do different target frameworks? Those were questions that we didn't know, we knew we still needed to support both. But we didn't know how we had what we have to do.

So we actually had some projects that were let me make a new standalone package, we're just going to write the .NET Core version over here. And we're going to have a .NET Framework version over there. We've since figured out how to target multiple frameworks. And the .NET Standard certainly helps. So you can say, "Oh, this is done .NET Standard 2.0, so all of our applications that have upgraded to," you know, was it Framework for 4.6.1-4.6.2? They can just use it, it's fine. But we had some applications that still needed the old version. And so, you know, we had to fork repos to keep that old version alive on the old version of the Framework as long as possible. But we're trying to migrate our application. So we don't have to keep supporting all of that legacy code.

When it came time to, you know, look at the entire API platform and say, "Well, can we upgrade this entire system from what ASP NET MVC to ASP .NET Core?" I basically just branch The, the whole repo and change the, you know, throughout the the csproj files and create a new ones and brought all the code and look what broke. And I spent, you know, a couple days just kind of going through not fixing anything, but finding out what we're all doing the code errors, because you got, you know, 500 compilation errors. But there were like five or six different classes of compilation errors. And so just kind of getting that surface area of, "how much work is this going to be? And is it impossible? Is it just hard? Or is it easy to solve?" And for some of those, there was an obvious answer, "oh, we've already solved that we have to rewrite our our startup to be a .NET Core startup as opposed to an MVC startup," that was obvious.

Entity Framework was one that was definitely a challenge. There was a lot of legacy, or a lot of Entity Framework six code in a legacy app that use the the model to recreate everything well, you didn't have, what is it? An edmx file? You don't have the the visual designer in EF Core. And I think if we had tried that same project, that same conversion, six months earlier, it probably would have been impossible. But because we waited long enough, EF Core now had enough support of the things we needed to do. But we kept finding edge cases. And we found where we didn't have full unit test coverage. And I don't like writing unit tests to do database test or integration tests, but we had to write some integration tests that would actually call a stored proc to see if we got the results back correctly. In the EF Core path is posted EF6 path. And so a lot of those took, "well, I can't solve all the problems. But can I go and recreate this little class of problem?" Jon skeet is really good at telling people that instead of you post, you know, your five source files to Stack Overflow, and someone has to figure out, "can you recreate your problem in as few lines as possible to demonstrate there is definitely this issue. This recreates my bug in five lines of code." And so I would stand up a new, you know, .NET Core console app that would call into our database and do something to see just what was going to happen. And then say, "Oh, I found the solution. Let me share that with my team. This is the pattern we need to apply going forward for this type of compilation errors," and we can get past it. And I checked the box and say, "Well, I figured out how to solve this, it's going to be a little different each time. But now we know that there is a path across these things."

Jamie
But what about docker, though? I mean, everyone talks about how everything should be in containers, right?

Thomas
There's a lot of guidance that says you don't you shouldn't upgrade your .NET Framework applications. And I, I certainly would lean on the side of caution, like we don't need to one of the drivers for us was we knew that application, we wanted to have the option to scale it out differently. So do we want to be put it into containers and do we need Windows containers for IIS and saying that there's so much extra overhead with that, it didn't make sense to migrate off of just deploying them as Azure App services, like there was not enough bang for the buck, there wasn't a cost savings associated with that, because the VMs, we're standing up for the same price is the the app service. And I like that you can kind of go into Azure and see, "how much is gonna cost me?"

But we also were looking at some of the other teams that have been very successful using docker and for their projects, they said, "well, they, you know, other teams had the issue of every time we got a new developer on the team, how do they get their development environment up and running, and everyone's got these little quirks?" And that's one place where docker can solve that issue that everyone runs the docker image locally, you know, make your development environment closely mirror your production environment. So if you want to go that way, then it's nice to have the ability to compile down and run on a Linux image, because that's what docker natively supports. And if you want to run on Linux, and you've got to do .NET Core, and, you know. We saw some performance improvements, just because there was less overhead with some of the things we did in .NET Core. But that wasn't always the case. And some of the EF Core stuff was a little faster. But we weren't doing it solely because, "Oh, we've been promised, there's performance improvements, we should definitely go this way." Like there's a lot of efforts going to take to get, you know, a few seconds of you know, SQL queries improved. So, probably not the yeah, it's probably not worth that effort. But if we have this bigger structural problem with the team of we want to be able to deploy more more easily, or you want to be able to develop more easily than it's worth, you know, that's a different than just a technical problem that we're trying to solve.

Jamie
So rather than writing a brand new system and .NET Core, if someone came to you with the task of re-implementing a pre existing .NET Framework system .NET Core, what would be your initial plan?

Thomas
I think nice to know that there's the it's, it's not an all or nothing equation, like you can, because the .NET Famework is .NET Standard compatible, maybe you look at saying, "well, what are the things we need to move off, and can we put those into the separate NuGet package? Can we do a little bit of code, but then it's still hosted inside a traditional MVC .NET Framework application. But those those shared libraries get moved out as much as possible." And some of that's just good modular design, it's, it makes for, you know, it's easier to maintain smaller pieces of code, you know, testing one little NuGet package, all that code should be well tested. Because it just it does its own little thing. As opposed to, "well, inside this entire application, I can only do you know, end to end test."

So I've done some of the kind of variation of strangler pattern that you take a bit of code, you make a defined interface to that code that you already have. And then the only implementation of that interface right now is the way it was called before. And you slowly build up a new version of that same bit of code in the new framework the new way you want to do it. And I've done this with, we wanted to transition to more of a DDD style. Well, we're going to introduce DDD concepts in this little language, ubiquitous language in this one component. But the interface into the main system hasn't changed, and eventually build up enough functionality that we can just make that switch. One of the things that you hear people talking about doing A/B testing, like can I start throwing code down the new path, while I'm still using the old path, just to see is the new path going to work. And that takes a little extra effort to set up. But it means that eventually you can move that little bit out into its own deployable unit, and you have less of a dependency, like your entire stack isn't dependent on the old framework, then maybe that bit becomes reusable in some other systems that you are just writing from scratch. It doesn't need to do all the functionality old system, but you can start building a new one that is just .NET Core and doesn't need, you know, Windows interfaces.

Jamie
So would you recommend extracting parts of functionality, which maybe can't be ported to Core and using something like the strangler pattern on them? And how would you explain that to someone who's maybe not technical?

Thomas
I think we mentioned this earlier that the idea of using metaphors, maybe strangler is going to come across sounded pretty, pretty violent. So maybe that's not though, you wouldn't want to throw out that term. But if we say, well, I've heard the architectural pattern of doing hexagonal programming or onion architecture as being just something similar to going into a house that you have your your external model, and you have a key to get into the house. And then once you're inside the house, you might have another locked room that the people outside don't even know about. But if you came in with that second key, you're allowed to go into the study. And, you know, using this for the code metaphor, well used to just walk up. And, you know, you walked in, and they gave you a cup of coffee, because you walked into Starbucks because they knew you and you didn't have to think about it. Well, now we're going to have this barista/cashier interface where you put in an order, and they give you a cup of coffee based on what you ordered. And the end result is the same that you walked up and asked for... you wanted a cup of coffee, you got your cup of coffee, you're happy, we've added this extra step of you know, you have to write down that you want a cup of coffee, okay, fine. But that doesn't really change a whole lot. But behind the scenes, now I can say I'm going to take this request for a cup of coffee and hand it to someone else. And they're going to make it and come back and give it to you. And I'm still going to hand it back to you over the counter. Eventually, we can go to that event based system where I set it there and I raised an event and you have to go walk down five feet and pick it up from the other end of the counter. It's a coffee metaphors always seem to work. There's always some way to come back and explain it to people.

Jamie
I love the use of metaphor to explain something, especially your coffee shop one

Thomas
I drink tea, but

Jamie
That's true, but I think it still works because you can still understand the idea. Even if you don't drink coffee.

Thomas
Right.And you can use the I'm going to put the kettle on. And you know, do I request someone to put the kettle on? Or do I stand there and wait while the kettle's boiling? Think you may have had that one on your show before someone talking about making tea.

I think yesterday we had the the coffee metaphor was was played out because someone was trying to do this abstract description of I have this workflow that has tasks A, B and C. But I want to reuse them in a different order. And so I create a new workflow that has B, C and A in that order. And the system was hard coded to do this follows that follows that how do we change it and it got very contentious and people couldn't come up with the they're wrapping their head around like I don't understand what you're talking about. Use your words, I don't understand what is A, what's B, and what's C? Like what's give me a concrete example. And instead of going down the road, what I have this data ingestion platform and I want to move this data. And then I want to do that. If you start talking in the actual terms, people then focus on the actual implementation. But if you start talking to abstract with just A's, B's, and C's, that doesn't work, we change the conversation to talk about ordering a cup of coffee. And we got into all these little nuances about well, it's like I went into Starbucks, and they only made coffee. And so there really was no reason to walk in the door. There's just a window that I walk up and they just hand me coffee, like they see me coming and they give me a cup of coffee. And if I want a latte, well they only make coffee, they have to make a new store that just makes lattes and then they have to make a new store that just makes cappuccinos. And they said that metaphor just kept expanding. And we realised, well, we don't want to make five different types of Starbucks that only do one thing, we want to have the I can walk in and ask for something. And that idea of just taking that metaphor, got us to start thinking about our problem in a different way, like, "Oh, this is how it's falling down. Like you couldn't explain the problem very well. Let's talk about coffee. And now we can explain the problem. In a tangential way."

Jamie
I think a lot of people undervalue the use of metaphor to get a complicated process across. Have you always used coffee metaphors?

Thomas
Yeah, before using coffee, I used to always do car metaphors. In fact, I worked with someone who, if you couldn't explain it in a car metaphor, he wouldn't come to your meeting, he was just obsessed with cars. And we went to the well, we had the Ferrari, and we had an RV, but you want a jeep and you know, got into all these nuances. If you still want to be able to drive off road and you want to go and take your kids to daycare, you aren't going to be able to go as fast, but you get all this extra flexibility. And the problem with cars is then people get too focused on brand names and whatever else and, and. But it is good to show most people drive a car without knowing any of the details is the internals. And they're fine with it. And they're, they're comfortable. And most people are fine operating there, you know, their smartphone or their computer without knowing how the internal code works. And some people don't want to they're afraid like, "Oh, it's all dark magic." And if you, you know, peel back the onion a little bit and say, Well, here is the basics of how algorithms work and how software works. You know, if you start talking about algorithms, you're gonna scare them away. But if you start giving the metaphors like, "Oh, that's how it's communicating. It's just like, I go on, you know, order coffee at Starbucks. And that's how Facebook works. I get it now."

Jamie
There's always something new to learn in our line of business, right? For instance, in the time that we've been talking 50 new JavaScript libraries have been created and died. But how do you go about learning a new technology?

Thomas
I personally like to find things that I'm able to inject into my normal routine, as opposed to, you know, an add on, like, if I have to dedicate time after work to sit down and spend two hours a night learning something, I know, I personally not going to do that. But I know some people like leave work, close the work laptop come home, immediately open up and they've got a side project. And that's what they want to do. So it sounds is a bit of being able to acknowledge what works for you. I've always had a commute of some distance. So podcasts, since I've discovered them back in like 2005 have been very useful to either put on my headphones or put it on the car. And just kind of absorb some of what's going on in the in the outside world. If there, I can give a certain small plug for InfoQ, because there's always new news articles on there. But find the blogs, find, you know, a Twitter feed that it's helpful. Make a Twitter list to say, "oh here, developers I want to follow," and kind of get exposed. And then sprinkling other stuff like I, a while ago, added a bunch of people that was following on Twitter that weren't just either software or straight news. And it really opened up my eyes because I'd be reading through and I'd see like software person talks about saying software person, and then you know, some news story and then like random picture of a dog or whatever it is, or some really insightful article and thinks that I, I don't read Twitter a lot. But I'll find I have five minutes, I'll just open it up and scan it for a little bit. And I'll usually find something that I click on, that I wouldn't have known anything about. And because it's just part of my day, part of my normal routine that that works for me. So find something that you can inject into your routine without being very disruptive. And it's easy to keep doing that on a regular basis, and then get a little bit of knowledge. And then when you find something that piques your interest, you can dive deeper,

Jamie
I've met a lot of engineers who were very happy doing the nine to five downing tools, and just walking away. And there's nothing wrong with that at all. But it's always been, like, my personal philosophy to try and expose myself to new technologies, and ways of solving problems. And it sounds like that's kind of how you feel as well.

Thomas
So I think the way I've looked at it is some people are very comfortable doing what they're doing, and they're happy. And I don't want to be come across as shaming them and saying, "You're not a good person, because you're not doing all this stuff." But I know, in my career, there have been times when I feel like, "Oh, I'm getting along. But my skills are kind of atrophying and how do I get excited? How do I do something, you know, new and different? How do I move myself to the next level?" And I think, you know, you drew the line of what does it take to be a good programmer, you have to know how to write code, you want to be a good engineer, you have to know a little bit about solving problems, if you want to take it to that level of I'm going to be great at my job. And I'm going to be someone who enjoys working on a team and people like working with me. And they like using the software I create. It takes getting outside that that bubble of your comfort zone of just knowing tech, like the problem, the problem you're trying to solve might not need more technology and might need less technology. And if you just say, "well, I've learned about this cool new thing, I'm going to use it," you have to be able to step back and ask the question of, "what are they actually needing? And do I actually have a good solution to that," besides the best software is the stuff you don't have to write like you don't if you don't write any code, you don't have any bugs. So if you can solve someone's problem without writing code, that's probably a better option. But that's a different way of thinking. So find ways that you can expose yourself to those other opportunities to say, "Oh, I wouldn't have thought of this before. But because I read this book, or took this class, or just talked to these people at a different meetup that wasn't a tech meetup. I now have this new idea and way of thinking that I'm just gonna try out."

Jamie
Yeah, I agree with what you're saying completely. And it's really funny, actually, because a number of techniques from our industry are starting to sort of bleed over into others, and vice versa. So like, I've seen teams who work in everything from banks, to supermarkets who have daily stand ups, sometimes even on the shop floor. And let us know, forget what we think of as agile started out at Mitsubishi manufacturing plant in Japan in the 60s.

Thomas
Yeah. My wife is in PR marketing. And she's been introducing agile techniques to her team. There's another one who's done presentations. Andrea starts with and f, I forget her name. But if you look up agile marketing, she's got a lot of stuff. And so those kind of ideas of, "well, here's how we did stuff in software. And now in the marketing world, can we do the same thing because they still have these projects that are long lived and you you still have, you know, goals and outcomes. And everyone's working on different things. So having, you know, a daily or twice weekly meetup, or a stand ups where people can say, here's, here's what I'm working on, here's the progress I made, here's what isn't working. And here's where I still need feedback, like having that same type of discussion" is one of the things that we've been doing in software for a while and other teams and other departments. You know, haven't exposed been exposed, they haven't even thought to change their their process.

Jamie
It has been an absolute pleasure to talk to you today, Thomas. But before we go, what are some of the ways that listeners can maybe connect with you learn a bit more about your work? Anything that you currently doing that kind of thing? I mean, are you on Twitter, for instance?

Thomas
Yeah, I mean, I haven't opened up my Twitter direct messages, but I guess I could, but please follow me on Twitter and ask me anything. There, you can follow me on my InfoQ page - you can just go to InfoQ to follow me. I am on LinkedIn, if you want to contact me on LinkedIn, there are instructions in my profile of how to make sure I actually respond. So I'm going to tell people that they have to read that to get the answer. Because I get you know that someone gave me the tip that if you get contacted by a lot of recruiters that are unsolicited, just be able to filter through someone who actually took the time to read the last sentence of your profile makes a big difference.

Jamie
So excellent. I'll be sure to add some links to the show notes for your Twitter and LinkedIn. And I'll also add a link your recent article about the liberal arts and how they can help make us all better engineers. All the remains to say really is Thank you ever so much for connecting with me today and for taking the time to be on the show. I've had an amazing time talking with you today. So thank you ever so much.

Thomas
Yeah, thanks for coming on. Jamie it was a lot of fun. So I hope you listeners got something out of it.

Wrapping Up

That was my interview with Thomas Betts of both IHS Markit and InfoQ. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and a full transcription of the interview. The show notes, as always, can be found at dotnetcore.show.

And don't forget to spread the word, leave me a rating or review on your podcatcher of choice, and to come back next time for more .NET Core goodness.

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