Betatalks the podcast

In this episode, we talk to Dylan Beattie, who is a Microsoft MVP and international keynote speaker. He is the director of Ursatile, the creator of the Rockstar programming language, and has performed his software-themed parodies of classic rock songs all over the world as Dylan Beattie and the Linebreakers. We talk about his programming language – Rockstar - in which he writes programs that resemble bad song lyrics. It started as a joke, but it actually worked and went viral. And how it made him use technologies like Rust, Scala and Python, or techniques like building interpreters in JavaScript, parsing expression grammar, recursive descent parsing, continuation passing, flow control, and more. We dive deeper into the fact that people do better work when they are enjoying themselves. Real software development is a craft, where we solve problems that have never been solved before. It can be a difficult and frustrating process; you get stuck and we underestimate how much time it can take. Sometimes you have to step back and do something else to get that creative process going again – tip: take a notebook with you so you don’t forget your good ideas. We also discuss the basics every developer should know, what skills a developer should have, and how there are three kinds of software that you might write. And, last but not least, we talk about how Windows as a development platform has gotten a lot better in the last 25 years, about different programming languages, especially C# and .NET, about (programming) language proficiency versus fluency, about translating programming expertise from one language to another, and his love for JavaScript.

About this episode, and Dylan Beattie in particular: you can find @dylanbeattie on Twitter and GitHub. Check out his website dylanbeattie.net and The Rockstar programming language at codewithrockstar.com. And, listen to 'Dylan Beattie and the Linebreakers' music on his YouTube channel. 

About Betatalks: have a look at our videos and join us on our Betatalks Discord channel

00:00 - Introduction
02:11 - Friend of the day
04:33 - The origin of Rockstar
09:39 - Why people work better when they’re happy
15:19 - Working on problems that have never been solved before
17:46 - Building trust in software
22:23 - What is something you can’t live without as a developer?
23:46 - The difference between maintainable and unmaintainable code bases
29:51 - Totally random question
31:52 - Language proficiency vs fluency vs idiomatic grasp
37:24 - What’s wrong with translating programming expertise from one platform to another?
40:35 - Closing

Introduction - 00:00

Oscar
Hey there. Welcome to Betatalks the podcast in which we talk to friends from the development community.

Rick
I'm Rick.

Oscar
And I am Oscar.

Rick
Oscar, what have you been up to lately?

Oscar
No, not too much. Well, of course too much. But yeah, preparing some things this week or yesterday day before mostly recording todays podcast. I always like to dive a bit in and check out some talks of our guests and previous things and see what they're blogging about. So you can actually have a conversation with them, but also preparing a session for Techorama next month.

Rick
Yeah. So we're, we're doing a joint session, right.

Oscar
Together, right?

Rick
Is this? I mean, we've done so I think, at our office once, but I think we never went to a conference and did one together.

Oscar
No, some like one off evenings, somewhere, but never conference, but somehow always our sessions are like movie titles. I don't know where that started at Dude, where's my server for Azure functions when that was brand new.

Rick
Yeah. And then we had Back to the Future...

Oscar
Back to the framework...

Rick
Back to the framework for .NET.

Oscar
Yeah for the convergence with framework and core towards five. Yeah, and that now we're doing at what did we call it.

Rick
Aesthetic web apps and the API multiverse? So we're going to look into all of those different types of API's that you can run as a back end for your static web app. Because now we can do more than just Azure Functions.

Oscar
Yeah, I needed to, I needed a reason to really dive into container apps. And I already love it. Yeah. Like you love static web apps. Or maybe it's more aesthetic web apps. Yeah, you're a fan. But yeah, that the container apps is really interesting.

Rick
Yeah. And I think that the fact that you can have API management as an API back end, or at least, the connecting level of the API's, I think that's pretty powerful as well. So static web apps actually, growing pretty fast. Oh, that's, that's nice to see.

Friend of the day - 02:11

Oscar
Nice. Well, Rick, who's our friend of the day?

Rick
Our friend of the day is Dylan Beattie. Dylan Beattie is a consultant, software developer and international keynote speaker. He's the director of versatile an independent consultancy based in London that specializes in helping organizations bridge the knowledge gap between software development and business strategy. Dylan has been building data driven web applications since 1990s. He's managed teams, taught workshops, and worked on everything from tiny standalone websites to complex distributed systems. He's a Microsoft MVP, and he regularly speaks at conferences and user groups all over the world. Dylan is the creator of the Rockstar programming language. And he has performed his software themed parodies of classic rock songs all over the world as Dylan Beattie and the line breakers. He's online at dylanbeattie.net And on Twitter, as @DylanBeatty. Welcome Dylan.

Oscar
Welcome.

Dylan
Hello, how you doing?

Rick
Well, we're great. How are you?

Dylan
Yeah, pretty good. Although listening to you read that bio out there. One I say all over the world too many times. It's funny, you know, people always like you want to do a bio. And you're like, is this gonna be read out? Is this going in a conference program? Is this gonna be like a part of a podcast or something? And? Yeah, it always sounds a little bit weird when you're like, Yeah, I should have read that out loud before I put that on my website. Well, it's all true. You know,

Rick
That's the most important thing, right? And it tells a little bit about who you are and what you do in life. So.

Dylan
It's also you know, it's who you are. It's what you do, but it's also who you're trying to get through to, because something that comes up often in what I do with you know, training and consultancy, is someone says, Hey, we want to hire you. Do you have something I can show my boss? And it's like, yeah, all right. So you've seen the concerts and talks, and we've talked in a bar or something. But now you need to persuade someone to make a purchase order. And so you know, different communication styles for different audiences is something that comes up a lot.

Oscar
I need to convince my boss do you know, the guy from Rockstar Lang? That's got to be very practical.

Dylan
That sometimes works, but not always so.

The origin of Rockstar - 04:33

Rick
Well, let's just dive right into that one. From the start, right, since we've already mentioned it, and it's in your bio, for people not aware of what actually Rockstar programming language is, could you? Could you explain that in a few sentences?

Dylan
Yes. So it came out of this, this this trope you know about people putting adverts on LinkedIn and stuff saying, hey, we need to hire a rockstar programmer or like a rockstar database engineer. And it's been around for years. There's an old blog post, Scott Hanselman wrote about, you know, the myth of the Rockstar developer, which is about 10 years old now. And somebody posted well, who I think he's the founder of Octopus Deploy, and he just put something on Twitter a couple years back saying, hey, we should confuse recruiters by making a programming language called Rockstar. And I sort of saw it. And I thought, that's pretty funny. And then I thought later, I can't remember why. But I was thinking, I wonder if you could make a song lyrics that compile, like you could create a grammar. So you could write valid computer programs that reused a lot of the sort of, you know, common tropes and idioms from like 1980s, hard rock and heavy metal music, I spent early in my career, I spent a lot of time working in VB script, I spent a lot of time working in Pearl. And I've done a little bit of work in Ruby as well. And those are all languages that sort of try and use natural language like natural English, to influence, you know, syntax and flow control and structure. And, you know, I just sort of sat down and started thinking, I wonder if you could do this. And it started out as a as a joke. Like, literally, it was a parody specification, that's all, I was just going to write one spec. And, you know, put it up on GitHub. And that was it. That was supposed to be the end. It's like, you look at any of the really, really big projects in history. Like, I don't think anyone who ever set out to do something really big succeeded. I think the biggest projects always start out as somebody going, this is never gonna be anything. Like a you see the news group post where, Linus Torvalds, announced Linux, and he's like, it's just a hobby operating system, it'll only work on three, eight sixes, all I can afford is 80 hard drives. So that's all it's ever gonna support. It's just for fun. It's not a big deal. But if you're interested, go and take a look. And of course, now, you know, Linux is the biggest operating system in the world by orders of magnitude and stuff. And yeah, this was kind of, you know, similar with, with, with Rockstar, it's like, this is just a joke, you know, we're going to write a little parody spec and think, you know, how would you write flow control using rock and roll? And how would you write operations and arithmetic? So I thought, you know, people talking about what are the prices total plus tax, I'm like, well, the prices the total with the tax. And then you could be like, you know, we talk about distance over time, that's division. So you've got a whisper over the water. And basically, by using an imaginative variable names, you could write programs that look like bad song lyrics. And then I put the spec up on GitHub, and I sort of just left it and it went viral, and loads of people kind of jumped on it and went, this is really funny. And we like it. And, and then somebody implemented it, I started getting people filing issues on the GitHub repo where I had this parody specification, saying, there's undocumented behavior here. And what's supposed to happen when you do this.

Oscar
How do you do this?

Dylan
Yeah. And I'm like, I don't know, like, I wrote the spec in a bar for a joke. And they're like, Yeah, but it's almost complete, like we've implemented 90% of it, which actually, I thought was kind of cool. Like, you know, but and so yeah, we, couple of us spent a few days just hacking around and closed up some loopholes in the spec. And then people shipped implementations of Rockstar, there was one in Scala, there was a rockstar to Python transpiler, someone started building one in rust. And I kept thinking, that's it, it's gone away now. And every once in a while, it just pops back up on the front page of reddit or Hacker News. And there's a whole bunch of people who didn't see it last time around, who go, oh, this is so cool. And because they go and they look at the repo, the sort of I think the biggest, like the serious technical thing that I did is, I built a rockstar interpreter in JavaScript so that you can run it on a website. Because you know, Rust is a great language, but it's not terribly accessible. If you're just, you know, a relatively inexperienced developer, you find this thing on Reddit and you're curious, and you want to try it out, you're not going to install rust, or Scala or you know, maybe you got Python already up and running. But I thought if this is something you can open up on a web browser, and just you type your programming, and you press go. And so I had to learn how to build interpreters in JavaScript. I learned about pausing expression grammars, you know, recursive descent, parsing, continuation passing flow control, exception handling different arithmetic standards, and all this kind of stuff. And so yeah, that's up there now on code with rockstar.com. And it's one of those projects, I have so many like ideas for things that would be fun that they'd be pointless. Like, you know, although Rockstar is it's in the GitHub Arctic seed vault, you know, the thing they did where got the code, and they buried it underneath permafrost. So yeah, if humankind doesn't make it through this, this latest iteration of whatever the hell it is we're doing, then at least the Rockstar language will survive so that the aliens who find the smoking ruins of planet Earth can go digging in the north pole, and they'll find Rockstar down there.

Why people work better when they’re happy - 09:39

Oscar
Yeah, they are probably thinking, we're not really efficient then. Like, that's, that's why they're not here anymore.

Dylan
I think the aliens would be like, I think I realized what this species did wrong. This their computer programming. So....

Oscar
But it's so awesome. But you went into you mentioned like, never set out to make, make a project big that it actually becomes big, some other projects as well. Do you think that's actually because you're in full creative mode and not bound into writing something serious?

Dylan
I think there', yes. I mean, I think part of it is that and this is something that I've actually, you know, given talks about, I think people do better work when they're happy. I think people produce better results when they're enjoying themselves. And one of the, I think perennial challenges of software as a, as an industry, you know, software as a commercial endeavor, is, it's fun. And people, you know, developers all over the world. And I have done this myself, many times, we'll sit up late building something that nobody actually wants, or nobody actually needs, because we thought it looked cool, and we wanted to build it. And, you know, I think managing development teams, a lot of it is about trying to channel that enthusiasm and that creativity into the things that actually matter, you know, the things which are critical to delivering a successful project. But certainly, you know, I think the success of a lot of open source is because, you know, people that definitely aren't doing it for money, and nobody does open source, but some people do open source because their boss told them, hey, we need this feature in this framework, so we can ship on you, on your platform or on your product. But you know, a lot of open sources, people who do it because they enjoy the challenge, and they enjoy the craft of creating software. And, you know, a lot of open sources, very, you know, very, very high quality, certainly compared to a lot of commercial software that I've had the misfortune to use in my life. And so I think, you know, creativity, inspiration, enthusiasm, I think those are an important part of it. Also, because software is frustrating, you know, computers are stupid machines, that the thing you did yesterday suddenly doesn't work. And you don't know why. And what's changed. And then you go digging, and you're like, oh, one of the, I have this package that depends on that package that depends on that package, and they've bumped that one, and they've removed 32 bit compatibility or something, you know, this is a daily occurrence. So I think, some amount of like enthusiasm, and, you know, inspiration, you got to love what you do, otherwise, you're gonna give up because if you don't love it, you're going to hate it very, very quickly. But there's a lot of us out there who just sort of accept that. That's, that's what we do. We deal with the frustrations and the package managers and the incompatibilities and the DNS problems. Because there is something profoundly satisfying about building a method or a library or a user interface. going, Yeah, that's good. I built that. And I like it. And I'm proud of what I did.

Oscar
I love the feeling of being stuck after a problem. And then finally solving it. Somehow, like the you already know, when you're frustrated, even shouting out loud, like what hell's going on here, you already know you're gonna solve it, at some point, you're going to be super happy about it.

Rick
But up until the point where you actually get really frustrated, then you start looking out a window or you go outside, and you just have to get a break from actually trying to solve that issue. And then that's, most of the time, that's the point where you actually find, but wait a minute. And I can't count the amount of times that I've said, But wait a minute, just before I fixed some things.

Dylan
So one of the one of the lovely things about the sort of way my life and my work is now I work at home all the time, you know, like a lot of people, but I have a piano next to my desk. And so when I get stuck, I just literally turn my chair 90 degrees, and I'll sit and I'll play piano for 10 to 15 minutes. And that kind of engages a different, completely different part of the brain. And, you know, at that point, it's like, and often I'll be, you know, playing away, and suddenly I'd be like, oh, yeah, I see what the problem is. And I'll just turn back and I'll keep doing it. Yeah, that works pretty well, because I've also had the thing where you're out having a walk and you're walking around the park, you're like, yep, I know what I need to do. And then you get back home. You're like, what was it? That's a lovely story. Did you ever so the guys who created RSA cryptography, whose names I will have to look up, Ron reversed? Let me let me just because I want to get this right. But they went on a skiing holiday, because they were all completely stuck trying to Rivest, Shamir and Edelman, the three people I went on a ski holiday. And one of them says, you know, he was coming down to ski run this is just before they came up with the public key cryptosystem that they published. And he said that, you know, I was on the ski run. And halfway down, I had this brilliant idea for an asymmetric cryptosystem. And when I got to the bottom, I'd forgotten it. And I never remembered what it was. You know, maybe it was nothing, you know, maybe it was junk, maybe it wouldn't have worked, but maybe I had this wonderful idea. And then I just forgot about it because I was halfway down a ski slope. And I couldn't stop and write it down. And it's just gone forever. So I think you know, the take a break and get away from things is a change context is really important. But I also, you know, when I go for a walk when I'm stuck, I always take a notebook with me. And I send myself voicemails and I send myself emails from my phone all the time. Just a little things that I thought that's a good idea. And I'm not going to remember that when I'm back at my desk. So yeah.

Working on problems that have never been solved before - 15:19

Rick
Yeah, completely true. And then you said, like, you play the piano because it taps into a different part of your brain but, but still, I mean, real software development. It is a craft as well, right? And it's a creative process. And then sometimes when you are trying to fix a really hard problem, and somebody comes over and says, Well, is it done yet? Is it done yet? Is it done yet?

Oscar
Yeah, that works....

Rick
That's the worst thing you could do. But also, it's, it's almost impossible to actually give it time of how much or give an indication of how much time it would take to actually fix the issue. Because...

Dylan
Yeah, the thing I think, is not nearly widely enough appreciated outside developers, and you know, people who work in development is we, most of the time only work on problems that have never been solved before. And you know, and I'm not talking, you know, big problems, like curing cancer or world hunger, it's like, you know, we got to plug this CRM into that finance package. And you know, like, has this ever done, they're like, no, no one, no one's ever connected that particular CRM with those customizations into that finance system or that account system with those customizations. So you're like, alright, well, maybe we'll just right click connect, and it works. Or maybe this is going to be a six week integration project, where we end up having to write our own adapters, and API wrappers and all these kinds of things. And one of the perennial frustrations of working in commercial software is the management level, people who make decisions about which technology you're going to use. They believe what it says in the sales material. And then like, Oh, we got this new CRM. Yeah, it says here that it supports customer login, so they can manage their own accounts. And you know, oh, yeah, it does, does it? Alright, let's have a look. And two days later, you're like, yeah, this? No, like, if you want to throw away every other piece of software we have in this company, then yes, our customers can log into CRM with a new password, you're gonna have to create and give to them. Good luck doing that in a way that's, you know, secure. But you know, it's, someone says, How long is it going to take to do something often think about, you remember, Super Mario, like in the days when you couldn't save your progress and computer games. And so every time you played Mario, you have to start at the beginning. And you'd play through the first screen, second screen, third screen, and by the end, it's like, how long does it take to get through the first screen of Mario? And you're like, oh, it's like eight seconds, you know, we've done it so many times. It's a known problem now. But you know, every time you play Mario, you get to a bit you've never done before, and then you're like, well, now I don't know how long it's gonna take. Maybe I complete it this time, maybe I won't, maybe I'm gonna die straight away and have to go back to the last checkpoint and play through from there. And you know, so much of what we do and development is we don't know, it might work now, like, we might be two minutes away from this works. Or it might be another day, it might be another week, we honestly cannot tell from where we are right now.

Building trust in software - 17:46

Oscar
Yeah, sometimes you're, you're also making some estimates. It's like, well, within two weeks, we can do this. You're done in 10 minutes, because you read the spec, and it actually made sense. And it is exactly how you would implement it. And that doesn't build trust. Also that way, like it's so yeah, it depends on indeed, it hasn't been done. But we have so many scars, that sometimes we are also a bit exaggerating in what it probably will take.

Dylan
I mean, one specific example that, you know, kind of stood out for me was adding open ID like social media login or doing a platform log into a system I was working on a few years back. And it was we had, we had to login with Twitter and login with GitHub already. And it's like, right, let's add login with LinkedIn login with Google login with Apple, we thought those are the other three providers. And LinkedIn, I think took about half an hour. Microsoft took about maybe half a day, Apple took us nearly a week. And in theory, those are all different. You know, they're multinational, big, well established computer companies with solid engineering, implementing what is supposed to be a public protocol, with standard, you know, request standard response standard format. And, you know, that was like, Okay, we got three of these to do. And it's the end of Monday, and we've done two of them already. That's gonna be easy. And yeah, the third one took us the rest of the week, just because of things, you know, you do what it says, and it doesn't work. And you're like, right, it didn't work. Why didn't it work? Okay, let's go back to step one. Let's check everything is this right? Is that right? Is that right? Does this authentication URL point to the right place? And you know, particularly when you're working with anything related to security, it can be maddening, because by design, they just say something went wrong. Because if they say, Hey, that's malformed on line 16, that could potentially give attackers information that would help them you know, mount an attack or try and break into that system. And so you just get back, no bad request, bad request, bad request. And you're like, all right, let's try.

Oscar
I had an evening of Ruin built when I'm trying to set up the getup OpenID Connect to Azure this week. Yeah. And it just said, nope, nope. And I forgot to add the permission setting that it could write the token in pipeline and the beginning. So it has nothing to do with my creation. So next day, like within 10 minutes, everything worked because I followed a new block off someone that was perfect. So yeah, oh, those things, right?

Dylan
Sometimes I'll do exactly that, is that right? Let's throw this away and find a different tutorial or a different reference and implement that one instead. And you know, the very least if you end up the same error message, that's like, alright, I'm going to need to ask someone for help.

Oscar
It might not be me.

Rick
So you just talked about, it helps when you've done things over and over again, to give a decent idea of how much time something is going to take. And we also talked about the fact that creating software actually is a creative process. And it's, it's something of a craft. And then we've had time in our hearings, in the Netherlands, at least, where everybody and anybody moved towards software development. I mean, I had a colleague who started off as a nurse then did some flower arrangement, and then thought maybe I can go into software development. Now that doesn't say anything about his abilities to actually create awesome software. However, there are certain things that you need to know and understand in order to be successful writing software, I think.

Dylan
So I actually, first thing I think, is I would love to live in a world where if you want to be a developer, it's mandatory that you have to have worked as a nurse and arranged flowers. I think that would lead to...

Rick
I agree.

Dylan
Much, much better, you know, empathy, social responsibility, aesthetics.

Oscar
We can put the job opening.

Rick
And our industry is still in its infancy as far as a welcoming and openness to other people.

Dylan
It's like a you know, the Karate Kid movie where Daniel wants to learn how to do karate. And so Mr. Miyagi gets in wax and cars.

Rick
Oh, yes.

Dylan
Yeah, we should do that. It's like, okay, welcome to our software bootcamp, first semester, nursing. Off you go. Yeah. And people come back. And you're like, right, now we're gonna do flower arranging. And the third one, it's like, right now we're going to do I don't know, landscape management or ecosystem or something else, and we're going to work in a kitchen. And then eventually, it's like, right now we think you're a well rounded enough individual that we can teach you Python. That'd be an interesting world to live in.

What is something you can’t live without as a developer? - 22:23

Rick
It would be. But then sorry, I completely. I think I totally agree. So there's no issue there. But what are the as far as you're concerned? What are the things that more developers should understand? What, what's, what's the basics? What is something that you can't live without? If you're going to read saucer?

Dylan
Um, it depends what kind of software you want to write something that I, you know, I'm very, very much aware of, there are, I think, three different kinds of software that exist in the world. There is software that you are going to sell software that is a product that you know, all the stuff in the Apple App Store, anything that comes out of, you know, Microsoft, Google, whether it's, its software you install, or its software as a service or platforms. You know, there is a software where you don't know who the end user is going to be. And you probably, you know, maybe you have some idea, or you have some representative user groups, but in your head, really, you have this sort of hypothetical, these people have this problem. And if we can build a better system, like so the thing that's frustrating me most at the moment is calendars and the total inability of every calendar out there to deal effectively with time zone changes.

Rick
Especially date and time in JavaScript, right?

The difference between maintainable and unmaintainable code bases - 23:46

Dylan
Well even you know, just calendars generally, this is, you know, as a consumer, like, I'm going to Austria this weekend for a Euro BSD con. And I'm doing a keynote there, which is going to be on Sunday morning. And of course, if I look at my calendar, now, the time is wrong, because my calendar is showing me what time it's going to be in London when I'm speaking in Austria. Now, the calendar knows I'm going to Austria because there's a flight on Friday. And if you look at the appointment that's in there, it has a different start and ending time zone. And then there's a flight back on Monday that has a different starting and ending time zone. And so there is enough information in the data that's there for the calendar to go, oh, yeah, this is what it looks like, it's 08:30, it's actually going to be 09:30 for you on the ground when you do this. And there's no calendar system I've seen anywhere that can get that right. And so that, to me, that's an end user product, you know, you could like right, when I start a company, when I do a startup, we're going to build a better calendar and we're gonna sell it to people who we've never met so that they can manage time zones more effectively in their calendars. And so that's kind of, you know, category one, this is what used to be boxed product software. And then there's the stuff where you're building for your team and your colleagues and you know, the people you talk to and you know, intranet applications, you know, monitoring pipelines, efficiency, all these kinds of things. You know, anyone's ever built a thing to export into a CSV file. So someone can make a spreadsheet out of it knows exactly what this column this category is. And then there's the stuff which is, which is fun. And the stuff which is, or others the stuff where you don't care about the code, what you care about is the output of the code. And an awful lot of you look at the code, which is written in academia by scientists, and you know, they are the Imperial College pandemic model. This kind of made headlines a couple of years ago, when you know, the first wave of the pandemic was kind of breaking, and Imperial College in London, they had this, this model for, you know, modeling the spread of a pandemic through a population that had been written by epidemiologists, in see some of it was machine translated from Fortran in the early 2000s. And they put this code up on GitHub. And of course, all the software developers looked at it and they were horrified. They're like, oh, this is so bad, doesn't obey the law of Demeter. And there are no solid principles. And, you know, you're sort of thinking, well, you have one way of looking at the quality of a codebase. And based on what you've learned from books, and you know, watching talks at conferences, and probably your own experience of the difference between maintainable and unmaintainable code bases. But and then, you know, a question comes up, is this a code base where the software matters? Or is this a code base where the output matters, and the software is less important. And, you know, I think there's a lot of very, very interesting kind of approaches to software development from people who they're not professional developers, they're not writing software that, you know, in their head, no one else is ever going to use it, they're building a tool for them to solve a problem they have. And I do this all the time, you know, I have dozens of little C# applications, JavaScript applications, I'll still use a, you know, .NET WinForms, like Windows Forms apps, if I just need to, I need to grab some output from like an online survey, I want to turn it into a bullet point list, convert it into markdown, turn the markdown into HTML and paste it into something else. And you know, I built a little tool to do that. It's horrible, you know, the buttons are all over the place. And I would never show that to anybody else. As an example of, you know, hey, look, this is what I do when I write code. But it takes something that used to take me an hour and a half, and it does it in about three or four minutes for me. And so, you know, that's a sort of valuable thing. So when you talk about, you know, what are the skills that somebody needs to be a software developer, I think the first thing is you got to understand what you're doing. And you've also got to understand what it might turn into, you know, I think there's a lot of products out there, which started out as a, as a hack, I'd like, you know, Linux, again, Linus Torvalds, building a hobby operating system for his own computer for fun. And you know, that one, I think, turned into a very respected and mature open source project. There's a lot of libraries out there that someone built something they wanted, and they open sourced it, and you go and kind of poke around, you're like, alright, I can see what you were doing here. It doesn't work. The tests are wrong. I can't make it build. But it's still probably easier than me starting off from scratch on this thing. So I think, you know, understanding the context, understanding who is going to be running your code, and what are they going to do with it when it's finished.

Oscar
But I really think that also the, the whole craftsmanship around software is mostly to make it changeable after maintainable for the future readable for other people. That's where the part is. Because if it's one off, if it's for now, if it's for you, you can just dump your brain into code. And if it works, it works.

Rick
There's the meme, right? If it works, it ain't stupid.

Dylan
And then you come back to it six months later, because you have the same problem again, and you're like, This is stupid. Who wrote this? It was me. Why didn't like document anything? Actually something that I've started doing now, when I when I solve a problem like that, I forced myself to blog about it, because the blog post then effectively becomes the one that makes me clean up the code just enough that I'm happy for other people to look at it.

Oscar
Secret shoutout.

Dylan
Yeah, the blog post is then the documentation. Because, you know, I'm probably not going to remember where I wrote it down on a text file or something. But at least on my blog, Google can find it.

Rick
Yeah, that's, that's actually something that has happened to me a couple of times where I actually find something I think I think I've seen this before, then I Googled it, and then I hit my own blog. Oh, yeah. Right.

Dylan
Yeah I did see this before.

Rick
So it's external memory. That's awesome.

Dylan
The worst one is when you Google a problem you're having because you're completely stuck, and you find a couple of hits, and you click through and it's, I know, I had this problem 10 years ago.

Oscar
This my question here on Stack Overflow.

Dylan
And no one replied.

Rick
One guy, or girl on Stack Overflow that actually had the same issue but no answers.

Dylan
When I found a forum post, like a forum thread from me 10 years earlier, having the same problem with the same software, and no replies. So it's like, alright, well, at least, we're still stuck.

Totally random question - 29:51

Rick
This is a Ton trombone. Oscar, do you know what time it is?

Oscar
Is it time for a totally random question?

Rick
It is time for a totally random question.

Oscar
Dylan, which protagonist from a book or a movie would make the worst roommate.

Dylan
Oh, that's an interesting question. I don't know. I mean, I've shared houses with some fairly eccentric people over the years and had a lot of fun with it. Actually, you know what? Any other people from the big bang theory that, that program I find, certainly any of the male characters from The Big Bang Theory, they are so stereotypically cliched like stupid people trying to write smart people that, yeah, if I if I had to choose between living in that apartment with them or living on the street, I'd probably live on the street,

Rick
But because otherwise you'd be explaining how stuff really works all the time.

Dylan
No, it's I sort of thing recently, I said, the difference between Sunni and Philadelphia on The Big Bang Theory is one of them is smart writers writing stupid characters. And the other one is stupid writers trying to write smart characters and get it wrong. Yeah.

Rick
Okay. Well, that's a clear one. Let's get back to you just said that you have a ton of C# and other language applications locally for actually just making your day to day job a little bit easier, right? Yeah. Why is it that you work with .NET? And C#? What's your why is that one of your go to languages?

Dylan
So originally, my I got into web development in the like, very early on, I was building HTML static HTML sites in the 90s. When static meant static, it didn't mean Angular JS talking to back end API's. It meant folders full of files that didn't move.

Rick
Product one dot HTML, that one, right?.

Language proficiency vs fluency vs idiomatic grasp - 31:52

Dylan
Exactly right. And then I got into my first exposure to dynamic like data driven web applications was from Microsoft Access, which access 97 had a wizard that would publish your database as a website. And that's how I discovered Active Server Pages. And that's how I discovered, you know, adto, and comm objects and VB script and all that kind of stuff. And, you know, at the time, there was that, or there was PHP, or there was CGI bin, there wasn't a huge amount of choose from an ASP, certainly in the late 90s, was a sort of relatively mature platform. So I got into that in a big way, which sort of, you know, I wouldn't say locked me in, but it gave me an affinity towards the Microsoft ecosystem. And meant I started to, you know, understand the concepts that I was running Windows, because I also, I played a lot of games when I was younger, and you could get quake running on Linux, but it was difficult, and it kind of sucked, and, you know, lots of other games, you know, need for speed and total annihilation, and all those kinds of things. They didn't run on Linux or Mac at all. And I didn't have enough money for extra computers. So I had one computer, it ran Windows. And that kind of predisposed me towards using that as my programming platform. And I gotta say, you know, Windows as a development platform has gotten a lot better in the last 25 years, programming on Windows 95 was entertaining. And then, you know, when, when Microsoft announced .NET, which was the sort of next generation and also you know, I like the fact that there was this convergence C# struck me as a very, very nice language. And it still is, you know, I think that the C# language maintainers, and designers have done an excellent job of incorporating, you know, lambdas incorporating things like switch expressions in a way that doesn't start making the language itself feel like it's, it's sort of teetering under its own weight. You know, I think C++ is a is an example of a language that C was kind of minimal enough that people complained and they didn't like it. And they're like, We want to be able to do objects, and we want inheritance, and we want all these things. And then C++ went, alright, we'll do all the things and also we'll throw in templating, and a bunch of other stuff or in there, and, you know, created a language which is now very, very difficult to sort of find your way into it. But I think C#, they are just they've done a good job. The language is evolving, I enjoy it, I know it very well, I feel comfortable writing in it, it's you know, I often talk about language proficiency versus fluency. And you know, I speak I speak English, I've grown up speaking English my whole life, I can just about kind of get by in French but I often find myself having to look up particular words. I can just about read a restaurant menu in Russian, and you know, anywhere else I go, I'm sort of, you know, looking I can't speak them with any degree because I don't have the vocabulary but I can sort of figure out what does this thing mean and what is that notice mean and these kinds of things. You know, I think computer languages are very much the same, you know, C# and JavaScript and SQL actually, I'm fluent I quite happy yeah, I know exact tell you how to do that. And maybe I'll look up like a little quirk of grammar like the way occasionally in English, spellcheck says you spelt that word wrong. And you're like, ah, there's two ends in millennium. Of course there is. And then you know, other languages like Python, I probably write Python about as well as I speak French, like, I sort of know what goes where, but I need to look up a lot of things. And then, you know, languages like Erlang, Haskell, I'm sort of looking at it like a language, I don't even speak going. Alright, I think I know what that might mean. And I need to look this up. And, and, you know, when you're solving problems, as opposed to creating code as a product for sale, you go with the language where you feel most comfortable and fluent, you reach for familiar tools. And, you know, I've watched these, there's a guy I saw last year on Twitch who did advent of code in a different language every day and half of them had never used before. And you know, that was it was quite entertaining to sort of sit and watch some of it. But you appreciate the, the gulf between, you know, some people like, yeah, I can learn any language, it's like, well, no, what you can probably do is, you know, if I was to start writing Haskell tomorrow, what I probably have after a week is I know how to translate C# into Haskell. But I don't understand any of the things that make Haskell special. And I don't understand, you know, the idioms and the advantages. I just like, I know how to translate the algorithms that are familiar to me. And the next part is, you know, getting that idiomatic grasp where you understand the things that this language does, which none of the others do.

Oscar
I think that's for languages and for framework, you also see some teams sometimes, well, let's do angular now or blazer now. And we've always been doing react, yeah, know exactly how the codes gonna look like, yeah, they're just translating their behavior in there. And it's not made for that it's strong because of other specifications there that make it better than the other language in some cases or the framework. But, but indeed, if you just translate it, it, it becomes weird. It's like some of our Dutch sometimes speak English, you really hear it

Rick
Dunglish right, the Dutch English, that's horrible.

Dylan
Yeah, that's a, I think, a great example you get in, and of course, now I can't think of one. But in human language, you often get, like, French fondateur, you know, potato. But if you don't know the word potato, you're like a pundit. And you go into a grocery store and ask them where the earth apples are. And of course, nobody in English knows what on earth Apple is, because that's not what we call them. And I think you get a lot of a lot of similar things when people try and translate programming expertise from one platform to another, is they take a lot of those weird kind of constructs with them. And, you know, ended up with, hey, how do I convert a char to a string in JavaScript, and it's like, we don't have that here. Like, there's no distinction between those things. Not just a string, that's only one character long. And if it's more than 16 bit Unicode, it won't work anyway. So good luck.

Oscar
Yeah, JavaScript is special.

What’s wrong with translating programming expertise from one platform to another? - 37:24

Dylan
I love JavaScript, I. So I will defend JavaScript, because it is the only language we've ever created, where I can write a program, and you can run it on any computer and run it on your refrigerator, you can run it on your phone, you know, in terms of the accessibility and the distribution model, you write the code, you put it on a web server, anyone on the planet can then run your program. And you know, that almost blows everything else out of the water. If you're, you know, your end goal is I want other people using my software, either because it solves a problem a lot of people have all because you are trying to develop a platform and growth is one of your, you know, targets, you want more users you want more engagement, which, you know, it kind of sucks. That's just so you can sell more adverts, but unfortunately, that's the sort of commercial model we've ended up with for a lot of the web. But you know, you take a program in JavaScript, hey, click this button. There it works. You too. Oh, yeah, sorry, um, my programs written in Erlang. So you're gonna need to install Erlang on your phone. And they're like, What? Okay, I guess you're not going to be signing up to our platform anytime soon. And I'm dumped on Erlang you know, Haskell, Ruby, rust, go. There's all these fantastically powerful and expressive languages, where, you know, step one is Oh, you'll need to install a supported runtime.

Rick
 If I'm not mistaking the deep space telescope that we have right now. Also runs JavaScript, right.

Dylan
I couldn't possibly comment this the James Webb telescope.

Rick
Yeah. If I'm not mistaken. It also runs JavaScript.

Dylan
It's now I read about this. There's some JavaScript tooling involved in the like, the reporting interfaces that they use in mission control for it. Because I saw the whole thing went viral about yeah, there's JavaScript running in space. And then the, you know, the much less exciting thing from NASA going, there's not JavaScript running in space. There's JavaScript running in mission control, you know,

Rick
Yes but still okay. So JavaScript is involved in, I mean, that's still that's kind of awesome.

Dylan
But I mean, there was a thing I remember when the first kind of pandemic thing hitting 2020. And lots of people were working from home and somebody who worked at NASA tweeted and said, I literally just had to have a meeting about what happens if someone is like remote desktop into Mission Control, because we're working at home. And they are issuing commands for one of our satellites and the cat walks across the keyboard. How do we make sure that doesn't happen? And I love that.

Oscar
That's a new challenge.

Rick
It is. But it's an awesome one.

Oscar
So cool.

Closing - 40:35

Rick
Dylan. Yes. Is there anything that we haven't touched upon yet that you would like to share with those listening or anything that you would like to get back to?

Dylan
Ah, that's always a tough question. There are so many things. You know, the travel the way in which people learn from one another how happy I am to be going back to doing in person events after the last couple of years. I'm going to be at Techorama in in it's an Antwerp, isn't it? No. Utrecht. DevOps is in Antwerp, the same week, because I'm going to both of them. Yeah. So Techorama is in Kannapolis in Utrecht, which is going to be great. You know, you get to catch up with a lot of people and find out what they've been working on this whole time. So very much looking forward to that. But now I guess the, the message I always try and sort of get out to people is, you know, if you're disillusioned with technology, and you're getting frustrated and burned out and everything, try taking a couple of steps back and do something completely different. Try and try and solve a problem. That's fun. Because that's something actually I've seen, just to circle back to Rockstar is I've had people come up to me, I've done talks about Rockstar before, and someone's come up afterwards. And when, for the first time in 10 years, I want to go back to my hotel and play on the computer. And you know, these are professional developers who are like, you know, it's this just became my job. Like, I do this for money, and I solve problems. And I work with a team. And I like the people and the work is okay. But I lost the spark a long time ago. And now it's just something that I do. And I saw that the Rockstar thing and I was like I actually want to play with that. That looks fun. And some people then come back in the morning and they're like, I stayed up all night and I wrote a rockstar program to calculate time zones or something. And I'm like, wow, that's a...

Rick
And it's now available for your calendar.

Dylan
Now available yeah.

Rick
That tt knows where you are and what the time zones are.

Oscar
No problem. We've just kind of solved put everyone to UTC.

Dylan
Actually, the best time zone is UTC minus 11 because nobody lives there. So if we tried to put the whole world on one time zone, then you know, we went for UTC. And in winter, Britain would be fine. Actually. Monrovia is UTC all year round. Monrovia and Reykjavik are the only ones that don't have daylight saving time. So they'd be fine. They'd be like, Yeah, we don't have to change anything. And everyone else would be like, Why are Monrovia and Reykjavik getting special treatment? So we'd have the least to do probably, we'd have to pick a time zone where nobody lives. So that upset everybody. And it's I think it's UTC minus 11 is like a strip down the middle of the Pacific Ocean with there's no like major settlements or human habitation in that strip. So if we did that it would upset everybody equally. And so it'll be very...

Oscar
Sounds good.

Rick
And that's a good thing. Yeah. Well, I actually just wanted to mention that. If somebody comes up to you and says, hey, because of your talk, I got the sparkle back. I mean, that's the biggest compliment you can get right?

Dylan
It's great. It really is. It's, you know, make people happy. Get, get people excited about something. It's there's a lot of frustration and unhappiness and anxiety in the world. And if anything any of us does, can make somebody smile and get them a little bit enthused and inspired again, and that's yeah, that's a big deal. It really is.

Rick
Let's close on that. Thank you, Dylan.

Oscar
Thank you.

Dylan
Thank you much.

Rick
Thank you for listening to Betatalks the podcast, we publish a new episode every two weeks.

Oscar
You can find us on all the major streaming platforms like Spotify and iTunes.

Rick
See you next time.

Oscar
Bye.