#255 Tomas Petricek always looking under the covers

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Tomas Petricek 0:00
My own journey, it was very much sort of, through fortunate random events, like getting to meet someone. And that then kind of open to new, new options. I mean, the thing that really helped me for many things in my sort of life was just doing things and and making them public. So I've always written stuff on my on my web page and publish things and like, Code Project, talked about the things. And then that led to too many random encounters through which I've, I've sort of learned things, but I've got no idea how reproducible that is as a method.

Tim Bourguignon 0:44
Hello, and welcome to developer's journey to podcast, bringing you the making of stories of successful software developers. To help you on your upcoming journey. I'm your host, Tim bourguignon. On this episode, I received Tomas Bester check. Among other things, too, let's do a PhD on context aware computations at the University of Cambridge, worked on F sharp tools at Microsoft Research. And he's now an assistant professor at Charles University in progress. We're not far away from from here from where I am right now. And a partner at F sharp works. He's interested in new ways of thinking about programming and believes that the most fundamental work is not the one solving hard problems. But the one that offers new ways of thinking. Hope we can get into that. Thomas, welcome to the afternoon.

Tomas Petricek 1:34
You just said you're going to avoid quotable quote, divorce quotes, and now you've done exactly that was me years to come up with that quote.

Tim Bourguignon 1:45
So I'm glad I have it right up front.

Tomas Petricek 1:50
Know, we can get back to real things.

Tim Bourguignon 1:53
Exactly. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up, if you would like to join the spine crew, and help me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info, and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. As you know, the show exists to help listeners understand what used to look like and imagine how to shape their own future. So as is usual on the show, let's start with the beginnings. Where would you place to start if you're dev journey.

Tomas Petricek 2:42
I mean, I think this is going to be the conventional story of sort of kid getting computers and starting to see what you can do with that. I was I was just a bit too late to the party and growing up in a bid to communist country at the time to have Commodore or things like that. So I got to computing but I was on sort of 13 ish, I guess, with things like HTML and JavaScript. And I did some Pascal as well, because we had a lot we had a little bit of that at school. I think that the HTML bet was was sort of this is this is the kind of thing that people frown about today, because it's like for software engineering, and the whole the whole thing was rubbish. But there was there was some some something really nice about programming in those days where you could like go to anyone's GeoCities web page, view the source code and copy their by picture following the mouse pointer effect or sort of changing image on hover effect, which you've had really do today with like NPM and Webpack compiled JavaScript.

Tim Bourguignon 4:03
That is that I remember the the websites where you had those catalogs of snippets, and you really just copy pasted it in your code, and it was working almost right away.

Tomas Petricek 4:12
Yeah, exactly. I mean, that's, that's the sort of the last thing I learned was like, you just copy things. And then you start to wonder, well, what if I change this and it breaks. But then you you kind of learn one or two things about that.

Tim Bourguignon 4:29
This is probably the thing that was so attractive about HTML and JavaScript. It was the the loop the feedback loop was so tight, you just change something and right away you had the the changes on the site.

Tomas Petricek 4:40
And it's actually doing something on the screen that's kind of visual. It's not like he sort of write write lots of code and then it prints hello world. The size, sort of done done some of that, but I was when I was at school and then for high school where In the Czech system is when you're sort of 14 or 15 to 18. I went to a school that had some programming. But I think the main the main sort of value there was being around other people who were into it. So I had a sort of group of friends who were always trying to be smarter than the teachers. By either by learning things in C++ instead of Pascal or by doing something weird. That was that was probably the sort of best, best way to learn things.

Tim Bourguignon 5:39
Did you have the idea that this could become your thing later on? Or was it just being around those people and having fun? For the sake of it?

Tomas Petricek 5:50
I think it was just having fun. I mean, before the high school, I did sort of contemplate getting into architecture. Which I mean, is a topic I'm still I still keep coming back to. But but so that was that was a thing I sort of thought about, but then I kind of just did spend more time with the computers because it was fun and a lifetime. But yeah, yeah. One of the one of the sort of most most fun things I ever did was always trying to be very smart with figuring out you can actually call the Vince windows 16 API that sort of when 3.1 or whatever API from Pascal and I wrote a wrote a sort of very bad looking Windows application all in Pascal, which I don't think anyone has ever done. Because it Oh, yeah, I thought it worked.

Tim Bourguignon 7:00
I remember playing a lot with Delphi, which was visual. Well, that was

Tomas Petricek 7:06
the sort of that was the real thing. Yeah. I, I, at some point, I got into Visual Basic six as well, which, again, is a thing that people sort of, would make bad comments about these days. But it was quite impressive. And it was not just the fact that it was like probably one of the first where you could like design the ID, the UI, and then add the code. But it also had quite an impressive debugger, where you could sort of step into your code, and it would show you this like, currently executed statement. And while that was happening, he could like edit the code and drag this blue, yellow thing around and edit your state of the variables and everything. So you could sort of almost start running the program without really knowing whether it works or not. And as it was running, sort of fix it to make sure it does the thing he wanted.

Tim Bourguignon 8:14
Indeed, VBS is frowned upon, but you have to put yourself back into the context of this time. It was very accessible, it was very fast, in terms of getting shit done. Yeah, a really great bridge toward access, which was a mini database or Maxi databases, but really allowed you to do things really fast without understanding. And that was important.

Tomas Petricek 8:41
And I think that's something you still don't get in like nothing, nothing that exists today, really, to some extent. So this is this is this is of course, I mean, my sort of early, early experience shaping my my feelings about the state of technology. I thought this guy was when you were like 65 Faith comes much earlier.

Tim Bourguignon 9:08
16 years as good as 60. Definitely. Yeah. So how did you stumble into the professional side of software development?

Tomas Petricek 9:18
Yeah, I mean, I did. Oh, I did some projects in PHP that I got paid for, through completely random through a completely random source. But I wouldn't call that professional. Like, why not when you could pay for it? Because it paid for it. There it was. It was some sort of grant application system that Yeah. I don't remember too much about how that happened. I know. That was probably the first thing I got paid for. I did I did then sort of ended up getting Going into C sharp and, and ASP dotnet at the time. And my first sort of real professional work came through a random collection. When I when I wrote some article on Code Project, which is this sort of community webpage with forums and, and articles that it still is still around, and I'm sure people still sort of use it. I wrote, I wrote some article about doing a little little component that was like mimicking the MSN Messenger pop up windows that you got when someone sends you a message. I was like doing some JavaScript open a little pop up window, just as a sort of HTML of the real new window, which for some reason, got very popular. And it got noticed by by various people in the sort of Microsoft community in the Czech Republic. So I ended up doing some projects with a person who's who was running one of the sort of check web portals as a probably a term that doesn't exist anymore. Basically, page with or sort of company that run like search engine, news, community things, directories of web pages, various various various things I worked on, on their discussion or a message of wards project first. Which did start as a very sort of unstructured and organized thing as just well try writing this and see what comes out. And then then it sort of took a lot of time for this to actually turn into something useful that they could run, but it eventually did.

Tim Bourguignon 12:13
We still student that the time Oh,

Tomas Petricek 12:17
yeah, this was this was vile, roughly at the time when I was done with high school and starting university studies. So it was sort of it was quite clear that I didn't know too much about programming, like them to to do anything useful. But I was still sort of learning through practice.

Tim Bourguignon 12:44
Okay. You mentioned University. How did you choose which path to follow? In your studies?

Tomas Petricek 12:53
I went to the charity University, which is the one where I'm sort of to which I've returned, and play. I think by the time I was deciding, I knew I was, I was interested in computer science. And there's a couple of options. I think I was also sort of curious about AI and cognitive sciences and those kinds of things, without really any sort of serious focus, but interesting things. I think that I mean, in the Czech Republic, Charles University is the one that has the reputation for being the sort of difficult one or the one where you get to do theoretical things. Okay. Which I guess had some had some appeal.

Tim Bourguignon 14:36
Why do you why was

Tomas Petricek 14:39
why was it? Well, I mean, I think that's probably something I've done sort of repeatedly throughout my careers. I've probably just wanted to see sort of under the cover of like, what, how do these things Really work or like, what's the sort of deepest idea behind things? Rather than just sort of learn, learn how to write code. And that seemed like the right way of doing it. But it was probably also sort of, like my group of friends from the high school, we all went there. So, okay, it was probably a common sort of socially socially influenced decision as well.

Tim Bourguignon 15:33
It's part of it.

Tomas Petricek 15:36
I'm probably, I mean, probably there was there was sort of some influence from the family as well, where my dad works as a professor. So the sort of idea of doing University things wasn't something that was foreign. Okay.

Tim Bourguignon 15:57
I see. I see. Do you find there this? This, looking under the covers? Am I making air quotes? Looking under the covers that you describe? It was as a place retrospectively whether the right place for that?

Tomas Petricek 16:15
That's a good question. I mean, I think you, I did get it, maybe in the sense that you, you get to talk to people who are interested in similar kinds of things. It's very hard to say what is actually under the covers of programming. And I think if you sort of asked me back, then I would have given you a completely different answer. These days, you're really sort of, there's much more to the sort of social side of programming and much more around the sort of communication and making things understandable. And what the University of this kind gives you, it's just a bunch of mathematics, and lots of theory. Which is, which is sort of a fundamental fundamental thing, in some sense. I know when I was, when I was studying, I got quite interested in design patterns. And I was trying to sort of do in like, all my all my project, I was projects, I was trying to do that properly, and sort of use those structures probably in places where they were just too complicated for actually being useful. But that's, that's probably because that is also a thing that kind of gives you a sense of like, there's something more fundamental behind programming. So I get I did get a sort of some taste of the software engineering concepts like design patterns, or there was a bit of a UML, at some point. Done by done by someone who was actually working in a sort of large consulting thing in the industry, doing the kinds of projects that do involve lots of like, upfront architecture and all the different UML diagrams, by also got, obviously a lot of like theory, and that eventually eventually led to functional programming, because well,

Tim Bourguignon 18:42
was it in the studies already? Or was it after

Tomas Petricek 18:45
we had the functional programming? Yeah, we had, I mean, we had some functional programming, but I think by the time I got there, I was already I already encountered F sharp do another sort of channel, which is quite a sort of fun story of where, where, while I was at the university, I started to buy organize some student talks and things around Microsoft technologies, which is what I was into. And Microsoft had some scheme for sort of supporting students who do that stuff. They, if they actually gave me or avoided me the MVP title back then probably for sort of much less than it would take to get it in a in a country where there's lots of lots of people doing Microsoft stuff, but hey, it was nice. And they ended up inviting me to various events include Going on sort of local European, sort of small MVP event in Cambridge in the UK. And I was sort of thinking what to do for my best sort of project. And I had the idea that sort of coming from my ASP dotnet web programming background, I had the idea that maybe I could somehow translate the C sharp code you write in ASP dotnet, to JavaScript, so that you can write your entire sort of application in a single language with both server and client side stuff, bing, bing, in the same language. This was around, I don't know, 2004 or five, something. Possibly. But before translating stuff to JavaScript was cool. And and so I thought, Well, maybe if I can get the compiled representation of C sharp, the intermediate language bytecode, then I can then decompile that and turn that into JavaScript. And I came across a library for reading the bytecode, which was written by Don Syme from Microsoft Research in Cambridge. He's He's the creator of F sharp and wrote the library, mainly because he needed to generate the code in F sharp and the compiler. And so when I, when I got when I got invited to Cambridge, I emailed him saying, I found your library, but you don't really have much of a documentation on the website. Can I sort of talk to you, and can you tell me how to use it. And we arranged to meet and this was like a one day event where I attended none of the event, but spent the whole day chatting with Don Syme about, initially, the slavery and then he sort of basically in the day convinced me that I should totally do BI project in F sharp and translate F sharp to JavaScript rather than C sharp, because F sharp is much more fun. And I thought this was this was fun project. So I'll try to do that. That I that I ended up working on this as my sort of final bachelor's Project at the University. I was obviously emailing Don, sort of questions about how do I do this or that in F sharp? Because there wasn't a lot of documentation? And I would always sort of send him a question at like, 1am my time, which was midnight, his time and he would answer within an hour. So that I could sort of continue at 2am. That's my with my project. So that's probably a very stereotypical swordfish, programmer lifestyle answer.

Tim Bourguignon 23:04
But interesting, I mean, my studies ended a bit earlier than that. But the the, the the only thing I saw from from functional programming was lisp. And it remained on a very theoretical plane. And that's something I deeply regret afterwards, because functional programming only entered my life for real, only 10 or 15 years later, back with JavaScript. And then I was hooked. And then something happened. But those 10 years, I completely occurred to this. Oh, it was there the whole time. And and I wonder what would have happened if I had, like you started was functional programming almost right away? This could have been very different.

Tomas Petricek 23:50
Yeah, I mean, we had some Haskell and Prolog at the university. But I think it sort of ended up working well for me, because I also got interested in F sharp at the same time. And so I got some got some ml programming book, which was kind of I had like these three things at the same time, and it all sort of clicked together. And I don't think it would have worked as well if I if the three things didn't came at the same time. Like if I just attended the functional programming course at the university wouldn't make sense. And if I just tried to learn how to write F sharp it wouldn't make sense but having the two at the same time worked really well.

Tim Bourguignon 24:42
What appealed to you so much in F sharp compared to probably the the the C sharp you had before in ASP net net?

Tomas Petricek 24:50
Um, I mean, I had I had very practical motivation for doing it, which was this idea of by trial. honestly think writing writing, client side client server web thing in a single language and F sharp just made it possible because it had this reflection mechanism where you could like, quote, or annotate certain bits of code, and it will give you a representation of the code at runtime. Kind of like Lisp macros. So that's, that's a sort of thing you could do in the language. And then, I guess from from that, you sort of it was the reason why I wanted to do it. And then you discover all the nice things like pattern matching, and sort of recursion, which is kind of an academic curiosity features, like learn it for processing lists. But if you're trying to write something that generates turns F sharp code into JavaScript, that's really a basic tool. So yeah, I mean, and at the same time, you have access to all the sorts of real droplet things. Like you could actually integrate it with ASP dotnet and write real server things. Which is a quite quite a difference from your sort of Fibonacci numbers written in Haskell.

Tomas Petricek 26:30
It doesn't mean, this isn't,

Tim Bourguignon 26:33
in my mind, sorry for the cliche, but when you start working with Microsoft Research in Cambridge, and working with stripe that early, the PhD is kind of obvious, as a next step. But was it for you?

Tomas Petricek 26:46
I think it took a bit of time, because so the thing that happened while I was after I was emailing, Don, same F sharp questions. I think he eventually got tired of sort of answering me and said, Why don't you come for an internship. And so I ended up actually sort of going to Cambridge for an internship for three months. And then again, during my master's studies for six months. And that's when I really sort of thought you can actually do a PhD in Cambridge.

Tim Bourguignon 27:27
Did you have some doubts about this before?

Tomas Petricek 27:28
I just didn't know this. I didn't, I never sort of it never occurred to me that that's a thing you can do. Okay. And I probably wouldn't think of it. Like, if you're if you're sort of in an environment where you don't know anyone who's done it, then I guess you don't think of it. But once I did the internship, and there's like, lots of lots of people I talked to who actually were doing something like this, then you kind of realize this isn't this is an option, and I ended up applying there. And getting in and the process for that was I think it mainly sort of relied on having good reference letters, which I did have from from Don Syme and I was. So the rest of like, once you once you figure it out, once I figured out this was an option, and actually was, I was, I realized them quite close to it.

Tomas Petricek 28:32
Did you? Did you consider

Tim Bourguignon 28:33
not doing a PhD in going to the industry and just working?

Tomas Petricek 28:38
Yeah, I mean, I think that was that was my sort of default plan. before and I, I pretty much always did some part time working. Either at the sort of that portal company initially, I don't quite know what I've done sort of, after that, and before the PhD, but I think I always kind of combined the two things. And then, when I was when I was starting my PhD, I did some more sort of contracting work with with Microsoft around there, around sort of early attempts to make to build an open source sort of infrastructure around F sharp. So I worked a little bit on tooling for a Monodevelop which was the sort of precursor to Xamarin Studio. And sort of figuring out how to do the F sharp integration there. So I think I could have could have sort of not done PhD and we sort of happily continue on that path. But somehow I sort of tried to do both things at the same time.

Tim Bourguignon 29:59
It didn't mention as you said before, you were interested in looking under the covers. And so the PG is the archetype of that.

Tomas Petricek 30:06
Yeah. Yeah. I mean, I think that's those those probably sort of PhD topics I could have done around F sharp as well. But I kind of thought if I if I, while it was it was sort of, if I do if I do something theoretic, something sort of slightly more theoretical. Now, it's probably time to do it. Because I'll never ever force myself to do something theoretical, again, if I don't do it now.

Tim Bourguignon 30:40
Did I get you right? You didn't do your PhD on F sharp, something related, it was something else,

Tomas Petricek 30:46
I was sort of loosely inspired by F sharp and by this, like, client server programming were on the client and on the server, they're like different environments, which can provide different things. But I wanted to do something that was more sort of theoretical programming language research around, like, how could you up? Well, it's hard to say what the initial idea was vocal sort of all rewritten by the actual thing I've done. But I think the idea was initially do something that around around the sort of, how can the programming language better support things like this client server programming, where bit of your code actually lives elsewhere and has to work slightly differently? Okay, so it was it was inspired by the sort of real F sharp problems I had, but it was definitely more thinking about the sort of, well, it ended up being more about the theory of programming languages.

Tim Bourguignon 32:01
Okay, what ended up being the subject you really wrote about?

Tomas Petricek 32:06
In the end, the my thesis was on context aware programming languages. And the idea was, there's a lot of sort of talking in functional programming, about effects and effects are what your program does to the world. And then you need to sort of track like, what how you communicate, or how you access memory, or how you access the file system, or what state you mutate, those are all effects that kind of do something to the outside world. And I came up with a catchy, catchy named idea called ko effects, which is the dual of effects. And that's what your program requires from the environment where it runs. So if you if you access some resources that are just available, that's a that's a cool effect, like you might the, the server might give you some state or if you're running on the phone, you have access to the GPS sensor or something. That's an example of a co effect. That's the motivation, at least in reality, the thesis is about sort of a couple of examples, like how you access variables, or how you might access state in data flow programming languages, where you have like, you operate over streams. But it's the PhD itself is very sort of basic theoretical analysis of these things. So you won't find any GPS sensors there, aside from the introduction. But it I mean, as you do in a PhD, you can you can claim, you've sort of discovered the basic principles, and the rest is an implementation detail.

Tim Bourguignon 34:08
Do you find implementation details afterwards, in your day to day,

Tomas Petricek 34:11
I never implemented anything. I did I do have a nice sort of web based version of the PI in the languages I built in my PhD. But I was really sort of I sort of stopped at the theory end of it. My sort of claim to fame is that the hack language by Facebook has has things they call sometimes capabilities, sometimes called effects, which are sort of inspired by this idea. So other people have actually figured out how to do something real with it.

Tim Bourguignon 34:55
Which is good, which is good and which is nice. Yeah, also, scratching your own itch and afterwards, okay, I didn't go that far, because reasons not enough time, or it was not my focus. But at least you see somebody else doing the next steps. And yeah, no,

Tomas Petricek 35:09
no, I mean, I think this this, this work sort of ended up producing nice, nice follow ups in all sorts of directions. And I always thought it's just because it's a, it's got a catchy title, but maybe there's more to it.

Tim Bourguignon 35:25
Was it then enough satisfaction of you're looking under the hood? And then you switch gears after that? Or are you still looking under the hood and somehow finding other ways?

Tomas Petricek 35:36
I think there's multiple ways of telling the story really. I could I could say, well, I always sort of done various things at the same time. So while I was doing this, I did also do some practical F sharp and I ended up at the same time, I sort of ended up being involved in various like F sharp conferences and doing doing talks about F sharp and eventually turning that into a sort of training and consulting business. Not too seriously, not not in a sort of, like, I'm really going to start a company to build a team and things. I was always with a consulting and training. So you can sort of do it as a one person thing. And that I thought was, that was something that was manageable while also doing other other stuff. So that was more on the practical side. And if I if I wanted to say yes, to your to your question about like, looking more under the cover, I think there's a there's a sort of line of work that I've done that leads there. Which is, I definitely did have some, what I found interesting in that sort of theoretical work is people always say, Well, this is the sort of foundations of programming languages. And then here's a bunch of equations and do whatever you want with it. And if someone wants to implement a real programming language, they do completely different things. So I did I did get sort of sight interest in philosophy of science, which is kind of all about how do scientists actually reason and how do they do the things they do? And like what's claimed? Like, why is a certain thing claimed as a reasonable result. And I think in programming language theory, there's a lot of this, like, we just assume that this, this theory tells us something about the real world. That's taken for granted. And but if you try to sort of see why that it's not at all obvious, you really

Tim Bourguignon 38:18
stumble on thinking models, and new thinking models where and a subjective view on reality, and so you take this an axiom, and have this as a basis for your thinking. And at some points, you build or you build, you build, you build, you lose sight of this axiom. And then, at some point, you have to come back and say, well, but was it true in the first place? Or in which context? Is this not true anymore? And what effects does it have?

Tomas Petricek 38:46
Yeah, and I mean, I think there's like these axioms that are shared by the entire community. So you never, never questioned that. And that's kind of what what in the philosophy of science is famous, famous work by Thomas Kuhn on scientific paradigms. And that's one way of sort of explaining that, like, everyone has these shared assumptions, and Kuhn Kuhn is a bit drastic when he says, The New Paradigm Shift only happens when the old generation dies. But that is probably the case in physics, as probably not the case in programming. Maybe

Tim Bourguignon 39:31
doesn't have enough history behind me to say yes or no. But it might be true. Yeah, it might be true. So did you see yourself going further from now on still was one foot in theory, one foot in praxis, one being researching always, how is it working and going deeper and the other one, well, let's continue on F sharp being practical doing consulting, consultancy or trainings? Do you say,

Tomas Petricek 40:00
I mean, I've definitely sort of since my PhD, I've done less of the sort of purely theoretical computer science. So what I've been doing since then is around sort of programming tools for data science, and more generally, kind of programming systems programming environments, which is, which is kind of more applied, or more practically oriented programming research. I think partly because I think there's, there's sort of something missing around how academics study programming system tools. Like we know how to talk about programming languages, which is the kind of you write some lambda calculus definitions, and you pretend that's your programming language theory. But that doesn't really tell you about how actual people sort of work with the programming tools. And my favorite example of this is the small talk Wikipedia page, which about half of the page is about small talk syntax, which is like what you see when you look at the programming language aspect of it. But if you look at any demos of people like doing interesting things with small talk, they always end up I mean, it's this like, graphical stateful environment where you can open the object browser and navigate to the objects that exist in the system and modify them live and change the behavior of your not just of the application, but also of the sort of development tools themselves. And I think there's just like this, this is something that's not captured at all by the Wikipedia page in like reasonable detail, like the half of the page should be somehow about all these sorts of aspects of interaction that are made possible. So I think we're sort of missing some some basic way of talking about those things. And one project I've done recently with my PhD student, while at the University in Kent, was this idea of technical dimensions, which is sort of trying to give you at least a vocabulary for describing what's happening in those interactive systems, so that you can sort of see what they at least kind of see what they do. And still trying to come up with like, programming language theory, or lambda calculus or something like that. But just name all the interesting things that happen in various programming systems. Like small talk, or or actually the ones we started from, like VB six, and, and Commodore basic and early vibe, like all those all those systems have interesting characteristics that you don't see if you look at just the language side of them.

Tim Bourguignon 43:12
That is very true. And I think retrospectively, it's always easier to to say which respectively, but that's one of the things that attracted me early on onto the Microsoft technologies will stack, because Visual Studio very early on, had all this somehow built in, and you could really what you described, go into the debugger, look at what's really happening, change things on the fly. And the more you advance in time, the more it became really possible to cut passes, change variables on the fly, change the behavior of what you wrote, and really see what's happening. And at some point, I came back to the theory of it, because I entered student way more vi practicality, what what really was meant, and I rediscovered things I had learned on the theoretical side, but never really understood. It was just, it was way above my paygrade at that time. And the practical side of things brought me back to this. And I would have loved to have that before. But I'm not sure it was pretty it would have been practical to have all this at the same time. So no.

Tomas Petricek 44:16
Yeah. So the sort of thinking about debugging as a nice, gives me a nice chance to sort of link it to my to my more sort of philosophical interest, as well. Because if you're doing philosophy of science, you end up looking at the history of science, as well sort of find the patterns there. And another another thing I'm doing, sort of right now, where right now really means over the last couple of years and probably over the next few more years is sort of looking Got the history of programming and various aspects of that. And debugging is a fascinating thing, where like, if you if you look at the how people talked about programming in like 50s or so, they didn't really make much of a distinction between debugging and testing. But over time, the two things became completely separate. And, like, testing is now completely sort of different thing with like unit tests and methodology around it. And debugging, if you look at some of the sort of writings around debugging from the 60s, they basically tell you the things that we do today, like in the sort of 60s, Lisp, debuggers, you were able to like break, break your execution, explore the state of the variables, modify the state of the variables, navigates to the code, change the code, and fix the bug and resume the execution of the system. And I think it's a good question like, What is it about testing that made it evolved into a completely new thing? Whereas by debugging is still the same sort of fiddling with stuff?

Tim Bourguignon 46:31
That's, that's a good question. Automation and computation power is probably one of the reasons. But

Tomas Petricek 46:39
But yeah, I mean, one of my sort of theories about this is also that like testing is something, when you talk about tests, it makes sense to people with different backgrounds, like, if you're a manager and test is a testing is a phase you do at the end of the process. I mean, in the 70s, if you're, if you're engineer testing is a sort of useful tool as in TDD. If you're a mathematician, you can think about the test coverage, and by what guarantees that gives you whereas debugging doesn't really have that, like multiple interpretations of the same thing.

Tim Bourguignon 47:21
That's a good aspect. So you, what I'm hearing is, is debugging is inherent to the to the programming itself. And it's not something that really appeals to somebody else. Whereas testing is more than an external view on the same thing, probably, but that appeals to more profiles, and everybody finds some, some interest in it.

Tomas Petricek 47:45
I think so I think I mean, that's, that's, that's a nice summary of what I'm sort of, tentatively trying to say. But, again, this is this is sort of, yeah. So this is, in a way, by getting back to this idea of getting under the cover and understanding how things in programming work this time, not by theory, but by sort of figuring out how we got where we got.

Tim Bourguignon 48:13
That's, that's going to be the title of the show, I guess. us it's been a blast, I have a feeling we covered only always only scratched the surface. But but that's already the end of our time box. I have an advice that I want to ask you. You mentioned. So when you started working internships at at Cambridge, you discovered that you could do something you had never suspected you could do before. What were your advice for somebody who is in this similar position with don't know, they don't know that they could do something? How to discover this?

Tomas Petricek 48:54
Yeah, I mean, I'm sort of reluctant to give any, any advices because I think in my my own journey, it was very much sort of, through fortunate random events, like getting to meet someone. And that then kind of open to new, new options. I mean, the thing that really helped me for many things, in my sort of life was just doing things and and making them public. So I've always written stuff on my on my web page and publish things and like, Code Project, talks about the stakes, and that led to many random encounters through which I've sort of learned things, but I've got no idea how reproducible that is as a method.

Tim Bourguignon 49:48
As the host of this show, I can tell you this is something that comes very often the doing things in the open and stretching your hands and really connecting with people Well, is is one of the constants in the in the unnecessarily advice but but best practices that people figured out at some point. So you're not the only one.

Tomas Petricek 50:13
Very happy to hear that. Maybe there's there's actually sort of things people can can learn from listening to all the shows that way.

Tim Bourguignon 50:21
I hope somebody listened to all the shows not just but at least some of the shows. Yeah, definitely. So it's been a blast. Thank you so much for sharing your story. It was really, really insightful.

Tomas Petricek 50:33
Thank you. It was it was a pleasure chatting with you. Because

Tim Bourguignon 50:37
where we will be the the best place to continue this discussion with you or find you online and or start a new discussion with you.

Tomas Petricek 50:44
I mean, I'm sorry, I've popped up, I keep publishing things on my website, which is Thomas P dot lat. And I'm still, despite the sort of imminent Twitter collapse, I'm still still on Twitter. And I use that regularly. So that's a good good venue for now. I'm on the more sort of F sharp, F sharp front. I'm also co organizing virtual F sharp conference in June, end of June. So that's coming up soon. And I'm looking forward to sort of slowly getting back to in person programming events. And there's there's going to be an F sharp conference in Berlin in September. So those those are some of those sorts of upcoming things. And I'm, of course, I've moved, moved to Prague, which I hear is a very nice place to visit. So if anyone's ever done any of us traveling through frog, and I'm sure we can, we can get them invited to some of the local meetups or visit the University. So combine combine a nice, nice, pleasant trip to a nice city with something useful.

Tim Bourguignon 52:04
I highly recommend that as well. Prague is a wonderful city. And if you can make a travel and work then that's even better. Thank you so much. I'll add all those links in the show notes.

Tomas Petricek 52:17
And thank you again. Thanks.

Tim Bourguignon 52:21
And this has been another episode of Deborah's journey. We see each other next week. Bye. Thanks for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms the show appears on on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep t i m o t h e p talker email info at Dev journey dot info