Good morning, everyone. Excited for another session of 99 Dev Problems. I keep saying
another and I feel like I need to change my intro because it's like it almost feels like
another is not a good thing when I'm like, yes, another amazing conversation. Super pumped
to chat with Matt this morning. Matt, I would love for you to introduce yourself.
Hi, I'm Matt. So at the moment, I'm the founder of FuelType. This is EdTech for developer
product I'm working on. Before that, I was a CTO at a FinTech firm called Telerium. It
did energy trading. And before even that, I was the CTO of the hedge fund that did high
frequency, medium frequency trading. I've always been interested in programming and computers
and software development since I was 12. I wrote my own operating system when I was
a teenager. I used some of that for my final year project at university. So there's plenty
to dive into today, hopefully. And obviously, had successes and failures along the way,
it'd be great to pick through that and see what we can find.
Yeah, for sure. Okay, you wrote your own operating system. That's like, yes, we all have like
had video game classes or we all had like early programming classes or whatever. But
like your own operating system, we have to dive into that. Why an operating system? And
like, what did you build? Tell me more.
So I think I came in with that engineer mindset, that sense of you can't really understand
something until you really pick it apart and build it. And so I got started with games.
It was nice cloning games like Pong and trying to come up with your own things. That was
in a language called BlitzBasics, so for basic. But what I think I really tried to dive into
was, well, why do things have to be this way? Can we build it a different way and experiment
with that? So I, you can get started with operating systems by writing the bootloader.
So you have to fit a whole ton of stuff into 512 bytes. But once you get to that stage,
you kind of think, okay, well, there's actually a whole bunch of different routes that you
can go. And what I managed to do was just really work on it, you know, try and break
down all of the problems, try to get it to do something cool that I know that a few other
people have done. And of course, if you keep going along that timeline, then yeah, you
can load stuff from the disk and get that going. But you get to a point where I got
like basic USB devices working. That's kind of cool.
That's super cool.
Yeah. And then for my university, finally, a project, I had to write a thesis. I was
a bachelor's. So this was, it wasn't as deep as Master's thesis, but it was still a couple
of pages plus. And what I wanted to do was take one of the ideas from the Linux kernel,
this idea of how do we make networking faster if we want to make a really, really fast network
traffic, one of the things that actually stopped tons and tons of data flow, the unnecessary
steps that we have or ways to reduce the complexity of sending and receiving tons of data. So I
wrote a, I took this, the idea, I put it into my operating system and you could end up sending
like with telnet and all those kind of basic TCP programs. It, wow, would you could send
the data, copy the data and use a space, like set a flag and then the network card with
goods and off the data. That was cool. I remember sitting and coding that for like 30 days straight
writing the thesis in like another 20 days straight. But for me, it was, it was great.
Yeah, it's that kind of purist form of engineering there is you have a good idea. You have a
certain amount of time to do it and just figure out how to make it work. And across the, the
brush that we all go for is, oh, cool, you know, this, all of this stuff together, all
of these hurdles that I've had to overcome. But I've got to this point where, you know,
I can actually go and send this piece of data and of course receive, you know, something
so you could connect to this telnet server and it would give you the first bit of Star
Wars is this sort of ASCII art diagram. It was kind of cool to see that running on something
that you have built from the ground up.
Oh man.
Yeah.
So that is, that is so sinking cool. Like I think there's been a few conversations back
and forth, you know, I've had a variety of different guests on. But I think what's like
really been so near and dear to my heart lately is like having really good conversations about
understanding system architecture, like, like really, truly getting every bit of what you're
building from top all the way down and, you know, bringing in a framework that you actually
deeply understand versus bringing in a framework you're not familiar with. You're like, you
like tell that story so beautifully, right? Like you went all the way down to the root
of building your own system at which then you would build software upon. That's like,
that's the deepest level of meta I think you could possibly get when I pass it on. How
cool is that?
Yeah.
That's really, it's really neat.
It's an approach to things, you know, it's, and I think the supplies outside of stuff
like engineering, can I, should I do stuff because someone else tells me that that's the
right way to go or try to pick apart? Well, how do they get to that thinking? What's the
kind of principles that where they kept in mind while they were doing that? And, you
know, what can I do that if it's a slightly different situation, what kind of principles
can I apply there?
Yeah.
So I found that it's really, you know, writing your own OS is pretty fabulous job, but the
lessons that teaches you, you know, you can't really rely on, you can't lean on anybody
else. You have to sort of figure out things for yourself. And if it breaks, it's going
to be really hard to figure it out, writing quality code. That sort of set me up, I think
for a good early start to my career for sure.
Yeah. Yeah, I agree. Oh man, I bet that was a beautiful, I mean, and also on top of it,
like, probably a really good story to tell in interviews and things too, right? So that,
you know, as you're, you're going into that, I can only imagine, I'll let you speak to
it, but like, I can imagine your sort of first jobs, right? They're like asking about, you
know, projects you did in college and whatever. And when you can speak to this, they're probably
like, okay, here's our guy, you know?
Yeah. And, you know, I spent a couple of months working in Bloomberg for me, the really first
interesting job I had was working in this hedge fund, this high-currency trading firm.
Well, yeah, what's their business? It's reducing the latency of network traffic, you know,
spending orders, receiving market data as much as possible. So it was Kismet, you know, I
was lucky to be in that place and have access to those kind of jobs, but also I had prepared
for it. It was the kind of job that was suited to me because I did all of this beforehand
there too. So yeah, it is a long payoff perhaps, but it really has kind of framed a lot of
things since.
Yeah, gosh, I can imagine. Okay, so I like to ask folks, you know, their education and
you already alluded to it, but if you want to speak to, you know, exactly what maybe
degree you were chasing down, you talked about your thesis, but just curious, you know, what
that education side of things looked like.
Yeah, so the, I went to Imperial College London, did computing there, they have it under the
Faculty of Engineering rather than science. So that sort of shows you the very engineering
mindset background. Most people call it computer science, Imperial is strange in many ways
and certainly in its course naming. I was going to do a masters, but I switched down
to take a job at Bloomberg, realized I didn't like it and sort of navigated that little
curve in my career.
So it's, you know, I really enjoyed my time there. I think it's fortunate with something
like computing computer science. I like the resourcefulness of it. You don't have to have
a lot of, you know, backing. You can turn up on the first day, as long as you're prepared
to read an experiment beforehand, you can make quite a bit of impact. It's the same,
you know, in many other subjects, I'm sure, but in computer science, it definitely feels
like that, that you can actually get a head start and, you know, that allows you to really
dive deep into things, explore other things. And it was a, you know, I really enjoyed that.
It was a good class and people who were passionate about computing. So I felt like I found my
people at university. I was thankful for that.
So honestly, I feel like that, that happens a lot, right? Like when I was a kid, I was
like, I don't know, I like to say I was kind of a freak of nature, but I feel like all
of us are very eccentric and different, right? So like, you know, during my day, I'd be like
ripping apart a VCR and trying to figure out how the VCR is working and then, you know,
ice fishing in another moment and then, you know, working on cars and another. So it's
like, I just had all these very eccentric sort of hobbies. And it was, it was interesting
to me because whenever I would spend time with people who enjoy technology, who enjoyed
coding, who enjoyed any level of taking things apart and understanding how it worked, I just
was like so happy, but I'm like, these people don't like to do the things I like to do.
So like how, how and what do I do here? And I think that's what's, what's so interesting,
right? Is like, when you can find that like engineering side of it and, and be able to
harness that and then meet the people along with it. Like I didn't go to college. It's
just, it's not the way I learn. I'm like, I throw me in the stuff and I'll figure it
out kind of learner. And I think that's a missed opportunity, right? Is like, you know,
having those fellow engineering students who think like, like I would write to sort of
allow you to feel like, Hey, I am normal. It's not weird that I just want to build stuff
and do, you know, techie things. So I love that. I think that's finding your tribe at
every stage of life. I think, I think feels really important as an engineer generally.
True. And I think if you don't have university, then your first job is off to the point where
you go, okay, yeah, I taught myself a lot of things, but here is this person who's been
doing it for 20 years who has, who takes you almost up to another level. It's fine to get
university degree, but it's, it's great theory, but there's so much gap and practice and experience.
And you come out of it thinking on amazing. And within two or three months of your first
job, you think, gosh, there's a lot to learn. So you're sort of traveling up and down that
dumb and cruega curve pretty quickly. If you're new to this field and the best way to do it,
of course, is trying to figure out what you don't know pretty quickly.
Yes, exactly. Yeah, I love that. Finding out what you don't know is, is always the hard
part, I think, because that's the thing, right? Is like, you know, so I have so many thoughts,
I'm trying to culminate them into one thought here. I, so develop, yeah, so developers,
like obviously, as, as we know, we don't have an owner's manual, like a doctor that has
medical licenses and protocols and regulations and things that they do and, and licenses that
they keep up, right? They know if they're a good doctor or not, they've got a scope and
a criteria behind it. So after engineers have nothing, we're just like, one of us is figuring
something out, the next one's ripping it apart and driving opinions towards it and trying
to make it better. And we're just, you know, trying to find our way as we go. And I think
it's, it can be a very isolating, maybe isolating, it's not the right word. It can be a role
at which imposter syndrome can feel very natural and quick, right? And so getting out of college
going into that first role, not realizing you don't know what you're doing can have
a very overwhelming feeling of, I just went to college, I should know what I'm doing,
why do I feel so lost, you know?
Yeah. And it's a very divergent, divergent field. And I think the example that you have
of the doctors side of things, well, they have one convergent goal, which is to make
people, you know, better.
Exactly.
That's, that's all they're measured against. And if they can come up with new ways to do
that, then they're an even better doctor. But for software developers, not only do you
have that symptom imposter syndrome, am I good enough? That's kind of competency. But
it's also that fit. Am I working on something that's actually worth working on? Or am I,
on the other side of things, am I working on something that 10,000 other people have
done already and have done better there too?
But those are both existential worries that I think is really easy to forget that most
people do experience day to day. And if we can get competency and fit right, well, any
realize, you get to the expert level, you're like the end of the, that in Kruger curve,
and you realize there are so many things that you won't have the chance to experience, or
you need to talk to other people to find out and try and grab as much as you can from them
and see what mistakes they've made to save a bit of time there too. So I totally agree
with you. It kind of plays on your mind quite a bit. And I think it makes you resilient
to that and to the hurdles obviously that come from across in the job there too.
Yeah, I know we could speak to like a lot of your career history and such, but I'd actually
love to like dive into what you're doing today, because I think it's so applicable to what
literally the conversation we're having right now of like this imposter syndrome and understanding
where your skills lie and understanding sort of capabilities and where you can actually
take your skills. So you're doing something pretty cool today. I'd love for you to tell
the listeners or watchers what you're what you're up to today, because I think it plays
so so nicely into this.
So I'm working on PureType and that's a developer education platform that I believe has a good
edge to it. It takes into context things that you're currently working on, the mistakes
that you might have made, and then recommends a personalized learning journey for you. And
if you can get your teammates on it, it gives you a sense of how your teammates are doing
and you might as you can know that as well. So the what I've seen as the limit is the
books and courses and we know developers purchase them, you know, and they invest in their own
education and not to the best developers do. But there's a gap in the market, certainly
from making that something you can fit into your continuing education, not a lot of people
have hours after work, for example, but you know, they do want to improve, they do want
to get better. How can you develop something that uses the few minutes they might have
spent in the day to give them the one lesson that they need to learn that day? That's the
angle I'm really chasing down. I'm trying to build a good engaging product. If I was
to reduce it down to three words, it would be due a liga for developers, but I think
that gives you enough credit for a good context. I'm going to apply to all of this and see
the lessons I can learn from building ed tech and selling to developers. I've learned a
huge amount already and I hope to learn a lot more.
Yeah, that's true. Well, I can tell you right now as someone who helps people who are targeting
developers, it is a long game. It's a building of relationships and all the things which
we chatted about beforehand. But I think that's really cool because I think there's actually
been a number of guests like Gingis was one of them during the first week. So I'll just
for anyone who didn't catch that one, go back. It's like episode 14 or episode four or five,
I think. And he really talked about this. He talked about engineering leadership and
how some engineers are just not, they're not prone for the leadership track, right? They
don't want to go and lead teams. They just want to be the best art engineer they can
ever be until they retire, right? But all the way to sort of what does that leadership
track look like? What does the other track look like, right? As you start to go through
that career ladder as a developer and he just felt it was so incredibly important to have
these plans and he had a really beautiful word for it and I can't recall what exactly
it was, but I love how he approached it essentially. And I think that precedent of as developers,
we really need to own our education. We need to own our career path. We really need to
take a step back and actually plan that out and be methodical. Our brains are so used
to thinking about the systems and to building things, right? It's we don't always necessarily
take a step back and look at our career. And I think that's what he really urged developers
to do is just do that. I think that is a beautiful melding into what you're doing, right? Is
like you're taking that advice and saying, Hey, let's put it to action in this platform.
And this is where you can come and actually make that happen. I think that's beautiful.
I'm going to pause and let you let you sort of reply to that. But yeah, and I agree with
him and education and career development. I think there are two major factors that most
people come across. The first is we have such a focus as engineering teams on delivery,
delivery, delivery. It's almost as if the only thing you're rated for is output and
the volume of that output. And I think that's that's a big part of the picture, but that's
not the whole picture. Right. So that's obviously the big time constraint that everybody has
and what they're judged against almost. I think the second side of things is that education
is one of those important, but not urgent things. And we all have books that we would
love to read. And, you know, we probably have a time of the week, but you never go, Okay,
I'm going to sit down and actually do that because I know that that's a big that's a
book that's been recommended a couple of times. It's important on a particular path that I'm
following that I can go and take a look and read through it and get that, you know, impart
that knowledge, put it into practice. It's often like we're, we only really invest in
ourselves when we absolutely need to perhaps we're searching for a job or, you know, that
we're in a career transition, whereas there's nothing stopping us, we have all the technology
that the kind of basis for all of this to actually break it up into little chunks and
stop sort of making excuses to ourselves of, you know, we could actually go down that individual
contributing part. It doesn't stop at senior you don't have to be an engineering manager.
You know, staff and principal, engineering jobs are complex. And I think that points
to one of the fallacies that we have in software engineering is we treat it like a lot of other
hierarchies where all of the leadership is actually invested in one person, like the
team lead, engineering manager, lead developer. It's not actually the case, you know, as soon
as you get to senior or perhaps you're a staff or principal, at that point, you are taking
leadership, it might be more technical leadership, but yeah, it's still an element of you have
to go out into the unknown. No one's giving you the answers because you're the guy that
has to, you know, you're the explorer with the partially filled in map that actually
has to fill stuff in there as well. And I think of course, that's one of the great engaging
things about this field is you never stop learning. And if you do, then you're almost
certainly wrong about that. You need to stop filling in the map for other people to follow.
Yes, yes. Oh, I fully agree. I mean, this bookshelf right here is probably like books
that I've 50% read. Well, probably books I've read a chapter or two scanned through the
book, and maybe have read 25% of them, right? Like it's, it's, we want to learn the things
we want the knowledge we want to be, you know, the best at our craft, right? And as developers,
we want to do it as fast and efficient as possible, like that's our end goal. So we
can share and be like, look what I built, as quick as possible, ideally, right? But
yeah, it doesn't have to learn almost, it's that sense of like, I'm going to lead to know
exactly what I need to know. And then I'll move on to something else there. But that's
a great first order thing, like you get something, you build it, it's cool, you get that rush,
then you could push yourself further, get that basis and then build on top of that knowledge
there too. So it's, it's kind of interesting to see who does that and how they do it and
obviously try and help coach other people to do it as well.
Yes. Well, I think that's this has been gosh, what a beautiful like theme that the show
has honestly started to like create all on its own, not by my direction by any means.
But there's been so many conversations recently about the lack of investment into ourselves
as developers, right? Like we will go buy the book, like you said, but sometimes it's
that's in our desk, or we'll go buy the course, like, you know, many courses I've bought that
I like haven't actually finished because I'm like, a, I wanted to support the developer
or be I did fundamentally want to learn, but it's, I just didn't prioritize the time.
And I think it's one of those things of like, we see those drawbacks when we get into roles
and when we're being pushed in different directions and I've been in a situation where it's like,
gosh, I really wish I would have picked up that course that I bought that I knew that
I needed, but didn't actually, you know, take it to fruition. So I think that there's a
major sort of precedent here of understanding like we are engineers and we are paid decently
well, like we should take some of those funds that we are being paid and reinvest them back
into ourselves. It's no different than a business, right? If you're starting a business, my dad
is an auto repair business, like it came with a tire machine, but the tire machine really
sucks. So it's like you serve customers, buy a new tire machine when you can, right?
And that's just kind of how business operates. So it's interesting that we don't do that.
Yeah. And look here as a system and in the entire example case, well, what's the thing
that's stopping us from serving more customers or serving them better? It's that let's go
fix that. Let's indulge that engineering mindset. That's no bad thing. And people do have
educational budgets. People work at companies that allow for this kind of thing. But if
you and I were to bet how much that money gets spent and the percentage of companies
across the board, I think it would be a number that's a fair bit lower than 100%. And I think
that's a very telling sign that even though you have those free funds available to you,
you don't necessarily use all of that. You're not developing as fast as you could, I think
is a common theme there. So I think with a more competitive job market, that's the kind
of thing that people are starting to realize that it's not necessarily always growing in
the more developer positions than could ever be filled. We've been through a bit of the
retractment is how do like 25 years of solid growth, it's going to be the bottom part of
the market that drops out fair enough. It might not be suited to them, but that means
that other people still need to shape up and make sure they've secured the roles or promotions
they'd like to get there too. So it's nice that it all comes together in the theme of
developer growth because I know that's something you're very interested in as well.
Yeah, yeah, exactly. I mean, from all sides, right? It's like, at the end of the day, like
I do the job that I do because I want developers to have the experiences that they want, right?
I want them to go through a product and it's like, beautiful and the ducks are in the main
navigation and it's crystal clear how to get started and the SDK is so stupid simple that
you're like, look at me go, you know, and so for me, it's very much sort of the same end
goal that you have, right? It's like, I want to see developers succeed and I want them
to have that experience that they can have to be able to succeed where you're on the
other side of how can we educate and how can we level up engineers in their actual career
skills and in their education to be better professionals in their role, you know, and
I think it's still a beautiful synergy of developer growth for sure.
It's a very positive cycle and I'd like to think that, you know, as pure type expands
as it supports more languages and technologies, it's freeing up managers to become more invested
in career developments, the software side of things, you know, allowing for that getting
rid of the mechanical, oh, you made this mistake, so go do this resource. Oh, did you get this
down? I've got to follow up, etc. This stuff often gets dropped. You then leave no time
for what I think is the most rewarding part of work, which is the ability for people to
invest in each other's growth there. So I'm not looking to replace that whole hierarchy
at all. What I'm looking to do is make sure that the human side of things actually gets
the time it deserves and we'll see how things go.
Yeah. Oh my gosh, I love that so much. I absolutely
would have loved to have focused on that as an engineering manager. I think when you're
in that space, right, it's, you have so many balls to juggle, right? It's both the technical
balls, you know, the business and other balls that you're juggling, right? But then you
have these humans that are reporting to you that you're, you know, responsible for their
career growth at which they are in your company. And I think it's, it's not always easy to
find that and to understand that. And so I love that you're doing that. And I think on
top of it too, there are so many different neurodiversities in technology, which I think
is actually why I think why there are so many neurodiversities is because technology is so
interesting to those that have a neurodiverse brain, they get to really dive in and leverage
what others may see as a disability and really bring that to life, which I think is so beautiful.
But what I think is, is interesting is when you have those neurodiversities on teams,
and that is not always easy to handle, right? Someone who, you know, needs to be in the
mode, right? You know, whether that be ADHD, because it's a focus or a tunnel thing, or
whether that be sort of just how they think and operate and being able to work when they
want to work or operate how they want to operate. And I think often, you know, in corporate
culture, we're not, there isn't really this beautiful scenario for a neurodiverse or an
alternative thinking type of a person. But I think when we bring it into this engineering
world, there is a space for these engineering leaders to sort of understand that more deeply.
And I think when you can bring that to what you're building, right, and there's actually,
it's more than just a number. Yes, they did lines of code, right? It's far more than that
because someone can create a more beautiful solution versus someone else who can write
more code, right? You understand what I'm saying. But I think there's, I think it's
just interesting too, when you bring that dynamic into teams as well with education.
And I think that draws upon two experiences I've had. The first is you can manage neurodiverse
people well. It's, it's at least a area that allows for that, you know, it's analysis.
It's not always about making 700 calls a day. It's, well, if you think about it for 20 minutes
longer, you might save an hour. It's not incredibly output focused. And so, you know, being on
teams, I, I like this principle of decisions are discussed, then made, much less of a top
down thing of decisions are made, then discussed, because you get to take the pressure off it,
you just get to collect opinions from people who might otherwise sort of shy away from
those kind of scenarios and then say, well, actually, yeah, I've made the best decision
because I feel like it's a mixture of all of these different points of view there. So
that's the first point. The second is, you know, it's about giving people a full picture
of what engineering is supposed to be. It's, even if you're managing a neurodiverse person,
the people in the business are going to think, well, okay, they're not kind of following
that. There's a strong group mentality as there should be in any company, but not everyone
can be part of all of the practices of that group. And trying to give them a good sense
of, well, this person is good, even if he doesn't follow all of the things there, or
he has a bit more flexibility. That's not because he's a special exception. It's because
that's the best way to get the best out of him there. And, you know, I'm not trying to
fit everybody into a single template of what a great engineering leader is supposed to
be. And I guess that goes back to what we were discussing about those two parts. Is
it management? Is it technical leadership? Is it both? That's, there are a multitude
of parts to follow. It's divergent. It's not convergent, I guess, to tie that particular
thread up there, too.
Yeah, no, I fully agree. Yeah, it's interesting, too. And I think it's, I'm just thinking back
to, you know, to like engineering manager days, right? Or even just general like leadership
days, I think that was probably the most painful thing to navigate with some of that stuff.
And it was, and it's hard to because as a manager, you're looking to advocate, right?
And so the more details and insights and information you can have to sort of navigate and understand
that I think is powerful.
Yeah, I agree.
Yeah, love that. Okay, so let's talk a little bit more technically, like you are building
peer type, right? And it's an actually, it's a platform itself. So what are the underlying
technical stack that you've been building in or end on top of it and or what is your preferred
stack to build in? But I assume it's likely the same.
So at the moment, right now, it's Elixir and Phoenix Live View. So Elixir is cool. Yeah,
it's, it's a language that's gaining a fair bit of popularity. And in fact, the initial
language is not supported on the platform for people to learn is Elixir because the
demand is there. And if you look at the Stack Overflow survey, it says, well, people actually
want to learn it, but they haven't got around to it yet. So good place to start. Also, good
language to code it in. So having built that, it's great for prototyping. It's a great language
to interface with other things, machine learning, the way in which it picks apart the code,
for example. So it's fine not to solve all problems at once. It's, it's almost a bit
like Python on the machine learning side of things. If it needs to go down and do some
numerical stuff, that's going to be some library that handles that. In this case, a lot of
platform functions like recommendation engine. I have all of these different streams of information
coming in. What's the, the, the areas they should learn next and picking that apart there
too. So there's some great libraries that have come up in the last two or three years
focused on things like machine learning focused on, in this case, Phoenix LiveView, it's like
a server-based thing. So you don't have to write a ton of JavaScript. You can just write
something in one language, get it going quickly, get the, the feedback that you need to go
right somewhere else as well. Speed of prototyping is such a huge factor nowadays, but also the
way that the language is designed, the stack is designed means that you end up writing
individual servers within the same application that keeps state nicely compacted. It's almost
impossible to, to write a code base that ends up being complete mess with everything, talking
to each other after a while. It's, it's a language I would have, I think it was a brave
choice to adopt back at the previous place five or six years ago, but I think it's a
sensible choice nowadays.
Yeah. That is really cool. Well, there's actually been, I'd have to go back to reference which
ones, but Elixir has been mentioned twice on the show. And in both of those times they
were talking, if I recall correctly, they were referencing like something that they
wanted to be diving into, but didn't have the time, honestly. So that's really interesting.
I love that.
Hopefully with pure type, they'll get the chance at least to pick apart some of the things,
get some feedback on that. And JavaScript type script will always be around. And my
plan is to support those languages next, but you can also give feedback on the individual
technologies and the frameworks that people are using within the language. And you can
go further. I'm hoping into things like software architecture. Yeah, you wrote all of this,
but actually you should probably use this pattern if that's the case. I think that's
going to be a really interesting path to travel down.
Yeah, I think that's going to be, that's going to be the like amazing, right? Because I think
it's, there are resources to fundamentally learn languages, but like you said, there's
a difference between learning that language and then taking that and actually applying
that. And so when someone can learn a new language and then learn how that language
works, right? That's, I think the beauty of it is like, we can pick up a language, we
can teach yourself, we can memorize, you know, syntax and whatever, but it's actually truly
understanding why that language is so powerful, why that's the one that you would want to
choose and operate with, having those strong opinions, right? And then understanding how
that applies into that build system. That's the, that's the good stuff that like will
drive a career forward.
Yeah. And you and I, I'm sure have been in the position where you learn a new language
and then you get your first bit of your first issue assigned to your first PR and you think,
okay, I could do it one of three ways, but I need to get some feedback from somebody.
Let me do it this way.
Yes.
Figure out the, and then you get to call it review. Oh, why did you even try that way?
You should do it second way or third way because, and then that's the point of which they say,
here are the principles, you know, you might understand all of these different things,
but here's how they fit together. And here's the factors that you should be taking into
account to move that particular choice there too. So that's, that's an interesting angle.
It's trying to make sure that people reach that point as quickly as possible. I think
that's going to be quite interesting to go down and give that feedback.
Yes. Yes. I fully agree.
So I am, I'm excited. You'll have to come back on the show after you've been, you know,
doing pure type for a while and, and catch us up on all the things that you've been up
to. Okay. So sort of thinking about some of the questions I like to ask, I'm trying to
think here, talk to your stack. How do you get unstuck like as you're building pure type?
I mean, you're sort of, are you a team of one right now?
I'm a team of one. And yeah, it is hard. And I think it might be able to allude to the
question of, well, how do you, you know, get over hurdles? How do you see past things
there? Yeah. Yeah.
I'd say it's, it's wearing multiple hats. You know, I try not to be attached to any
particular piece of code I'm writing. And obviously we live in an age now where the
cost of writing new code has collapsed. You no longer feel such a big attachment to, well,
I went down this particular path, this is going to take me hours to redo.
Yeah.
There it's, yeah. It has been critical. I don't mean it helps, you know, there's a review
element to all of this. You do have to look at things and think, okay, well, I've written
all of this, but I did it because that, that was the prototype. That's, it's almost like
I'm generating some good material that I would want to get feedback on.
Yeah.
Yeah. I think it's the days perhaps of sitting and coding stuff for eight hours straights
have, have changed significantly. You know, it's, it's much more mixture of different
parts of it. And I've always seen writing code as a nice side effect of the job. I find
myself leaning a lot more on chores, sketching stuff out on paper, getting some sense of
where things are. I think the nice thing about being a bit more senior and doing this enough
is the, having the language to criticize what the work you've done so far. It's a bit like
a chef who doesn't know how to describe what they're, the food that they're tasting or
the words that they have for it. If you don't have that language, it's very hard to know
what's good or not. And getting that feedback from others is absolutely fundamental to that
because they, they're the ones who say, well, this doesn't look right. And then they draw
it up into some high level principle as well. I don't know if that's the kind of techniques
that you've come across there and what you found useful there too.
Yeah. No, I think, I think that's incredibly helpful because like, you know, as developers,
right, sometimes it's hard for us to unveil the code that we wrote, although now I feel
like it's, it's less in that way in that now, you know, PRs and code reviews and stuff
are, are definitely a more regular type of a operation. But you know, like when I was
a learning to code, right, that wasn't a thing like GitHub wasn't a thing. There wasn't,
you know, this ability to go look at someone's code and review it. And like, I wasn't even
using git. There was like, Oh my gosh, SVN, like, and was where I started, you know, it
was, and even that was like painful. So it's really interesting too of like, I think now
if I could go back and change things about my career start, right, is like that, I think
is so incredibly valuable. It's like the ability to say, Hey, here's a chunk of code, here's
a chunk of what I did. Go look at it, go provide feedback on it, you know, do those things.
And it was just not as easy to do that in the past. So yeah, I think that, yeah,
I'd sort of blurred that out of my mind. But yeah, when I started it was SVN and no one
had, there wasn't a good code review platform for it. You just attached a diff to an email
and someone if they had time gave you feedback. And in 10, 15 years, we've come from that
prehistoric era to something where AI code reviews, obviously a big factor coming back
to me, the market, that's, that's just mad that, that we could have ever learned from
those kind of processes.
Honestly, now that you say it like that, wow, that is really like 15 years. That's real
fast for that to happen, truly, because like, not only did we not have peer reviews, like
you said, but now we've got computer peer reviews and human peer reviews and all the
possible reviews. Do you think, I don't know, gosh, like, it just makes me wonder, like,
I really can't speak to what it's like to learn to dive into technology anymore, because
it was just such a different world that we came from and how the evolution and how fast
it's grown is like actually truly remarkable when you think about it.
It was a shaky a start. It was harder. Things like repels didn't exist. 15, 20 years ago,
you just had to code up something, compiled it and hoped it worked.
Yeah, this is a danger turning into back in my day conversation, but that the cycle of
getting that first bit of satisfaction and I think that first moment of, oh, cool, if
that's the rewarding part for any future developer, then that's the thing that's the feeling
you've got to latch on to and I think for in the future, that's something which at least
you can experiment a bit more. We're almost as if we're becoming less, you have to have
an engineering mindset and more scientific mindset. I'm going to experiment with this.
I'm going to see if it works. I'm going to try and collect some feedback on why that is
and why it's not necessarily the best solution. I think that can only be a good thing. I think
we should accept a bit more failure as part of our job as software engineers almost.
Yes. Oh my gosh, I love that. I love that so much because there's just so much to it,
and yeah, man, I feel like I could pull this open even deeper, but I'm like, time. Okay,
so how about you in your own work? Are you in terms of, yes, capturing feedback, super
important, what have you, do you have a team of people that you reach out to them, like
a circle that you're like, hey, I'm working by myself? Can you review my code? Can you
review what I'm up to? How do you go about that being a team of one?
So it's almost as if I leave the code review to myself. So I don't know what kind of horrors
I'll unleash for anybody. I looked at the code base one day, we're often blind in that
sense. What I found useful is at a high level, is it worth building this feature? Why? What's
the feedback that I'm getting? What have other people done in the past? I've worked with
an advisor, a couple of advisors, the sort of people who've done it before, but they've
done it at slightly different angles. It might be security scanning. That's still a case
of is this code good? Why isn't it good? In that case, the goal is, well, it has a security
vulnerability. My goal is, well, there's a big gap between the code that you could write
and the code that you have. And I think here's where the areas that you need to firm up on
are the language that you're starting to speak. So I found that to be a lot more productive.
And then you get some of the educational guys, the sort of people who have done this, you
know, might be in high school or for college courses, instructional design, all these sorts
of people who I think ed tech people never talk to, but they have very strong opinions
on how things work, how people learn, how people learn, and the kind of questions that
you should be asking to get them off the speed there too. So for me, that's over the last
couple of months, it's been great to talk to people, job titles, for instance, I didn't
even realize existed, and we talk about things at a high level. And maybe that's the way
software engineering is going, that we are becoming more product engineers, we're becoming
a bit more attached to each discipline, but we're using the skills I think software engineering
has given us to pick apart those areas, find out those principles and become a lot more
adept at in every demand too. And I think in the fields that I've been in before, thin
tech and finance has been a strong value and actually learning what this product is or
this contract, how it behaves there too. It's been nice to speak those languages as well
as rights code there too. I haven't felt like a, was not becoming a software engineer, I
just felt like I was learning additional stuff that also indulged engineering, learning all
the things that I'd like to do. Yeah, yeah, definitely. Well, I feel like, you know, when
you're in some of those like really niche industries and like FinTech definitely falls
into that like healthcare is another one that sort of falls into that, obviously very regulated.
But there's a lot that you learn just because when you're operationally building, right,
you start to understand the industry itself, like how does the FinTech API's work, I hear
some of them are archaic, right? I haven't had I haven't actually directly worked for
a bank to have to work with some of those different sort of endpoints and things. I've heard
the brutal stories though. Mine was a more cutting edge side when I was in FinTech, but
it's really interesting to dive into that. And I think that's also been some good, you
know, premise that has come from various conversations that just again feeds back into what you're
building with peer type is, is like how important it is to actually like help and engage one
another and to really dive in to have those conversations. Good follow up question for
you. And I'm sure like, you'll have a variety of different answers here. But as you're
starting to meet those people that you've never talked to before job titles you've you've
never seen before, how are you finding those people? Like, are you just not LinkedIn scrolling?
Are you asking folks to do introductions? What's your path there?
I think it's it's both. And I think yes, LinkedIn, much more lines in terms of the quality of
the feed, but you can always unfollow people. The fact that you can, you can connect to
all these people that you have in common means that you can grow your network a lot more
than you ever could virtually. And for me, physically, having moved to a new city, Montreal,
it's great to get started in that and trying to pick through that and talking to going
to CTO meet ups. Well, they're all have an engineering focus to them. They're all interested
at least to see where things are going there. So I think LinkedIn is the first thing to
go to. I think the second is following the intro chain. And I'm saying not just Oh, you
talked to this guy that you asked him, Oh, is there anybody else in your network I should
be talking to? And there was some way for this is a nice conversation that's not really
going anywhere. You know, that overlap isn't there for enough, not everything works out.
But then the intro to me to somebody who goes, Oh, this is exactly the kind of thing that
I'm really, really quite handy with, you know, I really like the opportunity to do that. And
actually following three or four people deep. That's again, it's, I think that's one of
the great experiences I found during is brought me out of a, I need to be focused on this,
you know, there's this product release coming up as I need to make sure that this is as
good as possible to more divergent. Okay, there's 100 different people I could talk
to, but who's going to care the most at this point? And who's going to help shape the direction
that I've been seeing hundreds of hours building the right thing or and it comes down to that
output metric of I could write all sit down and write all of this, but no soul founder
is going to have the sort of resilience to do that. How can I use my time most effectively
and how can I talk to people who do that? So could I have done that in the same way
10 years ago? No, not really. People were based on LinkedIn, they weren't open to as
many conversations. I think we are becoming a more collaborative world. I think in terms
of these types of conversations, perhaps you and I wouldn't have met by the time you go
to Italy. And within companies themselves, we're realizing that software engineering
is quite a team sports, you know, yes, it's kind of practice individually, but it's becoming
more and more practices a group, so you know, more programming, pairing, all of those practices
are becoming a lot more efficient and easy to do asynchronously, etc. than they ever
were a few years ago. Yeah. Yes, I agree. Honestly, like, you know,
sometimes it's like there are some we can argue social media, right? And it's it's
goodness that it has brought to the world versus the negativeness that it has brought
to the world. But I do think that that LinkedIn has been one of the one of the really beautiful
things to be able to just connect and network with people in that way in in in more of that
professional sense, which I think has been something beautiful to do that. Because like
you said, I don't think we would have met, right? Like, as I look at sort of our crossings
and wherever it was a very serendipitous sort of meeting of, you know, someone introducing
there in that way. So yeah, I mean, we think about it right in like, gosh, okay, so my
I love the TV show friends, like, I love the show. So I swear this isn't a tangent. I'm
not going I'm not going way off way off course here. But we were rewatching it. And right
now we're like in season eight or something, right? But we've been rewatching it sort of
just it just kind of is like in the background, my husband loves to watch TV. Long story short,
it's just even interesting to sort of like watch old shows like that, right? In the beginning,
they didn't even have cell phones. And they're like, Oh, like Ross gets a pager because his
his like ex wife is going to have a baby or something, you know, and it's just interesting
to sort of think back to like that world at which we had to be like, leaving voicemails
on people's home phone voicemails to be like, Hey, can I intro you to a friend? Like it's
just so much harder to just say, Hey, I know somebody, let me connect you to them because
the path at which to communicate with someone was a lot more difficult.
Yeah. Well, it's a bit like cyberpunk and that whole genre and the fact in the Victorian
era, we built the first internet we could have basically real time transmission across
the Atlantic, but we still had horses for that. And trying to figure out, okay, you know,
speed of communication, what we could actually do with that communication is these two big
factors that we're always playing a part. I feel like we've made a huge leap in communication
over the past couple of years. And now we're trying to, okay, figure out, well, how do
we work together using that and make use of it? They're two of them's obviously LLM's
AI just fit into that.
Yep. Yep, I agree. I know now we have like too many communication passes, like, do I
mean to text you or Twitter DM you or send you a message on LinkedIn or email you or
I could call you all the ways. This has been such a lovely conversation. Where can folks
Yeah, great, great, great. Sorry, I didn't mean to cut you off. Where can folks find
you obviously peer type, but let us know the URL directly so that folks can go find that
directly. And then any, you know, places where they can meet with you or get to know
you.
Yeah, so it's pure type.ai.ai because it was the cheapest domain in Suffolk. It does use
a bit of AI as well. And I'm at fuel type.ai. But I'm always on LinkedIn, DM me there. I'm
always happy for a chat. I know how hard it is to get that initial network going. And
I like software development, I like learning, I like any intersection of the two. So I'm
sure I will get around to answering any messages that you end up sending.
Oh, I love that so much. I think, you know, like we talked about this a little in the
pre show, but it's like us developers and software engineers, we just want to hang out
with our tribe, like we want to get to know each other, we want to spend time together,
have these kinds of conversations. So absolutely encourage folks to reach out to Matt. It's
been fabulous meeting you like absolutely fabulous. You have done some super cool stuff.
I'm excited to dive into pure type other developers. I know there are a lot of earlier to mid to
light career developers that can really benefit from pure type. So I hope that folks get that
that message and they check it out as well. So yeah, it's been lovely to meet in chat
and I'm hoping to keep in contact and maybe appear on the show sometime soon. Let's see
how it all works out. Yes, absolutely. Honestly, I should bring you on and we can talk about
it later. But on the built for devs hub, I'm just trying to bring together like great,
beautiful, meaningful conversations. So it'd be great to bring you in there and maybe you
can talk, talk about sort of why you built pure type and, you know, sort of the backbone
behind it, at least in terms of like developers and you need to learn and, you know, all the
reasons why they should dive into investing in their own education.
Exactly. That'd be great.
Awesome. Okay, well, I hope everyone has a fabulous rest of their day. I'll see you all
again tomorrow. Matt have a lovely day as well.
Thank you. Cheers.
Cheers.