Tech Founder Decisions and Challenges with Malcolm Matalka

Hi everyone. My name is Patrick Akio. How does it feel to be responsible for customer conversations, delivering features, support and everything that is technical? Explaining all of that and more is my friend Malcolm Matalka. But before we get into that, we talk about how he sold his house and bought a new house, one that sails. He's living on a boat. Enjoy. Where do you dock?

Because I was wondering that when you told me like you live on a boat. Yeah. So it like everything in the software world and the boat world, it depends mostly. So when I'm on the boat, I mostly try to anchor. So you go into a Bay, find a nice Bay, put your anchor down because for most places that's free. So that's pretty nice. There are some places where they'll charge you to anchor and there's sort of three layers. There's so anchoring is sort of

your cheapest and most common. And then you can get a mooring ball, which is basically someone has anchored a ball out in a Bay somewhere and then you tie ropes around it. OK. So and that actually generally costs money. It's usually kind of cheap. Depends on where you are. It costs money. And I've actually one thing I've learned is a bit of a side tangent here, but one thing I've learned is anchoring is not environmentally free. OK, what do you?

Mean. So for example, if you go to a place with a a lot of boats Anchor, and you go down, you'll see it's all sand on the bottom. And if you go to that same area where boats aren't anchoring, you'll see it's grass. So seagrass and Anchor is ripping up the seagrass and there's animals that eat that seagrass. For example, turtles are a big one.

So there's a place called Tobago Keys that is known for its turtles and they don't allow any anchoring except for one very small part and they charge you to anchor as well. It's not free. They try to get you to take a ball because a ball, it doesn't move. So an anchor, you're, you're moving across the ground a little bit. You put your anchor down and then you have to set it, which means you Rev hard back on your motor and then the anchor drags a little bit until it catches

and then holds on tight. Yeah, and you're ripping up the whole ground when you're doing that. Whereas a ball, it's just there, it's attached like a massive block of concrete, something like that. So it doesn't move. And that's much better for the environment, although people don't like it because it's there's only so many balls in a place. And it costs money. Yeah. And then the layer after that is docking at like a Marina,

something like that. I generally only dock if I have to. And by have to it would be maybe I'm doing boat work or right now I have left my boat in the Caribbean while I'm here. Yeah. So I've set up in a dock and then I pay someone to go look at it and the fees for docking. I think in where I am it's something like 5 to €600 a month. OK, so it's not terrible. Yeah, it's not bad. Yeah. Yeah.

Last year friends of mine were like, we're going to buy a boat. You won, you won in. And I was like, man, all the stories online told me never to buy a boat. So I was like, no, I won't buy, but I'll, I'll have a big sale with you. So then they got together, a group of three, yeah, three people. They bought the boat like second hand, like you do, and they they've been sailing in Amsterdam like the canals and stuff, only in summer. And it's been really nice.

It's just, yeah, out of the three people, one person never, actually never actually used it. And then the other two people are just arguing what needs to happen with the boat. And one person obviously doesn't want to put in as much work as the other person. So I I've just been enjoying it from the sidelines instead of having a skin in the game.

Well, that's exact reason that when I decided to do the boat, I was like, I'm gonna sell my house and do 100% on the boat. Because I knew if I had a house and the boat required work on weekends, I'd be like, well, I could go to the boat or just hang out at home and do other stuff. I was like, no, I have to, like, make it a hard requirement to live in my life that I have to do this work. Yeah, well, I mean, I can see it really helping, but that was a

huge step. Like, did you always work up to doing this or was it? How much of A whim was it? It was, I would say like a multi year whim. I had joked in the past about living on a boat but I never actually thought it was something you could do. Was sort of like, hey, let's I remember talking to friends like, hey, let's start a software consultancy and then like go attack pirates or something like that. Combine it, yeah. That sounds like fun, but it was

just a joke, you know? And then like a lot of people during COVID, I got pulled into YouTube and YouTube figured out what sort of stuff I liked. And there's just this huge world of YouTube boaters out there. And I was like, wow, you can do this. This is cool. And then especially during COVID, you're sort of like, I'm stuck at home and I could be doing this. And so during that I was like, all right, I'm gonna set a three-year plan for when I sell everything and buy the boat.

The buying the boat thing was kind of hard, 'cause it really depends on the market and what's available and if it's what you want. And especially during COVID, the boat market went crazy high. Everyone bought a boat, 'cause they couldn't go travelling. So they're like, oh, I'll just buy a boat and go on my own. It's like a loophole, yeah. Yeah, exactly. So I got kind of lucky and that it worked out where I found the boat I actually really wanted

within that time frame. So roughly in the three-year time I'd executed on it and I was on my way to Martinique. Wow, that is. I mean, it's a purchase that you're not going to do often in your life, and especially in a time like COVID. As a first time buyer, that must have been very stressful, no? Yeah, And to be honest, I didn't really know how to sail that well or anything like that. Like, I'd taken some classes, but no, I wasn't like a pro. I'm not. I haven't been sailing my whole

life. And this is the next step. It was just sort of like, this seems fun. I'd sailed a few times and really enjoyed it. And I always liked the water. And I was like, I'm just going to do it like I don't have. I didn't have like kids or a wife or anything like that. So if I didn't like it, I could always just go back to living on land, you know? Yeah, yeah, but I mean, it's such a for me, coming back home,

home is a safe space, right? And if I have a work at the office like this or even a busier 1 where I don't do a podcast, let's say I get home and everything is relaxed. I know where everything is. I know where the supermarket is, where to get food and do my stuff and really wind down. And I can imagine when you like flip that upside down and all of a sudden it's not a, it's not a home on land anymore, but it's a home on the seas or on water rather it's different.

Like, did you take time off to accommodate for that or how did you manage that with what you were doing on a day-to-day anyway? No, I just sort of went head first in really. But it is, it is different. So being back here, so I'm visiting Amsterdam for a few months just to hang out with friends and relax and be on land and it is more relaxing. It's relaxing on a boat. You're still sort of like, all right, well is the weather gonna change tonight? Because I might have to move the

boat. Is this a good place that I put my anchor down because I could drag into the boat behind me? And then when other boats come in, you're always sort of like, well, are they too close to me? Like, do I feel comfortable with them? Do they seem like they know what they're doing? So there's always this thing going on in your mind of like, what's happening. You're being alert all the time and here you can really just sort of relax and you're relaxed.

Let go of it, yeah. But I say that, but at the same time, it is really pleasant being on the boat. You're like, all right, well, I don't like my neighbor, so I'm gonna go move and I'm still in my house. Yeah, exactly. That's I've thought about it because I I live and I overlook the the Amstal Canal. So then I see like first of all these houseboats and then second of all when it's summer I only see boats.

It's like so I I do see kind of the how do you say that the beauty of it. But then to live on it would be like even extra for. Me. Yeah, because also I like, I like my space and even though I live in Amsterdam, I don't have that much space. But it's more than what I would have, I think, yeah.

There's also an an unfortunate dynamic too where there's people like me who are doing this because we enjoy first of all sailing, but then also visiting places, going around and then when we visit some place, you know we we're tourists there for at least some amount of time. So we're spending money and location and all that. But there's other people that just live on boats because they're very cheap and they don't have to pay property taxes or anything like that.

And their boats tend to sort of look like garbage over time, to be honest. And I like personally, I think they make the harbor look unpleasant. And I don't like those boats, and the locals don't like those boats either. But they don't see the difference between someone like me and someone like that person who are coming in. And we have like we take care of our stuff and we try to contribute what we can there. Yeah, they see it as all the same. Exactly. That's kind of that's hard.

Yeah. Or they don't know how to like, filter out which of us is actually going to be there and make it hard for one or the other. Yeah, I've wondered how like I think definitely during COVID people are thinking about like I've seen camper vans where people drive around and and do that on land basically the same sleep out of the vans. Or people that have started thinking about just getting a tiny home somewhere on the side, very small, live, very minimalistic and it was always

there. Like I've always gone down my fair share of YouTube rabbit holes as well. But I think especially now since since COVID, it's a bit more apparent and people are actually actively taking that step. Yeah, yeah, yeah, yeah, I think so. I think you know COVID changed people in a lot of ways. Yeah, yeah. For. Sure, positive and negative, but yeah. Yeah. And then when you when you made

this purchase and acquired the boat, was that also when you were working with Terra team or how was that period leading up to that? That was so the initial plan was established when I was doing work for my other company, which is consulting, yeah. And then the final execution was during Terra team. OK. And that was, I think that helped because going into Terra team I'd I decided to do that 100% with with my Co founder and I had to quit my source of income to make that happen.

And I was like, well, I'm also going to make a big purchase that's going to cost a lot of money. So I had to. So the initial thing I'm going to quit my job and focus on this sort of I think set me up to be able to be more successful at taking on a next really big thing. I felt like, all right well, this went OK we're still, we're going, we're improving everyday

or you know all that. And when it was all right, time to pull the trigger on this, I was like, all right, well, I did the last thing and nothing bad happened, so. That's fun, Yeah. What's the next thing? Yeah, exactly. Can you can you elaborate on what Terra team does and what it is in the first place?

Yep, so Terra team is what's called a tacos, which is AI. Don't even know what TACOS means? Terraform, Something Collaboration software and the acronym doesn't matter. But what's meaningful is that we are like a number of other solutions out there. A service that lets you take your Terraform and Open TOFU code and test it and deploy it so that you can make your changes to your infrastructure. What sets Tera Team apart is that we are very focused on just a GitHub experience, OK?

And we try to make it so your entire experience is inside of GitHub. So while we do have a UI, our goal was that all of the normal operations you do, you shouldn't have to leave GitHub to do them. So you see your plan output in a pull request, you can replan in a pull request. You configure Tera Team entirely within your repository, so it's just a YAML file that's in there that we read and you can apply

within the pull request as well. And we do have a UI which you can go and look at other things, but you never have to. Yeah, I know Terraform infrastructures code cloud

agnostic. You can set up a lot of stuff with it. I've used it as well. What is Open Tofu? Open Tofu is a fork of Terraform. Yeah. So on August 10th, Hashi Corp announced a license change which effectively said that if you compete with a Hash E Corp product, you're not allowed to anymore with the versions going

forward from the license change. And as a response, a number of companies, all of us competitors got together and said in particular, we think Terraform is too important to the infrastructure of the Internet at this point. Lots of people use it to manage their cloud resources that it really shouldn't be controlled by 1 vendor.

So we forked it and it's called Open Tofu and it's actually part of the Linux Foundation. OK, so what's really nice there is the license change for Terraform made it from an open source license to a closed source license. Yeah, and part being part of the Linux Foundation means you have to be open source your entire lifetime in the Linux Foundation. Yeah. And it also means it's more community driven.

Exactly. And have you seen since that fork, let's say a difference in functionality as well from the two, from the two camps, let's say it's. A little too early because the first stable release of Om Tofu hasn't even come yet. OK, when was this fork? In September, yeah, I believe Wow. And it actually takes, there's a lot of infrastructure involved in running Terraform, like in terms of the providers and the registry and all that. Feel free to have a set all

right, no worries this. Gets cut out right? No, we keep it in. This is all one thing awkward. Yeah, no worries. There's a lot of infrastructure to set up actually and there is a lot of work to make sure. For the first version I want it to be as feature, feature compatible or In Sync with the current most recent Terraform release. And as part of this, you can't actually look at the code anymore, cuz that's under different license and that's not legal.

So you have to sort of look what they did, read the docs, and then try to do it yourself. Yeah, that's challenging. Yeah. Yeah. And you gotta be really precise about it because you can't have just any hint that something nefarious happened. It's really gotta be you did it. So there's a lot of like firewalls in place to make sure developers aren't actually looking at the other code or anything like that. So it's coming. I believe the launch date for

the stable. There is a beta out there, but the stable release is coming in January. That's me, the first stable release. That's gonna be the one that I said feature compatible with the latest version of Terraform, but still an open source license.

Yeah, I I, I didn't mean to go this deep on it, but since you seem quite knowledgeable, what what is the incentive for people to work on then kind of the open tofu version? Because from a Hashico perspective, I get it, there's a company backing it, but with all open source software, there's the challenge of all right, is this community driven? And then who's responsible and who's funding this?

So part of the transition to making open tofu actually involved a number of companies pledging effectively FT ES do it. Yeah. So there's a lot of. I think there's something like in total 15 FT ES devoted to open tofu. That's great. And the origin is really so the

I think there's two things. One is there had been talk for a long time of people thinking that Hashi Corp wasn't being a good steward of Terraform. I I can't speak to their other open source products, but Terraform particular, yeah like there's number of pull requests that are feature complete, they are, they pass all tests and everything and they just sort of languish there so. That's not really fulfilling from the people that created that.

Yeah, and a lot of the features are actually what the community wants, of course, and they're just not happening. So on that, on one side it's the community wants these things and then on the other side it's us as businesses wanna be able to continue running and we can't use later versions of Terraform. So there's a business incentive for us as well to keep that.

Yeah, and that makes sense. Interesting when you were explaining what Terra team is and what it does. I was thinking about previous projects where I ran Terraform and I wasn't mainly responsible for setting up the infrastructure, so I don't know exactly how it ran, but I think we ran a lot in GitHub Actions nowadays. Is that like a a competitor you see or what are your thoughts on

that? We actually build on top GitHub Actions. So we see GitHub Actions as sort of a ephemeral on demand compute. Yeah, and what's really nice about it is it runs inside of your GitHub infrastructure so to speak, So you control what it can see. Yeah, you can even run your own self hosted runners and we don't have to care about that at all. We just say hey GitHub, run this action and then stuff happens and it can gates with our back end for what to do.

So for us it's really nice because you basically get to control where all your secrets are in particular and you can see everything that we've done. So the audit log is right there for you. You can turn us off really easy if you don't like what we're doing. So for us GitHub Actions is is part of the product we build on top of. Yeah, it goes hand in hand. Yeah. Yeah, that's nice. And especially the secrets of being your responsibility.

Yeah, that's nice. Well, so we're we're a smaller company and we have made explicit decisions about what responsibilities we want and what ones we don't want of course. And secrets is one of those ones where we just don't want your secrets. I can imagine. And GitHub is a is fantastic for us in that sense, as we don't have to. Yeah, Yeah. I think especially I mean in in

any software team, right? Depending on your team's size, you would have to think about your total cost of ownership. And the smaller you are, the smaller you want that cost of ownership to, because otherwise it's not manageable in in offering a quality level of support. Yeah, Yeah. And I think that's kind of a a meaningful difference when compared to, for example, when I've worked at larger companies where you don't necessarily have to take a holistic view. That depends on where an

organization you are, of course. But really for a large organization, just everything's so big, you can't take a holistic view. It's just not feasible. Whereas for something like what we're doing, we have to sit back and say, all right, like we are a niche solution. We really think that there is a market for people who just want to never leave GitHub. They don't have to, but it's still a small one and we're OK with that 'cause we want to be a

small company. We don't want to be a billion dollar company or anything like that. And because we are smaller, we can look back and we have to look back and see what a the holistic view is and what and that affects the vision of the product and then the architecture of it and then all the way down to it like languages or frameworks we choose and then what experience we end up giving the customer at the end of the day. Yeah, I I wanna dive deep on that.

But before I do, I was wondering, I mean you were you

said you had your own consultancy company before that you worked at other companies big and small. When did this idea pop up that this could be kind of a stand alone company and you could build a product around this? I would say so when I was doing the consulting work, that was by myself. And so my Co founder Josh and I, we've been friends for decades. Yeah. And we'd both sort of seen similar trends and similar

ideas. And we had also wanted, we both kind of viewed as, you know, it'd be nice to have a company where we can again not be billionaires, but just you know, make a decent salary and give a service that we really believe in and think people want. And just over some time when I was, we were sort of both sort of like, well, you know, this consulting thing's OK, but it you really can only make as much as the number of hours that you work.

There's no passive element of it, no. And it would be really great to sort of make something. And as it scales, it doesn't take more hours all the time. You still have your normal work day. Yep. And then we started the idea of like let's make a company and then we started looking around what the options were. And he has used something called Atlantis more, which is a it's a similar tool but it's open source and free. And he was just like, I think we can do better than this Atlantis.

It does great for what it is and all that. But we thought, if we focus on a particular aspect of this and Atlantis supports Bitbucket, GitHub, all the things. And it has a lot more of coverage. Yeah, on different things that it does, we're like, all right, if we could narrow down something else, then we can make a better UX and we'll see what happens. So we started that. We built it over the course of a year or so. Yeah. And then we got it to the point both of us working at the same

time. Just Josh and you, yeah. OK. And then we released it, and some people signed up. Nice. Yeah. And but this, you said a year and a half of development work. Before about a year, yeah. About a year how? Because I think that would be, I'd be nervous throughout this period, right, because you're

building up towards something. Did you do any market research with regards to is this a good product, market fit or just because of what was established when looking at competitors you're already quite confident in what you're building? I would say we didn't really know what we were doing at all. I love the honesty, yeah. And we were thinking, you know, this is something we would use. Yeah, let's see what happens.

Yeah, you're the customer. Yeah, we originally actually started by trying to do a hosted Atlantis and we built some stuff where it would basically spin up an Atlantis on the fly for you. When a request came in it was still on top of GitHub and all that spin up on the fly, run it and then tear it down but then save all the state. And we did get some people using it but we found we didn't have, we couldn't really get the UX that we actually wanted out of that.

And it was there's a lot of complicated code to make sure you split up the right Atlantis and it went there and we had to like route it to the correct place and and all this sort of stuff to manage machines to manage and all that. And that's when we stood back and said all right well we have the basic idea. We have a few people that at least installed it and said like, all right, well it seems OK. So if we can just make something better, probably more people will.

That's nice. Yeah. I mean that's the sometimes that's the little bit of research you need, right? Yeah. Yeah. We did know that there's a market out there like there's Spacelift, Scaler and 0, all these. So there's clearly something to this. Yeah, you just need the right fit then. Yeah.

Yeah. How was it working with Josh? Is he a software engineer as well? He his background is more on the OPS side. Yeah, he can definitely program, but more of spending time in the OPS. And I'd say it's great. Like, we're very close friends. Like I said, we know each other for a long time. Yeah, we just get along really well. Like, we never, we never like have arguments about things. There's no like ego or anything like that. We're both good.

We're both sort of like, is this not a good idea? Like sure. That seems like the best mindset because I've also read don't don't get in business with your friends because you might not be friends at the end of this. Yeah, but you haven't had any, any challenges like that? No, not at all. That's great at all. Yeah. And he has, I would say he's definitely grown a lot more than me into his role.

So he's been taking on more of the sales and marketing side and I've been more focused on just what I'm more comfortable with the software development. So he's definitely been better than me at going outside his comfort zone. Yeah, and doing new things and we have customers. So I think he's doing a great job. Yeah, absolutely. And you're still a two man team, Like there's no idea of expanding that?

I think we definitely will. At some point we'll have to because one of the things we really value is giving really good high quality support. And as we grow in our customer base, it's going to take more and more time to do that. So we're going to have to take someone on eventually, train them up, probably get them. We'll see if it's like sort of a coder position. And then because you kind of have to know the system to be able to give that great support.

Of course, we're definitely not against expanding or getting more employees, but we don't want to be a huge organization. Like I said, like we're really focused on, let's give something that this, this particular market really likes and we just have a good life. Yeah, yeah.

When I when I talked to you before, the support aspect you mentioned there as well, you highlighted it. Good quality support and I think that that's what works best for getting dedicated, reliable customers as well on both ends. That's how you create partnerships. But the fact that you're with two people that that can be quite challenging, right? Because as your customer base scales, you wanna deliver the best support for all customers.

Yep. And when a few people have a problem at the same time, then you're just limited with the amount of hands you have. Yeah, we. I don't know if we're just lucky right now, but I would say for the most part, once a customer gets going, they're kinda good. That's good. Yeah. That says a lot about the reliability. Yeah, We try to focus really heavily on having a keep the code base very simple, keep what it does very simple.

So we really haven't had many bugs and again, maybe lucky, but the bugs we have run into that actually impact customers have been solvable in like a day. That's good. Yeah, yeah. I was wondering because you you

mentioned kind of starting this up together with Josh, right? Even the, the blueprint of what it is now, probably you, you imagined it together with the two of you and you built it from scratch and you now have the continuation plus the consequences of those decisions, right.

Whenever I come into an organization, I mean, see there's a consultancy, so I come in at the very start and we have the ideation and we deliver something and then usually it goes to a company internal or a handover to whoever needs to maintain it. Or I come in and there's already something existing and I have to make it better or shift

something. I don't see kind of the full trajectory of making those decisions and then following and seeing through how it takes into effect as well as being kind of 50% responsible of this whole thing. How, how was that kind of responsibility wise? Were you? Were you comfortable in making those decisions when it comes to the technology and the choices there? Yes, definitely.

In previous roles I've had, I've usually been in sort of a tech leadership position, so I sort of have a view on roughly what I think software should look like. And for most situations, I may not know exactly what the right thing is, but at least have a direction on how I think it should probably be solved.

So I have sort of a high level mental model of how things should work and how software development should work, and I feel like I've had enough experience, but I understand at a high level what the consequences are and what the aspects of it to to be careful about to avoid certain risks versus just going all in on certain decisions. So for for example, we as I've said multiple times, we have this vision of being not having a a huge user base, smaller

company. And so we're perfectly fine with a a pretty standard solution of like a sequel database, in our case Postgres, with a bunch of services in front of it all hitting the same database. We're not going to try to do a million requests per second, so we don't have to go crazy on that sort of architecture. So we're like, OK, well that's just solved for us. And we have taken a perhaps

unorthodox view or not view choice of our Our entire back end is written in Ocaml, which is not a very mainstream language, but I chose it because one I feel very comfortable solving problems in it. I feel like if you gave me something where I couldn't find a library, I could probably write a library that solves the problem that we have in short order. OK.

And it's very powerful language. And also I just enjoy reading it. So I know if I come across a problem that's maybe a bit dull, I'm like, all right, well, I enjoy writing this language. So it's it's gonna be fun. I'll get it done. Yeah. Yeah, exactly. And I do think that that's there is a lot of discussion around, oh, you should use this language because of this, that language because of that.

And I think really the differences between languages are a lot smaller than people like to imagine. And I say this as someone who's advocated for certain languages throughout my career and now I look back and be like. Probably. Probably wasn't the right decision to really advocate that hard for that because it doesn't matter that much. Which one was that in the past? Oh, I mean, I've gone from like from Python to I worked for an Erlang for a really long time now, an Ocaml, and I've done

like Ruby and all those. But really I was like a a Python guy for a while. And then I sort of moved on to Ocaml. And you know, you can solve all these problems in those languages. And I think, yes, there are technical reasons to choose one language over the other. But at the end of the day, whether or not people actually will sit down and write it and enjoy it, yeah, is probably going to trump any factor on the

technical ones. I think that's it's becoming an increasingly bigger and bigger factor. I like Go, I love writing in Go. It's the first kind of production code back end language I wrote. I did Python in University 2.7 and I loved it also and that was kind of the first experience. And then I did Go and all of a sudden I had types I needed to consider and take care of and put in place and I I grew up with that and I still really enjoy writing that language. I've written a lot in Node.

I stay away from Java and anything JVM related just because I don't want to get into. I feel like the depth of knowledge I need to be successful is like is like a lot deeper and I need to catch up. So I stay away from those. But I enjoy writing in Go and preferably, if I would have the choice, I would, I would use the same language. Yeah, maybe it's because of kind of I might be a different software engineer. I don't really love the technical, technical side.

I want to use the language to solve the problems and deliver value. And I do see a trend where people are more like that, and I think that might be better as well. But we also need people that love the technical side when it comes to not having a library and being able to figure that out as well. You also need that. Yeah, yeah. And like. So you look at a problem and

your mind thinks and go and like, oh, this is gonna be fun if I do it this way, whereas I look at a problem like, oh, how can I solve this in Ocaml? Because there's a whole different approach to how you might solve problems in these different languages. Ocaml.

For those who don't know, it's a statically typed language, kind of, kind of. It's sort of similar to maybe a Haskell. OK, but it's more practical, I'll say, in that Haskell is a pure functional language and O Camel allows you to have mutations wherever it makes sense. As API writers we try to make those mutations not pass a certain API boundary, but still

you want to get stuff done. Sometimes you have to do that, and that's perfectly fine and sort of the ethos of O Camel, but you take a very type heavy approach to how you solve

problems. So an example of that is I today actually I'm working on a little web end point where if you want to have a like if you have like an HP request that initiates a task that might take longer than the request would live, let's say a few minutes, maybe hours, who knows you want to get back an ID to something and then pull every now and then being like, hey, is it done or whatever mechanism.

But you need some detachment of here's the request I did and then I need to go ask if it's finished in some way and the way and OK, well person might approach that is I have a task and in the type I store whether it has been saved to the database yet or not. So you create it and then you might do some preparation work where you do it, but then you wanna save it to the database before you actually give it back to a user. So I have sorted the type, whether it's been saved to a database.

And then I know before I get back to the user that that piece of code that gives it back to the user only takes one with the storage type. And in maybe like a language like Go, you wouldn't do that. You would just be like, well, just do the right thing and you're OK And then for for OK old people, it's like, all right, no, we wanna like, do we have the ability, It's cheap. Yeah, let's do it in the types. It makes sense that way. Yeah, very interesting.

Another example is just real quick is we have before we actually kick off a terraformer open tofu run. Yeah, we go through this whole state machine of operations to determine if it's OK and one of those is. So it's like an RBAC check. Like is this user able to do this operation on all the directories that they need to be

able to do it on? And so we have it so that before the code that actually initiates the Terraform operation takes a value of a type that guarantees it's gone through the security check. So if we re factor that code where somehow we forgot to do the security check, well the only way to get a value of that type out is to do the security check. So your code won't compile until you fix the code to do that. Interesting.

Yeah, I think that's it's a smart way of doing it, and it's probably because Ocaml supports it that you can. So then you do. Yeah, and it makes a lot of sense in that way. In Go you wouldn't have that, it would be either the same type, and you would have to make sure your validation happens. I mean, you can do it, but then you have to move everything to a specific type for that. So it is possible. Yeah, and it's also kind of how

you think about things too. Like, again, the the marginal improvement here is it's like, well, you would go and testing and realize you didn't do the security check. It's no big deal. So but it's how I think about the problem and it's how I enjoy solving the problem. So I'm more likely to do it 'cause I I had this ability where for me trying to do that and go, I'd be like, why can't I encode this in the type? This is so frustrating. Yeah, I've heard that before from other labs.

Yeah. For me, it's funny that you said when you envision the architecture, you have let's say multiple processes talk, talking to the same interfacing with the same database in that way. You already said, well, we don't envision this going to that scale. So these are the decisions based on that. And usually what I see is the opposite. We envision this going to and then we have the decisions based on that. And I'm like, but we're not

there yet. And I think because you made those decisions, you're really leveraging speed and removing a lot of complexity that building for that skill would offer otherwise would require otherwise. Yeah, I do think it's important to always have what I'll call escape hatches where you make your decision. But you do have this out in case something happens where you end up being wrong. And that could be that you've

designed the for example. The API to your database doesn't really depend on only talking to one database or something like that. It just so happens that it does, because that's all you need. But if you do have to scale up databases, the code has to change very little to support that. So it's always good to have escape hatches, I think. Yeah, yeah, I agree with that.

It's the, it's the. And I think this is really hard from theory, because I think a lot of practical experience will teach you where to build in the escape hatches where you need them. Yeah, and you might actually use them. Whereas you could also say, well, escape hatches everywhere, just in case we need them. Yeah, and you don't want, you don't want that in because then people are gonna be like, what's happening over here. Yeah, yeah, yeah. That's the harder part.

And it is. Sometimes you gotta sit back and just realise, wow, computers are really fast. Yeah, yeah, like a lot of the scaling problems you have, it's like, no, they're they're really fast. Self solving sometimes. I I don't know about. Yeah, this blog post must be like 10 years old or something like that. But basically it was when Hadoop was the rage. Yeah. And this person is a blog post. Yeah, pretty sure is.

A blog post basically took like a a problem their company was using to solve Hadoop and it solved with Hadoop and it took however many hours. And they're like I rewrote this with like a Python program on my laptop and it ran in like 20 minutes. Yeah, And their point was basically the scale is just ridiculous and actually it's hurting you because all the serialization Hadoop was doing and all the cluster management, all that was just making

everything so much slower. Yeah, where if you just solved it on your laptop, you actually would have gotten to the answer a lot faster. Yeah, it's all overhead. Yeah. Yeah, that's that's rough. And certainly there's data sizes where Hadoop does make sense or those sort of things make sense. But maybe check to see if you can do it with like a Python script in your laptop first.

Yeah, I think the, I mean the more offerings we get, the less people understand kind of the depth of technology or what it is really good at in which context. I think the more people will use technology let's say in the wrong way for their context or there might be different offerings and then you get into either time issues or just scaling issues or issues in complexity in general.

And I I don't see that problem solving itself in the future because there's more rather than optimizing what we have.

You would probably be exposed to this a lot more than me, but how are you seeing all the AI stuff impact that? Cuz I can see someone's just like hey solve this problem for me and they get out some code and they paste it into their editor or whatever and then they hit save and they move on with their day and maybe that code was a really bad choice or something, I don't know. Yeah, I haven't. I haven't experienced that as much. Like I've been leveraging where I think it's really good.

I know where it's more productive than I am and then incorporating that kind of in my way of working. But I have talked to a lot of people that are fearful of that

and me myself, I don't. I don't really see how we can cross this knowledge gap because a lot of people that are less experienced are going to use it. They're going to learn a lot from it, but they're also going to have knowledge gaps because of it. And then when they have to do something on their own, they might not be as fast and they might not understand why they're not as fast, but it's because of foundational like set of knowledge might be missing

there. And then for the experienced people, you can see what is right and what is wrong, right, at least based on gut intuition, practical experience, just by virtue of having more years, you might see more in that way. And with people that don't have that and that grow up, let's say leveraging generative AI in that way. I don't see how we cross that knowledge gap. That's for me, very hard. Do you have a sense of what the debug situation looks like after, I don't know, like a

generation of AI generated code? To a certain degree, like with our own, we've played around and innovative with our own large language models. And in there you can also incorporate, let's say if I if I do a text to solve a certain problem, I can ask where did you get that reference from and it can actually pinpoint where it's these and these documents and this combined gives this output. So in that way it is there. But that's on a smaller scale. LLM yeah, right.

Right Now with the models that we have and the ones that we're using that are from other companies established, I think it's really complex to get to the actual source of where I got that information. Yeah, I'm not sure if that's possible. I just have like this comedy slash horror movie idea in my head of some like service company having like a bug that all that user reporting everyone being like I don't know how to fix it like when I type in do this to the AII get the same code back.

Yeah, yeah. But it's it's really helpful. Like I had to do some low level stuff, I mean an IoT project right now and I really had to do some low level stuff and I was like, well, I've never done this before. How do I do this and spit something out? I'm like, well that's wrong. Try again. And eventually I I got to something right.

And then with the colleague we refined it and that's now like the output that we use and we use the most basic examples to at least like get the theory behind it and get the understanding rather than just copy pasting. But yeah, in in that way people can copy, paste or use it to actually gain knowledge it it really depends on the user. Yeah. And you know how every generation's like, oh, with the radio, kids aren't going to read or whatever, and then TV kids aren't going to read.

I sort of think some of the criticisms of the AI code Gen. are the same things that people have about Stack Overflow, Right. You just go and you copy and paste Stack Overflow and you know that that is a problem. I've been at places where code's been committed and you're like, do you even know what this does? No. It's like, well, it shows because it doesn't actually solve the problem. Yeah. And I've also seen stuff where like I I recognize this and this is exactly the right thing to do.

Yeah, yeah, absolutely. I'm in the camp of definitely embrace it, figure out where it works best, use it, leverage it. Because I don't think, I think if you don't do that then it's going to fly by and and let's say your competitors are going to overtake you and that's a past that's a bad position to be

in. Yeah. Yeah. Do you use? Do you use it actively? No, I am definitely a a laggard when it comes to different ways of coding. I'm very comfortable with what I have, and maybe I'm going to be like the get off my lawn guy in 10 years, but I feel like I don't feel like, I guess I feel like we spent a lot of time trying to make sure we're making the right decisions and the actual coding part is not so big on what we're working on.

Yeah. So I don't feel the strong compulsion of actually generating the code is reducing A bottleneck anywhere. Yeah. And maybe again, maybe that's just me being like an older developer and not seeing the value there. I think I would probably use it more and more of an exploratory way of, hey, I've got a new APII haven't used before, let's just

learn about it through this. And maybe when I write the production code I would actually do it by hand, but I would explore it through something like this. Yeah, I think I I agree with you that the the programming part actually doing the doing the what it needs to do is less and less because you're mostly spending your time on. First of all the bigger the team, the more aligning the people and getting the same mental model.

But also understanding why we're doing this in the 1st place because usually you have multiple options and then figuring out which option to pick sometimes depending on team size takes longer than actually implementing them. Like I've been in discussions where we were like well if we if we built all AB and C we probably would have been done, but we're still discussing which one we need to pick in that way. So with that being said, I do think the, the productivity part

of it might be lower and lower. It also depends on the project. If it's, if it's clear cut, what needs to be built and a lot needs to be built, then you can start building and this will probably be a productivity booster if you use it in the right way. But as kind of the domain gets more complex, it's usually, yeah, which one of these do we build? Yeah.

And which one is the right one? Yeah, to go back to having a look at things holistically, it's a lot more than write this function for me. It's where are we going, where we want to go, what's, what's the risks we're trying to avoid and what does the customer need? Yeah, I did this exercise with my team. As soon as we get there, then we're in trouble, Yeah, cuz then we're like, well, does it all and it builds it. Yeah, yeah, that's the hard. Just AI's writing code for other AI's.

Yeah, yeah, self improving introspection.

When we talk about productivity, you're in a two man team. So I was thinking, if you're not productive, then the product is not progressing in that way. Does that rest on your shoulders quite heavily, or how do you take into consideration your own

productivity? Yes, it does in the sense of that translates, and this might be more of a founder thing rather than specifically a software dev thing, but because it translates more directly into how much revenue we're gonna get, you know, so if we have a customer that wants something and then they'll start paying us for that, well, if I'm slow on that, that delays the time until we start getting that revenue. Yeah. So in that sense it does.

But at the same time, I think you just, you just have to cope with these things and anything that's gonna weigh you down too much, your mind just sort of figures out a way to be like it's OK. It's it's funny that you say that because I think that having been in a let's say larger organization, I think that's always the case that a customer's willing to pay for it. So then a dev team starts working, just the timeline is is so stretched out and then still people are waiting for it and it

takes maybe months to build. But with you it's, it's very touch and go like something needs this. I can build this. The longer I build, the less. Yeah, yeah. And you're much, you're much closer to it and in in the sense that you are connected to it in terms of you know I talk to the customer and I also build what

they want and Josh does as well. And so in in at least larger companies you might have a customer say this, but then you maybe you have like a product owner or something between you and the customer. So you always have this little firewall of like, well, I don't really know the person or I didn't really talk to the customer and some places do it differently, but a lot of times the devs aren't actually talking

directly. And then for larger companies you just have sort of recurring revenue. So it's not like your next month is really dependent on what you do 'cause you sort of, you know, one reason which is totally valid to work at a larger company is stability and a start up. One reason not to work there is the lack of stability and that's perfectly OK. But it also is a sense of urgency, a different sense of urgency. Yeah, yeah, I can.

I can imagine that. I enjoy the sense of urgency, yeah, But then also I enjoyed the stability, so you have to pick. Well, you can have them both too, right? Like there's nothing saying if you're working at a stable company, you can't feel a sense of urgency. But if you are the CEO of a large stable company, you probably have to expect a lot of your employees are not going to feel the same sense of urgency that you personally have. Yeah, I get that as a as one of

my final thoughts, you mentioned in a larger company or in in different organizations, software engineers not talking to the end user or the customer in that way. Do you think that's harmful, or what are your thoughts on that? Having been like now you're probably one-on-one on the same table talking to them, probably virtually, but still. It depends. Of course it depends.

Some people are where they are at A at a company because that's how they feel good and they feel happy and they may not want to talk to a customer and they're still going to deliver everything just fine and there's nothing wrong with that. I think I've worked some places where it was really like, oh, everyone's got to be doing. Everyone used to feel like a product owner and and that just didn't.

In my experience. It worked really good for some people and it didn't work that great for other people and

people didn't work great for. It just sort of felt crummy at the end of the day because they didn't feel like they were not like, not like living up to it. But they they just felt like there was this pressure put on them for something that that's not what they wanted to do. They wanted to, they wanted to solve problems with code and they were perfectly happy with that and they were great at it. So I think I think they're probably 1 Downside to at least my experience in doing in large

organizations is people get sort of roles in labels and that's like what you're supposed to do. And it's much harder to be like, well, I'm a dev, but I actually really enjoy doing these customer things as well. I don't want to be closer to that and maybe that means I'm programming less but we need to find a spot for that. And then the person that's like, I just enjoy dev feed me the requirements. I'm happy to do them. I'll bang them out all day long.

Just that's what I want to be and it instead we get like a lot of silos and people get defined by whatever their their title is rather than what they enjoy doing. Yeah, that's hard. Yeah, I I was always in the camp that I think the product will be better if more people understand the customer. So then I I very black and white would say, I think everyone should understand the customer.

But as you, as you lay it out, I do understand that people don't get energy out of that and that people are very, very capable of delivering feature after feature, maybe even better than the people that understand the customer. So we have to find a way to be flexible and still get the best of both ways. Yeah, because that gets the end, the best end result in that way. Yeah, yeah. I think, and this is somewhat on a a tangent, but a different

something I experienced a lot in large organizations was rather than trying to find where someone was the best fit, they'd hire them for a role and if it didn't work out, let them go. And I think that's a shame, 'cause I think a lot of times people are doing what they think they might be good at, but maybe they're not and they should be able to find.

And an organization is actually really, it's really empowered and has the ability to understand what their employees want and like and are good at. Yeah, because they've seen so many of them, you know? So I think it's it's always a shame when I would see people get let go and it's like, you know, I think if you just let them do this job they would probably actually have really excelled at it.

Yeah, yeah, I fully agree. It's, and I think it's my preferred way, but it's really hard to do that. Yeah, the capability needs to be there for them to do that and have like split responsibilities and people have full ownership of those responsibilities in different teams. But yeah, that would be the preferred way, right? That an organization is flexible enough to accommodate for what

people want. And if you have a group of diverse people, you also need to have diversity in the work that they do. Yeah, absolutely. Yeah, that's. It's tough, yeah, that that flexibility 'cause I think as organisations get larger they get more regimented in how they do things. Partly because if you're if you're the the farther you are away at the like, the higher up the the ladder you are.

It becomes hard to understand what people are doing unless you have some sort of mental framework for what their job is and what they should be doing. And if you have all this dynamicism, then it's probably much harder if you understand, like, is my company doing good, is it not? I don't know. Do like, do we need to hire for this role? It's like, well, it's a it's a fluid role. Yes. You trust on a lot of people. Yeah.

I think it just becomes complex if you have more and more people within this amalgamation that we call an organization, things just happen either organically, automatically. Sometimes it doesn't make sense, sometimes it does. And it's fun being part of it and learning from it. Yeah, sometimes it's not fun being in the trenches, but you would still do it. Yeah yeah, I for someone like me I really do enjoy the smaller org. I really like the self direction.

So for me that's always important. I I would get frustrated when I was an employee at larger orgs where I like, I really wanna think it's this is the right way to do it. And even if everyone around you agrees, you might have to do a little bit of political game playing to make it happen. Yeah. And I and I like. I'm just not. You don't wanna? I'm not. Good at it. I don't enjoy it.

It's time and patience, yeah. I enjoy just having a conversation with someone and saying yes or no and and doing. It doing it. Yeah. So at a smaller org you can do that. And I think some people are really good at it. And and I don't, I don't wanna say it's like, that's like the political thing isn't like a negative thing. Because at a larger organization, like getting people on board with your idea is really important and it is a valuable skill. And there are roadblocks along

the way, for good reason. Yeah, it's a challenge and people thrive in it. Yeah, it's not everyone does and not everyone has to. Yeah, yeah, cool, man.

I've, I've really enjoyed this. I must say, that's a lot of fun, fun insights for sure. Yeah, just in general, how your mind works, how you've got to this point, what the challenges are. And thank you for sharing that. This was a blast. Thanks for inviting me, I really enjoyed this. Awesome. Then we'll round it off here. Thank you so much for listening. I'll put all Malcolm socials in the description below, check them out, let them know you came from our show.

And with that being said, thank you for listening. We'll see you on the next. 1. Beyond coding.