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.
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.
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.
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.