#96 Dylan Beattie THE Rockstar Programmer
Transcript
⚠ The following transcript was automatically generated. ❤ Help us out, Submit a pull-request to correct potential mistakes
Dylan Beattie 0:00
This will go down in history as a fantastic piece of timing. In this year, January 2020, I started my own company, doing international software training and conferences and consultancy. And of course, January this year was a very, very different world to March this year. So it's been a challenging couple of months.
Tim Bourguignon 0:29
Hello, and welcome to developers journey, the podcast, bringing you the making of stories of successful software developers. To help you on your upcoming journey. My name is Tim Bourguignon, and today I received Dylan Beattie to keep it short. You are a software developer, Rockstar, of course, and since you're a software developer and a rock star, you are the creator of the Rockstar programming language.
Dylan Beattie 0:52
Yeah, correct.
Tim Bourguignon 0:55
We're going to talk about that very soon. Okay, but first, the very short reminder The show exists to help the listeners understand what your story look like and imagine how to shape their own future. So let's go back to the beginning of your story. Where would you place the start of your DevOps journey?
Dylan Beattie 1:14
Interesting. So, so I spent my childhood in Zimbabwe in Africa. I was born in Kenya, my parents moved around a little bit. And I'm probably one of the only people in the world who had a computer before I had a television set. So when I grew up in Zim, we didn't have a TV. Zimbabwe was a great place to grow up in the 1980s. You know, we had a swimming pool in the garden used to go camping out in the bush at the weekends and stuff. And yeah, we didn't we didn't have a TV but one day my dad got this computer for work, which was a thing called in the UK and kind of English British Commonwealth countries. It was an Amstrad 6128. I think in Europe, the same thing was sold as a Schneider six, one to eight. And it was it was rubbish. It did do very much at all. And I was you know, I was sort of eight years old and I wanted to play computer games. And it came with some games that weren't very good. And I don't know where I got this idea from whether this is just kind of my, my character or somebody told me something. But I was like, I can make better games than this. I'm sure I can, I just need to figure out how. And so I started learning how to I had like a book I got out of the library, which was games written in BBC BASIC for a completely different computer. And of course, I had no idea that there were different kinds of computers at this stage. I just knew that I typed in programs and sometimes things worked. And sometimes things didn't work. So at a very, very early stage, you know, I wouldn't even say in my career, but a very early stage in sort of my relationship with technology. I had this idea that the the stuff you read in the manual, maybe isn't going to work first time but normally you can figure it out. And also probably started to develop this idea that you know, what is underneath the hood here that the behind the scenes, this is a deterministic machine, the same input will normally produce the same output. And you know, you can you can kind of triangulate in on what's actually going on underneath underneath the scenes and develop a better understanding of the machines and how they work. And, you know, I sort of played around I built little, you know, quiz games and odd one out games and try to do graphics and never figured out how to do graphics. But, you know, it wasn't, this was never mind sort of Stack Overflow and stuff. I don't think there can be have been more than maybe half a dozen Amstrad programming manuals in the whole of Zimbabwe in the entire country, let alone You know, bookstores where I could go and find teach yourself and this for dummies and you know, programming guides. So I was just sort of, you know, making stuff up as I as I went along. And the other thing that there was on that, that Stretch machine was the logo programming language, which was a graphical language where you could write programs that made this little turtles crawl around the screen and draw shapes and draw pictures. And that was fun that kind of you know that that gave me a, a lifelong love of breaking art and design down into geometry, and then kind of building it back up. And even now, if you look at logos that I designed for my projects and companies, I tend to design using straight lines and circles. And I think a part of that is because at the sort of very early early age, I was using logo to make interesting shapes out of straight lines and circles. And you know, how do you combine those very primitive elements to make something that looks a little bit creative or a little bit exciting? So that's kind of how it started, you know as me in Zimbabwe on this Amstrad typing in games and reading about logo and trying to make the make the computer do what I wanted it to do, and you know, do do interesting things with it. And it's sort of you know, it It goes on from there. I ended up running the school I went to we moved to the UK when I was 10 years old. And you know, the schools I went to first couple of years we had the the BBC Micro, which was ubiquitous in the UK for it during the 80s and 90s. So we had this this lab of BBC Micro computers that we use to make games and that kind of thing. They were trying to teach us to do spreadsheets, but you know, 12 year olds don't care about spreadsheets.
And then, I had this sort of this this weird in retrospect, it was a weird stroke of luck. If you look at my sort of speak of bio sometimes that I submit for conferences and things. It says Dylan wrote his first web page in 1992. And that's actually true because 1992 so my third year of what we call secondary school here in the UK, we had to do work experience where you got a school for a couple of weeks and you go and you work with local companies and my mother and you You're the guy who ran the computing department. So not computing science. This is just like, you know, IT support and computer labs at the University of Bristol. And she rang them up and said, you know, My son is looking for some work experience. And he said, Oh, yeah, brilliant, send them over. And Ronald Haynes was his name. And it was great, because I basically had this this one week with him in this lab where they had, you know, they had Unix machines, which I'd never seen before. They had terminals, they had telnet. They had, and this is right at the beginning of the World Wide Web. Like, I think that the HTML 1.0 draft specification was maybe six or seven months old at this point. So there really wasn't you know, there were very, very few websites. Most companies didn't have websites. Certainly most people had not got a modem at home. And there was no idea of kind of browsing the web and surfing the web. These things didn't really exist as concept yet. But the web existed, there were browsers and there was HTML. And so you know, one afternoon, Ron said to me, Hey, this afternoon's thing, we've got these these notes, we took in a meeting that we've typed up, and we're going to publish them on something called the World Wide Web. And so you know, I kind of sat down and he showed me how to use vim. It may even have been VI, I don't remember the time period. But so you know, we kind of walk through how to do a bunch of editing using vim and putting these angle bracket tags into this document with some bullet points and that kind of stuff. And we did it and then FTP that onto a server and looked at it in NCSA. mosaic. And that was it. It was a web page on the World Wide Web at a time when they were, I don't know, less than 1000 pages on the World Wide Web. And I did that. And you know, in retrospect, you kind of look back at it. And it's easy to think, oh, man, if I'd seen the potential I could have, you know, quit school and become a webmaster. But of course, you never see the potential at the time. You know, I probably saw 100 things in that week that I'd never seen before.
And then I went back to school. And you know, I went back to studying mathematics. And the weird thing is I never studied computing in any capacity until I got to university. I did maths, and I did physics that I did English. And I did design, because the people I spoke to I was like, what are we going to learn? And they sort of said, well, you probably know most of it already. It's not that advanced with doing spreadsheets and word processing. And so it wasn't until University when when you know, computer science became an option that I actually did any formal study. So yeah, that's sort of the the journey that took me from the Amstrad one to eight and writing quiz games, to computer science at the University of Southampton. But I ended up I took a gap year I took a year out between college and university. And as I was studying for my a level examinations, which is the exams in the You take a bunch of exams when you're 16. And then you take a bunch more when you're 18. And the ones that you take when you're 18, they kind of govern which University you get accepted to. And so I my first year of college, which was that, that second that a level set of exams, I was doing really, really well. And then when I took my study leave for the finals, my dad bought a new computer, which was a 486 that ran povery, the persistence of vision raytracer. And I just got hooked on it. And I spent instead of studying for my maths and physics exams, I spent the whole time playing with povery. And I dropped a grade, which meant I didn't get my first university place offer. And so I took a year out and worked as desktop support for Arab at the engineering company, which my dad was working there. So he sort of said to me, we've got all these computers, they don't have a bunch of, you know, workstations can just PCs Windows PCs, that was set in boxes because they didn't have time to set them up. And he said you want to come and work for us for a couple of months and install these companies. And put them on people's desks. And it was great. You know, I was playing with computers, it didn't kind of occur to me at that point that there might be a career in this, but I was enjoying it. And you know, people often sort of say, you know, when did you want to know? What do you want to do when you grow up? What are your career aspirations? I've never been very good at that kind of long horizon planning. I know what I want to do today. And I know what I'm excited about doing tomorrow. I have no idea what I'm going to be doing five years from now. And I don't really think I ever did you know, university is kind of easy. It's like, well, this is what you do. You do three years of this, and then you graduate. So you're not kind of personally responsible for making any career plans for a couple of years at that point, because it's taken care of, you've kind of slotted your career into this box that What are you doing, I'm at university and then kind of, you know, solves the closes down that line of questioning. And so, you know, I spent this year doing computing stuff and I started out just installing WordPerfect and Windows. And by the end of it, I was, you know, building Install scripts and I'd automated things and I kind of knew pretty much everything you could do with Windows, I knew a little bit of Unix and Solaris for running file servers. And it was great. And I enjoyed that every day even in like, you know, a civil engineering office in Bristol every day, there would be something that we've not seen before that I could sit and try and figure out, you know, how do you get this program to work with these new printers that we just got? How do you restore a file from a backup tape from when we were running the old backup system and you know that that sort of the enjoyment of just being constantly challenged with problems that none of it ever felt routine, there was always novelty and there was always this this interesting stuff. And yeah, that got me to university. Then I graduated from university in 2000, just as the the first.com bubble was bursting, and got a job building websites. And so you know, one of the the interesting things that the people I think often come up come across in the story of that Korea journey is about technology stacks and how you end up.
And I think that this, we're going off on a little bit of a tangent here. But people feel different degrees of affiliation with different kinds of, you know, programming models and languages and databases and these kinds of things. And I know people who they, they don't care, they'll turn up and they'll use whatever it is, and they'll very, very rapidly develop a high degree of proficiency. Whether it's, you know, Java, JavaScript, dotnet, Ruby, PHP, COBOL, they're like, Alright, this is what we're using. But I also know people who do feel kind of very strong sense of affinity with a particular stack or a particular set of technology. And, you know, when I, when I got out of university, it's like, well, what do I want to do? I had a, you know, experience, I studied Java, academically, like we built Java distributed systems with network sockets and these kinds of things. I'd studied scheme and Lisp, and I dumped JavaScript programming. I've been running Linux for a couple of years. And you know, the whole thing's wide open. But I'd also built little database driven websites in Microsoft Access 97. If you remember that going back, what, 23 years now, it had a feature where you could build a database and then publish it as a website. And you gave it a folder, and it dropped all these files into the folder that had dot ASP file extensions. And you know, I did this once we had some some stuff at our upper I was working, I was doing little bits of work there in my holidays. And they have this stuff like phoneless, that they wanted to be able to put on the intranet, which was a pretty neat idea at the time. And I played around and I was like, Look, you can do this, and then we can publish it. But then when we make changes to the phone numbers, they automatically show up. We don't need to update the intranet. And that was my first kind of experience of database driven web application development. And it was it was ASP, and I knew ASP is resulted kind of doing this and then taking apart these ASP files that got created by access and figuring out how they worked. I knew ASP pretty well. And there weren't a lot whole lot of people who knew it. And for some reason that was in demand, you know, Microsoft was still seen as a very, very safe choice of platform by, you know, companies with corporate IT budgets and that kind of thinking. And so I got a job doing classic ASP, was just ASP active server page development, initially with VB script, and then I switched from that to using j script, because ASP, you could run JavaScript on web servers. And so that kind of gave me this Microsoft SQL Server was the database, classic ASP, and JavaScript was the the scripting language and then on the front was HTML, JavaScript, CSS. And I found that a very productive kind of platform to work in. I guess, just because I you know that the problems I had the years of doing Windows desktop development meant I knew where to start looking to figure things out and poking around. And so I do did that for a couple of years building little websites for, you know, clients to do all kinds of things. A lot of it was putting catalogs online. And you know, this was the age when most companies didn't have websites, the vast majority of customers that we worked with needed their first ever website, they bought a.com domain name or a dot code at UK, and they wanted something to put on it. And sometimes it would just be a couple of placeholder pages. But the interesting ones were the ones who would come to us with their printed catalog and say, what's it going to take to make this into a proper website that actually works? And you know, sometimes it would be, you know, generated with reports, and there'd be some relational data already behind it, that you could take and you could import into SQL Server and run reports and pages from that. And sometimes they'd have you know, I worked with one client, their catalog was CorelDRAW files, and every page of their catalog had a layer that had a lot of photography on it, and then it had a layer that had all of the product specifications. And then it had a layer which had all the kind of advertising copy in the marketing text. And, you know, turning that into a website was kind of fun because you got to do a little bit of scripting to isolate these layers, which had the product specs, and then some stuff to pause those and turn those into structured data and pull that in. And then, you know, working out what's the best database model to run this thing off. And that was fun. Lots and lots of fun working on those kinds of projects. And, you know, a lot of cases it was like, okay, the website is now finished, and then they put it live and they go away for six months and see what happened. So there wasn't this this thing you you sometimes get where you build a system and immediately like Monday morning, they start filing bugs, and saying, you know, this is a problem. This didn't work this worked and figuring out all that kind of stuff. And eventually one of the clients that we worked with that gave me a call and said hey, you know, we're
interested in bringing Someone on full time would you be interested in moving to London to come and work with us. And I did. That was a company called spotlight. I worked with them started out as webmaster building basically the entire it stack by myself. And by the time I left there, 15 years later, I was systems architect, we had a team of about 16 people working on three development strands. We had a, you know, dedicated ops team. And the whole technology stack had migrated from most of it from from ASP JavaScript on to dotnet. And we were starting to build out some you know, micro services and message queuing and these kinds of architectural patterns. And yeah, so and then I got I got another phone call 15 years into that from a company in London called skills matter who I knew very well. What had happened is the sort of the last few years I was at spotlight, I started first I started going to conferences, and user groups because I was stuck and I wanted to learn and I wanted to, you know, get the opportunity to talk to people who's having problems with designing dotnet systems or you know, database models, all these kinds of things. And you know, I wanted to have the opportunity to meet some of them and chat to them. And it's funny, the story that you hear a lot in, you know, other professions is about what inspired people to try something is they saw somebody great, you know, you talk to guitar players who were like, I saw Jimi Hendrix on TV or I saw the Beatles or Eddie Van Halen as like, I want to do that. That's what I want to do. And that that's what kind of set the career and you know, athletes and people talking about seeing these amazing performances. And I kind of I saw a lot of really, really good speakers and was like, yeah, this looks good. But then what actually galvanized it was I saw I'm not gonna tell you who or where or when, but it was awful. It was the worst talk I've ever seen. And I was just like, I can probably do better than that. Like, you know, I don't know, but there's no way I'm going to be worse than that. And if they'll give That person, a microphone and an hour on stage, then maybe they'll do that for me too. So I took together some of the ideas that we'd been working with at spotlight and I turned that into some talks about doing interactive web programming with jQuery. And I pitched that and I got that on the user group. And that's what got me into doing events and community and conferences. And then a couple of years into that. I got a call from the C CEO at skills macro in London, where I'd done conferences and program committee with them. They're expanding, they're growing the team, they're looking for a CTO, so I went and joined them. And that was a massive kind of shift from the kind of my comfort zone in terms of technology. Because their stack was all as Postgres it was Ruby on Rails, I switched to using Mac OS as my main, you know, day to day development, operating system for a couple of years. Different deployment scenario, they were running on Heroku, there was some Redis and some Elastic Search in there. So again, this thing of You know, getting to grips with unfamiliar technology and unfamiliar problems, and how do you quickly iterate on a solution and get that to work. And they actually, they went into administration, October last year, which was kind of quite sudden and unexpected. And basically, it was like now that's it, the company's run out of money. We, the lawyers that are coming in, thank you very much, everybody. You can file your, you know, any claims for redundancy pay or anything with this number, please give us your keys and off you go, which was unexpected, you know, and that sort of threw me a bit of a curveball. And I was like, Well, I'm not sure I want to go and get another job. You know,
it's been I've learned a great deal, but I was reaching a point where I was so busy doing, you know, conferences and running community events and getting more and more involved in that side of things. I thought, you know, now is now is the time I'm going to take a couple of months off and relax and then and this will go down in history as a fantastic piece of timing. In this year, January 2020. I started my own company, doing international software training and conferences and consultancy. And of course, January this year was a very, very different world to March this year. So it's been a challenging couple of months. But it's you know that the interesting thing, you know, to bring the journey right up to date is within the last probably the last month or so. So, stays what sixth of April, so six of March, I was in Copenhagen. We just done a in person conference there. I was flying back to the UK to come and do a couple of meetups one of those meetups decided it was going to go virtual that week. Another one ran a physical meetup and you know, everyone had hand sanitizer and please, you know, sign this form to say you haven't been in China or northern Italy. And within a week, the whole thing was completely locked down. But I was lucky enough to kind of get an early insight into what we were going to do because of that first meetup that that ended up being run virtually. And I sort of thought there's going to be a lot of people wanting to know how to do this, how quickly can we get something up to speed? And how quickly can you know, I familiarize myself and the people I work with with the capabilities of this technology. And so what I did is I went out on Twitter and some groups that I'm on pulled together just a whole bunch of interested people, speakers, consultants, you know, and said, Look, we've all got to figure this stuff out. And the nature of the problem is such that I don't think anyone can figure this out on their own. Let's put together a group of people who are gonna do ad hoc virtual meetups and video calls, and we'll figure this stuff out together. How do you present an online format? What are the tips, what works, what doesn't work? How many people can you get in a room? Is this platform any good? Is that platform any good? What kind of cameras should we be recommending that people buy and how should they set them up and all this kind of stuff? And, you know, did that in a sufficiently public way that it It very sort of quickly, people noticed what was going on with it. And DC conferences got in touch and went, hey, we have three events, we need to virtualize that. You're already we're supposed to be, you know, teaching and speaking. We're doing them all online. Can you help? So I've spent the last two weeks working flat out with them. We ran NDC, Copenhagen as a virtual online event last week. It went really, really well. We got some very positive feedback, London awful lot about the format and the constraints and capabilities and all this kind of stuff. And so that's now you know, sort of full time, the latest installment of Well, we've never done this before, but I'm sure we can figure it out if we ask the right questions and talk to the right people. And so I seem to have, you know, accidentally become a specialist how to virtualize online technology conferences within the space of the last month. And it looks like that's what I'm going to be working on pretty much flat out for the next the next couple of months until I avoid using until things go back to normal because actually, there were a lot of About normal that I think probably not a great idea. But I am very much looking forward to being able to travel and see people in person again and that kind of thing. But, you know, until until that's possible this is this is what I'm doing now.
Tim Bourguignon 24:13
Congratulation on the pivot.
Dylan Beattie 24:18
Right? Well, you know, it normally does experiences what you get when you don't get what you want. And I have a lot of experience by that definition. So
Tim Bourguignon 24:27
there's there's a whole bunch to unpack. I'm not sure where I could start. I would like to come back to two comments that you made. The first one was about the about the logo, language. I think this is a fantastic metaphor, which you said was using primitive element to make elaborate things. This is the perfect metaphor for programming.
Dylan Beattie 24:45
Yes. A lot of the time. Why just a lot of the time. Well, you know, it's an interesting idea. I've always my whole life been fascinated by systems that afford a kind of modular design approach. You know, I grew up with Lego, I still love Lego my in my house is full of Lego. And I think that one of the challenges that we have always faced with technology is how do you we were looking at a different example, say you're working in your building cars, you know, cars, passenger vehicles, those kinds of things. And I'm sure you're all familiar that when you design a new car, you start out with models that are made out of clay or card or plastic or steel, or would you know there are all these materials that people work in to refine the design and they prototype elements of the drive trains, they try out different materials, they build ergonomic mock ups and everything.
And it is there is a very, very clear understanding in those industries. That the thing you're looking at is not a real car and you are not going to drive home in it today. That is not what this is. And you know when you're doing construction architecture, We build 3d mock ups in software. And we build cardboard models of buildings with those, you know, little plastic trees stuck around them, and you do artists impressions. But again, there is this very, very clear, you know, you don't ever show somebody a cardboard model of a hospital. And they go, Oh, brilliant, thank you. It's exactly what we wanted. And then they start moving in, you know, they're like, it's what we wanted, when can you start building it? But with software, you know, the finished product is boxes on a screen. The prototype is boxes on a screen, the mock up is boxes on a screen. And you know, we've always had this this challenge in software, about how do you do that, you know, first, there's may be the high fidelity mock up. And the way that I tend to build web websites and web applications now is I start with a user journey. And I use a piece of software called axia Asura for that, because axia lets you build interactive prototypes, and it makes them look like pencil sketches and writing fun Some kind of you know, wobbly lines. And that allows you to prototype the journey without building anything that looks like a finished website. But then the next pass over that is I'll take that journey once we validated the steps and the interactions. And I'll turn that into a high fidelity HTML mock up. And at that point, it's really hard explaining to people that this is only 10 or 20% of the work that's required to make this thing real. Because to them, it looks great. It just doesn't quite work. And it looks like there's a couple of bugs. And you're like, No, no, when you click that button, there's nothing behind it. There is no database, no logic, no behavior, nothing, nothing at all like that. And you know this, your idea about or your your observation about how we compose simple components, you can get something that does 90% of what you need in 90% of circumstances by composing, you know, components in a fairly simple way. One of the interesting historical footnotes about JavaScript as a programming language. You will never supposed to use JavaScript to write systems JavaScript was glue for connecting Java applets. And so you were supposed to write your components that did the heavy lifting in Java, and then deploy them into the browser and use little shims of JavaScript to connect them together. In you know, like building Lego or something, this whole rapid application component model that was was very popular around the era of Visual Basic and desktop applications. And you know, there was still there's react components now, and there's bootstrap, and that this idea of composing components into systems has never really gone away. But then I think you get to a point where it's like to make this any better, or you're working on a system and it's like to increase the capacity or the throughput or to really understand the security. We now need to take the the model, the product that we've validated by sticking simple components together, and we actually need to build something that does This job. And that's something I think it's very, very hard to tell at what point do you do you do this? When's the right time to do it? How do you know? How long is it going to take? And this is, you know, I think one of the biggest challenges around software architecture and software engineering is when do you ship and how much faith do you put in the thing that just went live? Because you know, agile and you know, lots of kind of lean engineering things advocate the idea of the minimum viable product. And so you do the minimum viable product, but then what do you do immediately after that, what's your definition of viability? You're like, it worked. We put the website online, it was immediately overwhelmed, and it crashed because too many people were trying to use it. And some people are like, Oh, well, that just proves that, I don't know PHP doesn't work or that we shouldn't have built it in Java. And it's like, no, it proves that people want your idea. That's the assumption that you validated it. You know, the viability of the minimum viable product often has nothing to do with software. It has to do with Is there a market is there an audience For the idea that we think is going to sell, and you know, the MVP, you put something online, do you remember the early days of Twitter and the fail whale? When you know it, Twitter would be down daily, like people daily would would, Twitter would fail to update and fail to refresh. And you know, people think of it as an engineering failure. But it wasn't it was a triumphant business success, because it showed that the capacity or the demand for that product vastly outstrip the capacity of what they'd invested in it to date. But, you know, alongside Twitter, there's probably a company that we've never heard of, because they never launched, who didn't build it with PHP and MySQL. They started out on day one, and they're like, we're gonna support 1.5 billion users. We need this whole thing to be engineered from the ground up using Scala and distributed message queues. And they were, you know, eight months into building their data flow diagrams when Twitter launched and took over the world. We don't know you know, those things. The history is written by the winners. And the losers don't get nearly as much mind share. And so we look at the the approaches that happen.
But yeah, to go back to your point, I think, you know, we can, this idea of assembling simple components is a really, really powerful way of prototyping and enabling rich conversations about what you're trying to do and whether it works or not. But then you I think, invariably get to a point where the thing that makes you special, the thing that makes your product stand out is that everyone else has built theirs out of components, and you've actually got something special, which other people didn't have access to. An interesting, you know, very, very relevant example right now is video conferencing platforms. Because it is, in theory, and you know, it says my software developers optimism speaking, in theory, now there are enough open standards and open protocols that building video conferencing doesn't look that hard. most browsers have API's for doing real time video. most browsers have API's for connecting to cameras and microphones. And so the, you know, can we get three or four people talking to each other over live video, I think you could probably do a proof of concept just using off the shelf components and open protocols in maybe a day over enthusiastic hacking and get something that worked well with the right people under the right circumstances. But then if you want to turn that into something which can host 200 million active calls and stand out in terms of you know, quality and interactivity, which is what I understand is happening with zoom as a product at the moment. You know, I do not believe for one second that zoom is made by bolting together off the shelf components to create this this, you know, composite system. I think they have really invested a lot in building compression algorithms and user experience which is not created from off the shelf components. And I think that's why at the moment, they've become so prominent, I think it's why they're getting so much attention in terms of security and vulnerabilities. And you know, these kinds of issues. And over the last couple of weeks, you know, I've evaluated in a sort of fairly informal way, probably a dozen different video platforms. And that experience of I want to talk to some other people. All I have is their email addresses. What's the easiest way to get us on a call together, we can see each other's faces. You know, zoom is easy to set that up. Google Hangouts is easy to set that up with discord, you can set it up, but you have to jump through a couple of hoops to get the right friends and the right channel and all these kinds of things. There's a platform called whereby that works brilliantly, unless you need more than 12 people, at which point it's like no, we just don't do that. And, you know, you do start kind of thinking, Well, what is it that makes these products stand out over and above those ones? And I think it's that I think it's there's a point at which once you've validated the approach. It's like okay, now we need to replace this set of components with something that we've really, really tweaked and optimized and that we control end to end. So, yeah, components are great for doing things that get you 90% of the way there and prove you're on the right track. But if you really want to kind of, you know, win and own something and stand out better than than all the competitors in that space, secret sauce, you know, the 11 secret herbs and spices that KFC using their recipe or the the Coca Cola formula.
Tim Bourguignon 34:33
Hopefully that's their component approach to to come back to something else you said. You said you were not really the the one to to plan your journey ahead. A couple of steps ahead. Yes, but not too much. what's what's your algorithm to steer your life How do you decide on taking branch a, instead of French be
Dylan Beattie 34:59
the thing That, you know, there are all these
decisions that come up in life that look like a big deal. You know, like if you decide, I don't know, your moving house, and you need to decide where you're gonna go and live. And it's, I think it's easy for people to think that everything comes down to this decision. Like, if I pick the right house to live in, then I will be happy and everything will be lovely. And if I pick the wrong house to live in, then everything will be awful and everything will be miserable. But you know, I don't I don't necessarily agree with that as an observation. I think very much how good your days are from one day to the next is down to what are you trying to do that day and why are you excited about it? And, you know, the happiest periods I've had in my life that have still been points every day that just really, you know, pissed me off, upset me. And the absolute worst periods in my life where I've been dealing with the out and depression or you know, all these kinds of things, I can still look back and be actually, you know, even at the worst of it, there were moments in every day that were good moments or, you know, happy or inspiring moments. And you can I think we have more control over those kinds of things than, you know, a lot of people credit. And so if you look at a plan, and you're like, right, if I make this decision now, then everything for the next five years will be fine. You know, when you express it like that, it sounds a little bit naive, right? It sounds like well, how can I ever make the right choice? It's like, Well, no, you, you make the right choice based on the data you have available at the time and then you kind of follow through on it. And you'll be prepared for the possibility that you may have made a mistake, but you also like Alright, well, this is this is normal. Now. This is what I woke up with this morning. What am I going to do today? What am I going to do tomorrow? What am I going to, you know, do out of this I have a side project which has been a lot of fun over the last couple of years, which is a band called Blind breakers, which is all conference speakers who are also musicians. And you know, we get together when we go to conferences, and we play shows at after parties. And you know, we got invited to a bunch of things in November last year. And you know, that's taken probably three or four years to get to the stage attack now, but I didn't start that four years ago, as a plan of I'm gonna get this person and this person, this person, we're going to learn these songs. We're going to play this show on this date. I started it with just me and a guitar and a couple of funny songs I wrote about programming. And you know, there was this event called pubcon, which happens as a kind of after party for some of the NDC events. And I got to know Todd who organizes it, and I said, Hey, you know, I'm gonna bring my guitar to pubcon and play some songs. And he's like, oh, cool, do it. And you know, I was drunk and everyone was drunk, and it was probably a mess. But everyone enjoyed it, and it was pretty good. And based on the success of that, I came up with a couple more songs and then some Somebody a guy called Vikki fabula, who's a Russian Russian programmer and keyboard player who lives in Oslo, he came to me and he said, Hey, you know, do you want to add musical collaborator? Should we do the show together? So we did a show, and it's just grown. And you know, the outcome of that project over three or four years? Is the net result of lots of little decisions of like, Yeah, let's do a show next week. Yeah, let's do this. Oh, someone's gonna be in town. Let's let's drop them an email and see if they want to join us. And it's, it's worked, you know, is it? Is there some way it would have worked better if there'd been a master plan? I don't know. There's no control group. There's no kind of, you know, a be testing for this kind of thing.
But certainly, you know, just a big part of it is when you have an opportunity, and you're like, Okay, if this goes wrong, it'll be embarrassing, and it'll be in front of a roomful of people and, you know, it could damage credibility. And but you just got to get over that and go, what the hell you know, what's the not what's the worst that could happen? What's the best that could happen if we do this, and it was Next, what is the greatest positive outcome? And, you know, one of the other things that I think I think this actually goes back to Metallica to an interview I read with them. They did an album called load about 20 years ago that didn't get a hugely popular response. And I read an interview with James Hetfield, you know, sort of singer and guitar player. And he's like, well, we made the album we wanted to make, because if we made an album we didn't like because we thought the fans would like it, and the fans didn't like it. Then we made an album that everybody hated. And that was a massive mistake. So we made an album we wanted to make so if nobody else likes it, at least we liked it. And I think you know that that's a philosophy you can apply to a lot of things when you go into making a decision. You're like, Well, what do I want to do? You know, and never mind trying to keep other people happy or, you know, impress clients or shareholders or audiences or you know, Like, what do I want to do? What's the thing that I'm gonna look back and go? Well, it was a disaster, but at least like I'm, you know, I was honest with myself and I had a good time. And, you know, that is a philosophy that has mostly stood me in pretty good stead thus far. So, yeah, I don't have a five year plan. But I do have a set of principles. I used to make decisions from one day to the next. And I've been doing that for a lot more than five years. And most of the time it's working.
Tim Bourguignon 40:27
Yeah, it sounds to be working fine, even with Coronavirus and pandemic was starting a new business.
Dylan Beattie 40:33
Well, yeah, you know, I wrote a business plan. I wrote a very detailed business plan that I used to get, you know, get my bank account and set up my business accounts and all that kind of stuff. And the business plan lasted about three weeks after which it's like, well, that's not happening. That's not happening. That's not happening fine to improvise a new business plan. You know, you know that the movie Apollo 13, about the the NASA mission to the moon where they had the explosive And there's that scene where Ed Harris is playing gene Krantz. And he comes in and he goes, right, it's time to improvise a new mission. You know.
Tim Bourguignon 41:10
Congratulations on that. Let's stick to the to the music analogy. And yeah, and bridge the software world you hated. I don't know where the idea come from and how you came to the Rockstar programming language. Yeah. Can you give us the pitch about this? Because it's, This is nuts.
Dylan Beattie 41:29
So it started out, it's
again, there was no plan here. It started out with this whole idea of bat Rockstar programmers and you know, you go on like LinkedIn and you look in the jobs advertisements, and you find these people going, Oh, we need a Java Rockstar, or we need a this Rockstar or that Rockstar. And it was a guy called Paul Stovall, who is the founder of octopus deploy, which is a brilliant deployment solution for dotnet platforms, which I'd worked with anybody put this thing on Twitter that said, you know, to really confuse recruiters, somebody should make a programming language called Rockstar. So that's where the idea came from. And, you know, I've always I've always enjoyed writing lyrics and writing poetry. And I like esoteric programming languages, I've always found them not just like the the type languages, but languages where there's one that was it's years ago, it's about 20 years old. Now it's a module for Perl that allows you to write po in Latin. And what it does you know, Latin has different formal grammars for referring to singular things and plural things and possession. And what the pearl lingua Romana module does is it uses the rules of Latin grammar to replace the rules of pole language syntax. So operators which have different behavior when you apply them to a scalar or to an array now become Latin verbs which have different forms for the singular and the plural And I thought that was genius. You know, I love that kind of idea about how do you translate idioms and concepts from one domain into a completely disconnected domain in a way where they now they still remain internally consistent. And so I had this idea I was I was in a bar in I think, in Sydney, Australia, I was waiting for some people and they were late and I had my laptop and I thought, I wonder if you could write a spec for a programming language that looks like, you know, rock and roll lyrics and heavy metal lyrics. So I started playing around with it and just, you know, stealing these little phrases and snippets and, you know, we're talking cliched. You know, my heart is as strong as the ocean type lyrics, power ballad stuff. And I, you know, I came up with a parody specification that looked reasonably consistent and I managed to write fizzbuzz in it and I thought that was going to be the end of it. And it just it sparked it. The Internet found this thing and loved it. Kept just kind of, you know, doing things with it. People started implementing compilers for it based on my parody spec. There was some web additions, I got, you know, press coverage and classic rock magazine wanted to do a feature on it. And all this kind of stuff. And eventually I, I kind of, I didn't feel like I'd done enough work to justify the buzz that was happening around this. And I was also kind of feeling left out all these people were out there building Rockstar compilers, and I was like, well, I wouldn't know how to do that. And I don't like not knowing things. I like understanding things. So January last year, I took a couple of weekends over Christmas and dusted off my old kind of, you know, university era knowledge about compiler engineering and syntax trees and pauses. And I built a rockstar interpreter in JavaScript, which was a lot of fun. It was difficult, but you know, it got easier learned about pausing expression grammars and I put that online, it's a coat with rocks. start.com. And the nice thing about it now is that it's a very easy language. So anybody who wants to can be a rockstar programmer, because all they need to do is go to code with rockstar.com and type in some code, and they click Run and they know you're a programmer now and because you did it in Rockstar, you're a rockstar developer. And, you know, it was, I designed some stickers and this kind of thing that I get printed, and I take with me when I do conferences now. And it's just, it's fun. It's pointless as a programming language, you would never use it to build anything important. as a teaching tool, and I kind of study tool. It's been really, really interesting. I've done you know, conference talks, where I use rock star to demonstrate how you build pauses and how you build compilers. And that that's got kind of really good reception and some really positive enthusiastic conversations and stuff. But it's also it's something people keep asking about. It's people like us, you know, tell us about the rock star thing, that kind of thing, which I like because I enjoy conversation. And I enjoy, you know, the connections and the friendships that you can make with people. Let's start off with somebody going, Hey, you know, you're the rock star guy, and you sit and have a chat. And then you ask them what they're working on. And then you know, maybe next day you go out after a conference session, and you have a beer. And, you know, this is where, where friendships and connections and open source partnerships and all this kind of stuff come from. And it's it's nice creating something that facilitates that.
Tim Bourguignon 46:28
It's a fantastic icebreaker for sure. It is indeed So, and it adds up very well with what you said before doing what you like and even if it's a disaster, which is it is not in this case, but if it were, you had fun doing it and I think that's obviously what people see. But the the the follow up question I would have is, is did it succeed in screwing up with recruiters.
Dylan Beattie 46:54
There are certainly fewer Rockstar jobs on LinkedIn now than they were two years ago. But maybe that's just The economy? I don't know. I do. I do see people now, people on LinkedIn endorsing each other for Rockstar as a skill, which I love. I think that's so so good. So, but it's it's not yet been added to LinkedIn official list of programming languages so there's still still some goals to achieve.
Tim Bourguignon 47:20
Is there a 10 x language? I think there is.
Dylan Beattie 47:24
There's one called enterprise that somebody created to be an enterprise developer. And I think there's a 10 x language now. And it's just you know, you get once you realize that, you know, people who are good, this can actually create languages very quickly. You know, the latest idea I had was a language called mohito, which is all programming with emoji, no characters at all, just emoji. And there is already an emoji code language, which is kind of, you know, similar idea. So I that's kind of rattling around that I'm sure next time I'm I'm waiting in a bar and people are running late. That'll end up with a specification. or something. And I'm
Tim Bourguignon 48:03
looking forward to it already. I'm Dylan, if you had one call to action for our listeners starting their journey or on their journey and something they should do today, what would be your your advice or your call to action?
Dylan Beattie 48:17
That's a good question.
One piece of advice that's always stood me in good stead is try and when you're working in software development, you are always working with abstractions. You know, when you build JavaScript, you're building on top of a runtime that's running on top of an operating system that's running on top of an instruction set that's running on top of a processor that's built on top of logic gates. And, you know, I think there's there's always value try and understand even if just at a relatively kind of high level. Try and understand one layer of abstraction below the layer you're working at. If you're, you know, working in JavaScript, just try it. understand a little bit about how the browser is going to run your code or how no j s is going to run your code. If you're working on relational databases understand what's actually happening in terms of, you know, physical disk and memory allocation. Just because, you know, once you, you open that door and you take a peek through, you don't need to be an expert on what's on the other side. But you know, that it's there. And you have some kind of idea, some some concept, that something is happening behind the curtain behind the door, that could be causing headaches or problems with the stuff that you're working on. And once you understand that, it's not magic. It's just that you're working, you know, on a piece of technology that's built on technology that's built on technology, but actually at every level is probably smart people making good decisions. It's just the decision they made that day wasn't what you happen to need this day. And I think that makes us better developers. I think it makes us more kind of empathic and more simple. thetic and understanding. And it's also interesting, you know, I love taking things apart and finding out how they work. And while there's a lot of fun stuff in the world out there that we can we can take apart at the moment and find out what's going on. And we all have so much time on our hands at the moment so
Tim Bourguignon 50:18
at the woman disappears easier. That's true. That's true. Yeah. And when you reach the turtles, you can stop, it's turtles all the way down.
Dylan Beattie 50:24
That's turtles all the way down. But hey, that might be a new species of turtle that nobody's discovered yet.
Tim Bourguignon 50:28
Absolutely. Awesome. Thank you very much. Um, if the listeners wanted to continue this discussion with you, where would be the best place to reach out?
Dylan Beattie 50:40
So I'm a very easy person to find if you type my name Dylan bt into Google, you'll find my website Dylan bt dotnet. You find my email is Dylan at Dylan bt dotnet. I'm Dylan Beatty on Twitter, Dylan bt on GitHub, Dylan bt on Facebook. I'm Dylan bt one on Soundcloud which upsets me but there's somebody else got
that first.
But yeah, I'm a pretty easy person to find Twitter is the best place to find me and chat. Because you know i Twitter is a very easy forum to meet people. It's transparent. It's I like the format very much. I'm on it a lot. But yeah, drop me an email, get in touch. My company is versatile. You are at I le.com. Like a bear Ursa who does a lot of things. And yeah, at the moment, although the website doesn't quite reflect this yet. My specialism is in virtualizing technology events. And I've been you know, blogging and writing about the progress and things we've learned with with making progress on that. So yeah, get in touch. I'm always happy to chat,
Tim Bourguignon 51:41
any chance to see you on virtual conferences in the next weeks.
Dylan Beattie 51:47
So the ones that are definitely going ahead are there's a dotnet EF w days which was going to be in Kiev and is now going to be online that's happening this Saturday the 11th and next time Saturday the 18th. And then I'm also doing an online workshop with them on Sunday the 26th, which is a one day introduction to building distributed systems with dotnet. There's NDC Porto, which is now in DC online is taking place at the end of April the 21st, to the 24th, I think, which again, online, get some tickets to that we figured out some really, really interesting ways of virtualizing, the online conference format. We got good results with speakers, we're trying out some new technology NDC Oslo, which was previously one of the biggest events in the development calendar, but you know, 1800 people last year, that's in June that's going to be running completely online. Next, which is where I was supposed to be today in St. Petersburg, Russia that's now running in June and is going to be running online. So check that out. And And the interesting thing is all the events that are like we're still running because we're on November, and all the other events that are like we are reshaping July until November, and the other events that are like well, we probably going to run something in November. So if this you know, COVID-19 situation resolves itself over the next the next few months, then you know that November is going to be very, very busy. I think I worked it out, there's like I can, I can be on the road doing conferences for seven weeks back to back without going home in the middle. So, but we'll see it's, you know, even November is a little bit far ahead to be planning.
Tim Bourguignon 53:29
For the say story, I run a side project gathering papers, and I was pushing back to to fall. And I'm not sure what to do with it because I actually am at this mistake. I think big gatherings are not going to be so easy even involved, but no, well,
Dylan Beattie 53:47
yeah. Well, you know, I mean, the other the other interesting thing, I think, conferences or conference organizers should start thinking about now is I'm getting invitations now to virtual calls. conferences and now you know, people I've not worked with before they know me through work I've done on my you know, my reputation, who are like, we'd love you to speak at our virtual conference. And I'm like, Well, you know, without meaning to sound too mercenary what's in this for me because on the one hand, you know that the organizations that I have an existing relationship with I'm very, very keen to help them survive and succeed and want them still to be going on the other side of this thing. But you know, speaking of the reason why speakers do what we do is most of us we love traveling we like meeting people, we enjoy the the live audience and the atmosphere and our virtual conferences are very, very different proposition. And the format works very well in terms of presenting material, but in terms of you know, all the extra things that happen around it that we enjoy a lot of those on hold for the moment. And so you know, this invitation is like, you want me to get up in the middle of the night so I can talk to a webcam and you can broadcast it live for your event that's happening and you know, They are or Russia or Australia or whatever. What am I getting out of this? And, you know, I think those events need to start now thinking if we do end up trying to run virtual events for a longer period of time, how are we going to structure it? What's the nature of the sort of, you know, the commercials business relationship? Because we've not had to think about these questions before this has taken everybody by surprise a little bit. Even the, you know, the people who in January was saying, Oh, this is gonna be a big deal. A year ago, we had no clue. Nobody had any idea this was coming. So a lot of interesting questions, a lot of interesting conversations are going to be happening, but absolutely, we'll figure it out.
Tim Bourguignon 55:41
Awesome. Dylan, thank you very much. It's been a blast listening to story.
Dylan Beattie 55:45
It's been my great pleasure.
Tim Bourguignon 55:46
And this has been another episode of devjourney. And we'll see each other next week. Bye.
This is Tim from a different time and space with a few comments to make. First, get the most of those developers journeys by subscribing to the podcast with the app of your choice, and get the new episodes out to magically right when they air. The podcast is available on all major platforms. Then, visit our website to find the show notes with the old links mentioned by our guests, the advices they gave us, their book references and so on. And while you're there, use the comments to continue the discussion with our guests and with me or reach out on Twitter or LinkedIn. And a big big thanks to the Patreon donors that helps me pay the hosting bills. If you can spare a few coins, please consider a small monthly donation. Every pledge, however small helps. Finally, please do someone you love a favor, tell them about the show today and help them on their journey.