Business, Innovation, and Managing Life (April 24, 2024)

Hello, everyone. Welcome to another episode of Q and A about business innovation and managing life. And I see a number of questions saved up here. Gosh, let's see. Well, okay, there's one from Hyvie. How I think it should say, should business adapt to changing technology? Are there existing strategies to combat these roadblocks in development? You know, one of the issues in companies in general, but what people do in general is you build systems. You build with them, with technology that exists at a certain time, and then you end up with something which then 20 years goes by. You built that system, put a lot of effort into building it. You had a certain team that built that system, and 20 years later, that system is unbelievably out of date. But it's super expensive to think about replacing that system. And by the way, the. The team that built it is long dissipated. One thing to understand about building systems is the types of people and the types of effort that's needed to architect and build a system are different from the types of effort that are needed and types of people often that are needed to maintain that system. One of the things I've certainly been caught on in the distant past is you build something and you have a lot of intensity, a lot of people involved in building it, and then it gets finished. But then you keep on having that same intensity, those same people, and it's very expensive and it's a waste of money. Because the fact is that the thing, the activity of maintaining and sort of incrementally enhancing is different from the big push to get the thing built in the first place. I would say that the thing that sort of dooms systems is when it's like, well, you just managed to get it to work at the beginning with lots of sort of Scotch tape and sealing wax and so on. And then you have to build on top of it, and you build on top of it, and you're dealing with, you know, sort of patching the hacks, and it's very expensive thing to do. You know, it's always complicated if there is a. What technology should we use for building this particular kind of thing? And it's like, well, there's this emerging technology, there's this new system and a new thing, and we might use that, and it's kind of on the leading edge, or we could use this old thing that is kind of almost at the end of its useful life and where it's becoming increasingly difficult to maintain. And that's always a complicated issue. I mean, years ago in our company, I started Insisting that whenever we were going to have a new system built that was going to rely on new technology that we hadn't used before, that we had a fairly sophisticated review process to try and figure out whether that was a bet worth taking. And that review process included things like, well, if it was something that was based on some open source project, if it was a company, whatever else, know something about the producer of those things and what the level of stability or enthusiasm or whatever else would be. I mean, an example of this in neural net frameworks. We are now, oh, at the beginning of our fifth generation of neural net underlying, kind of emergency interact with the raw hardware type infrastructure. And we've gone through as four previous ones. Each one was great in its time, but didn't make it in the end. But it was a good bet on our part, wasn't completely foolish that we should bet on. Those things just didn't work out. And in some cases we tried to influence the course of whether it would work out or wouldn't work out, but it wasn't always possible. But I think that's a thing where at some moment you have to say this technology that we're using is not going to work out. Let's kind of, you know, let's jump to a different horse, so to speak. Always a painful and difficult thing to do, always costs a lot. It really helps if the original architecture was done in a nice clean way because then there's at least the chance that you can sort of take the, the core of what you built and move it to this other system efficiently. Now, I mean, for us it's the, the system that we feel we can rely on is our whole WOLM language technology stack, which has been sort of out and about now since 1988. And I have to say we have managed to maintain almost perfect compatibility through all of that period of time. So you can take a piece of code that was written For Mathematica version 1 in 1988, you can run it. You could take a notebook that was created in 1988 and you can run it today. And that actually works. And I've done it a bunch of times and it's really pretty cool that we managed to maintain that compatibility. It's taken serious effort to maintain that compatibility. It's taken having made the right design decisions at the beginning most of the time and when we didn't, being able to see how to make a nice clean bridge to the right answer, so to speak, and maintain compatibility and so on. So for us it's and I would like to hope for lots of other people that using Wolfram language and our technology Stack, Wolfram Cloud, technology Stack and so on, that these things have been able to. These are a great example of something that actually has maintained compatibility over the course of now 37 years. I think that the. Well, 36 years to the public. But the. I think that's a very rare thing. I mean, you know, even something like C code, the header files will have changed, the actual core code will still work from that period of time and so on, but lots of other things will not, I think. But in terms of how do you build, you know, how do you build systems that well? So one question is, when you build systems and how do you renew them, how often do you kind of review what you have? How much do you say, let's jump to the new version, let's do this or that thing? I have to say, in our own internal operations, we based a lot of what we built, whether it's the whole world from Alpha technology Stack or our internal ERP system now is all based on our technology stack, our software testing system and so on. These are all written with our technology. That has the added benefit that for us using our own technology to do things allows us to test our technology so that we get it to work for ourselves and we get it to work for everybody else. And that's a sort of added benefit there. But I think there's often the question, okay, when do we start using the features of new version X of our own technology in one of these areas? And we've been, I will say that it's taken some active effort to make sure that we keep sort of parity and we have short delay times between a new version coming out and the new version of the private cloud based on that technology stack, or this or that thing based on that technology stack. It's taken real effort to build systems where that delay is short, because when you sort of are going to deploy a new version in a new environment, you have to retest everything, et cetera, et cetera, et cetera. But that's kind of the microscopic scale of when do you adopt a new technology? How do you decide whether to sort of do that new thing or whether to use the tried and true that may be kind of dying. There are also questions like, okay, do you have people who know that technology? I think one of the things that people find with our technology, for example, there's a good supply of people who know Wolfram language, but people will often not put it on their resumes because they think it's too easy, which is kind of silly and frustrating and the wrong thing all around. Because actually, it's kind of a. For many employers, it's kind of an indication that you know about sophisticated things. So it's really a worthwhile thing to put on resumes. And I know some people very much use it that way, but many do not. They think, oh, you know, it's so easy to get started. It's not really a programming language that I should put on a resume, which is wrong and a mistake on all sides. But in any case, there's also the question of, well, how much effort does it take for people to reach what level of capability in the system? And how much do you need kind of obscure, secret knowledge to use the system? Well, one feature of orphan language is it's a very deep system. So there is, you know, at the tentacle, so to speak, there are things which you could do with it, and they require, you know, detailed towers of knowledge, and you could keep learning it forever, so to speak. But the vast majority of what can be done, and particularly now that LLMs can help you sort of get started writing code and so on, the vast majority of what can be done is rather easy to get into. And sort of the whole idea of Wolfram language is it's a language that's intended to be read by humans as well as written by humans. And so that helps when you're actually looking at code that has already been created in the language. But in any case, and plus, another big feature, not to toot our own horn, but I have to do that a little bit, is because it is a symbolic language. You can pick out any piece of code and it will run on its own. It's not something where you have to say, let me set up the right data structures in memory so that I can do this. It's like this thing will just run and you feed it a symbolic expression, and it will produce a symbolic expression. But talking more generally about sort of technology and companies and so on, and when do you jump into a new thing? When do you not, you know, when do you jump into VR, when do you jump into blockchain, when do you jump into LLMs? When do you. Or machine learning or whatever else, how do you make the decision about when you should jump into these things? I think the thing I tend to do and believe in, at least, is sort of always know what's going on and try and understand every sort of new technology that is coming online. Try and at least make sure you understand, if you're managing a company, for example, that you sort of understand what the thing on offer actually is. You might then decide the thing on offer is irrelevant to us right now. There's no connection between what's on offer and what, what we can do. I mean, I will give you some examples in my own history, I have to say, when the web came along, long time ago now, there had been previous systems, so the Internet was already a thing. And you know, I used it a lot and at et cetera, et cetera, et cetera. And there were FTP and of transferring files, and there were things like Gopher and Wase and all kinds of other systems that were kind of ways to access sites on the Internet, so to speak. And, and I had used the Arpanet actually as, since 1976. I used the Arpanet as kind of an interactive access thing, but you know, with a, with a terminal interface just talking directly to a computer, to a timeshared computer. So, okay, so the web comes along and I have to say, in the first few months I didn't pay much attention to it because it was like, oh, it's another thing like Gopher, like this, like that. You know, what's special about it? What ended up being special was this sort of feature of, oh, you can put GIF images into these pages. And that kind of made things start to come alive and you started to have browsers that could see images and so on. And I missed that for a couple of months and then kind of was like, you know, okay, we need to pay attention to this. You know, we got our first website up pretty quickly, et cetera, et cetera, et cetera. And sometimes when you're dealing with kind of, you know, there are new things that, that get mounted where it just turns out to be not interesting. It turns out that either the thing was some kind of piece of hype that was generated for whatever marketing reason somewhere, and it just doesn't make a lot of sense, or perhaps it just doesn't make a lot of sense for your particular company. It just doesn't connect. So, you know, in modern times there's. Should we be using AI? Well, it depends what you do. You know, there are certain kinds of things where, you know, general principle for machine learning kinds of things is if 80% success in the task is a win, then machine learning is worth looking at. If the only way this task is worth doing is 100% success, that probably isn't the right place to start off. But Maybe there's some other piece of your business that has, for which 80% success is worthwhile. Maybe there's something that involves, I don't know, responding first level response to customer service inquiries or something where it's kind of a human to human interaction and where that would be a reasonable thing to do. But it's also the case that when you see something like AI, LLMs, whatever else, people will start saying it's so amazing, it's going to do everything. And there's a certain motivation for that, even for large companies to say, this is going to be the most exciting thing since sliced bread or whatever, you should be paying attention to it. You, the person making decisions for a company should be paying attention because gosh, golly, you know, that's a great way to sell consulting services or other kinds of things. It's a great excuse to go talk to a customer, is that, well, there's this new thing on the horizon. Should you be using it? And sometimes the answer is yes, you should be using it. Sometimes the answer is no, this is just irrelevant to what you're doing. But I think in this whole sort of question of is it worth brainstorming, you know, can it apply to your business? Yes, it absolutely is. And I have to say that practice in doing that helps a lot. I mean, I know for us, for me, you know, I've been doing that for, I don't know, 45 years or something of trying to figure out does this new thing that arrived actually, is there a way that this connects to what we're doing or a way we can use this? I don't always get it right? I don't always. And, and then, you know. But it's worth trying to make that connection. I mean, I think our Wolfram Solutions consulting organization does a bunch of work like that for people partly because we've sort of had developed the methodology internally of saying, given this thing that you're doing, does this new technology idea, particularly one that, you know, we already have an implementation of in our technology stack, does it apply? Now, you know, there's another issue which is internally you say to people, hey, hey, there's this new cool thing. Does it apply to our thing? Why don't you try it? Well, sometimes it will fail. Question is, why did it fail? Did it fail because there's no there there. And you just, you know, the thing was a piece of hype that didn't mean anything, or did it fail because the particular people who tried to execute it didn't sort of push it hard enough or didn't understand it well enough or whatever, that's a really difficult thing to untangle. I would say that I've had a hard time untangling that. And my best strategy for trying to untangle it is understanding more and more myself. But for example, this has certainly happened with machine learning for us of things that we've said let's try using machine learning for this or that thing. We've been doing that probably, gosh, now it's well, 15 years under the name machine learning and longer ago for other kinds of techniques and for other things that nowadays will be called machine learning. But you know, and sometimes it's just like you try it and by golly, it works. So for example, for us, a lot of things to do with automatic algorithm selection where you're trying to solve some problem and there are 200 different ways to solve those kinds of equations, but you're given a particular equation, you know, what is the right solution method to try and use? Well, we've many years ago we started automating. Many like 30 years ago we started automating that kind of thing and using what would now be called machine learning methods. And every so often we sort of updated the way those heuristics work. And that's a case where things did work. Other cases, some things we, we tried a bunch of things with sort of pre LLM technology over the last decade or so for doing parsing, particularly for WolframAlpha. Most of those things didn't work. And should they have worked? I still don't know. I think probably, I mean even today that with the LLMs we have today, that's not really a thing that works that great. We have much better technology for doing that, not using specifically LLM techniques, but that's something where it could have been the case that you feed in a pre LLM type thing and it's like boom, it just works. I would say so. It's a tricky thing to assess when there is a new technology and you put a team onto saying can we apply this? And they come back. If they come back and say yes, that's great. You can see what works and it's all good. When they say no, it's like was it a real no or was it just they couldn't figure out how to do it? And as I say, that's been challenging even though. But my best strategy is just, it's sort of a strategy for many things is just try to understand it yourself. And that requires a certain degree of I would say confidence, one might say arrogance, that, yes, I really can understand all these things. And some things, you know, some pieces of technology which people hype a lot, are actually pretty easy to understand. Some are not. I mean, for example, you know, in the early days of blockchain, the actual sort of, how do these protocols really work? Or, you know, you're doing, I don't know, zero knowledge proofs or something, how do these protocols really work? How realistic is it that you're going to be able to get this or that thing where people say, in principle you could do this? A good example right now is quantum computing, which I have been skeptical about since I first studied it in about 1980, 1981. And the same sort of things that I think were issues then are still issues today and are rearing their heads in very practical things that people report about what's actually going on. But that's a question of should you say, oh, gosh, should we put a lot of resources into this right now? There are other reasons to do that because the formalism is interesting, even the physics is interesting and so on. But it's like, is this going to be a thing that, you know, our bank should start worrying about today? My answer is no. But the, you know, although there are. See, this is where it gets tricky because in a case like, for example, take blockchain as an example, you know, how practically useful is blockchain? Well, there's certain use cases, but it's not as you can buy coffee with Bitcoin type thing as one might have thought it would be, based on sort of early hype. On the other hand, the effort to think through what does thinking in terms of blockchain type ideas, that leads you to computational contracts. It leads you to a bunch of things which really are a useful kind of paradigm for thinking about lots of kinds of business structuring sorts of architecture kinds of things. Are you actually going to go out and use Ethereum as the blockchain to run your business on next day? Probably not. That's the unlikely case. But thinking through, sort of using this as an excuse to kind of rethink, wait a minute, how are we doing our transaction processing? How does this thing, how does this ledgering mechanism work? How are we representing these contracts and so on, that is a worthwhile thing. And I've seen that a bunch of times. It happened also with cloud computing. It's, you know, I have to say at the beginning of that I was like, well, you know, we've seen timesharing before. You know, really, is this any different? What's special about it? And then when one got into it, it's like this is this thing where you have this persistent sort of computational construct and it's really a bit different. And there are different ways to think about that. And it's useful even for pieces of your technology stack or business that aren't really going to be ultimately changed by actually using cloud technology, but the effort of thinking them through with cloud technology as a lens is useful. So a few comments, but these are. It's always, I mean, another big issue is you're a company, you know about certain kinds of things. Something comes along and you just don't know about it. And that's a case where people will hire things like our Wolfram Solutions team. I think one of the things that we like to pride ourselves on being able to do is because we have this technology stack that makes it really easy to make prototypes of things, it becomes very sort of efficient and low cost to get to the point where it's not just writing, you know, writing a report, which is not something we do particularly about, you know, this or that thing and how you could use it in the biz in your business, but rather it's about, here's this actual prototype that you can run and see and you'll get a sense of what's going on. I, I will say this is something I, I certainly experience all the time, is you kind of have this. You imagine how some system is going to work and, you know, you have some view of that. After all the years I've been doing this, my imagination is fairly good for what the system is going to be like, but it's never quite correct. It's always, once I actually see the thing running, one somehow internalizes what's going on much better. Even if the thing that's running is only a small piece and it's just a sort of a demo and a prototype, it's still super useful to see that thing actually running. It gives one, it just gives one a psychologically very different approach to how to think through what the consequences of something are. So anyway, but in general, I mean, I would say that when new things show up on the horizon, it's worth trying to understand them and see whether they do or don't relate to business and having a good argument for why it doesn't relate. I mean, so for example, right now, VR and ar, xr, whatever, you know, several times over the years I've sort of said, hey, VR is coming. We should see how we can use it. And I've had a lot of sort of consistent employees over the course of decades at the company, and they've often reminded me, in 1991, you said VR was going to be a thing. And we started working on it and we built a bunch of stuff for visualizing molecules and doing other 3D kinds of things, and nobody cared. And it's like, is this different? And, you know, you can have arguments for why it's different. And it's useful to remember what you thought about, about the last time you were thinking about this particular piece of technology and you know, why you concluded what was going to happen and then see whether it did happen and try and learn from your mistakes. And, you know, I've tried to do that and I perhaps here I, I try and repeat, describe some of the mistakes and how not to make them. Let's see. Lollylol asks, is Wolfram language much faster today than it was 35 years ago? Absolutely. I mean, not least because the computers are faster, but even within sort of the many different things. I mean, first of all, when you build a system like Wolfram Language that is intended to be, there isn't really anything quite like it, but sort of a very global sort of computational approach to the world, so to speak, the important thing is coverage at first and to get the big picture and to see how all the pieces fit together. Later on, you start to say, oh, we've got numerical linear algebra, let's make it incredibly fast. Oh, we've got graph theory, let's make it incredibly fast. Oh, we've got image processing. Oh, we've got some network communication things, you know, progressively, once you have the big picture, at least for my way of doing system architecture, once you have the big picture and you kind of see how all the pieces fit together and you see which pieces are the ones that are sort of on the critical path to getting things done, then you make those faster. And that's what we've done over the years. And that's one dynamic. Another dynamic is new algorithms are discovered and invented, sometimes by us, sometimes by other people, where the thing that used to be an N squared thing now becomes an n log n thing. Or we did this a lot with working with polynomials, for example. We managed to figure out, this is now 20 years ago or something, all of these methods for using essentially approximate arithmetic with various kinds of bounds and theorems about those bounds to be able to just sort of bash through things that were otherwise very computationally expensive. And you see See the same thing many, many times. So one dynamic is that as well. Computers get faster. The there's more memory, you can cache more things, you can just have tables of things and so on. That's another, another thing that helps make things faster. They also you just build out. I mean, for us, we're going and we're looking at areas where it's like, can we optimize this? Yes, let's do it. Another thing that happens is more special casing. So there may be some general way of doing something whose main feature is it works very broadly. But then it's like, okay now, but in these special cases it's this and this and this and this and this that you can do and you sort of optimize all those special cases. The code is vastly more complicated, 100 times more complicated. But nevertheless, in typical usage, those cases are very efficient. You know, it's always a strange thing. You know, I wrote a bunch of the original code for things like pattern matching in Wolfram language. And it was kind of complicated code written mostly around 1987 or so. And I think the thing that was probably the most difficult there was, it is full of these kind of heuristic guesses about, you know, there is a general algorithm, but the general algorithm will be quite slow. So there are many heuristic guesses about, let's make sure this path is optimized, that path is optimized. And there were many places where I was just guessing, oh, a 16 bit field is going to be enough for this thing most of the time. Even though I know if that fails, it's going to fall through to some general algorithm which will be less efficient. But chances are that's going to be enough to do lots of cases and so on. And I think somewhat surprisingly, I got an awful lot of that stuff more or less right. Even though sort of a shot in the dark, intuition kind of thing, a judgment based programming effort. And I think that's a thing that, you know, over the years we've sort of developed from that. And that's something that is a very routine thing that we're doing is sort of judgment based programming where it's like, can you find these code paths, these cases you can optimize? Is that worth doing? If you say, well, I got this fantastic optimization, it's going to be useful one in a billion times, it's like, no, it's not really worth it because the chance that you introduce a bug by having that extra complexity in the code is much more than the cost of the kind of one in a billion times, it'll be slower than you wanted it to be. Let's see. Well, various things here. Jamie is asking what has been the biggest or notable technological advance that's happened in your lifetime? That's really easy. Computers and computation. When I was, you know, at the beginning of my lifespan, the only computers were a few mainframes and the very, the sort of, the sort of ubiquitization of computers and the ideas of computation. That's been the big thing that happened last half century or so. And that's really a, you know, it's a big sort of moment of history, so to speak. It's the thing where kind of the development of technology in a sense becomes a meta thing because computation is a general framework that you can sort of. And that sort of. There's this universality of computation and software and so on that makes you be able to build things in the things you built, so to speak, rather than just like I built a specific steam engine and then I have to build a specific other kind of machine with cogs or whatever, separately. So that's for sure, that's. That's been the biggest thing within that the other, you know, obviously for everybody. The web and the whole sort of communications infrastructure is also a big thing that has, I would say that has had less effect on me than it might have done. I. When I started writing my big book, New Kind of science, back in 1991, the web was extremely young. There wasn't really anything on it. And when I finished that book in 2002, the Web was much more developed, although many things like social media were not yet well developed and so on. But it was notable because I was doing research, so to speak, a lot of research, historical research, all those kinds of things in the service of my science project. And so I could kind of see what was the difference between beginning of the decade and end of the decade without Webb. And with the web there was a difference and wasn't so dramatic. I mean, just to give a sense, 1977, 1978, I was doing particle physics and I wanted another kinds of science. And I was like, let me look up page papers about this or that thing. How did I do that? Well, today I might go to a search engine. Then I would go to usually a system called Dialogue, which was a pay system that had the abstracts of basically all published technical papers in it, and you would go and do a search. And the language, the search language was kind of obscure. And I wonder if I still Remember it select. And then it had things where, you know, when you had two words, I think you had w paren between the words and things like this, it was all. It was a little bit weird. And you had, you know, you had different results sets and you had, you know, S1 to S whatever. I forget all the details. It was a bit obscure, but it was there. And librarians, reference librarians would use it all the time. I think I was unusual. And maybe it's a lesson in. In these things, you know, Know, it's like, learn tools, use tools. So, you know, I learned how to use this thing. It wasn't terribly difficult. I'm sure it didn't take me more than an hour to kind of probably less than that to read the documentation and, you know, learn the basic commands and so on. And I think there was some obscurity to the whole thing because it wasn't perfectly documented. But so, you know, finding, oh, I want to find a paper that talks about this. It's pretty much the same experience as today with search engines. I mean, there were some funny things. Like there was this thing, this permuterm index for the citation index where it was kind of like titles of papers and they literally were listed with every word. Every non. Sort of non. The a of type word was listed in sort of a permuted index. So you could say if it was, you know, cats eat mice every day or something, there would be. It would be indexed under cats. It will be indexed under eat. It will be indexed under mice. You could go through and you look through these books and libraries. And I did that when I was first working on cellular automata in the early 1980s. I went and tried to find all previous work and the subject that was a little complicated because the names were often different. But, you know, I did that by using these books in a library. And sometimes you would have to go find the actual material on microfiche and things like this. And it was more difficult. But I would say it was not transformatively different. I mean, it is the only thing that happens with these kinds of what can you do? What can you do easily is when you can do things easily, you do it on a whim. Even if you don't absolutely know what's going to come out. If it's difficult, if you have to walk to the library to do it type thing. It's like, am I really going to do this? You know, you have to have a very organized way of saying, I'm going to collect 10 things. I'm going to do at the library. Let me go and do all these things. I will have to say that my own efforts, building Wolfram language and so on have been, were originally motivated by what I wanted to have for myself. And the real objective there is to get to the point where kind of you have an idea and on a whim you can implement it because it is sufficiently easy and automated to implement it. That that's a feasible thing to do and that's worked fantastically well. And that's a sort of transformative thing both with computers and with the technology we built over the years that really gets one to the point where you can use the sort of the computer as this kind of superpower appendage to go from the things you think about to things you can actually implement and so on. So, I mean, that's. But certainly computers and computation are the big thing. I would say that other things, a lot of what's happened is the kind of streamlining. So that's been a big thing that was sort of just didn't exist before making it easy to do computation. It's partly my own efforts that's been really important to me and has gotten to the point where many, many, many things, even in the last week, there are things I just would not have discovered. Kind of interesting because I discovered recently, actually, that I wouldn't have discovered if the difficulty of doing the computer experiment was sufficiently great that I really had to put a lot of effort into thinking about whether I was going to do it or not. But it's just like, it's easy, just do it and then you see something surprising and so on. And I think that. And so for all of these things, and it's perhaps true for things like looking things up on the web, I have to say it's probably less true than it is elsewhere because the previous system, while it was kind of, you know, it would give you your, you know, how many dollars you spent as the printout at the end. But it wasn't terribly many even back then, you know, it was a less smooth experience, but I would say it was still a pretty decent experience when you were looking up, for example, technical papers and so on. That's an infrastructure that's existed for quite a long time, at least longer than I've been around. Elsie is asking, how do you think about the buy versus build dilemma? Yeah, well, I mean, that's always an issue. And it's like, okay, there's several parameters. Is the thing you buy actually the thing you want is the Thing you buy so expensive you can't afford it is the thing you can build something where you might say, oh, it's easy to build it. Then n years later it's like, well, it wasn't quite so easy. And I would say that for my company, we have done a lot more. Well, I would say we do a lot of building, particularly with our own technology stack. We do a certain amount of buying or otherwise using technology that exists elsewhere. I mean, I think one of the things that I am so cynical about is the look, it's open source. You can just use it. Well, no you can't. The real version that works costs a bunch of money. The version that you can use is entangled with all kinds of legal issues, et cetera, et cetera, et cetera. The version you can use has all kinds of security issues and your customers are going to say you're using that. We can't use your software if you use that type thing. So. But the whole question of whether you take something from the outside world versus build it yourself, I think one of the things that can happen with you take it from the outside world is the thing you get isn't really what you want and you kind of turn your business on its side in order to use that thing because that's the thing you could get, even though it wasn't really the thing you should try to get. But I think in, I mean, another thing is actually understanding what you're getting is always challenging because it's, you know, the effort to know what it's going to really be like in your environment when you really set it up as you want to set it up. Yeah, some salesperson can tell you it's going to work great or you're going to try reading the documentation and say, I don't understand this at all. It's, it's kind of a, a, it's challenging and it's worth spending the effort to really see what's this going to be like if we actually implement it. Because sometimes it's happened to us not so much recently, but it happened in the, in the distant past. We'd get some system, some fancy system, people would sell it to us and you know, lots of effort to sell it to us. And we get it in. It's like, look, this is a piece of garbage. And at that point you're so invested in it, you've spent quite a lot of money on it. You've got people involved in tending it and so on. And it's very hard to say this is such a piece of garbage. We're just going to get rid of it. Although we have done that. But it's a hard decision to make. I think we see with respect to people using our technology, our technology is rather unique, and people say, oh, we can just build it ourselves. No, you can't. There's a sort of reality check of, okay, if the thing took 30 years to build and had, you know, quite a lot of sophistication behind it and. And so on, it's like, oh, we're just going to build it ourselves. It's not realistic. On the other hand, there are other pieces of technology where people say, it's the most amazing thing. And you kind of look inside it and you say, wait a minute. This is kind of, you know, much of what you've done is something that sort of tries to build a framework that is specific to a particular company, let's say. And it's really not going to generalize that much. And what's underneath there that's general is kind of trivial. And it's often hard to tell what's going on. You really have to dig quite deep to find out what's going on. And I won't claim that we've always done that correctly. It really is hard. I mean, I think it sort of helps, as far as I'm concerned, that I've seen a lot of the things that go wrong before, so to speak of it didn't really, you know, to use it, you have to distort things. That's always a problem. But on the other hand, it's like, okay, it's like you're buying a car or something, okay, and you can say, I want a car that has this attribute and that attribute and that attribute and that attribute. Well, there's only a limited number of makes of cars that exist. So, you know, at some level you're going to buy this thing or that thing or that thing, and you say, I want one that has all these attributes. Well, I'm sorry, but no such thing exists. And you're not going to build your own car, so to speak. So, you know, that can happen as well with technology that, you know, by the time, you know, I think it's, it's. Yeah, for. For most people, it's. There are things, you know, if, if you're buying something that's clean, it's good, and it is actually going to work in your environment, then think about buying it. If it's a big stuff, if I have to turn everything upside down to be able to fit in the thing that I'm buying. That's probably a bad sign. I mean this comes up with cloud services versus on premise sort of compute services and so on. And I think the thing I've noticed there, if you're a fairly small company or a fairly non technical company, then using cloud services is going to be a win. Even though they're more expensive and there's certain amount of you have to do it this way and not any other way. If you're a company of a, you know, a technical company with more than a few hundred people. I think there's good arguments like we have our own sort of infrastructure which we've had for many years and you know, we tend, you know, we, we, we have, we sort of tend our own infrastructure. It's more flexible for us, it's cheaper for us, et cetera, et cetera, et cetera. And at a certain scale of technical people, it's worth doing that rather than having people where, if you're using sort of other infrastructure, let's say you have to have people who are experts in the use of that infrastructure, which is a very different kind of expertise from people who are involved with for example, building your own sort of custom setup. Just. Well, a few thoughts on that. Let's see, Elsie is asking how do you think about and handle competition, be it business or technological competition, say LLMs versus symbolic ways of doing, of computing things. I think the. I am not a very sort of competitively oriented person or business person. So, you know, my goal is to build things that I think should be built and I don't really care whether other people are sort of say we're building the same thing, even if they're not, or whether one's in a, you know, I much prefer to be in a situation where we're sort of in a, in a, where we're building things that are very different from what anybody else has built, which is what spent the last hour long doing. I think that in a sense there's a certain. Well, for example, LLMs are not competitive with sort of symbolic approach to computation. They're very different kinds of things. They achieve different kinds of things. Having said that, I've certainly worked a lot on how LLMs work and I'm continuing to work on that and trying to understand what, you know, to what extent one can sort of have the best of both worlds and what situations and, and how all these things interact and and so on. I'm, I'm a little bit interested that the, you know, there's the like, oh, we can just plug in a. This or we can just plug into. That is people's typical attitude. There is actually quite a lot to understand and that's what somebody like me tries to, tries to do. I mean, in the course of my life, our sort of business existence, we've invented a huge, huge number of things and people eventually, at some very slow rate, people rip them off. It's very slow. It's almost disappointingly slow. And it's a complicated thing because when you have things like notebooks, a good example, something we invented in 1987, which finally became sort of popular with all the same sort of structure, although not the same implementation or I think many of the things that we figured out that really make them a smooth thing have not been successfully copied. But it's something where it took to me shockingly long for what seemed like a really obvious idea to get copied. But on the other hand, the copying has a certain advantage because at least people know what the thing is then. And you're not saying we do this. People say, what's that? I don't know what it is. So there's a certain value in having, you know, sometimes there's at least some value in having sort of more people know about the thing. It's, it's, it's always a little bit, it's kind of, you know, if you're trying to make a business and people are always saying, oh, but isn't it the same as that? You say, well, that's kind of a lousy 20 years out of date copy of the thing. Well, you know, that takes effort to say that and it would be nice if one didn't have to. On the other hand, the alternative might be you say, we've got this great thing, and people say, what's that? So it cuts both ways. Let's see. Golagaz asks, do you think having middle management in high tech companies hinders innovation? Interesting question. I think that when you have complicated projects going on, you have people who are sort of on the ground doing pieces of those projects. Something needs to integrate all those pieces or the project can't coherently happen. I mean, in our company we have quite a layer of project management whose purpose is mostly the knitting together of all those individual efforts. It's not really so much the deciding what to do. It's the we decided what to do. Now let's figure out how we actually get it done. Let's actually have the process work of getting the thing done. And I think That's a good use for sort of middle management. The bad use tends to be, oh, there's some vague directive over here from the company at large. And we're sort of trying to muddle and figure out how to implement that objective. And we're going to come up with our own kind of rather lame ideas for how to do that. And it all kinds of gets very muddy. And I think that can, you know, I think in a sense that's perhaps a sign of weaker leadership, as in if the leadership could communicate their vision clearly. It's like, okay, people know what to do now. It's a question of executing on that vision rather than there's sort of a muddle layer in the middle. That that's kind of turning that vision into something that is sort of consistent with what the people already knew to do, et cetera, et cetera, et cetera. I mean, one of the challenges with innovation is that it takes effort, it takes push to get innovation to happen. And usually that comes from leadership. If you set things up properly, then if some bright spark somewhere is coming up with this great idea, that idea should get propagated to leadership to a point where the idea can really be executed. That's not trivial to achieve in companies because what you don't want is lots of sparking going on all the time with people saying, I don't want to do what I was told to do based on the vision of the company. I have my own better idea, let me go and do that. And that often doesn't end well. But that happens particularly when that spark doesn't get propagated to the right place so that it can really have its, its moment to be decided on and to get done. And I won't claim that to have completely figured out how to do that, but it helps sort of the more open and direct the internal culture of a company can be and the less, oh, you're the manager of the manager. And so I can't really suggest anything to you that's, that's a bad thing. I think, you know, I, I, one of the things that can happen is a company has, you know, there's a certain culture in a company and then there are people coming in and coming into middle management and things like this who are coming from the generic culture. Let's say, you know, they, they went to business school, they, they learned this is the generic way you do this. They come into a company and say, well, we know the generic way to do it, we're just going to do it. Generically. And that's kind of a killer to a company that has some kind of unique culture, unique vision, unique mission. That's kind of how you kill that is by just sort of reverting it to the mean by, you know, having a layer of people who only know how to do the generic thing. And I think that's a reason why it's always great when you can have sort of people who come into a company at a fairly junior level, get sort of enculturated, and then kind of get promoted to more senior roles when they're ready for it. And things like this. That helps because that means you're not just having a sort of flow of generic talents that has generic views about how things should work. But, you know, innovation is always quite hard and it's always quite. It always requires pushing. I mean, people have a tremendous habit of doing what they've done before. And even, you know, I know my own experience, there are things where, you know, I'll have invented something 25 years ago and it becomes a thing that we do. And so it keeps going and it keeps going. It's happened to me in science as well as in companies and such like. But that, you know, you invent something, people start doing it, it becomes the thing they do. You say, well, actually there's a different idea or a better idea. And they say, we don't want that. We're just doing the thing we were doing. And they'll often say that new idea is a crazy idea. That new idea, even if the idea that they are doing everything they're doing based on was an idea you yourself had years earlier, that still doesn't mean just because you had one idea that made sense, the people, even with good intentions, are saying, but the new idea, that's crazy. And it really takes effort to. And you often have to break down, you have to justify the idea. I think the notion that sort of management just says, let me order you to do this and just do it. When you get to that point, things are broken. When you get to the point where the people you are trying to express an idea to or express a vision to are like, I just don't get it. I'll just obey orders type thing, it's a very bad sign. And certainly I think one of my kind of sort of responsibilities is to explain stuff. In fact, usually I often find that I'm more enthusiastic about explaining than people are necessarily to hearing the explanation. Sometimes they're like, just tell me what to do. I don't like that very much I want people to understand why they're doing what they're doing. But it certainly helps if you're doing leadership kinds of things. Sort of being able to explain yourself well is a very useful attribute. I mean, it helps me that I do like these live streams where I get to explain myself for long periods of time. That's not bad practice, so to speak. I think the. But you know, when you get to a situation where, where it's a just do it because I told you to or just trust me, I can't explain it type thing, it's, it's a bad situation. Now to be fair, sometimes I do get, for example, into that situation because I'm just like, we got to get this done. You know, I know I'm right. I don't really need to just debate it. You know, we just got to do it. I don't like that very much. It's usually a bad sign with the people involved on the other side of that when they're not like, okay, I get it too. I understand. I didn't see that before, but now that you pointed it out, I do see it type thing. That's a much better situation. So in any case, I think. But in general, this problem of, you know, where does the new come from in a company, for example, that's often a challenge. You know, in our company, I think maybe bit more than half the things that are sort of new ideas kind of came from me. And I don't really know that precise number, but for me it's a big success when the new ideas didn't come from me. But it is also a driver that I'm somebody who's thinking of the new ideas and that in a sense the culture of the company is such that sort of leadership is involved in thinking of new ideas. Not true in all companies. It's quite often true, but it's not, not always true. And it's something that's worthwhile. And in order to do that, one of the things that can happen is there's so much to do based on what you're already doing that even at the level of leadership, you're like, I don't have time to think about anything new. I've got to spend all my time tending what is already there. But I think an important feature of leading a tech innovation oriented company is you have got to be interested enough in and carve out enough time to sort of chase what's new as well as kind of tending what already exists. Let's see, Doug you do mentioned, I said, I just mentioned that someone can't build something that took 30 years to build. Do you think that will change with AI advancing enough to cut build time frames by orders of magnitude? You know, I remember when we were first working with a bunch of computer companies ON this is 1987 or so, and when the first version of Mathematica was going to come out, what's now WM language and we were working with bunch of software, a bunch of hardware companies about them offering it as part of their software offering on their computer systems. I remember one person, I remember who it was as well, but sort of, you know, as part of some negotiation, this was actually okay, it was with a company called Sun Microsystems, doesn't exist anymore, but, but was a big workstation company, very successful workstation company at its time. And sort of, I think it was sort of a part of the negotiation was like, don't, you know, you know, computerated software engineering is coming and all this stuff that you're spending all this effort doing, it's all going to be trivial in the future. It's like, well, I don't think that's going to happen. And you know, it's just one of these negotiating things. But in the idea that what you want to do will magically be done. See, the issue is the first question is what do you want to do and what's the AI going to do? It's going to say, well, other people have done this so well, you could do the same thing again. But if you're trying to do something new that hasn't been done, you have to kind of define what it is that you want to do. So I think that's, you know, right there, there's sort of a fatal flaw in the. Oh, it's all going to get. Everything that one does in building some complicated system is all going to be kind of automatically doable. Because a lot of what building a system is about is defining what the system should do. I mean for us, sort of the design of our system and how all the pieces are set up and put together is a really important part of the value of the whole thing when it comes to just sort of generating the code. I would say that, well, one of the things that people look at kind of modern LLMs and they say, oh my gosh, it can write a chunk of C code or it can write a chunk of Python code or something. And people, I think it's sort of amusing because in a sense by the time it can do that, that Piece of code is sort of boilerplate and the language designer should feel actually that thing that you're sort of plopping down there as a piece of boilerplate is something that should have been designed to just be one function because it's a repeated lump of computational work. Not always true. I mean, the thing that we found is that as sort of an enhancement to documentation and as a confidence builder of, hey, you can get started and do something. LLM written code is very useful. I don't see kind of the, oh, you're going to be able to sort of automate, you know, the fact that people are saying, oh my gosh, we can make code writing more efficient. Most of that is because they're not writing a Wolfram language or well, that's kind of a unique high level language, but they're not, they're writing in low level languages where, yes, they have to, you know, spin up thousands of lines of code to do things which in our language would just be one function. And you know, one can discuss why that's happened. And I think it's partly because, you know, software engineering is a, is a profession where people come in and just write code all day. And that's not the, you know, what we've kind of oriented ourselves towards is and many of our customers are people who, the main thing they want to do is to think about what they want to do and the actual doing of it. They want to be as automated as possible rather than I'm going to spend my time actually grinding out the code and that's my job type thing. It's more I'm trying to figure out how to take the next idea, have it, implement it and so on. And that's my job, is coming up with the ideas and I want as much as possible to delegate the actual making the code work. And that is delegated in our language because we've automated a lot of things. So I think that's kind of the, I see that as being the gosh, one can make writing code more efficient. Well, yes, that's what I just spent the last 40 years trying to make happen and that lots of people who use our technology stack know very well and it's routine that people will say, you know, look, I did that in an hour and it took the other people at my company, you know, two months to not be able to do it type thing. And then they say, why didn't those other people just do what I did? And I think it's because of this sort of different, you know, what really is the job? Is the job to do it or is the job to write code? And if the job is to write code, then, you know, something which sort of minimizes that out is, you know, is a different kind of thing. But so I think in thing to realize which whenever something has been built kind of ergonomically, so to speak, to serve a particular, to fit in a particular niche, to serve some particular use case and so on, people often say, oh yeah, we can do that better immediately. And sometimes a lot of craft has built up and a redoing of it can make it easier to do sometimes. But there's an awful lot that ends up being, oh, you know, as you really got into that area, you smoothed this thing, you polished that, you figured out this thing, you figured out that thing. And that can get very deep and not, not easy to just come in and say, hey, we're going to come into this area and just immediately kind of take it over, so to speak. I have to say, in my own experience with our own kind of technology stack and sort of computational ideas and so on, we've had more success in doing that than we should have had, in a sense. And part of the reason is because we have a really strong framework that is applicable across a lot of different areas, and that does allow one to go into an area where things have been built up. But there's both a lot of depth and a lot of cruft. And somehow with a new framework, one can sort of break through that and get something better. But the usual, oh, we're just going to sort of patch it all together. And people ignore the fact that there's a lot of detail that you have to kind of understand and get right. I think. In the question of whether machine learning is going to just be able to learn everything and do everything. Well, I think the answer to that is that the things that we humans do, there's a better chance of that. The things that we have managed to get tools like computers to do, there's much less chance of that. The artifacts that we built that are computational artifacts are things that are kind of, once those artifacts exist, they are a very streamlined way to get certain kinds of things done. Now, you know, in the Future, will the AIs build those artifacts? Well, not really, because to build those artifacts, a large part of that is which artifacts do you want to build? And that's a sort of not an AI decidable thing. That's a thing that's sort of a. There are an infinite number of Choices and the humans have to pick what they actually want. So, I mean, that's a few thoughts on that. Let's see. Well, let's see. Another one from lc Speaking of that area. It's always hard for me to know what the referents mean here because I get a stream of questions and so on that is curated relative to the raw things that come in on the various channels that we broadcast this on. So a referent like that is a little hard for me to parse. But the ELSIE is asking what innovation and business lessons can be learned from. They specifically mentioned a company called Thinking Machines that I was involved with in the early 1980s and such. Failed ventures. Yeah, I've seen a lot of ventures that have failed. And you know, they fail for different reasons. Sometimes they fail just because people kind of give up. Sometimes they fail, which is a little bit what happened in that case. Sometimes they fail because the idea was really bad. Sometimes they fail because the execution was bad. Things fail for lots of different reasons. And I think in many, many cases, Thinking Machines being one example, there were many paths to success, even when things looked like they were kind of blobbing down into failure. And in the end, sort of what happened was there wasn't the resolve to go fix these things. Now, having said that, there are plenty of cases where you'd say to somebody, you should do this with your company. And they will say, I just don't want to. That's not the thing I want to spend my life doing. It's like, well, there's a path to success. But, you know, and there is a path to success, but the people, you know, on the front lines, they just don't want to do that. It's very much like, you know, in the giving of any kind of advice, you can tell somebody you should do this, and they'll be like, well, yes, I can see that if I did that, I would get to this and this and this, which maybe I want, but the path to get there is just something I don't want to do. And, and so it's kind of not, not all that useful to suggest that because it's kind of not, not something. I mean, you're suggesting. Take on all of this sort of pain and suffering because trust me, at the end you'll get the thing you want. It's often hard to convince people and companies of that kind of thing. And plus there are kinds of things that people can naturally do. I mean, you say to somebody, your company should. I mean, if I were looking at my company from the outside, I would say your company should be much more commercially aggressive, but that's not something that I'm interested in. It's not something that we sort of have a culture that's built in that direction. But yet if you said it depends also what you're trying to optimize, I mean, are we trying to optimize that the company does interest in things? We're trying to optimize that the company makes as much money as possible. What are we trying to optimize, so to speak? And you would be absolutely correct to say that our company would be a bigger, stronger, wealthier company if we were more commercially aggressive. But we don't do that because that's not what we want to do, so to speak. And it works okay for us not to do that. In other cases. The things that you should do are things that you can't get away without doing them. And so the thing will just fail if you don't do those things. But a few thoughts. I mean, there are many details of. Could talk about maybe another time I'll talk about business failures I've seen and what went wrong and how you could have avoided having those things go wrong. But I would say that an awful lot of the time what eventually fails is resolve. Let's see. Well, See a comment here from Yitzchak about. Do you agree that technology is brimming with ideas and resources, many of which are free? This means that it sort of transformed business approaches with today's opportunities mainly centered around services. I really don't agree with that. I think that this is the kind of the promise that. Look, it all came from one guy, Richard Stallman, who I've known for a long time, who got upset that he wasn't hired in a particular company. And he's like, I'm going to invent this kind of free software thing. And everybody said that's a cool sort of social idea. I mean, it already existed before that time. There was certainly software that had been produced, particularly by academics, that was freely given away, so to speak. But it became this thing where it's kind of the. For a while, I don't think it's true anymore, the kind of the righteous view of how the world should be put together. It wasn't very realistic because in the end, if you want to build serious software and it isn't just a copy of something else, then you need to do lots of work that requires people to be paid to do things that they wouldn't do unless they were paid to do it. And in the end, behind most big pieces of open source software, you'll find some company that is just paying people to do it, but where it turns out that because of the business structure of that company, they think it's just fine or even a good idea to give the software away because their real value comes in some distribution channel they built up in some services organization they built something like that. I don't think it's true that. I think it will be a sad thing for the world if sort of all of the stuff that the world is kind of based on and built with the products and so on was all like, oh, we're just going to put together whatever we can for free and we'll fix it all with services, so to speak. I mean, people have said to me many times, you're making a big mistake with your company. Your software is too good and too easy to use. You should make it harder to use so you can sell services around it. Well, okay, that might be correct. From a business, you know, from a profit optimization point of view, I've never felt that that's the right thing to do. And I think it would be a shame if the world kind of concluded that that was the thing to do. I mean, I think there have been, you know, a bunch of big companies that sort of made shifts from technology to services and so on. I would say that there is much to be done in building products rather than doing services. And by the way, when you build products, it has just vastly higher leverage. I mean, a product, you build it once you build it and it's great and you sell it a gazillion times. Services, every time you want something done, every time somebody's going to buy something from you, you're doing more work. It's a much lower margin business and usually depending on how it's operated and it tends to be. I don't think it's better for the world if everything has to be sort of patched up with services. I also think that the whole concept that sort of a company is just a shell that's bringing in services to do everything it needs to do is a very strange concept. I mean, in some sense the development of economies is such that one is going towards more specialization. But I think that I tend to think there are many cases where I think when people go overboard with that, I mean, I think it's often when you have a company that does certain kinds of things, something new comes along. For example, there's expertise you don't have or something very unusual comes up where you're not going to have a person sitting around at your company who knows about that particular thing. They won't have anything to do for a decade, and then suddenly they'll have to wake up. But I think the. Yeah, I'm not a. I don't think it's true. I think that there are great opportunities at any given time. If you watch sort of what is just now becoming possible based on ambient technology, ambient features of the world, ambient understanding, there are always great opportunities around those things. And the best opportunities are probably the product opportunities, not the services opportunities. The services opportunities are kind of what you have if you have to kind of. You don't really know what the opportunity is. You don't want to make a bet, I'm going to build this specific product. Rather, it's like, let's make these services because they're kind of more flexible and you can kind of do this service or that service or the other service. It somehow reminds me of history of biological evolution, where kind of at some moment in history, the idea of individual organisms learning things came into being. And before that, it's like your genetic code said, you do this, this, and this, and that's kind of like you're building a product and it does this, this and this. And the sort of consulting services thing is more like the learning within the lifetime of the organism, while the organism has feet that look like this. But by learning how to dance with those feet in a certain way, you can get the organism to be able to do something different. And that's sort of a view of kind of the services layer. But if you can, you know, if you can nail it correctly with the right product, it is much higher leverage. I think. The. Yeah, Doug, you know, mentions that they've. They've used a lot of kind of enterprise software systems, which is overly complicated. Yeah, I mean, that. Look, I can tell you, executives from. From such companies have said to me what a big mistake we're making by making our software sort of too easy to use. Because in their world, it's kind of like you make a lot of the money from the services, and there isn't a lot of push to make the software easy to use. In fact, it's a negative. It's a. Why would we spend money on trying to smooth this out when, you know, when that money is just taking money away from what we can make in services? Let's see, Max is asking advice on a career in tech. With everything moving at such a fast pace, you know, I kind of think everything always moves at a fast pace. It depends on where you're looking at it from. I think one of the challenges is sort of education. What you get educated about is often moving at a much slower pace. I mean, the things, you know, there isn't yet a class on. Maybe there are classes on prompt engineering or something now, but, you know, it'll take a while before such classes develop on a large scale, even if that makes sense, which it maybe doesn't. The. So, you know, the. What you learn in school is probably unless. And that's, you know, sort of what one of the advantages of potentially advantages of the kind of leading edge schools might have is sort of what's the delay time between when the thing is relevant in the world and when there's a course about it? And sometimes, you know, there's often pushback and, you know, oh, we should be teaching people these things, even though, well, actually, nobody's thought about it that way for years. You know, in, in, in the kind of real world, so to speak. So first thing is, you come out of school, you've learned a bunch of things. It looks like, oh my gosh, the world moved on from what I learned. You know, things are moving at an incredibly rapid pace. But that's partly because you learned things which are 25 years out of date. And you know, that's, that's, you know. Well, it is what it is. But the, you know, I think one thing is, you know, actually learn about the new things. And you know, there are in the modern world of sort of the web and online courses and, you know, all these things like our company has our Wolfram you offerings and so on. There are, there are plenty of ways to learn about kind of leading edge things that aren't the things that were taught in school where the school wasn't teaching leading edge things. Yet some schools are better than others at sort of adding in leading edge stuff. Some professors might be better than others and kind of injecting those kinds of things. And some are like, I've been teaching this class for 35 years and I'm going to go on teaching it the same way I've always taught it. Not to say that all. There's plenty of knowledge that is worth teaching that was 35 years old, that, you know, or 100 years old or 300 years old, that's still worth teaching. And people shouldn't sort of let that decay away. But certainly in terms of technology, it's like, let me teach you how to write Some very fancy kinds of Java code. Probably not a very good idea. Let me teach you. When I started working on computer kinds of things, the serious language was assembly language. Let me teach you how to write an assembly language and how to structure your code for, you know, in written assembly language. That's kind of not a thing for all but some microscopic fraction of the engineers of this world, so to speak. I mean somebody needs to know how to do that, but it's a small, specialized effort. And so I think the sort of understanding, what's sort of understanding the leading edge of things is probably no harder than understanding the things that were from 30 years ago that you're being taught. It's just that they aren't necessarily packaged in a form where you know, oh, you take the course, you know, the 201 computer science course or whatever it is and it's going to have that, you know, rather you have to be a bit more entrepreneurial and say, what is it that I want to learn about? There are probably good resources out there to learn these things. Go learn them. And then, you know, I think in, you know, I some was asking here about starting careers in tech. I think there are skills like sort of the skill of how you think computationally about things. That's a skill not as many people have. They know how to write code, specific pieces of code. They don't know how to sort of think computationally. Kind of our big effort is to get it to the point where if you think computationally, our technology stack provides the way to implement things and also provides a way to help you think computationally. Well and I would say that sort of thinking computationally about things is a really useful skill and a long term skill and completely transcends the details of whether you're writing this language with this syntax and so on or another one. I think the thing that is also always an issue is okay there, you know, there's a big waterfront of possible things you can do in technology, in the modern world and so on. Which are you going to pick? And I think that's a somewhat personality dependent thing. I mean, I think, you know, there's always this trade off between pick a thing that's popular, where there lots of resources, everybody knows why it's useful, but there's also a lot of competition. Or pick a thing that right now is a backwater off in, you know, in the wilderness and really nobody's doing it. It's not so easy to find the resources to learn about it. But you'll be the best person in the world at doing it real quickly because there aren't many other people doing it. And which of those you pick is somewhat personality dependent. I mean, some people sort of thrive on the competitive aspects of things. Some people thrive on the idea that I'm doing something nobody else is doing and that where I know it's important even if the rest of the world isn't giving me that feedback and maybe I have to go explain to the world why this is important. Whereas in the more competitive kind of herd situation, it's like, everybody knows it's important. It's just, can you run faster than other people and with different personalities that, that's, you know, it's a different thing to approach. So I think that that's another way to perhaps think about these kinds of things. I think that, you know, people starting careers, there's always a question of, you know, what kind of company do you work for? And that's again, a somewhat personality dependent thing. I mean, there are people who really want to be in a very well defined environment where you can be a software engineer 1 and then a software engineer 2 and 3 and 4. And there's a kind of a well defined career progression. And others are much more, you know, I'm going to make things work by kind of using my own wits, so to speak, to navigate what's going on. And that sort of is, are you going to go for a big company that has a lot of structure, it's very well defined, where you can spend your whole life advancing different levels, or are you going to go to a startup that could be in turmoil and where the thing has, you know, where you come in and then the next day it's like, oh, by the way, our CTO just quit. Will you take over that role even though you're very young and just out of school and et cetera, et cetera, et cetera? I mean, it can be both opportunities and, and lots of crazy things can happen. And it's somewhat personality dependent. What, you know, which of those environments will be a better fit? I think it is. It's also, you know, find a company that is a good sort of cultural fit. And by culture, I mean things like, is it a company where people sort of say everything to each other directly, maybe not necessarily politely in all cases, Is it a company where everybody is very kind of deferential and so on, even if they don't actually say what they mean, you know, those kinds of things? This is at a company where all tasks are going to be broken down into very small pieces. And it's very well sort of structured of, you know, you fill out this form and you do this thing. Or is it a company where you're kind of on your own and you have to take your own initiative to do things? There's a huge spectrum of different, different characteristics like that out there. And to know yourself well enough to know which one you should fit into is very useful because that's where you'll be able to thrive. If you're in a company with too much structure for you, you're just going to be frustrated, like why am I filling out this form? What's the point of that? If you're in a company with too little structure, it's like, I don't know what to do. It's very stressful because I can't decide which of these things to do and nobody's telling me and it's all too undefined, so to speak. So different people are in different places on that spectrum to some extent at different times in their lives as well. I should wrap up soon here, but. Let's see. Well, there's a question here from anything talking about my personal life history and having started doing science and technology as well pretty early in life and asking how did I manage those kinds of accomplishments and cultivate the imagination needed for those types of topics. I have to say, when I was, you know, a 15 year old kid writing physics papers, I didn't really have this big wow, that's so amazing. I was just like, this is something I can do and I want to do it and let me just go ahead and do it. And if somebody said, you know, as, I mean, I, I didn't give people opportunity to say, wait a minute, this is not a thing that's done. Because I wasn't really talking to people about sort of the meta of what I was doing, so to speak. So you know, for me it's kind of like, can you do it? You know, can you figure out how to do this? You know, then let me just go and do it. And I suppose the important thing for me is that I haven't found the, you know, it's like looking around and saying, are other people doing this? Wait a minute, should I be doing this? Nobody else is doing this, I shouldn't be doing this. Maybe it's just my particular kind of crazy personality or something. I haven't been very concerned about looking around and saying is everybody else doing this thing? For me, it's just like I figure out what I want to do. Can I do it, can I make it happen, etc. Etc. Etc. Rather than the, you know, thinking about either, either being oh, I'm so excited I'm doing something nobody else is doing at that level, or being like, wait a minute, I shouldn't be doing this, nobody else is doing it. So that's kind of, for me that's an important attribute is, you know, just do the things that you think you should be doing. You know, I was, people will say to me, you know, well, I'm thinking of making a career change and this and that. I'm kind of bored with what I'm doing and like, should I really do it? It's like, you know what? If you're thinking about it in that way, you almost certainly should do it because it's kind of like people's tendency is to not do the things that they, you know, to always be second guessing themselves and should I really do this, Should I not do this? And it's, it's usually if you think about doing it and have sort of conceptualized and enthusiastic for it, you probably should do it. And you know, you might have to figure out how to do it. So, you know, when I was a kid doing physics and things like that, there was a certain amount about how to do it type thing, you know, how do I. Well, what were the issues? I mean it. I managed to how do I get access to a computer that can do the things I want to do? How do I. Whatever. But these had very practical solutions or how do I. One big thing for me actually was how do I do all these complicated calculations where I don't want to spend all my time, you know, chasing minus signs and factors of two in giant sheets of paper with a bunch of algebra on them. And for me it's like, well, let me think about how to do that. Well, gosh, I could use a computer to do that. Well, can, is that realistic? Well, yes, it is. So you learn about computers and you figure out how to do that and by golly, it works really well. So it's kind of like, you know, you have some objective and can you figure out how to go there even if other people aren't doing it that way? And something I've seen many times is I'm doing something and it's like, why is nobody else doing this? Like, I've just been working on a project where it's kind of like, you know, in retrospect it's like, why did nobody else do this before? It seems kind of obvious now that particular one, I have a little footnote to that, which is I almost did this project in 1985, and I didn't quite see enough to be able to see to do it. So in a sense, why didn't all those dummies do this project before? You know, I was one of the dummies type thing. And so you kind of realize from that that it's not quite as kind of, you know, just because it seems obvious to you, it doesn't necessarily kind of. It's not, you know, for whatever reason, you may be in some unique situation and you shouldn't worry too much about, gosh, why did nobody else do this? I think that's, for me, that's been sort of an important thing. And I do wonder. People are always asking me of projects we're doing, company and this and that and the other. Why is nobody else doing this? And, well, sometimes the answer is because it's a bad idea. But that's the minority case. The majority case is because they didn't think of it because things weren't oriented so that they could quite do it. And sometimes things I've done, for example, are things where it just was, well, I can do this, so I'm going to do it. And then I'm like, why is nobody else doing this? And then I think harder, and I realize, well, actually, I have these attributes that make it easy to do this where it isn't easy for other people. Like, for example, I've collected ridiculous amounts of data about myself and so on and what I do over the last, I don't know, 35 years or so of all the keystrokes I type and all this kind of thing. And it's like, well, why haven't everybody done this? And the answer is, because it's kind of hard to do. And I can do it because I'm running a company that I'm in charge of. I've got people who help with my system administration for my computers, and I have all these systems that keep it running, and occasionally somebody has to tweak it in some way. If I was doing that all myself, I'd never get around to doing it. So although it seemed like, oh, this is an obvious thing to do, it was something where I hadn't really internalized why it was easier for me to do than for other people to do. And that's something that I've certainly seen a bunch of times. All right, well, I should probably wrap up here. And I see all kinds of interesting other questions which I'M have a great I would love to address but I see I'm late for the next meeting for my day job and I do need to do my day job and build WOLM language and do all the science and so on I'm doing. So I have to break off from my hobby here and go back to the day job. But thanks for joining me and look forward to chatting with you another time. Bye for now.