SPEAKER_01 0:00

G'day everyone. Welcome back to the podcast. I've got a very special guest today, Simon Rake Allen, who is a CTO at Mindset Health. Welcome to the podcast, Simon.

SPEAKER_00 0:09

G'day, g'day Simon. How are you? Nice to be with you.

SPEAKER_01 0:12

You can never have too many Simons. And to get it out of the way early, Simon and I are of the same vintage, which means we both owned and still lust after Wombat computers that are an Apple II clone from back in the day. So here's my public call. If you have one, preferably two Wombat computers.

SPEAKER_00 0:31

We're in the market.

SPEAKER_01 0:32

We're in the market, exactly.

SPEAKER_00 0:34

My mother actually turns out that she went to school with the guy that made them, and that's how I got mine, because she called her friend, and my dad took me round to their office, and I remember going into this guy's office. This was 1983. Yeah, maybe end of 83, early 80s, 94, uh 84. And he in his office, I was a little kid, I walked in there with my dad to buy my first computer, and I remember this really clearly. Above his desk in the corner, hanging from the ceiling, was an apple with an arrow through it.

SPEAKER_01 1:10

I love it. And and the the Womback computer is at the center of one of these seminal uh computer IP cases in Australia that we won't get into now because it's not the topic. But it's worth mentioning that that you know, giving you a feeling of our age because the topic today is is a decision that Simon has taken, uh or maybe not even taken, we'll dive into that, which is the world of the software uh developer, uh engineer, call it what you will, is changing slash under threat slash being redefined uh uh more than any other time. However, we've been around for a while, and Simon is a far more accomplished software developer than I ever could dream to be. But Simon, give us a taste of a your background in software and then what happened about three and a half years ago.

SPEAKER_00 2:05

Yeah, so I've been coding since I was nine. At nine at school, we had a computer lab there, and I was a little dork, and I used to hang out at the computer lab watching all the big kids at school do this stuff. Um, and um I I was uh taken by it, and I would join the computer and I stayed there and hung out in this room every day. And there's one other guy, he took me under his wing and he showed me how to ride it. We were riding in, I think we had some kind of terminal system, and I wrote my first game, which was the moving car track, and you use the arrows to move your car at the bottom as the track comes down. Fantastic game. Um, and then we got an Apple IIe at at school. Um, but there was actually a moment because we got we're about to switch into the AI conversation. There was a moment for me at that school, at that time, that got me obsessed at that age with AI. One of the big kids at school came back from his father came back from overseas and brought him a present, which was a chess playing board. So you put you put the board down as an electronic board, you put all the pieces up, you move your piece, and then the computer flashes the light on the square. Red light, the little red light where it wants you to move its piece to, and you do that and you play it. And so on the weekend, I was invited in, we came to the school, and the the the teacher, the computer lab teacher, set up this computer to play against the Apple IIe.

SPEAKER_01 3:30

Machine versus machine.

SPEAKER_00 3:31

Machine versus two machine enter, one machine leave. And that blew me away, and I've been obsessed with AI ever since. And so, as a part of my background, I have to uh reveal that I actually spent ten years at Monash University studying AI and doing you know postgraduate work in AI and building AI simulators and actually working on how to make computers able to code. So, three years um I developed a simulator that could help um AIs to code, and then I spent the three years analyzing computer-generated software code. So I've got yeah. I I was doing it when it was daggy as hell, and everyone would call me a dork.

SPEAKER_01 4:11

Well, we've had many, many an AI winter has happened in our professional lifetimes, but obviously um things are different this time because stuff's caught on in a way that it hasn't before. But before we get into that, like you've been at very large organizations like like NYB, various banks, etc. Like you you do a lot, you've done a lot in the startup community as well. So just to help folks who who don't know you, um you're a real no-fool and software developer guy, aren't you? Like you you build a lot.

SPEAKER_00 4:42

I'm I'm very active as a builder. I love to build. I mean, if I'm I build a bit at work, you know, obviously as a CTO, you get you go in and out of building. I'm right now in a building mode. Um, I'm on a new mission now to empower the non-developers at the organization. Um, I think that's the next frontier for everyone, is that I think last year, 2025, was the was the year that developers got on board. And obviously there's not everyone's there yet, but 2025, I think, was the you know is when the mainstream kind of cotton on it, okay, this is where it this is where it changes forever. And I think the moment that it changed for all of us, um, you know, and I worked as I I mentioned for many years in AI, and it was always cool, but it was never magical. But the day that ChatGPT launched, I think it was in November of 2023, maybe 22, three and a half years, so yeah. Yeah, November.

SPEAKER_01 5:36

End of 22 for me.

SPEAKER_00 5:37

End of 22, November something. Um, that was the epoch for us. That was the beginning of the new era. That was the moment that everything changed. AI went from being here and AI winters to going 10 million X in its capability. It's the thing that we were all dreaming of building and having. It it became true. And there's no going back. Um, and I'm I'm seeing uh, you know, it's it is a struggle, right? We have to reinvent. I mean, engineers, software engineers, we've been on a pedestal. We're those geniuses that can do anything, you know. And um, Jesus, uh, two days ago, so my my sons are they're in their 20s, early 20s, they've started writing little programs to try to find ways to um invest in the stock market safely. And I'm like, fine, you know, my kids have never got into coding. Like they never followed in father's footsteps. And I'm not bitter about that. Yeah, it's always they rebelled. And so now they're both coding, right? Using using Claude. And so the other day I said to my to my 20-year-old, I said, Hey, uh Gabe, I said, Um, you know, do you need me to help? Can I help you with anything? He goes, No, Dad, everything you've ever known, I can just now do in 30 seconds.

SPEAKER_01 6:48

So that's an interesting point right there. So, firstly, there was the stab through the heart, yeah, echoing the stab through the apple sign.

SPEAKER_00 6:54

Thank you.

SPEAKER_01 6:55

But but let's let's dive into this. Because I mean, as a as a professional, you know, I I I I joke about it, but I mean you've spent many, many, many years learning lots and lots of skills, different languages, different frameworks, different tool sets. Now, in my experience, you've typically been at more the cutting edge, so you've been early on some of these shifts and trends, but you've you've learnt a lot that has gives you value and credibility and and and scalability from a professional standpoint. When you saw what ChatGPT could do from a coding standpoint, even back then, what was your mentality about what it meant for you personally and for your skill set? Help us just walk through. Because I was the reason why I'm asking is I want to help two cohorts. The the cohort of person like ourselves who've been around forever and are going, what's going on here? But also the cohort of brand new, shiny graduates who are like, I was ready to be a software developer, and people are telling me my job doesn't exist anymore. So what was your thought process when you saw what could be and that it challenged everything you had been?

SPEAKER_00 7:56

First it was shock because we always thought that you know LLMs and this stuff would be good at language, we'd be good at a few things, not good at creative and design, and certainly not good at computer programming, which is so logical and very precise, and you need all your semicolons in the right place. And to see it actually be able to do that was like to you know, that I think was the shock we all hit, right? But um now you've got two choices. What do you do? Do you fight it or embrace it? Um, you know, and I'm honestly I've been trying to build this for most of my career. Um I've been I've been waiting for this moment. So I absolutely dive, you know, dove headfirst headfirst into it. Um and obviously when you start in those days three and a half years ago, it wasn't it wasn't great. So um we were all people who were diving into it, we were all building wrappers and tools and harnesses around it to try to make it basically usable. And all you could do really was get it to do one function at a time. And and it wouldn't test it. It would say, yes, it passes all the tests, but then you actually run the tests and they all fail, but it tells you it passed because it didn't actually run it. It couldn't run it at the time. Like we've come a long way. So, but you know, jump on board right then, and I'm like, just how far can we push this? How it's going to, you know, the you know, do you remember then the days where we used to have a different JavaScript framework every other time? That was the big joke, which JavaScript. Well, now it's like the AI conversations also it always ends with this week. Like, yeah, it's it can't do this or it can do that this week, because next week, who knows? And everything I've been building, next week, Claude or Cursor or somebody comes out with that feature. Um, but it's it is such a transition. Like, for me, it's been exciting because you know, one of the reasons when I'm a CTO that you don't get enough time to code is because of context context switching. Context switching is a whole interesting topic that we've we've got to we've got to cover, but you've got to spend time to get your head into a problem, to find out all the the architecture that's existing and what you want to do, and if you want to make a change, that time has collapsed to zero. So you don't need the context time necessarily, you need to focus somewhere else. And that's actually been the beautiful thing. Um, people who are embracing AI are now actually focusing somewhere else rather than in the code, and it's a shame because you know, we all grew up, you and I and everyone else, we grew up on the books of you know software, clean code, the the good the go for pattern guys, the you know, how to make you know kiss and dry and yagny and all these principles, and uh there's like 50 of them. They've I think 49 of them have gone to zero value.

SPEAKER_01 10:37

So do you think do you think it's moot? Do you think because I I guess this this has an interesting thing is that is a software engineer or software developer someone who writes code or someone who solves business problems using technology?

SPEAKER_00 10:50

You you've got to redefine it because we used to write code and now we used to write code in order to provide business value, but those things were months, if not years, sometimes multiple years apart, right? And now they are seconds apart. Right? You can so I think the new skill, and by the way, uh you know, experiencing technology, you know, what it means to be a coder is just changing. It's not all gone. Like in in um uh three years ago, before before the epoch, before the overlords arrived, what was in what was important was you know that you understand everything about the code and the system and the architecture. And now what's important is the the the features and the customer and the you know the architecture, those are the two skills that have really come into play here. Because before it was always easy to code and anyone could learn to code. And we had we had we had derogatory terms for coders who uh you know just could just code. But the great coders, their code could live in production, right? Because they understood infrastructure and understood performance and security and reliability, and they you know, and you know, if you're using cloud functions, they die after 60 seconds, they time out. So if you've got a function that takes longer than that, it'll kill it. You don't care about that when you're on your PC and it works on my machine, right? So the nature of the coder now has moved, I think, more towards understanding how to instruct AI to write the code in a way that solves your problem and allows you to put it in production and for it to live there because that has always been half the job, and now it's half the job that only the software engineers or the experienced ones know how to do.

SPEAKER_01 12:30

I think I think you're right. I think it's interesting too that a couple of things. Firstly, people are very selective in assessing the quality of code that goes into production in a lot of cases. Um I've seen some pretty ordinary code that got through for reasons that would be there. So I think, you know, to to assume that all uh all code as uh doll north is not a accurate representation of all software developers. Like with any occupation, there's there's good, there's bad, there's in-between, there's average. But I think what's coming to the fore here is a the ability to ask really good questions, both around the domain you're working in and the code base you're working on, but also applying some critical thinking as well.

SPEAKER_00 13:11

And I think that critical thinking to me is now the now the skill is knowing when you have to care. Right? That's a good point. Because code quality matters on that at the moment. Where do you see it? Yeah, so code quality depends on like if you're prototyping and it's gonna be thrown away, then you don't care at all about the code quality. If you're putting it in production, then you might care. It depends where in production it is. Is it in a mission critical path that you need performance for or you need security for? Or is it in an area, you know, for example, I was working on some drag and drop the other day. And do I care about how that actually works under the hood? It's a front-end thing. I want it to work, but I don't care how it implements it as long as it's as long as it's performance. It's not a back end, it's not gonna risk anything from my company. So I care, I don't care. That's what I'm saying.

SPEAKER_01 13:57

Did you read that code? Did you did you do a view of it? Or you just said it functionally it works, it doesn't have to be elegant.

SPEAKER_00 14:04

In the background, I'm scanning, right? I I I have my editor on my top screen, and on my laptop screen, I've got my GitHub diff app, right? The one I manage all my my check-ins with. And so as it's coding, I'm watching the files, it's changing file names and seeing the diffs. So I'm always just looking at the diffs because sometimes it'll do something in a way that I, you know, that I don't like or I want to change. Right? It's important for me to know the architecture in order for me to be able to guide it in the right way. But I sometimes care more or less about the code, and that I think is the new skill, right? Or at least one of the three.

SPEAKER_01 14:37

One of the new skills. Where do you stand on on testing? What's your and again, yeah, we're recording this in in sort of you know May of 2026. So call that out because uh yeah, exactly, because things change so quickly.

SPEAKER_00 14:49

So I said to you I I said out of the 15 things, 49 of them have gone to value zero.

SPEAKER_02 14:54

Yeah.

SPEAKER_00 14:55

The 50th item was testing. So I'm actually still in a bit of a funk on testing. I was obsessed with it before the epoch, and now I'm confused because if I ask um the overlord to build me some code and I say please build me the test at the same time, it'll build a test to match the code, and it'll say that's zero value. So when is it of good value? Um I the other day I did something and it's I said to it, oh, remove this, remove, uh no, change this feature, right? And it decided that it should remove a different feature as well, because it's probably not needed now that I don't have this particular feature. So it removed that other thing that I still needed and it removed all the tests for it as well. So while it's doing everything with the tests at the same time, it's judge, jury, and execution are all in the one in the one agent, and that that that has no value. So I think you know, the testing for me, I'm and I I'm I admit I do not have the final answer on this, but testing for me was always if I come and look at your code, Simon, and I want to make a change, the testing is my safety net. So I think that's that's really it. But if my safety net, if the code tests all run and my AI also changed the tests, so what I have been doing is saying to my overlord, do not ever write tests, change tests, or touch tests. And so I've been using Cursor and Claude separately, one to do the coding and one to do the tests. So they both check each other. And that's how I found it I it's not the right workflow yet, but that's along the lines of what I think has to happen here. Because if it does it at the same time, then there's zero value in that.

SPEAKER_01 16:31

Well, it's got to be adversarial in some in some way. I mean, you know, again, back in the old days, you know, the the the joys of the code review and doing unit testing on someone else is always you were trying to find the bug. Like that was the whole point. Because let's face it, it was boring as hell to do that. Like I hated doing cross-testing and all that. So I hated it with a passion, but you had to do it. So it's like, well, if I'm gonna do it, I want to find that bug. I want to prove, you know, make make my time worthwhile. Um, and so I guess you you're trying to do the same through the through these agents using different models because they're attacking it from different perspectives. Yeah. And and I guess to some extent, that's what we we we're getting with um, you know, mythos and that sort of stuff, you know, the the ability to just go crazy on a code base and figure out what's going on. Um, but it's interesting, you you know, testing, I feel like in every transition we've had in technology is always the last thing to be looked at. It's like the the unloved, you know, second step cousin. It's it's always like we can go really fast, but we can't do this in at scale or at speed.

SPEAKER_00 17:30

Look, testing definitely took a look, you know, it took longer than the you know the modern software revolution. The testing revolution, you know, took a bit longer. And I, you know, a lot I think the Ruby community brought that in. Uh, you know, they became obsessed with you know uh testing first and all that kind of stuff. So yeah, it has been a bit of a bit of a laggard. I think it's gonna take a beating right now because people are moving so fast uh the testing actually slows you down now. You might as well just get it wrong and you know redo all of your test harnesses later. Uh, you know, this I mean, and that's a part of this transition, right? Uh all my rules about how to build and what to do in what order, and you know, what are the trade-offs and how long things will take, all of that is being challenged. And I just have to check myself all the time. No, no, that's wrong. I'll give you an example. I went on holiday with a with another family uh last year, and we went to Greece, and we couldn't read any of the Greek signs. So I said, Ah, I'm gonna build us all an app that we can learn how to speak Greek, or at least read Greek. And so this this thing would it would give up a random uh Greek letter, and then you would say it out loud, and then it would put up the phonetics of it, right? And then it did three letters, and then it did simple words, and so we got better at at pronouncing, and we had this whole roadmap, and the um the other family that one of the people said to me, Hey Simon, why don't you make it say the word rather than just put the phonetics up? And I'm like, you know what? We've that's a bit more complicated. Why don't we do these features first and then we'll we'll build up? And I checked myself and I said, Claude, make it say the word. And about 15 to 17 seconds later, it was now speaking it. That's the stuff that you just you know, I'm getting wrong.

SPEAKER_01 19:09

And this is putting back pressure onto the whole art of product management as well. You know, we used to spend ages grooming a backlog and prioritizing and assigning points, and and even like I always get a chuckle when Claude, for example, tells me, Oh, this change is gonna take 80 hours. I'm like, Yeah, it's gonna take you 15 minutes, dude, but that's okay. Um, but you know, these these these trade-offs that we used to agonize over correctly because everything cost real cash money and time. The time you would spend agonizing over the difference between it is more than the time of doing the thing now. So it's turned it on its head.

SPEAKER_00 19:42

Literally, though, literally, and I one of my developers the other day just said, guys, why are we arguing? We've been arguing for six minutes, we could have built this in five. Yes. We're just not there yet, right? That those are the um those are the decisions that just we need to rewire how we think about software engineering. Um, and you know, I I I just think the biggest productivity gain is going to come from people who can build who understand A, the customer, and B, the architecture. The architecture, that's this week, that'll go away. Understanding the the customer will never go away because we only want to build things that are useful, and I don't see AI ever being able to really work out what is useful. It's giving you good hints and it's giving you good frameworks, but but understanding deeply the user is unbelievable. And if you've got to sit there as a developer and you have to be told everything from a product manager in your ear, think about this. It used to be 10 to 1 product managers to engineers, right? And there's there's a you know, on a on a pizza-sized team, right, there'd be four or five, six engineers, and then a uh UXR and a product person and a few of that, and they often were only fractionally on your on your team. They were they were across five teams and they would do 20% with each team, and you know, they were uh, you know, fractionals on your team. And you know, if you had a really productive team, and you know, we've been getting better and better as the JavaScript frameworks have settled and we all now know how to build with React and we could do it pretty quickly before the epoch, we I had a team, we were getting to three or four to one on the fractionals. Yeah. Because you know, we could build things so quickly that we needed to hear from the product owner and from the UXs and the designers what to do next. That time has collapsed to zero and you cannot wait. I can do 30 or 40 features now in a day myself, but only because I can think of them fast enough.

SPEAKER_01 21:36

Yes, yeah, you got to keep the machine fed.

SPEAKER_00 21:38

Yes, and my cues, I've got these agent queues that for each product uh that I'm working on, I'm keeping you know, three or four cues full, you know, all the time. So I'm just wrapping between these four agents, um, looking at what it did last time, filling the queue with the new features and a whole set of changes, and then swiping and going to the next thing. And so we talked earlier, we made Mentioned uh context switching, the I think that's actually a latent thing that we actually need to all get on top of. Because in the old days, you know, if you spend two or three days on it and get your head into an architecture only ready right now to make that change, and then someone says to you, Can you make me a coffee? And oh my god, I had to context switch. It's erased, it's fallen off the stack. I am working with imbeciles, you know, and you would be all you'd be outraged, right? Um you now need to context switch.

SPEAKER_01 22:28

Well, you need to context switch, and that that comes with its own cognitive tax, both from an energy perspective and just a brain power perspective. And I think added to that, there's sort of this latent FOMO that goes on for people who get excited to build because you know, we've got these these token limits and what have you, but you know, the machine is available 24-7. And so, you know, I feel bad if I don't have my agents doing stuff overnight. Like I want to sort of Yeah, it's it's like the old mainframe batch days. You know, I want to submit the job, go home, come back the next day, see what it did. It's that same thing, but I think that's that's putting this sort of pressure on. You see a lot of developers walking around their laptop now so they can press next or approve the next thing. I mean, do you think that feeds into this sort of franticness around context and switching?

SPEAKER_00 23:11

Yeah, we're we're all getting frantic, and I love it. I had them I had a meeting with somebody at 12 o'clock and it was 11.59, and I said, Oh, I reckon I can get in one more feature. You know? Yeah, I love that. I have never provided so much value to so many to so many users ever in my career. This is the golden age right now. Uh, you know, until we all lose our jobs, this is the golden age, right? Um, this is the thing. We are in the developer's golden era. Um, it's it's post uh epoch pre-singularity. So that's the that's where we're at right now.

SPEAKER_01 23:47

You're right. Because I mean, yeah, look, I mean, typing, typing code, not the most fun thing in the world, you know, and we we used to spend ages of time trying to figure out how to write less code, so it all the way back to you know, copy books in mainframe, all the way to frameworks, abstractions, and other stuff. Then it was code completion, code snippets, shortcuts on your keyboard, Emacs bindings, all that, you know, as much as you could do to speed it up.

SPEAKER_00 24:09

Yes.

SPEAKER_01 24:10

But this has taken it off the table altogether. But the other thing that's taken off the table, I'm interested in your view on this, is I always remember on projects, we always had the architect. You know, it was always the usually slightly older person on the team who'd been around longer, they were more senior, or they'd been on the project longer, and they they had in their head all the knowledge. It was like, you know, the old the knowledge of the taxi drivers in London. And you know, if you needed to make a really serious change or you need to understand why something was, you had to go and see them and talk to them and hear what the reason was. But now I get the feeling that if you can add a code base to an LLM and ask the right questions, it's playing that role. It will tell you.

SPEAKER_00 24:51

I don't think so. I don't see that. No, okay, good. I think there's I think there's the two halves. There's the coding and then it's getting it into production. And to get it into production, you have to know how to architect it. And there are so many options there, and AI is not yet good at that. And I think the peer people with experience and who have seen lots of architectures are making better decisions on that front. And you, if you ask AI what to do, it'll give you an arch, it'll give you an architecture. I have never found that to be um good yet. Um it's a this week problem, right? I'm sure it's gonna get better. It's gonna be better.

SPEAKER_01 25:22

Because you're right at the moment, you'll say, How do I do this? It'll say confidently, do it this way. And then you'll say, Well, what about this other way? And say, Yeah, that's a much better way.

SPEAKER_00 25:29

Yeah. And have you considered this? No, you're right, of course, we shouldn't do it that way, you know. So it doesn't really know, and it's not really reasoning very well about that stuff. And it will get better once it sees more. But that is so I said there's you know, the two skills are architecture and and users, right? You need to understand your users and your business, but you need to understand architecture so you can guide it to do things in the right model. Um, and you know, it makes stuff. I mean, I'm trying to work on a on a problem right now on a system to enable the other people in the organization who are non-developers, give them a platform where they can do really good computer programming with databases and APIs and everything without knowing and without needing to know the architecture. So I've got to do a lot of architecture work right now, and the AI is not helpful at all. It's interesting. Yeah, I've been through three suggestions and none of them are. I mean, they're ridiculous. They're ridiculous. Yeah, they're ridiculous.

SPEAKER_01 26:19

So but do you think that's that's similar to the well, the co-completion sucks, and now the co-completion's great? Is it we're sort of in that that mode? Or are we at the point because there's always this argument of you know, is is there enough information to train these models on to give a sensible answer? And you know, code and and and algorithms, yeah, it's it's out there, you can you can search on it. But you know, what's in Simon Rake Allen's head that he learnt, you know, 20 years ago on a dark night, rainy night, trying to get a change into production and realized never do X. Um that's not in any model anywhere.

SPEAKER_00 26:50

Yeah. I mean, look, it probably look a lot of that stuff folklore and probably it probably is, but for some reason it's just not yet configured. I don't know whether they've got benchmarks around this stuff. Um, because you know, coding's half the job, and they're really good at coding. And I think they need to now point their their engines at the other half of the job. Um, so the other day I built, I I asked it to do some feature, uh, had a front-end, back end, you know, scenario, and it was this I had to do like apply something uh to a list of things, and it did it all client side. So it made the initial call, got the list back, and then did 50 API calls to, you know. That seems ridiculous from a you know, even a junior coder wouldn't do that, but that's the way it did it, and it was a it was an easy fix, obviously, just to tell it. But luckily, I was watching and like I oh, oh, it's gone with that pattern, like duh, not you know, not not in this case. So the other day, right? I was doing uh working on this thing and I was thinking about the whole you know, Yagney and dry, and I'm thinking, dry, does it really matter? Let's say it does it the same thing ten times, so you've got the same code like that would be for humans, right? For coders, that is a sin. That's not clean code because what happens if you get a bug in one, you know, you've now got a bug in all. But but I my line has always been who cares? AI doesn't care about that, right? AI would fix the bug in all ten places, and that's a okay, Simon. Except I had the issue the other day and it didn't. It fixed it in one.

SPEAKER_01 28:28

Um so you know, so our assumptions can be flawed in terms of the scalability or the the correctness. Again, it comes back to correctness and testing and validation.

SPEAKER_00 28:38

But it's but this is also our skill. If somebody, and you'll see this a lot, developers will be judging AI, said, Oh, I told it to do this, and it made three copies of the same thing. Like, so what? Like, you might have to then give it a bit more guidance, that is still 10,000 X better than what you had to do before. And so the skill is actually in not just giving it the one shot every time expecting it to get it right, the skill is to be able to know exactly how much to guide it towards the architecture that you want and when, and how much to have your eye watching the diffs go past, that you can then you know give it the adjustment, because that is the skill. And as soon as you hear a developer go, oh, it didn't do this, I told it, didn't find the bug, you know that it's the developer's skill with AI, not the AI. Because it's the whole thing's on a journey right now.

SPEAKER_01 29:25

So then if I'm uh a newer developer and I'm just starting out, now there'd been a lot of talk about you know juniors, what happens to juniors, because you know, it wasn't the job of juniors to write all this this this you know code and spend late nights writing code. That's part of it, but I'd argue not the core of it. But anyway, as a junior, what would you do now? Like what what would you be leaning on in terms of skills, tooling, attitude, like what would you be doing if you were starting out again?

SPEAKER_00 29:54

No different. Double down on AI, go hell for leather, and as a part of that, you're learning how to read code and you're learning about architecture, and you're learning about you know your users and all these different things. And you know, the code is being written for you. You still need to know what that code is, and you don't need to know how to read it, and you know how to interpret at a glance what the architecture is. But guess what? You've got the overlord there who can help you with the architecture as well. So people can learn architecture way more quickly. I love the advice you get on architecture, it's actually really interesting. Like you say, I'm thinking of doing it this way. Would this be what are the pros and cons of this approach? Or give me five approaches and then ask it what's the pros and cons of one of those. Unbelievably eye-opening. It's not the it's not the oracle, it's not the gospel, no, but it has seen enough of that in its training that it can tell you which which things to consider and what to look out for, and then you can choose, and then you guide it to do it right. And that is, you know, normally you'd have to buy what's it called? What are those things called with the paper in them? Books. You'd have to buy a book, you'd have to buy a book and read, you know, distributed architectures, you know. Um like how annoying is that? And now it's at your and now it's you know, and then after that it became Stack Overflow, and then it became right, and now it became the overlord telling you what it is. And so that is just so your ability to learn and suck in information now, that's your skill. Just yeah, yeah, write as much as you can, experience the you'll as a junior coder, you know, you always made mistakes, and then you have to fix it, and now you just get to do that on a way faster cycle.

SPEAKER_01 31:27

The iteration speed is just so much quicker. So then let's close with a lightning round of what is your current tech stack of choice? Like if you were and I'll qualify, okay. You're you're building a startup for yourself, so you get to decide all you don't have any other dependencies you've got to worry about. What would you what would you reach for to get a fastest time to value and b most robustness? They could be different, they could be the same.

SPEAKER_00 31:53

If you're if you're talking about software and languages um and databases, then the answer is it doesn't frickin' matter. It doesn't matter. I mean, I once asked it to do this, that, and the other, and it did half of it in TypeScript, half of it in JavaScript, and the other half in Python. Doesn't matter, right? So those choices I think are less.

SPEAKER_01 32:15

I think it's not matter because you know how to read those languages, or like what if it did try to do that?

SPEAKER_00 32:19

Of course I know how to read them. But from there's no benefit pros or cons either way, in my opinion. It used to be because TypeScript, better than JavaScript, you know, no closures, and we've got uh, you know, type, strong typing. Great. Typing is a human-level thing, right? It's nicer, I think it probably makes it easier to find problems that a AI has made, so fine, but just no longer one of those big critical decisions. Which database? I think it's important to choose the drive database, and you've got two choices, in my opinion, for most of what you do in in you know in the web world, and that is you've got a collection or you've got a bucket or you've got a SQL, right? Those are your three main things. You know, obviously it's just collections, you know, document-oriented or SQL plus a bucket and plus some other stuff that you might need. That's really about it. And whether you use Superbase or Vercel or Cloudfront or you install Postgres, uh immaterial in my opinion, these days. Um I I tend to, although I so I've been trying to empower the rest of the organization. So I'm A, I'm trying to build a development environment for them that is a custom environment, right? And so they don't want to have to make all these, I want to make all those choices for them. But I just always just go these days with an X.js. I just love it. I just think when you've got when you've got the um the React front end and the back end so close that you have APIs and your front end in just different directories in the same tech, that makes it very easy to you know assume correctness and change an API and have you know, rather than doing the ergonomics are very nice too packages, yeah.

SPEAKER_01 33:52

And when you do have to dive into it and do a little bit of debugging or poking about, I just find the ergonomics of that really good. Like I'm not working hard to figure out what went wrong or to find the error to give to the LLM to go fix itself, you know, that sort of stuff.

SPEAKER_00 34:05

Just yeah, absolutely. But honestly, that's nice. That's what's that was my go-to before. Had I just said put in old in Python, I think that'd be fine as well. You know what I mean? And like would not notice the difference. That's not that is not the limiting factor. It's users and it's architecture, right? Do you understand your users and your business and what's going to be there? Because you know, you can now run 50 experiments in you know in a week. Which experiments are you gonna run? That's the harder question to me. Make your company successful. Absolutely. The equation has changed. Get used to it.

SPEAKER_01 34:39

Thank you so much, Simon, for coming on. I'll let you get back to your various cues of work that are no doubt waiting like chiclets waiting for the mother to come back in the room.

SPEAKER_00 34:48

Simon, give me a chance. I'm just gonna be I'm just gonna review PRs from my agents right now. So, like the longer here, the better, you know. Thank you, Simon. Lovely to lovely to chat with you.

SPEAKER_01 34:57

Fantastic. And thanks everyone for listening. Please share your feedback when you can. And until next time, with all the AI you can, keep on building.