Business, Innovation, and Managing Life (December 21, 2022)

Okay. Hello, everyone. Welcome to another Q and A about business, innovation and managing life. And I see there are a bunch of questions saved up here. Let me see what I can do with them. There's a question from Paolo. This. My theory is, this is a simple question, but it's always. I always. Whenever I think the question is simple, it turns out it's not. This is a question about operating systems. And let's see. Hold on one second here. Yeah, okay. All right. Okay. There's a question about operating systems and personal productivity and asking what kind of computer setup do I have? Let's see. Well, I. I've been using Macs for nearly 20 years now, but I have alternated between different kinds of systems at different times. And I've used. I was using Windows before that, I was using NextStep before that, I was using sun workstations. That was in the. Sometime in the late 80s to early 90s. So I've used a variety of different things. And I like to have access to all sorts of different computer systems because we make software that runs on all these different kinds of computer systems and I like to have sort of personal experience with them. So, for example, I have a machine that I use with some frequency that has a KVM switch that allows me to switch that machine. It allows me to switch its display, keyboard, mouse between a Mac Windows machine and a Linux machine. And that's kind of convenient for kind of seeing how things work on different kinds of machines. I have to say, I'm quite. I think Windows 10 and it's. It's looks. Looks quite nice. I don't happen to. It does not happen to be the. The system that I use as my kind of default system. But that's purely, at this point, sort of purely historical and might even change. I think that the. I have to say, when it comes to these graphical user interfaces, I have to tell a story against myself, so to speak, here. The whole idea of, you know, oh, you move files around by just, you know, pulling around on the desktop from one, you know, file browsing window to another and so on. When I first saw that whole setup, which must have been probably 1979, 1980, visiting Xerox Parc, where a bunch of modern user interface methodology was invented. And I saw a demo on the. I think it was on the Alto computer of this kind of GUI method for moving files around, I was like, you can't be serious. If you've got a window that obscures another window, you won't be able to move this file from here to there, or you're trying to move files into a folder or something like this and the folder happens to be closed or you can't see it because the screen isn't tall enough. You can't move the files from here to there. Like you can't be serious. This is actually going to be a workable system. And of course it's turned out it is a workable system. But every time I'm in a situation where there's a, you know, where I'm trying to move files around and it's kind of off screen and I can't sort of scroll around properly and so on, I think back to that moment at Xerox PARC where I was like, you know, this can't possibly work type thing. But it's an interesting case of sort of system design because the cases where it doesn't work are sort of rare enough that it's still very useful to have the common cases easy to do and the sort of corner rare cases. They annoy people like me who are into kind of these kinds of design issues when they happen, but they don't happen all that often. And so it's still a very usable system. Much better than having something more structured where even the simple operations are harder to do. But any case, in terms of my personal setup, I have my sort of main desktop machine is a sort of top of the line Mac thing. I think it has like 28 cores. And I have two main big screens that I use. One of them, I'm often used for live streams. And then I have my sort of secondary screen for other distractions and things, even during live streams and so on. Then I have a. For doing video conferencing from my desktop machine because I have my two big screens and they're kind of one's on one side, one's on the other side. If I'm looking at those screens, I'm looking, you know, one side or the other. And that's bad in terms of actually talking to people, looking at a camera. So I have an iPad that is sort of a third screen that I just put on a stand right between my two main screens. And then the camera is also sitting between the two main screens. And then so I'm kind of, you know, talk to the iPad type thing. When I'm doing video conferencing type stuff. It's a. It's a fairly good setup. And it means that, you know, on a sort of, when I'm not doing video conferencing type stuff, I have Just my two big screens and it all works fine. And I'm not kind of, I don't have some weird setup where I have to have a camera, right. You know, the, the screens are tall enough that to put a camera on top of the screen wouldn't have the right angle, so to speak. So anyway, that, that's that set up. Then I have, I, I like to make sure that I, I walk for 10,000 steps or so every day. And so when it's nice weather and my usual personal minimum operating Temperature is around 40 degrees and when it's at least that temperature outside, I usually go between 40 and 80 something degrees and then I'll walk outside. But when I'm walking inside, I have a treadmill with a computer that I've set up with two screens sort of ahead of the treadmill, so to speak. And I learned many years ago that if you just put kind of a gel strip underneath where you have to rest your arms to be able to type on a keyboard I can type up to about 2.5 miles per hour. And usually my sort of little scheme is tilt the treadmill to like 5% incline. So I'm doing a little bit more work but not having to go too fast and then be able to type there. That's the machine actually where I have the KVM switch to switch to different kinds of systems. So that's that setup Then. My file system is a network mounted file system on. Well, I have sort of a Dropbox thing running for my sort of most active files. But for my large archive files I have network file system, network attached storage system that is accessed by all my computers. And then I have, for sort of compute server stuff I have Linux machines and I have a couple of, I guess, what is their brand name? Threadripper, I guess machines that have one has 32 cores, I think the other has 64 cores. And what I'm usually doing is using Wolfram language, which has a very easy way to do parallel computation. And I've simply set it up with these parallel computation profiles so that I can immediately bring up about close to 200 cores for my various other machines, so to speak. So I can just say parallel map or something of some function across some set of data and that will run on my 200 or so cores across the various machines that I have. And so that's the basic setup, I think. Yeah, I also have, oh boy, I'm an obsessive, don't lose stuff person. So in addition to. So in terms of backups, I Have an active backup. I have RAID file system and then I have a backup that is at a remote location that is an online backup that's just being rsynced. I don't know whether it's actually using rsync, but something like that to a remote location. And then I also have files backed up every day to tape and so on and to sort of make sure all that stuff is working. I always get an email every day that lists all the files that went to the backup. And that's actually useful for me as well because it kind of gives me a sense of, oh, I don't know, it gives me sort of a personal sense of how much was achieved that day, so to speak. And I also can kind of, you know, you know, kind of implicitly eyeball it to make sure nothing went horribly wrong. That's a general thing that I like to do is I like to have these daily backups of the daily emails. You know, I have one from biometric data of heart rate and things. I have another from, from keystroke logs and so on. And these both give me a sense of kind of what I'm, you know, am I doing what I want to be doing? Am I typing as many keystrokes as I want to be typing those kinds of things? And it also, because it's a daily email, I kind of notice if it doesn't come in. And so I'm the kind of safety net for the automated system. And you know, these automated systems, they do break and they break with some frequency. But then I kind of notice, oh, wait a minute, I haven't seen a backup thing today. I usually see that and I get some idea to kind of check on that. And I actually also have been meaning to build more systems that kind of are the monthly checkup of, you know, because I get monthly reports of various things as well. And it's kind of like the, oh, it's the first of the month. Where is my, you know, I should have my report of reports, so to speak, which kind of gives me a sense of whether, whether the right things have come in. Good example of a one that was recently added. I have a backup generator and I don't know, a few months ago the backup generator didn't work when it was supposed to when there was a power outage. And it's like, how can this be? It has a self test mechanism. Well realized that, well, it does have a self test mechanism, but the poor generator was self testing and saying help, there's something wrong. But it didn't tell anybody. And because it does send, you know, it's connected to network and, but it wasn't properly sending through a message. But I also don't want to get something from my, you know, my backup generator every day saying, okay, backup generator is okay. You know, it's okay, but the number of systems, you know, there's a limit to. I get about 600 emails every day anyway and I would prefer not to get more things that were like, this is okay, this is okay, and so on. So what, you know, one has to just write piece of orphan language code that takes the, takes the mail that's coming from the generator and aggregates it. And then if there's something wrong when it does its self test, it sends something with a big banner saying self test failed. And that actually happened not long ago. Or it sends a weekly thing that just sort of says the self test is okay. But that's not good enough for me because if I just get a piece of mail that says the self test is okay, I don't really believe that because there's so many things that could have gone wrong in the piece of code that generates that and so on. So I want to see. It says self test is okay and then it's an aggregation of all of the individual messages that the generator sent through. So I'm not going to read those. But I get a warm fuzzy feeling seeing, oh, there are lots of messages. Know this piece of code didn't just say generator is okay and you know, be done with it, so to speak. So anyway, that, that's thoughts on those kinds of things. Is there anything else? Let's see. I, I, you know, it's pretty useful to be able to, you know, probably once every year or two I'll go back to my keystroke log because it's like what happened at this particular moment? I've lost, I've got this image or something and it's like, where did this come from? This just happened actually a couple of days ago, although I managed to solve it a different way. But it was, I've got this image which I was going to put into something I was writing and I realized I retrieved it from some archive system that I have online archive system. And it's like, where did this actually come from? I've got the image, but I don't know where it came from. And so how do I find that out? Well, it's actually, now that I'm mentioning this to you, there might have been some other ways I could have found it out. I don't think it had its file name anymore. So it didn't have, wasn't searchable by file name. And I don't have an image search set up on my internal archive system. But what I did know was when that file was, when that was a cell in a notebook. And the way our Wolven language notebooks work, they keep a timestamp in the notebook of when the cell changed, its was changed. So I knew when that had been added. And so that means that I can in principle go back to the log, the key log, and just look at what was going on at the moment when that was added. What was I doing on my computer system? I think what we realized was there was a different thing, which is it was being accessed from an internal web server. Internal web server has a log. You just go back and look at the timestamps on the log and you can figure out what was the actual internal, you know, the URL that was accessed at that time. Boom, there's the picture. So you know that that's an example of, of, of the use of one of these systems. And you know, for me, I tend to have all these systems and they're pretty complicated and they, you know, they have to be kept running. I have to have some confidence that they keep running. But then most of the time I just don't pay any attention to them at all. And then occasionally I realize, oh gosh, I gotta go find something or whatever. And then it's like, oh, that's nice. We actually have the system in place that allows one to find it. The, let's see. Nothing else I can say about my computer system. I mean the idea of off site backups I consider to be quite important. The idea of online backups is also important because the things that I have, you know, I have nine track tapes that were made in the early 1980s and we finally read them. But it's a pain to take that medium and read it. Like I have a thing that's a recent issue, which is I was just thinking about some stuff that I did like 50 years ago in 1972ish on a computer that was programmed with paper tape. I have a bunch of the paper tapes. How do you read a paper tape in 2022? It's not that easy actually. It may be that the only place where there's paper tape reader that's working is a computer museum. And alternatively you can take the paper tape and put it in strips and photograph it and use image processing and so on. But that's a nuisance too. But if I had those programs in online storage, then they would have been sort of grandfathered all these years. And that's what's happened to things that I had from the mid-1980s. They'd been in online storage all that time. And so even though the actual storage media of nine track tapes, weird kinds of discs, all this kind of thing, those have all changed. Optical DVDs, all this kind of thing, those have all changed and they'd be a nuisance to read now, the stuff that's in online storage has been able to be continued without trouble. No doubt the underlying disk drives have changed, but the fact that it is accessible at an operating system level has all stayed the same. I mean the same is true by the way, With file formats. I'm happy to say that the Notebook file format that we have for Wolfram language has been kept compatible now for 36 years. So I can take notebooks that I created in 1989 and they just run, they have a little conversion message actually at the top now, but they basically just run in modern operating systems and so on. The only thing that's really pretty amusing is they have stored their window size. And so you've got these tiny little windows that were the big plush know cover my screen for an, a Next Step 1.0 computer or something back in the day. Anyway, let's see, let's see. Aaron is asking with consistent routines and self tracking, have you developed a strong intuition for how many keystrokes you've done in a day, how many steps you've taken? Yeah, I really have. And it's kind of, it's kind of shocking because there are all these things where I kind of, you know, I like to walk at least 10,000 steps and I kind of, I don't really have to look at, you know, I kind of know that I've walked that amount of time even though I might have been wandering around, you know, outside and not really paying attention to time and so on. Yeah, I think somehow one from having that feedback one develops that. And I also probably tell you, you know, my estimate for how many keystrokes I typed on a given day is probably fairly accurate. The one thing that's kind of a bug actually which I was thinking about recently is my keystroke logging is midnight to midnight. But I usually work until about 2:30 in the morning. And so in a sense I have a bonus, I have bonus keystrokes for the next day from my sort of previous day. Of work that sort of confuses things. But I think that's. I think it's probably better to leave it as midnight to midnight because it's too confusing otherwise. Let's see. Rbc is commenting about an IRC client for a Tiki 100. I've not ever heard of a Tiki 100 computer. Interesting. Yeah, I mean, I. In fact, just yesterday I pulled up a virtual machine that I have for running a system called SMP that I built starting in 1979. It was a precursor of Wolfram language and Mathematica. That was the thing that launched my first company actually as well back in 1981. But that ran on things like Vax computers and so on. And I wanted to bring it back from. I wanted to be able to run it because it's actually kind of. It was kind of. Okay, here's the thing that happened. Somebody was telling me about sort of these new ways of doing symbolic index, symbolic indexed arrays of various kinds and so on. And I'm like, you can't be serious that people are now talking about this. I actually did that back in S and P in 1979. And it's like, let me remind myself how that actually worked. And I looked at the documentation and I thought, I can. Let me actually run it. And I have a virtual machine that. It's kind of amusing because it comes right up and it says, hello, it's 1986. Basically, it thinks the time is 1986, but there it is running and you can run SMP on it. That was. And so, yes, I did indeed have this thing that is now very modern and there are all these papers about it and so on. And that's exactly how S and P worked. And it had a whole bunch of design issues which maybe have been resolved in the last 40 years. I'm not sure, but it's a good thing to look at Again, it's actually going to get kind of complicated kind of quickly with. Let me not get into that here, but sort of a generalization of arrays meets directed acyclic graphs meets other things. Sort of an interesting thing which I had kind of a junior version of in smp. But anyway, the main point was that's a thing where I've got a virtual machine that. That runs. Runs smp. Actually, I. I also just recently found somebody has built a virtual machine for the very first computer that I use is called an Elliot 903. And so if I can read those paper tapes, I'll have a virtual machine that will actually run the code and the paper tapes. And actually we have a virtual machine framework for Wolfram language now that we can feed that into. So I'll be able to run that inside Wolfram language. So, you know, it's a. It's kind of storing these. I haven't really been very systematic yet in storing virtual machines from my past, you know, from sort of past things I've done. We have one, for example, my big book, New Kind of Science, finished in 2002. We have a virtual machine that we stored at that time that will run all of the production software that runs, that generates, you know, typeset pages and so on. Let's see. RBS is commenting. Apparently the TIKI 100 is a Norwegian computer released in 1984. Wow, okay. With a Z80 processor. You know, one of the things that's always interesting about sort of early computers is there were non American early computers, so to speak. And it's somehow it's interesting to see the extent to which these domains sort of concentrated in one place but didn't do so immediately. Anyway. Okay, let's see, there's a question here from Dante. Would I be able to go back to pencil on paper like pure research? I do lots of pure research, but I do it symbiotically with my computer. I mean, I'm always typing Wolfram language code and notes and so on into notebooks. And that's how I think these days. It's kind of me and my computer, so to speak. I do also use pieces of paper. I occasionally. I have this device. Well, I've been using this thing called Remarkable, which is a sort of tablet like thing where you can draw on it. Although I have to admit the fact that it's been away from my desk for a couple of months is not a good sign for it. But I have been using that as a way to be able to sketch things and so on. But I do find that I use. When I'm thinking about sort of abstract things, I do have a habit of drawing these incomprehensible sketches on pieces of paper. And I find that somewhat useful to sort of define thoughts. But in terms of let me work out some math on a piece of paper. No, haven't done that in 40 something years. That's why I built a bunch of technology to do those things. And it's almost all the time. It's kind of like I think more directly in that sort of computational form than in something which I could readily write on a piece of paper. But I still find it useful for the very sort of extremely conceptual stages of things. I don't know. I find it a useful kind of crutch to be able to draw, as I say, incomprehensible diagrams like I can. Even from yesterday I was working on something quite abstract where I just find it useful to sketch out these things. Somebody's asking here did I. Doug is asking, saying their first experience was on a Commodore 64 playing a game called Oregon Trail. Did I ever program any games? I programmed some very trivial games on the Elliot 903 computer in about 1973, 1974. And I have to say I lost interest very, very, very quickly. And I'm not really a big. I feel bad sometimes because I know many people who've done a lot of great work in compute games and so on. I'm just not really a consumer of that. The game that I, the. The main game I programmed, I. We used to have these. It was a computer at the school I was at and they had these sort of open days and you know, it was kind of a. There's a school in England that. That's a very old school and. But it happened to have a computer. And I think the, you know, the, the open days were mostly very old world kinds of things that people were interested in. But there was also a comp exhibition that I tended to organize. And so people would come in and like what the heck is this? I've never seen a computer before kind of thing. And so I, I did program a few things there and I think my. My favorite was this game where it would have. I mean the computer was pretty simple creature and it's a big thing the size of a desk, but. But it was not. It had 8,8000 words of 18 bit memory, ferrite core memory. But anyway it had these big buttons which were interrupt buttons among. It had a bunch of toggle switches and things for entering addresses and so on. But then you could have these big buttons and it had a teleprinter. And so my game, such as it was, was you print out two letters of the Alphabet, you know, CR or something. And then the game was press the button that corresponded to were these letters in order or not in order? And what was kind of interesting was that which I never really analyzed properly was as you sped it up and started putting letters out more quickly, people actually got it wrong more than 50% of the time. You generate the letters randomly and people would actually press the opposite button to the one they should press. But anyway, that was about as far as my Computer gaming efforts got, which is fairly pathetically little, but so not, not my world particularly. Let's see some other questions here. Okay, Elliptical is asking do you have any career advice? Job seeking advice. Say they graduated and searching for a job is quite slow. Also been considering starting some sort of 3D printing business but don't really know how I can gain the skills for that. What made you start a business? Well, gosh, you know, I'm not sure. Okay, job seeking advice. You know, if you are being selective, I mean if you're just like I want to get a job, any job, that's one thing. You know, just apply for the jobs that you might be qualified for. But if you're being selective and you say, you know, I want to do something really interesting and there are some companies that might do it, you know, one thing I would say is research the place that you are interested in working and find out, you know, what is it really like is, is it. And don't, don't believe the, the random online reviews which have little to do with anything in many cases but try and figure out more what does the company actually do and you know, how would you fit in? How would your skills be relevant to that? And then when you write, you know, when you contact the company, it's like write a reasonable letter that tries to explain that don't, you know. One piece of advice I sometimes there are two kinds of COVID letters that I consider to be rather deadly. One is I just got a degree in X, therefore I'm qualified to do job Y. It's like, okay, you know, there are certainly some kinds of sort of very whatever trade based degrees where that might be the case. But in for example computer science saying I just got a degree in computer science, therefore I'm qualified to write, you know, core kernel code for your system or whatever. It's like no you're not. You know, that's a complicated skill set. That the fact that you got, you know, did these classes has something to do with it, but fairly little to do with it. So in other words, these, the, the one thing that tends to be in my observation is, is kind of the thing where you say I've got this degree, therefore I can do this job. It's like well maybe you can, maybe you can't. If you really know exactly what the job is. If it's a trade type of thing where it's a very plug compatible position, well yes, that's fine. But most know tech company positions for example really aren't of that kind and most, you know, in tech companies, the details of how the company works do matter. And you know, it isn't just a plug compatible thing. I did this class, therefore I can do this job that is vaguely similar to what that class is supposed to be about. That's one thing. The other thing is that the, at the other end of researching the company and so on, I'm always, you know, I'm always interested by the, the, the letters that kind of say, they kind of tell you about your own company. And it's like, no, you don't need to say, you know, the letter says, you know, your company does X, Y and Z. And it's like, yeah, we know that, thank you. You know, that's not really the relevant thing to put in this letter. You know, I have to say I'm sort of reminded of some of the. Sadly, I don't read these things from sort of the front lines anymore and haven't forgotten for many years now. But at times I, I have for one reason or another. And I'm, I'm reminded of one. I just, this is from a very, very long time ago of a chap who sent in something saying, you know, I've been using the software for a bunch of years and I've reported so many bugs that I feel like I should, you know, come work for the company and help fix these bugs. I thought that was, that was kind of charming actually. That person we hired not into technology but into marketing, it did very well there, has built a whole career on that. But that was, you know, I think these things at least, you know. And again, another thing to realize is, you know, companies all have different personalities. And so the thing that might be a great cover letter for a company like ours would be deadly for some other company with a different company culture and vice versa. And so that's another thing. In a sense, you send out the COVID letter represent, if the COVID letter represents you, then there's a, and the company says, hey, great, we want you type thing. Then there's a chance there's a cultural fit. If your letter represents you and the company says you're not going to be a fit here, then that's again useful information for you because better that you find that out and you know, go work at another company instead or something than that you, you know, you go there and you're like, oh my God, I hate this place, et cetera, et cetera, et cetera. Because it's not really a cultural fit. So anyway, I think I, I don't Know, in modern times, I, I'm not sure what's the, you know, as of the last few months, the tech industry has been in a shedding jobs rather than adding jobs kind of mode. Although I don't know whether that's true across. I mean, thankfully, our company has not been afflicted by that. But the, you know, I don't know whether that's true. In my opinion, a lot of sort of Silicon Valley tech companies kind of overhired and sometimes even in this mode of let's hire up all the software engineers so our competitors don't have anybody to hire type thing. And I think in many cases I cannot imagine what a thousand people would do on some project where I know there are a thousand, five thousand people. I just cannot imagine what that number of people would do on a project like that. And I feel like severe over hiring and overfilling of those kinds of roles. So I'm not sure exactly what the story is in the sort of tech industry hiring these days in terms of starting one's own business. It's, you know, it's very confusing for me because I, you know, I started my first business when I was 21 years old and I was a kind of a young professor type and I kind of got backed into starting my first company by having built a bunch of software. And what are we going to do with this? Oh, let me see if other people can set up some, you know, organization to do this. Oh, that's not going to work. I have to do it myself. And then I sort of backed into starting my first company. But, you know, and, and in fact, when I did that, I, I was much, I was not very confident that I knew what to do. And so I brought in other people to do a bunch of functions that actually didn't work very well. I would have done better really running things myself, even though it's like, what did I know? I didn't really, you know, I had no business background whatsoever. The, you know, I suppose it's been confusing for me because in my view of the world, most things about businesses are kind of common sense. Now perhaps that's because my particular version of common sense happens to include sort of thinking about business kinds of things. Or perhaps it's because it really is in some sense common sense. I think the most important thing about sort of businesses and thinking about businesses and so on is to actually keep thinking, you know, people who have very good analytical skills, they're great at doing some technical kind of thing, and then you give them Some kind of real world business type problem. And it's like, and they just, they switch off the thinking apparatus and they're like, you know, they can't think analytically about that question. And that's, I don't understand myself. I mean, that's, you know, it's like you have to keep the thinking apparatus engaged. You know, you've got some strategy question about a business, I don't know, you're trying to start a 3D printing company and you have to ask the question, well, you know, why aren't they just going to send it to Shapeways and get it Sent back by FedEx or something? The, you know, why are they going to use your 3D printing company, not another one? That's sort of an obvious question. Why is it? I mean, I know I just recently, actually as a, as a gift for one of my kids, I needed to get some stuff 3D printed and I needed it in a hurry because, yes, I hadn't thought to do it until a few days before, you know, the birthday or whatever. And so it was like, I need to get these 3D printouts in a hurry. How am I going to do that? And I remember from many years ago, actually one of my different kid of mine from, oh gosh, this must have been 15 years ago or more, sort of early 3D printing, wanted to do some stuff and live in the Boston area. And it's like you look in the, in the phone book, more or less, and you find a 3D printing shop and literally we, you know, sent them some files and you go over there and it's like, you know, it's a thing full of printer dust or whatever and there's somebody there and they're, they're taking the things off the printer and they're, you know, brushing off the residue and all this kind of thing. And it's like, here's your printout. Just like the old copy shops, which I suppose there are copy shops now. I haven't been to one in a super long time. But yeah, I mean, they must exist. They do exist, but there used to be these kind of regional 3D printing type places. I don't know whether they still, I don't think they exist because I think that the things that I got done recently in a hurry, I would have been very happy if I'd been able to just send it to some place in Boston and drive over there and pick it up, type thing and. But I think it was, it was better to just get it sent, you know, to Some central place, and then it comes back by overnight, you know, by FedEx or some other overnight service. So, I mean, that would be, you know, that's kind of the applied common sense. It's like, does the world need another 3D printing outfit or is there a special niche? For example, I mean, like, do you specialize in like, printing 3D molecules for pharma companies or something? Or printing, you know, printing models of molecules or something like that, which have some special features and some special things you need to worry about as opposed to printing sort of CAD output for people who are making bolts and things? Or do you specialize in printing some other different kind of thing? Because a lot of these things. But if you just say, I'm going to make a generic 3D printing thing, you have to ask, well, why would somebody use your thing rather than this other thing? And sometimes it'll be like, I mean, I was a little bit surprised when I looked at this very recently for my little, you know, procrastinated birthday gift that, you know, rapid prototyping, one would think would mean you could get back a 3D printout really quickly. But actually it's not so quick. And some of the things from some of the bigger vendors were like, oh, it's going to take three weeks, and et cetera, et cetera, et cetera. I mean, the other thing with 3D printing is you send your file in and somebody says, oh, that's not printable. And that, that's, that's an issue. And that's probably a niche for somebody. That is, you take, you know, for somebody, I mean, you know, from orphan language, we can generate 3D printer output and we, we have a certain amount of knowledge of what is printable and what's not based on computational geometry. But some things depend on the specifics of printers. You know, can you actually print this out of this material and so on? We won't know that because that's something specific to printers. But I suppose there's a. I don't really think that when you Send in your 3D printout stuff to one of these services, I don't think it's easy to get a human who will tell you, hey, you can tweak this, and then it will be printable. Now it wasn't. It's just like the automated system rejects you. So, you know, just a few thoughts on. On. I mean, my basic, my basic point of view is, you know, you need to be able to apply sort of common sense thinking to make a business that's Actually going to work. And the question of whether you should build a business yourself or work for somebody else is partly, I mean, it's a very personality dependent thing, slightly resource dependent, but I think more personality dependent than resource dependent. And it's something where there's some people where being in charge. For me, for example, I will say that sort of an admission of some kind, it is vastly less stressful to be in charge than to not be in charge. Even if you're in charge, that means you make a decision, you might get it wrong, all sorts of terrible things will happen. You're the one ultimately holding the bag, et cetera, et cetera, et cetera. You have to worry about this and that and the other. But for me, that's much less stressful than being in a situation where somebody else is in charge of. And I'm like trying to say, hey, can you do this? You know, let me, let me persuade you to do this or that. I, I, you know, I find that I don't like that. But for other people, it's not the same way. For other people it's kind of like, oh my gosh, I'm in charge. That's too much responsibility. What happens if I do something wrong? I'm going to, you know, be, you know, be freaking out all the time about whether, whether I'm doing the wrong thing. So, you know, I think it's somewhat personality dependent. Which of those, if you're in the category of, you know, I'm just going to do what I do and I, you know, I don't mind making decisions and et cetera, et cetera, et cetera, then you're kind of in the, in the, in the camp of why not start your own thing if you can. But you know, the other thing about starting one's own thing is that one becomes the energy source usually for the thing. And so if one is in like, oh gosh, I'm not very energetic, you know, can't somebody else pull this forward? Well, guess what? They're not going to. And the, you know, you, if you're in charge and it's, then you will ultimately if, if you kind of stop doing anything, then the whole thing is probably going to grind to a halt. I mean, it can have a certain amount of momentum, but in the end. So for example, my observation with, with our company, for example, is we have a lot of, a lot of terrific people and I would say that maybe we're getting into a state where this is no longer true. But in the past it was you know, when a new thing was going to happen it really always required me to kind of pull the organization in a new direction. I think that's, that's actually less true now. There are quite a lot of people who are, who are initiating new things and really making them happen. Let's see, That is asking how do I manage holiday madness? You know, I have not. I'm embarrassed to say that I haven't really been out and about much and, and the house full of family question. I have have a big house and it's. I would like it if my, my. You know, the. It's. It's kind of somehow it's nice to have more people in it because otherwise it's kind of. A waste to have a big house without more people in it. Let's see, There's a question here about from Laios. How do you apply computer science 500 plus employee new kind of business to architecture and city planning for billions? There aren't cities with a billion people in yet. Maybe there never will be. You know, I think you're asking about architecture and city planning. I mean there's just somehow the trend, it's like maybe 25 years ago kind of architecture went kind of CAD went online as opposed to people drawing things out with drafting. And I think that happened for residential architecture maybe 15 years ago or something now. And it seems like the thing that has been a progressive trend is sort of compute stuff as opposed as well as just draw stuff. And you know there are these building information management systems and things like this. But there's also, and I don't know quite what the state of this is. I mean people use our technology a bit to do these kinds of things is you're, you know, you're representing a piece of architecture, you're representing a piece of city planning. What can you do simulations of what will actually happen? Like if we put down this, actually we did a big project actually on this for, for road traffic flow. You know, you put down this configuration of roads and you have this. You know what will actually happen? Will there be traffic jams every morning? Will they not? How do you model that? That's a non trivial thing to model. And actually we invented a pretty nice system that's based on actually turns out road traffic flow is a funny story. Maybe back oh gosh, 40 years ago or so I was interested in the problem of why are there traffic jams. You know, cars going down a road, they just will all slow down by five miles an hour. Why does it end up being the case that you get stop, start traffic, well, it's some kind of instability. People talk about kinematic waves, things like this. And so I was curious why this happened and I tried to figure it out. It's actually more than 40 years ago now. And I didn't really get anywhere with it. Meanwhile, I worked on simple programs called cellular automata, where you just have a line of cells, each black or white, you have a local rule that updates them. And I found all sorts of fascinating things about how you can get very complex behavior in those systems. Very simple rules. Well, years go by and then I discover that one of the rules that I'd looked at, Rule 184, the 256 of the very simplest of these solar automaton rules, turns out Rule 184 was pulled in by road traffic researchers and became the standard minimal model for road traffic flow. And so it was kind of a funny case because I looked at road traffic flow. I hadn't sort of put two and two together. Admittedly, it was a little bit different timing for me of the cellular automaton thing that I invented for quite different purposes, could be sort of wheeled in some sense for road traffic flow, to this problem of road traffic flow and then became the standard minimal model. But so that's the standard minimal model. But then you ask, well, how do you make it more sophisticated when you've got multiple lanes and people changing lanes, all that kind of thing? We came up with a nice kind of graph based way of doing that, which got deployed in one one situation, although it's not clear whether it's going to be, whether it's going to be used more broadly. But that's an example where one could get a pretty realistic view of sort of how road traffic flow works. And that's a, that's an example, it seems to me, of one of the sort of big trends of, you know, you do a design, maybe you generate a million different designs by some kind of generative process, and then you run these simulations and you say which one is going to lead to this kind of behavior. That's an example of a kind of thing that is sort of a coming event. Now the thing to point out, one of the things that happened in architecture with cad, for example, is people realized with modern materials and construction methods and so on, you can build anything more or less, you know, all these traditional, you know, buildings with, you know, straight, you know, boxes and columns and moldings and all this kind of stuff. We don't need that. We can Build a thing that's an arbitrary, complicated shape. And you know, there are certainly various iconic pieces of architecture which were done that way. They tend to have all kinds of practical problems. Like, you know, the roof leaks because there's a place where there's a flat part to the roof. Because, you know, in, in, well, you could get very fancy and say because of Morse theory, you know, some theory of multivariate functions, there always has to be a place in a roof like that where, where it's flat somewhere. But that's kind of, kind of funny. But, but where the water collects and you have to have all kinds of remediation for that. But any case, the, the, you know, there was this sort of trend of let's use technology to make sort of arbitrary shapes in architecture. I think the problem with that is that people have a certain set of things that they're familiar with and comfortable with, and it doesn't include this, this funky stuff. And while it's like, it's interesting, it tends to be, you know, people tend to not necessarily react that well to it. It's like, you know, you can make a hexagonal, you know, you can make a circular house or something. Chap. Longtime person at my company did that. And it's like, well, actually it turns out you can't get furniture that fits on the walls because it's, et cetera, et cetera, et cetera. And it's all rather. You know, the stack that we built in our civilization is very oriented towards the particular ways that we've like built buildings and the things we're familiar with there. And so, you know, it ends up being. So what that comes back to is if you're doing sort of generative architecture and you're trying to make all kinds of different building forms, one of the constraints is probably what will. You can make different forms, but they are forms that somehow fit into what is familiar to people. And that's kind of an additional constraint. But doesn't, it doesn't. It's not really a cramping of the, of the creativity of the system. It's, it's more, it's, it's just something which humanizes it because, you know, with a computer you can generate all kinds of stuff. The computational universe is full of all kinds of interesting forms and so on, but they have no connection to us humans. And when we look at them, we're like, oh, that looks kind of random, or that looks really complicated. We can't really understand what's going on. You know, it does it does raise the question of, with sort of modern generative AI techniques. What I mean, there's been. People have used a bunch of ideas of mine for generative architecture and so on, but now that we are very used to the idea, whether it's one of these GPT systems or whether it's something for generating images or whatever else, we're getting to the point where it's very easy to get an AI system to make human textured stuff to make something where, well, that sentence sounds reasonable, even though when you string ten of them together, it's kind of nonsense when you go from the first to the last and there's no real sort of skeleton to the animal, but there's lots of flesh on the animal, so to speak. And that flesh is very kind of human, you know, very, very sort of. It feels very sort of human appropriate, so to speak. And I think that that raises the question of when you're doing things like architecture, can you invent kind of human appropriate architecture in the same way you can invent human appropriate sentences or human appropriate art forms and so on? You know, back I realized just, I was reminded of this just yesterday actually, that back in 2005, we did this Walton Tones project, which is kind of just generating pieces of music from cellular automata actually sort of plucked from the computational universe with certain constraints on saying you look for 100 different cases and you say, let's find one that seems to be sort of thematically like, I don't know, I wouldn't know it, but you know, hip hop or something, and the. And then that's what we return to the user. And it's sort of interesting because I had thought that this Walton Tones thing, I thought, what would be the role of computers in composing music? And what's turned out to be the role is people tell me this is a good site to go to if you want a little bit of inspiration about coming up with a new kind of sort of tune of some kind, sort of the opposite. It's like the computer is doing the creativity, the human is doing the interpretation and the humanization of things. And I was just hearing yesterday actually that somebody who's a writer for television shows saying that there, that, you know, using the chat GPT thing was good for, or using GPT or 2 or whatever it is to. To sort of generate possible things that might happen, given this prompt was useful to them. Again, it's very much the computer is the source of kind of the. The shaking it up, you know, source of inspiration. So to Speak. And the humans are kind of plucking out what is of human interest. Just like, you know, you're a photographer or something. There's the natural world and it's got all kinds of things going on in it. And you say, that's a really nice rock. I'm going to take a picture of it. And it's the same sort of thing, I think here. So that would be my thought about that. Let's see. Oh, gosh. There's questions here about from Narayan. Do I feel like I spend too much time managing people instead of solving technical problems or is the balance right? You know, I have been very kind of, I don't know whether pushy, irresponsible, whatever about that over the last, well, 30 something years, which is, you know, if you start and CEO a technical company, what does the CEO actually do? Well, in principle, the CEO should define what the CEO does. But there are certain things that you get pushed into. One of them is you get pushed into doing sales and you get pushed into, basically, you know, you're the one who the big customers want to talk to. I decided from the very beginning I'm just not going to do that. And maybe we would do better as a company if I did that, but I just don't do it. And you know, it doesn't take very long for a sales organization to, to just say, okay, we don't get to call in the CEO to talk to the, the big customers, so to speak. That's something that, you know, that we're doing ourselves and hopefully they do it well. You know, it's. So long as you can make the company work without the CEO spending all their time doing that. That's, you know, for somebody like me who doesn't, that's not what I want to spend my time on. That's a win. Now, in terms of doing technical work, I mean, I do a ton of technical work because I've really found that the highest leverage thing for me to do is kind of product design. Well, product design and strategy, those are the sort of high leverage things where what expertise I have and the experience I have and so on is really valuable. Doing things that what I try to do is not do the things where it's much more dilute. I mean, there are things that I can sort of figure out, I think quite quickly because I've got 40 years of experience in doing a bunch of stuff where just like I can kind of pluck out of my experience base. Oh, we've seen something like that before. Okay. This is the answer two minutes. As opposed to letting somebody who hasn't seen this before kind of try and figure it out. And it's two months and it's complicated and it's, you know, et cetera, et cetera, et cetera. So that's what I tend to do now in terms of sort of managing people. You know, what one tries to do in a company like mine is have enough structure that the raw get people to sort of move forward and do things can happen without me doing it. I mean my main role I suppose in that is reviewing projects. One role is sort of defining product and defining strategy around product and another, another role is kind of making sure that things actually do move forward. And I would say the main way that I end up doing that is I just review projects. And we have some whole sort of schedule of reviewing things and so on, some weekly, some monthly, some every three months, things like this. And I think that's a useful driver for getting, you know, people, I, I like to think actually prepare for these meetings and you know, and they make sure they've actually got things to say and they'll be, you know, I'll always say there'll be an agenda. It's pretty organized. We have a good project management infrastructure with people and so on. And it's kind of, you know, it's, it's like, well, what did we, you know, we talked about this a month ago and I have decent memory so I usually can roughly remember what was said, but usually the sort of reminder of what was being worked on, what was said, it was going to be worked on a month ago. And then like what happened with that and then usually what happens in those meetings, they're important things. So one thing is sort of prioritization of various kinds. So something will be, I sort of said, or it came up, we're going to do this thing, okay. And it's like in my mind I'm thinking that's a two month project. And then people come back and say, oh gosh, it's really difficult. It's, you know, there's this problem and that problem and the other problem, so there's two branches to that. One is, look, there's an engineering problem here, let me try and give you a solution to that engineering problem. And that happens because I have lots of experience. And so, you know, there'd be cases where people are kind of saying, oh my gosh, you know, we don't see how to solve this. It's like, well, why don't you just do this. Now sometimes when I say, why don't you just do this? I'm cutting some corner. But they didn't know they could cut that corner because to be able to cut that corner requires knowing that the higher level strategy is not going to be affected by cutting that corner. Unless you understand that higher level strategy, it's hard to see that that corner can be cut. And I'm a great believer in people understanding as much of the high level strategy of the things they're doing as possible. On the other hand, you can't overdo that because you end up with a situation where either people are always second guessing that higher level strategy, which is kind of a waste of time, or people are just drowning because they're like, oh my gosh, I've got to be responsible for all of this. I don't want to do that. I just want to do my part of it. I think the other thing is in terms of the priority story. So one thing is you solve the engineering problem. The other thing is you realize, look, if it's going to take more than two months, it just isn't a priority. I goofed. I suggested you do it based on some high level strategy consideration, but that strategy needs to be reordered based on knowing now that it's going to take six months to do that. And so, you know, I think that's a, that's a common role for me in kind of reviewing projects is, you know, did this, did this thing that we launched actually make sense now that it's in flight, so to speak? And I think that that, that's kind of a, a common, you know, a common role there in terms of the straight sort of managing people and telling this person, do this, do this, do this. I, I myself do that more at a sort of project level than at a specific person level, at least for things other than for sort of special projects, things that I'm working on directly myself now occasionally what needs to happen is one needs to reorganize things. So for example, right now, kind of an interesting case because we've realized that there are a bunch of things that are strategically needed and it's always an interesting situation. They are departments that have no name because they're functions that people didn't sort of hadn't realized were kind of a thing you could wrap together as a, as a, as a piece of sort of functionality of this is the thing we have to do type thing. So you know, there's one delivery and deployment new thing. Well, you know, we have all these different versions of Wolfram language on desktops, on cloud and this and that and the other. We have all these, all these different ways to do it. And we've realized that we need to collect together one group that is just about delivery and deployment as opposed to we've got a cloud group and a mobile group and this and that. It's just it because it's all sort of an integrated problem. And so we have to sort of create that group. Another one is I think what we're calling user flow quality analysis. Quality assurance Quality analysis actually I think UFQA anyway, and that's about these workflows. People use our stuff, they're using this piece of this, they're trying to, ultimately they're trying to produce this kind of output, but they need to use different components of our technology stack. And it's like who's checked that there's really a smooth thing that lets you go from here to here to here. And the answer is we realize, well, quality assurance doesn't check that. Quality assurance says this is the functionality it's supposed to work. We're going to run tests against that. User experience doesn't do that because they're dealing with specific, you know, we've got this piece of functionality we want to provide a user experience for. And so this kind of workflow based quality analysis more so than assurance because it's not a thing where we know what the out what it's supposed to be. It's an analysis of is this flow reasonable. If it's not, you've got to kick it back to various groups that can then deal with that. So that's another kind of thing. But, but so you know, one of the things that happens is you've got to actually make up the structure which you know, will often be something I'll be involved in doing. And then you have to figure out how do you actually move people around and sort of rearrange things and so on. So you actually implementing that structure. And that's something that, you know, I rely on other people to help with. But in the end I'm probably going to be somewhere involved in making that jigsaw puzzle fit together, so to speak. But so those are the things that I tend to do. And you know, I think it probably when you have a scale of company above maybe 100 people or so, the sort of direct individual management of individual people by the CEO probably decreases. I mean by the time you're doing individual management of individual people, something is probably wrong. I mean, I Certainly do sort of one on one meetings with a bunch of senior managers fairly regularly. Those tend to be extremely smooth running meetings. There's an agenda, there are issues, there's this, there's that. That's kind of like, you know, I'll give whatever, you know, experience, you know, benefit. My experience has to contribute to these different questions. And occasionally there'll be a, you know, what do I think, what do I want us to do about this or that? Because it's ultimately a decision that has to, that somebody who is looking at the whole strategy has to make. But you know, I don't think, I think by the time one is kind of really dug in, you know, when one has a company of a certain scale, by the time one's dug in worrying about individual employee issues, it's a bad sign. And you know, I'm afraid it's, it's one of these things that by the time there's an individual person who one is talking a lot about to all sorts of people, oh, this is happening, that's happening, that's happening. It's usually a super bad sign. It's usually that that's just not a sustainable situation. And one of the things that's sort of a trap in kind of HR types of things is you end up with the really great performers, you never talk about them. And the kind of the crummy performers where there are always problems, you're talking about them all the time. That's exactly the opposite of what should be happening. And you know, that's the separate challenge is to make sure that the really good performers are doing what they should be doing and want to be doing and so on. And I think one of the things like at our company, one of the great things is we have, I think, a really interesting mission that we've been on for like 36 years now. And you know, it's an exciting thing and for people who are interested in it, it's kind of a great thing to be pursuing. And I think that when I think about people at our company and I think about people who are not into our company and what we're doing, it's like, why are you working here? Type thing. That's, that's not really a good, you know, it's not good for you, it's not good for us because, you know, what we want is people who are excited about what we're doing and excited about what they're doing, contributing to it, because that's where you have productivity, creativity, all those kinds of things which happen to also be the things that people themselves, you know, tend to find fulfilling. So I. I'm. I'm kind of a. A. And I think particularly in these times when there's been a lot of kind of moping, you know, imposed by, you know, pandemic lockdown, et cetera, et cetera, et cetera, you know, all kinds of crazy things happening in the world. It's. It's a time when. When there's a certain, you know, one would like to think people could be in roles where the thing that they're doing, the job they're doing, is something fulfilling and something that they find worthwhile and interesting. And if that isn't happening, it's kind of like, well, it's probably the wrong thing somehow. Let's see, the question here as a narayan is saying, is it safe to say a business is a machine made of people? Yeah, I think so, pretty much. I mean, it's. It's. That's. There's a certain amount of. I don't know. It. It. One of the challenges for me is there's sort of a bit of a creative part to it that isn't so machine like. Because once the thing is in motion, doing something, and you've set up all the systems within a company, then it is like a machine with people as the components. But there's another part of it which is you've got a certain set of people, you've got a certain set of projects you want to do. How do you creatively figure out, given the people you have and the projects you want to do? You know, where are the matches? What projects can we now do, given the people that we have? What projects should we sort of feed to this set of people and so on? It's a little bit less. Less machine like there. Let's see. Question here from Richard about how do you decide balancing effort between invention versus innovation? Well, not quite sure what the difference is between those. I mean, I think there's always the question of, you know, do you. Do you figure it out for yourself or do you leverage what's already been done? And I think the. Often if you go too closely to what's already been done, you kind of lock yourself out of being able to really find the best solution. On the other hand, if you're off inventing everything for yourself, it can be a long road. And so I think my tendency is to try and sort of look around at what's out there, and then I really think about it myself and try and figure it out how Do I want to do it myself? Once I've sort of figured that out, Sometimes there are pieces to that where it's like, oh my gosh, that's a long complicated lift there. And you know, and let's hope somebody else has figured that out. Let me go find out whether that's been figured out, then leverage that particular thing and then keep going with the sort of plan that came from me trying to figure it out for myself. Let's see, Kotecheck is asking, can this sort of scaling of employees needed for a functioning company get modeled and planned by your technologies? Interesting question. So it's like, given what we're trying to do, how many people do we need? I don't know. I mean, there's a history of people thinking about sort of software projects and things. There's, you know, Fred Brooks's mythical man, month from long, long ago, based on the IBM 360 operating system, I guess, OS 360. The building of that, where it was like, you know, one would assume, based on kind of, you know, how many people does it take to dig a ditch or something? The more people you put on the project, the faster the ditch is going to be dug, that that would be the same way it worked with software projects. But the observation from that experience at IBM back in the day was quite the opposite happened. The more people you put on it, the less efficient it got. Now, I have to say, I think there's ways to manage things where that doesn't work that way. I mean, it's very easy to see how you end up with that situation, and particularly in things like software projects. I suppose in a company like ours, we're always running thin enough that that isn't really that this thickening effect of more people are trying to contribute pieces to the code and they don't really know what each other is doing and everybody gets sort of micro siloed and so on. You know, that effect, you know, sometimes I think, you know, I've seen projects recently where companies, you know, big tech companies, where it's like there were 10,000 people working on this. And it's like, I cannot imagine how you have 10,000 people working on this. Well, I can imagine it, but it's an incredibly bad idea. And you know, but, but then I suppose one of the things that can happen is, oh my gosh, you know, how can we rely on a few people here? What if they don't do the right thing? Let's put in more people so that we have sort of this Law of averages kind of thing where something's going to happen. Not sure it works that way. You know, I think the. And I see that, okay, so I see that in projects we do where somebody will do it and they do a kind of an okay but not great job, goes a certain distance. Maybe it gets finished, maybe it doesn't quite get finished. And the new team comes in to work on it. And then there's a tremendous tendency for the new team, the sort of hotshot team, to come in and say, oh, everything that's been done before is garbage. We're just going to throw it away and start from scratch. I never like to hear that because it's like, look, somebody put a lot of effort into this, costs us a lot of money to build this. You can't really be serious that you're going to throw it away and start from scratch. And sometimes we do, and sometimes it's the right decision. And sometimes that is just a sign that the, the new team that came in didn't bother to understand what was done before. And they have a kind of vision of what should happen. And it's kind of like it takes work to understand what was done before. And they're just coming in and sort of, you know, bull in China shop. It's like, let's just destroy the China shop and, you know, start from scratch type thing. And so it's, you know, that is a sort of a management function of get people to actually pay enough attention. I mean, we've. We've had cases where one of the more interesting cases was a large project where a person who was an intern on the project, who's now a person somewhat more senior person at the company, but that's. That kind of tells a piece of the end of the story. But an intern working on this project, and they said this project is just going in the wrong direction and they decided to go off and do their own version of the project. The person who was managing the project, wonderful person, but sometimes a less, I would say less engaged manager than they might be. They were like, oh, you know, this intern person is going off and doing something crazy. I don't know. I'm not paying attention to that. Okay, fine, intern person goes off for six months and they actually build a substantial chunk of. Of what this project could be. And then we have this situation where we've got this substantial, you know, plan B version of the project versus a plan A version that's been done by a much larger team over a much longer period of time. It's like, what should we do? And, you know, some people just say, ignore the intern project. Forget it. I didn't do that. You know, it was like we actually tried to do a serious assessment of, you know, was that should we jump from, you know, plan A to plan B? We eventually decided not to, but it wasn't a, you know, for lots of detailed reasons, but it was, it was not the thing where, you know, can you, can you deal with that in your organization of having. Having a thing like that happen? And I, you know, it was. That's not a perfect, it's not a perfect situation that, that, that forking ever happened in the first place. But I'm not sure what I was addressing there, but I was talking about sort of, how many employees do you need? And, you know, do you end up with a single trunk? I mean, there's some companies I could name, large tech companies where they routinely have multiple teams working on the same thing. That seems to me a horrific thing to do. I mean, perhaps it is, you know, if, if people are free, then maybe that's a good strategy. It's like, you know, it has a certain sort of. I can imagine some military situations where it's like, you know, you attack here and here and here, and hopefully one of them will work. And, you know, you get teams of people to do, you know, you're building a piece of software. Let's get three teams to work on this exact same thing and see who wins. Again, depends on company culture. You know, I consider one of our commitments to our employees is that the things they do should actually be. Be used. And obviously, if you have three teams working on something, two of them at least, are going to lose out. But that's a, you know, that's a thing you do. If you have a lot of employees and, you know, people are free, so to speak, you can, you can do things like that. I think that the question of sort of, what does it take? You know, it's a good question. You know, it's a very common question that we have to ask is given this project, as I now imagine it, how many people, how much effort is going to take? Here's where that goes wrong. Basically, whenever we're doing something that's new, that's never been done before, we never know how hard it is because we don't know what the, you know, what the roadblocks are going to be up ahead because we haven't got there yet. And I think, you know, that's a. And that's one of the things when people say, well, we got to know how long it's going to take, how much it's going to cost to do this. It's like we just don't know because it's never been done before so we can't answer it. Sometimes we're lucky and it turns out to be easier. Sometimes we're unlucky and it turns out to be harder. You know, I have to say the person who founded our project management group. Oh gosh, how long ago? 33 years ago or something now, who's still with the company, although somewhat retired now, but he had had previous experience doing project management for actually building freeways where if you get the kind of the cost estimation wrong and a billion dollars is being spent on something, it's really bad news. And so he was very proud of being able to figure out kind of how long it would take us to build, describe some piece of functionality. And he kind of really got into the art of figuring out how long it was going to take to deliver it and he got really good at it. However, we noticed the following thing. So we had a big sort of issue with this. He could predict this version given what's going to be in it. It's going to take 18 months to finish. And then the problem was, do you tell people that? Because it's like that is the estimate. It was a good, it was a good correct estimate. But as soon as we told people that estimate, people were like, oh, okay, it's going to take 18 months. Well, I don't really have to push that hard right now. I'll just wait for a year and then I'll push harder. And of course then it wouldn't take 18 months. It was a kind of a self defeating kind of thing. So it was kind of. Despite the great prowess in predicting how long projects were going to take, it turned out that wasn't as useful as it might have been because it became a self anti fulfilling prophecy. If you told people how long things were estimated to take. RBS is commenting that sub projects is a good thing to have when they're projects that involve more than a person for sure. I mean, you need to break things into sub projects. Although one of the things that happens is you got a project and you imagine it's going to be broken to certain sub projects and you try with some skill hopefully to figure out those sub projects. But the killer is always the things that weren't in any of the sub projects, the things that were. Group A is doing sub project one. Group B is doing Sub Project two. Oh, but there's something that's in between project sub project 1 and 2. Who does that? And if you've been too rigid in saying, group A does this, group B does that, it'll be like people are sort of shrugging their shoulders. It's like, well, we're not doing that. That's not part of our responsibility. We're not doing that. So if you define that too precisely, you end up with these situations where there's a lot of shoulder shrugging of people saying, well, that's not in our box, so to speak. To deal with that, the. All right, we should probably wrap up soon. I think I have to do some day job kinds of things. But let's see. Okay, here's one maybe I can. Can try and address from Gian. As technologies become more and more complicated, do you sometimes feel a sense of losing control or that it gets really overwhelming to try to understand how everything works? You know, I'll tell you a story. When the Web was new, okay, I didn't pay attention to it. Why? Because I paid attention to the last three systems that, you know, there was Gopher, there was Waste, there was several others, and I paid attention to these. And it's like, okay, I understand how they work. And then the web came along and it just seemed like another one of those systems. And I was like, you can't be serious that. You know, that we're going to have web pages where you can only read them and you can't write on them. Okay, that was. That was. I was wrong about that. But I kind of had an overhang of about probably three to six months, but I really wasn't paying attention. And then it was like, oh, my gosh, this is really taking off. I really better pay attention to it. And then there are these moments where you just have to dig in and try to understand what's going on. I found that. That another example of that, I don't know, cloud computing, blockchain, all these various things. Some of these things are kind of complicated. I mean, blockchain, defi. All these things, they're complicated. And I suppose what tends to happen with me is I'll kind of have an ambient understanding of things. I'll pay a little bit of attention what's roughly going on, what are the main buzzwords, what are the trends? And then at some moment, I'll decide, this is important enough that it's worth me actually understanding how to do it and tell another. I think I'm telling a Lot of stories of silly things I've done. But I buy a new car probably once a decade. And so the one that was before, the most recent one, I have buy this car. It's a fancy car, all that kind of thing. And I realize I've been driving this car for like eight years and it has all these controls and I don't know what most of them do. I've never touched them. I don't have any idea what they do. And so I'm, I'm, you know, I've never bothered to read the manual. I've never bothered to figure out, you know, what is that button that has some incomprehensible icon on it? What does it actually do? You know, maybe it's the ejector seat. I don't know. I don't think. It's not that high end a car, but, you know, in. And so, you know, I'm, I'm getting a new car and I decided I will do something which one might think was totally horrifying, which is, I would say, you know, as part of buying this car, I want to get some person from the, you know, car dealership to just show me how the thing works, you know, show me all these various buttons, because that way I'll actually learn once and for all, you know, what do all these buttons do? So it didn't take very long. It's probably, I don't know, 30 minutes or something or less of the one time where I actually learned what all these buttons do. And I'm not sure I remember all of them, but at least I have some global sense of what's happening there. And, you know, otherwise I could go for another 10 years and still not have any idea what half the buttons do. And I think that, that, you know, it's somehow with some of these technologies and things, there comes a moment when it's sort of worth learning how it works. Now, sometimes there are things where I think it's often true that there are early times when technologies are being built. Sometimes there's a critical moment where it's pretty easy to understand what it does because it hasn't encrusted itself in all kinds of detail. There's just the main idea, you can understand it. Then it encrusts in lots and lots of detail and it's not a great time to learn it. And then later on it kind of simplifies because people learn what's important and what's not. And then it's another good time to learn it. And I Think sometimes there are things where it's just like somebody says, well, let me learn about some aspect of, I don't know, blockchain or something. And it's at a moment when it was just lots of things got added, nobody knows which of those things are actually going to be important. And you can dive in. It's like you're reading the whole textbook and it turns out you only need this one method from the textbook. And that's the thing that's going to emerge as the important thing. And so there's sort of a wrong time to try and learn some of this technology. And, you know, as I say, the early period. The risk with the early period is the technology is going to go on a different rail or off the rails entirely, and it'll be not worth learning. And later on it's gotten too complicated and hasn't gotten simpler again yet. And sometimes, you know, then when it comes out in the end, you know, the sort of deadly thing might be that textbooks get written. And the textbooks, you know, the, the textbook authors are like, we're very proud. There's a lot of very complicated stuff to explain. And then it gets, it's very, you know, they're putting in all this complexity. I mean, it's always a thing for me, it's very striking of things I've invented in science and such like. And, you know, years later, somebody will write a textbook that has that stuff in it. Sometimes they're great and very clear and so on, but. But too often they're like, oh my gosh, this is so complicated. This is a simple idea, guys. You know, even just read the original paper I wrote about this. It's a simple idea and it's very easy to explain. And, you know, but the thing that's in the textbook is this big, long, formal, encrusted thing. It's like, how the heck is anybody going to ever understand that? So, you know that that's. Yeah, that's a thing there. Okay, I'm led to look at one more question here from Ark. How do you encourage people to envisage a positive future when things aren't currently going as they expect? That's an important point because when projects, people say, oh my gosh, this project is too complicated, it's impossible, it's never going to work. I think one of the important roles of, you know, CEOing companies and things like that, leading things is to, to turn the impossible into something where people have a vision of how it might be possible. And, you know, it's And I think the way one does that is one has to have that vision oneself. If it's just like, oh, some little birdie told me this was going to be possible, and I'm just feeding you that line, it's going to be possible, but I don't know how to make it possible. That doesn't really work. You know, you have to be able to have a vision yourself for how it might be possible. Even if a few of the steps you don't know, and you'll have to tell people, this is a problem we have to solve, but you've then defined the problem and people know I'm going to, you know, bash at that problem, and if only I can solve that problem, then we've got this whole, this whole kind of wonderful thing that we can do. But I think, you know, it's when people just say, just go solve this. I don't know how to do it. And I don't really have a vision for how it all comes together. It's, it's difficult for people to follow that well. And I think that, you know, for me, when people tell me this project is going badly, this is wrong, that's wrong, the other thing is wrong. Maybe I'm just a, a total optimist, but I, I kind of, you know, that's a great situation as far as, as far as I'm concerned. That's a situation where I feel like I can contribute something. And it's like, okay, I. This is how you plot the future so that something better happens. What can you do? I mean, the thing that is always the worst for me is just like inaction is always much more kind of stressful than taking action, even if I don't know how things are going to come out. But it's kind of like I'm taking action, I'm doing something. It's not just sitting there and saying, oh, it's all broken type thing. And I think, and somehow one of the things I've noticed is that if you imagine what's the worst case scenario, and then you say, what do we do in that worst case scenario? And then you realize, well, actually the worst case scenario, there's ways to deal with that worst case scenario. It's not quite as bad as we thought. You don't have to be worrying as much when you look down. It's not like it's a bottomless pit, so to speak. And that, I think helps often in sort of removing the kind of the, you know, the level of anxiety. And it lets people it makes it easier to think about what you. What you're going to do because you're not always worrying about, oh, my gosh, what if this happens, Et cetera, et cetera, et cetera. But I think the. The important thing is to sort of plot. You know, how do you. How do you imagine a. You know, it takes effort sometimes. You know, this is wrong, that's wrong. This is broken. We don't see how to get there from here. You know, okay, well, how are you going to do it? And if you're in a leadership position, you just can't figure it out. Well, there's probably something wrong, but if you can figure out these are the steps to take, then that's the way that you give people a sort of more positive view. I think I have to say, the number of projects that I've done where people, maybe this is a. You know, people start off saying. They just say that's impossible and it just can't be done. And it's like, well, let's just think about that a bit. What if we do this? What if we do that? What if we do the other thing? It's like, oh, maybe that's possible. That's exciting. You're often running and starting to do things. And I think, as I say, that's one of the roles that I think I've tried to play is to take the impossible and make it. Make it, you know, at least seem possible and seem to. To be something that. That can be pursued. All right, I should probably wrap up here and thank you for lots of interesting questions. I see more that I didn't manage to address, and I look forward to doing that another time. I think. I'm not sure. I haven't paid attention to the calendar when we're next doing this, but I know now it's holiday time and we probably won't be doing too many more of these. I think maybe I'm doing another one on Friday about science and technology, Q and A for kids and others, but then we'll probably be breaking for a short while. But thanks for the questions and happy holidays to everybody and see you again another time. Bye for now.