cofreepress-jonathan.txt

Jonathan:
My thought process was that like, "Everybody's doing the same
thing. Everybody's reading Cracking the Coding Interview.
Everybody's reading books, doing Udemy courses, what is something
different that I can do to accelerate myself?"

Sandy:
Hello and welcome to the very first episode of the Cofree Cast.
I'm your host, Sandy Maguire, and today, I'm joined by Jonathan
Lorimer. Jonathan is a software developer based in Toronto, who's
passionate about functional programming, particularly Haskell.
He's the organizer of the Toronto Haskell Meetup. Interestingly,
Jonathan got into technology late, after having done his
undergraduate degree in Philosophy, where he focused on
Epistemology, Philosophy of Law and Ethics.

Sandy:
On a more personal note, when I first met Jonathan, I was sleeping
on his couch and forced him to call in sick in to work. We did
a three-day coding binge, working for 14 hours a day, about as
deep in the weeds as you can get. He's the only person I know
who's ever been gained to do that sort of thing, has quickly
become one of my favorite humans. Thanks for being on the podcast
today, Jonathan.

Sandy:
So, I guess, we'll just dive in here. And my first question for you is that you
got into programming rather late in your career. And I was wondering what
you're doing before that and sort of why did you start thinking about
programming?

Jonathan:
So, as you said, I did philosophy in university. I was actually, I was a bit of
a slacker in the university. I really didn't kick things into high gear until
maybe third year. I had a really great professor and she noticed that I was
really engaged in the essays that I was writing, but didn't come to class a lot
and she kind of like sat me down, and said, "Hey, look, you don't have to be
here. You could go off to college and learn a trade. You could take a gap year.
There's a bunch of different things you could do."

Jonathan:
And that kind of made me refocus and made me take things seriously. And I feel
like at that point, I really started to enjoy my Philosophy. I really started
to do the readings more seriously, and just became more of an engaged human in
general. So, but at that point, I was kind of far along in my Philosophy
degree. I didn't really have an idea of what I was going to do, so I finished
up my degree. I knew that I wanted to get a job right away and not really moved
back in with my parents and try and kind of find my way.

Jonathan:
So, I got a job doing construction. I had previously been into art and
architecture, so I thought, "Hey, maybe I'll learn construction and find my way
into property development or something like that." I was just kind of lost, so
I started working construction and that was a very formative experience. I was
really bad at it. It was previously everything I'd done and it wasn't
necessarily great, but everything had been kind of easy. I'd done all right at
sports. I'd done all right at school, but construction, I was just so bad and
I was bottom of the rung. I think the first day I was allowed to drive the
truck by myself, I got in a car accident, so it was a pretty stressful
experience. And being bottom of the rung in a construction job, you get bossed
around a lot.

Jonathan:
And then winter was coming and winter in Canada, not great and you're outside
doing construction, so. And I was already dreading going to work every day in
the summer, so okay, I just need to get out. And so, I started looking for
alternatives. And I started cold calling people to do just general business
development stuff. I reached out on LinkedIn. I tried to set up meetings. I was
generally looking for strategy type jobs and no one would respond. No one
picked up the phone and it was incredibly demoralizing.

Jonathan:
And so, I said, "Okay, I need to retool or rescale." So, I looked into a couple
of things. I looked into I think graphic design, because I had the arts
background. But I saw coding, and I roughly knew that coding was a relatively
lucrative position. And I figured with my background in logic, maybe I'd have
a chance at it, so I applied to a boot camp and got accepted. And then I went
off to the boot camp and that's how I got into tech.

Sandy:
Sort of interesting, you mentioned the ego thing of being good at everything
you did until you got to construction. And I wanted to ask about that when you
were doing tech. I feel like so many people approach tech when they're young
and grow up with it and so much so that it shapes the person that they become.
And so, I was wondering what is it like to get into programming as an adult? Is
it hard? Did your ego take a hit or was it something you were naturally good
at? Just how smooth did it go? And maybe you could tell me a little bit about
that.

Jonathan:
To give a more direct timeline, I started the boot camp at 24. I'm 27 now.
I graduated university a little bit late at 22 or 23, I can't remember. I did
an extra year and going into the boot camp, I had a very, very particular goal.
I figured that the hiring rate out of the boot camps was not 100%, so I had the
goal to be in the top three of the class at all the projects. And the idea was
that in every project, I was top three. I finished somewhere in top three and
those are the candidates that the hiring managers were going to select.

Jonathan:
So, I went in quite competitive. I don't think anyone else quite had as much of
a competitive attitude. I think people kind of showed up and they're just in
survival mode. So, I think that a more aggressive mentality held me in good
stead. There were people who did have coding backgrounds and they had a head
start. But I think I ended up being top three in my cohort. I do think it's
a bit, I don't know. It's a bit unfair, because the type of coding boot camp
was very specific. It was get good at React, get good at web development, and
get hired. So, it was actually quite easy to treat it as a skill rather than
more of an academic endeavor or something that I was trying to understand
deeply.

Jonathan:
It was really more of can you learn what makes a React component and mimic this
web template. So, that lent itself well, I think, to the type of attitude that
I went into it with. Yeah, so it wasn't actually that hard, I don't think until
I got into functional programming. And there's a very specific story of how
I got into functional programming, but that's when things started to get more
difficult. And I started to compare myself to peers who I think are more
advanced. Some of those like lifers, those like programming lifers.

Sandy:
That's really interesting. I want to get to functional program in a minute, but
just a little more on this topic first, which is, would you recommend that more
people put off getting into programming until later in life? Or do you think
that was an asset or a liability?

Jonathan:
Yeah, I do, actually. I had a bunch of friends who are kind of, they're having
a tough time finding their way as well. Actually, in the grand scheme of
things, I feel like I got into programming relatively early for someone who got
into it late, if that makes sense. But I have these friends who are kind of
mutt, who are kind of 25, 26, 27 now and they've tried to get a job in the
discipline that they went to university for unsuccessfully. It's actually
a pretty harsh job market out there, I think.

Jonathan:
And so, they've asked me, "You made the transition, do you think I should?" And
these are people who are Economics majors or they're really into urban
development and urban planning, like really, really interesting things. And the
advice that I give them all the time is to try and be a subject matter expert,
rather than just a technologist because it's a bit paradoxical because I chose
to become a technologist. But from what I've seen or in my opinion, I think
subject matter experts are in short supply and I think there will be a premium
on them in the future.

Jonathan:
It's very easy, or I shouldn't say very easy, but it's a solved problem how to
take a technical specification and translate that into working code. It's not
so straightforward to actually understand disparate domains and to be able to
explain those to a technologist and have them build something. So to get back
to your original question, I think there is some advantage to being, to having
subject matter expertise outside of tech. I think it does expand, expand the
way that you see the world and it gives you a lot of intangible skills that can
inform the way that you do things.

Jonathan:
It's hard for me to point exactly to what mine are because Philosophy itself is
very abstract and it's also relatively related to tech, because it's pretty
logic heavy, so I don't know. I can't say exactly what the separate skills that
I developed that I wouldn't have developed if I'd done a Computer Science
degree. But I definitely feel that I have a few at least. And so, I think that
would be the primary advantage is that you're kind of this hybrid of you've got
expertise outside of tech and you can speak about real world things. But then
you can also take a technical specification and write the code.

Sandy:
Would you say that your life experience is the thing that maybe differentiates
you most from other programmers, the lifers, as you call them?

Jonathan:
Yeah, yeah, I think so. Maybe what it is, is that in technology, there's kind
of diminishing returns as you invest time. And so, I've kind of got the steep
curve from an early learner from Philosophy and then I'm also enjoying the
steep curve of being on in my technology journey, so maybe that's a good way to
put it.

Sandy:
I'm really curious as to whether you were ever aware of programming rewiring
your brain. I find the more I learn about technology, the more I see it
everywhere in the world. And not necessarily like, "Oh, there's computers
everywhere, but there's computation everywhere," and sort of. And so, but
again, that's something I've grown up with and it's hard to exactly pinpoint if
my brain ever changed or if I grew into that. And so, the question I'm trying
to ask is, did you ever feel that way? And if so, how did computation ever
change the way you think about the world?

Jonathan:
I'm going to take a roundabout way of answering this. I feel like I've had this
experience with Philosophy, where once I started to learn formal Logic,
philosophical argumentation, I learned the skill of putting together an essay.
I started to see that everywhere, this logical structure. And it was a little
strange to me, because some people found that quite grating when I would try
and force logical structure onto our conversations.

Sandy:
I think we all have that, that experience.

Jonathan:
Yeah, I'm sure. But I think what that stems from is that there are human
interactions where people enjoy living in the ambiguity, if that makes sense.
The ambiguity can be an aid or a crutch, if you aren't entirely sure what
you're talking about. But for the most part, I started to see this logical
structure everywhere. So, it started with philosophy, but then to come back to
programming, and I'm not sure if you want me to get into this now or later, but
I had at my boot camp, there was a mentor, who gave me a crash course on lambda
calculus. And that was probably the formative experience of my time at the boot
camp.

Jonathan:
And learning about the lambda calculus was really what made me understand the
logical system that I'd seen in everything. It was actually just computation.
And so, the experience I had is he was a mentor that was really into functional
programming and really into category theory. And we'll have this lecture on,
this introduction to lambda calculus and he wanted to test it out on someone,
so he showed to me. It was kind of like a practical example where you'd learn
the basic rules and then you'd start to build up structure. So, he showed me
how to build true and false in the lambda calculus, how to encode it. I think
it's called Church encoding. And it showed me how to encode.

Jonathan:
And then from my experience about truth tables and logic, I was able to deduce
how to encode or and it was kind of like this magical experience. I felt like
what I was learning was objective and true and real and out there. And one of
the things that this mentor used to say was, I was into chess, he was into Go
and he would tell me that Go was an objectively better game than chess because
Go has more possible permutations and fewer rules. So, it was inherently more
general. And I still enjoy playing chess, but I actually think I agree with
him, that there was something more beautiful about this game.

Jonathan:
And I feel that analogy applies to lambda calculus, where you've got very few
primitive operations. You've got lambda abstraction and function application
and that's it. But from those very few rules, I saw this proliferation of
structure, this logical structure that I had seen on the world, so that is
a very roundabout way of saying that like, "Yeah, I think I had seen the
structure in the world. I had seen people shy away from it. I had seen that it
can be applied to a lot of different domains." But I didn't really quite know
what it was and I think what I learned lambda calculus and felt like what I was
seeing was just computation out in the world.

Sandy:
Yeah, absolutely. Just to question a little more about the Go versus chess
thing. It sounds to me like you're saying if you were to write an AI to play
Go, it'd be harder than one to play chess and therefore, it's more an
interesting game, is that?

Jonathan:
I guess that's an example of it, but I think the way that the mentor was coming
out was that the interesting part of a game is that you don't really know the
outcome. And so, there's this anticipation of you trying your skill against the
opponent's skill and it's not entirely obvious, who's going to win. And Go has
a deeper tree, a deeper and wider tree of possibilities from fewer rules. And
so, I guess what that means is that some of the rules in chess are contingent.

Jonathan:
So I think that with Go, I don't really know that much about Go, but I think
your valid moves are just placing a pebble on the board in a specific position.
With chess, you've got all these different moves that are very particular to
the pieces. It's like it's unnecessarily constrained.

Sandy:
Oh, I think I see what you're saying like the lambda calculus has so few
restrictions.

Jonathan:
Yeah, it's the lambda calculus has two moves. And from that ever that you get
this very-

Sandy:
You get all computable functions.

Jonathan:
Yeah, exactly. Whereas chess you've got, I don't know exactly how many moves,
but pawns you can move forward. But sometimes if there's a piece in the way,
you can move them diagonally, you can't move them backwards. Horses, you can
move backwards, but only in an L shape, so there's all these very specific
contingent rules. Whereas in Go, it's no, it's just this one move.

Sandy:
That makes a lot of sense to me and it's a fascinating way to think about it.
I'd like to ask you a little more about your journey to functional programming.
You mentioned you had this mentor who's got you thinking about it. And was it
something that you bounced off a few times or did you learn about functional
programming and just dived in?

Jonathan:
After the introduction through lambda calculus, I had this transcendental
experience, this aha moment, but I still didn't pursue it. I always treated it
like Philosophy where I said, "Oh, yes, it's interesting and it's abstract."
But I'm trying to get a job, I'm trying not to go back to construction, and
lambda calculus isn't going to help me write React. So I put it off, but I had
this attitude where I was like, "Okay, I'm going to do functional light
programming. I'm going to do functional JavaScript." Just from an aesthetic
perspective, I thought it looked nicer that kind of thing.

Jonathan:
And then I got a job and I was trying to improve. And this mentor invited me
over to teach me Haskell. He was big into Haskell. At this time, Haskell was
a black box to me. And so, I started learning it and I thought it was a bit
uncomfortable. I wasn't entirely sure that I want to pursue it. I was like it's
interesting to train me to be better at doing functional JavaScript, but
I don't know that I really want, but I kept coming back to it.

Jonathan:
And I think, a couple of my early experiences at startups. So, I worked for
quite a few companies that had a very quick succession. The first company
I worked for the startup went under within three months. The second one was
just really bad code, and then the third one was a bigger tech company in
Toronto, but still, they used pre-rudimentary programming stack. And I think
what I started to see was every company I worked at, there was this elastic
band ball of features where they just kept wrapping one around another and it
was very messy.

Jonathan:
It was, I was always frustrated. I felt like we were prioritizing ourselves
today over ourselves tomorrow and we're making a ton of work for ourselves
tomorrow because of the exponentially increasing complexity. And so, I was
still doing functional light program or functional light programming
JavaScript, but I was looking for tools to combat complexity. And I kept coming
back to Haskell. Really, it started with types. I got into TypeScript. I was
learning some Haskell still just to keep up with my functional programming.

Jonathan:
And I think I started to recognize the constraints in Haskell, that had made me
think it was impractical at first, were exactly what I was looking for to fight
this complexity. And then when I tried to introduce these techniques, I was met
with a lot of resistance and the resistance I was met with from the senior
developers, felt unreasonable. It felt like people were just against Haskell
for the sake of it being Haskell, saying it was necessarily complex, it was
really hard to learn.

Jonathan:
And I had this feeling that like, "No, it's the opposite. This is making things
simpler." So, I feel like people's negative attitude towards Haskell pushed me
more towards it. I've always been a bit of a contrarian and then once I was on
the Haskell flywheel, it was impossible to get off and the big career goal
became finding a job in Haskell. So anyway, that was my journey into Haskell.
It was little bit slow, but no, I didn't really ever bounce off of it once
I had decided to get into it.

Jonathan:
I have bounced off of some things. I've tried to learn a bit of category theory
and I've consistently bounced off of that. But Haskell, I think as soon as
I recognized that it was the south to unnecessary complexity or to I guess,
sprawling complexity, it became a no brainer. And it's the only programming
language I would choose to write software.

Sandy:
Do you think that being a contrarian is necessary to get into Haskell?

Jonathan:
I don't think so, but I think just on the path that I was on, it was the final
push that got me to dedicate literally all of my time. Because I was also
trying to split some of my time about getting good at CSS and getting better at
React, and things that I thought were directly applicable to my day job. And
then when people started to fight me on it, I was like, "Okay, screw this, all
I'm doing is Haskell every night."

Sandy:
To switch attacks a little bit, at some point, you hired a programming coach,
which is so I think rare in this industry. And I'd love to hear more about
that. What was it like?

Jonathan:
That was a really interesting experience. I had a learning budget at the
Toronto Bay startup and I have always been really keen on finding alternative
ways of getting ahead that my thought process was that like, "Everybody's doing
the same thing. Everybody's reading Cracking the Coding Interview. Everybody's
reading books, doing Udemy courses, what is something different that I can do
to accelerate myself?" And paying for a coach seemed like a no brainer, because
I was trying to get better at all costs. And I was severely limited by time,
but if I could exchange a little bit of money for a quicker development that
seemed like a no brainer.

Jonathan:
So, I hired this, I went out looking for coaches. I found one named Jimmy
Koppel. I heard of him through Composed Conference in New York. He gave
a really interesting talk on defunctionalization, the best refactoring you've
never heard of. And he's a really interesting individual, because he's got
a very strong programming languages background. I think he focuses in program
synthesis, but he writes a lot of Haskell. I think he knows some dependently
type programming languages. I think he's done some work in Agda.

Jonathan:
But I don't want to misrepresent him, but from my understanding, he's firmly in
the camp of object-oriented programming. He really goes between the two, but
the people that he's usually coaching are like FANG company software engineers
who are looking for a way to get an edge on the person next to them. So,
they're usually like Java, Python, JavaScript programmers. And so when
I engaged him, I was still extremely junior at Haskell. I think I couldn't even
put together a real application because I was still struggling with
understanding IO and the different monads and how to get my effects to play
nicely and just like fighting with the type system.

Jonathan:
So, I wanted, my goal was to get better at Haskell and I did say that to him,
but I also gave him some more abstract and general goals. And so maybe, it
ended up not working out. I did the 10 sessions and I didn't carry on. But
maybe the reason it didn't work out is because I was too vague from the outset
about what I wanted. I don't think I even understood. What I really wanted to
do was to get a job in Haskell, but I thought that I wanted to understand
general Computer Science Principles better.

Jonathan:
And so, he had me go through these modules. And I learned stuff like how to
encode some types in object-oriented languages. That was an interesting one,
like the visitor pattern. I learned, he had me do some exercises on the state
monad laws, so I get after a get should be the same as just the one get and
there's a couple, but. And so, that was interesting, but I think the main
lesson that came out of it was that there is something to object-oriented
scholarship.

Jonathan:
So, and probably the best paper he gave me was, I think it's on abstraction, by
James Cook. James Cook has a couple really good papers and it got me thinking
about law abstraction, but also, what does object-oriented programming has to
offer. And I do try to be even-keeled and balanced in my perspectives on
things. And so, while I love functional programming, I really do want to give
object-oriented programming a chance.

Jonathan:
And so, I do wonder why do we speak so negatively of it in the functional
programming community? Why is there this huge rift? Are there not ideas that we
can take for a majority? Why do I personally struggle so much with
object-oriented code bases that I have a really hard time cutting through the
complexity and understand them? So, it led me down this path towards data and
co-data, which has been a bit of a theme, a bit of a research theme for me in
the past year. I've let it go a little bit, I would to come back to it, but
yeah, that's been an interesting pursuit.

Jonathan:
So, I guess the reason I chose to get the coach was I was willing to exchange
money for an expedited improvement. And the best thing that I got out of
coaching was an interesting perspective on object-oriented programming and
a nuanced view of what object-oriented programming is.

Sandy:
I've heard you mentioned this before, your research interest in data versus
co-data. And it sounds to me like that's quite tied to the functional
programming OOP divide? Do you think that's true? And if so, could you speak to
it a little bit? It's not immediately clear to me what the relationship there
is.

Jonathan:
So, I should provide a caveat that I'm not a PL academic. I'm trying to
understand these things, but I'm not sure that I entirely understand, but I'll
give it my best shot.

Sandy:
Yeah, I don't think being an expert is necessary here. If it were, none of us
would ever talk about anything, right? So.

Jonathan:
Right. So, the classic example of co-data in a functional programming context
are streams. But really what co-data is, is it's the production of a value from
substructure. So with the stream, you can think about it, you always define the
stream in terms of how you consume it. And so, in an object-oriented language,
objects are co-data because they're defined by methods implemented on the
object that implicitly consumed the object structure and produce something.

Jonathan:
So, a concrete example of that would be like a class that represents an
infinite list of numbers. And you can imagine that internally, it just starts
at the number zero and then when you ask for one and increments it and gives it
to you, when you, so there's a head function or a head method say. And then
maybe there's a take up until and I will count out the numbers and give you
those. But implicitly, each method takes the self or the this argument, so it's
consuming the larger object structure. It can reference the internal state and
produce some value for you.

Jonathan:
Another way to think about it, and so I guess the data corollary is just or
abstract data or sorry, not abstract, algebraic data types that we're all
familiar with. And I think that's actually, that gave me some insight into why
Haskell spoke to me so much early on is because with data, you're
constructively building something up. It's a lot easier to visualize the domain
that you're trying to express. With objects, you're defining your problem
domain in the negative. You're defining it in terms of how you consume the
data.

Jonathan:
So, I think object-oriented programming is just from our perspective is more
complicated. But it gets more interesting because you can define data in a code
data base language and you can define co-data in a database language. So, you
can describe the other one in a separate host language. So, I have a GitHub
repo where I try to express co-data in Haskell. And from the Cook paper and
a couple of other papers that I've read, it's become clear to me that the core
of co-data is abstraction. And that makes sense when you think about it as an
infinite structure. Co-data is infinite, because it's self referential.

Jonathan:
I'm probably not explaining that in a great way. But the co-data is abstraction
and I think it led me on a different journey, which was like, "Okay, how do we
express abstraction in Haskell? And how can we use that effectively?" And
I think then that becomes a software engineering question. So to summarize,
co-data is directly connected to [inaudible 00:31:47] program. Data is
connected to functional programming. You can implement each other into other
languages and there is something, in my opinion, more concrete about data and
something about co-data that is related to abstraction.

Sandy:
Something you said about defining co-data in terms of how you use it, it
reminds me of continuation passing style.

Jonathan:
Yeah.

Sandy:
Is there a relationship there that you're aware of?

Jonathan:
I think that co-data is connected to continuation passing style. I think if you
look at final tagless encoding, I think that might be co-data and this relates
back to the category theory of it, where code data is a final co-algebra and
data is, I think, an algebra or an initial algebra. I'm probably getting that
wrong. There's actually a really great tweet recently by someone on Twitter,
I forgot their handle. But they're talking about how lenses describe
co-algebraic composition, so, lenses are just composition of co-data. And then
it all makes sense, because in object-oriented land accessing nested structure
is really easy. You just chain dots. And in Haskell, it's pretty hard and it's
because you're trying to talk about co-data composition in a database language.

Sandy:
That's a really interesting insight. I think I'm going to need to wrestle with
that a little further, maybe offline.

Jonathan:
Yeah.

Sandy:
Maybe see that the-

Jonathan:
I think it's, yeah, lenses are co-data composition.

Sandy:
To pop the stack a little bit, I was wondering what do you think makes a good
programming coach? And is that the same as what makes a good coach in the more
general sense?

Jonathan:
So, I think in a general sense, a good coach is someone who understands your
goals and helps you get there. So, that might have been why there was a little
bit of friction between me and Jimmy. Granted every session was great and he's
a great coach, but it didn't get me closer to getting a Haskell job, which
I needed to be honest about being my ultimate goal. I think being a programming
coach is particularly hard, because programming is really overloaded. There is
programming in the sense of a boot camp student who wants to just write React,
and that's totally fair.

Jonathan:
And there's functional. There's different disciplines of programming that you
can learn about. There's an academic aspect to programming. And so, it's really
unclear what you want to get good at. And there's also like just software
engineering principles in general, which is a fuzzy discipline. It's really
hard to nail down, but is obviously fairly important. And then on top of that,
all these things bleed into each other.

Jonathan:
And you can even see that from my investigation into co-data where it became
obvious that okay, at the core of co-data, there's something about abstraction.
Abstraction is this fuzzy notion in software engineering. It's a really
overloaded term. Those, I mean abstraction by putting an interface on
something, more like an existential type. That's actually how I did the co-data
encoding in Haskell was heavily using existentials.

Jonathan:
But you can see how the academic discipline of understanding co-data, final
co-algebras, initial algebras bleeds into this fuzzy idea of abstraction, which
is in some way related to interfaces and that's a huge aspect of software
engineering. So, it's really easy to blur the lines. It's really easy to talk
past each other. And it's really hard to move someone towards their goal and
even understand what they're trying to get out of the coaching session.

Sandy:
I've done a little tutoring myself, as the tutor and I found that was the
biggest challenge for me was trying to get a sense of what was the student's
goals. And so, it's nice to know that it's not just me who has that issue.

Jonathan:
Well, it's understanding their goals, and then it is also understanding how to
best move them forward. And also, hopefully, your skills align with their
goals. It's very easy, I think, as a coach to try and push the student towards
what you're interested in. And it's very hard to genuinely engage with them on
their terms about what they're interested in. Kind of reminds me of
a therapist. When you go to a therapist, a good therapist will not say what you
want to hear. They'll help you come to a conclusion yourself. And I think it's
really hard to be unopinionated like that when you're talking about
programming.

Sandy:
So, being a software engineer is like being a-

Jonathan:
Being a therapist. No, no, no. No, no, no. We just all need therapists.

Sandy:
You put together the Toronto Haskell Meetup and it sounds like inadvertently,
you did quite a lot of tutoring through that. And I would love to hear the
story of how it got put together and what happened there.

Jonathan:
Toronto actually has a surprising lack of functional programming. There's
a couple of closure companies, but there's not a lot of strongly-typed
functional programming. And because of that, there's not a lot of a community
around it. When I looked into it, when I was getting serious about Haskell and
really want to get better. Obviously, if I'm going to pay a coach, I'm also
going to go and seek out the community and try and get better that way. And it
wasn't there, but I found remnants of it. There was an old Google Groups about
a Haskell Meetup from five years ago. There was a secret CS cabal that
I couldn't really figure out how to get an invitation to.

Sandy:
That's what makes it a secret.

Jonathan:
Yeah, exactly. So I said, "Okay, if I can't find the community, I'll just
create one. There's obviously people who know this stuff in the city, because
there's the old groups. So, I'll just make the meetup and then all these
experienced Haskellers will come and I'll get really good at Haskell." And
obviously, it wasn't the case, so but when I made the Haskell Meetup, it became
very clear that there's a lot of people who know nothing about Haskell who are
very interested in learning it. And those were all the people who came. Lots of
people who hadn't coded in Haskell ever or people who are on the same level as
me who are going through learning a Haskell and the classic Haskell learning
materials.

Jonathan:
So, I ended up having to lead most of the meetups. And I remember my poor
girlfriend at that time, Claire, I was slaving away all week to learn material
to present at the meetup. And then I'd be gone for three hours during the
actual meetup, I'd come home and bring her cold pizza from the meetup. But
yeah, I basically, ended up doing a lot of teaching, and it was really good. It
really accelerated my learning, but it was a lot of work.

Sandy:
What do you think makes a good community?

Jonathan:
I mean, it all comes down to engaged community members. Luckily, there was
another developer who was maybe slightly ahead of me by a couple of months in
terms of this Haskell learning, who was also interested. And so, he shared the
burden of building the community. He came up with some of the ideas with me.
The community was good, but we had a very spotty attendance and that made it
really hard. It wasn't easy to predict how many people would come. It was hard
to get venues because I couldn't give concrete numbers. So obviously, an
engaged community.

Jonathan:
I think, what it takes to have an engaged community is consistency. So,
I noticed there was a huge uptick in attendance and repeat attendance when we
standardized on the day of the month that we would show up. And we were able to
get a more stable location that would host us for a couple of consecutive
months rather than having to get a different location every time. So, just your
goal as the person who's interested in building the community is to make sure
that you provide the foundation for an engaged community, I guess. And then an
engaged community is the key to a good community.

Sandy:
As a follow-up, how can members of a community contribute to the community? It
sounds like being engaged might be your number one answer on this? Is there
anything else that the members can do to help build it without necessarily
being organizers?

Jonathan:
Yeah, honestly, producing content is the biggest thing. I got a lot of thanks
for the pizza, I got a lot of thanks for finding the location, I got a lot of
thanks for being there early and staying late to close it down. But by far and
away, the biggest time commitment was generating the content. And so, if you
want to be an engaged community member, offering to give a talk is so important
or even offering opinions on how to direct the content. Because I found myself
a lot of the times, sending out polls on what people wanted to hear about and
nobody would respond. Yeah, so that's definitely the number one way to
contribute is providing content because it's the number one time suck.

Sandy:
How do you maintain motivation in that? It feels like you're producing so or
you're giving so much to a community and it feels like they might not be giving
back as much as you'd like. How do you maintain just excitement for it?

Jonathan:
Well, I think for me, it was dumb blind faith that Haskell is the answer.
I always say that I have like you know how people can hold three or five to
seven things in their head at once? I think my number is closer to three, but
Haskell holds a bunch of things in its head for me, so that's why I it so much.
It allows me to even function as a programmer. So, Haskell really did seem the
answer to all my problems, so I think that's what kept me going.

Jonathan:
Also, I think it's important to say that I was inspired by a lot of other great
Haskell communities. At that time, Haskell exchange was massive and I'm glad
they're back. Also, there's the New York Haskell Meetup was really active and
it was nice to see them. I think there was a smaller than the New York Haskell
Meetup, but there was a Vancouver Haskell Meetup. So, it was nice to see
a reference point within Canada to go off of. So I think the other Haskell
communities offered a lot of inspiration. And at that time, I was on house for
FP Slack a lot. And so, that was nice to see as well, like a digital
correspondence community. So yeah, I think the outer communities were the most
inspiring part.

Sandy:
One of the issues I find with Haskell is everybody who engages with it seems to
really love it but there almost aren't any meccas, right? Almost all of it is
online. And do you have any advice for people who'd want to try and build
a Haskell community locally, in order to get more of that, that vibe in person?

Jonathan:
I don't think that it makes sense to have one overarching Haskell Mecca.
I don't think it will ever work out. I think people need to find communities
that can better shape themselves to the needs of the individual users. So, for
example, Toronto Haskell group is a great example where we were comprised of
beginners. I desperately wanted us to be a bunch of expert Haskellers and for
me to be the dumbest person in the room, and therefore, learn really quickly.
But that just simply wasn't the case, so I had to tailor the content. So,
that's like a little aside about a Haskell Mecca.

Jonathan:
But building local communities, I think it's important to listen and engage
with the community members. It is very similar to AB testing or user interviews
from an industrial perspective. It's important to have constant touch points to
make sure that you're actually accomplishing something worth doing. And then
also, it's really helpful to find larger organizations that can help you out.
So, I was lucky.

Jonathan:
I had to find a ton of spots to host it, but there was a tiny crypto exchange
that did Haskell and so, they hosted us a couple of times. There was
a university where there was a PhD professor who was into Haskell. And so, she
let us use a room in the university for a little bit. There was a Scala company
that was desperately trying to hire, so I tricked them into letting us use
their office. So, these larger organizations definitely helped.

Jonathan:
The other one I was looking for was to embed the Haskell meetup within another
larger community. So, I was looking for something like there's a closure
community. I went to a couple of their meetups. It turned out, they were having
some of the same problems as us, so I couldn't really turn to them for help,
but I was looking in that direction. So I think, yeah, if you can find a big
brother to take care of you that can help you get the community off the ground.

Sandy:
About getting into programming, you said a quote, "Deep down, I had this
reverence for Philosophy. I truly believed it was a great foundation that set
me up for success." What did you mean by that?

Jonathan:
It was the direct subject or the subjects that directly map to something in
programming like analytic philosophy, logics, that kind of stuff. But I also
think, some of the softer philosophical disciplines like ethics, theories of
justice, meta ethics can be very useful as well. So, maybe I'll break down meta
or metaphysics, philosophy of language, and analytic philosophy are all
extremely logic based and very heavily formalized. You could probably even use
theorem provers to help you write a paper in those disciplines.

Jonathan:
And then there's the history of Philosophy, which is a bit soft. There's
a Philosophy of the mind. There's the schools of ethics and those are a bit
softer. But what those really helped me with was being able to hold two
positions in the same argument at once. So being able to, it's not quite
looking at something objectively, because especially with ethics, there's
really no objective answer.

Jonathan:
But being able to entertain an alternate position to your own, I think is
a really useful skill. I think it translates to programming really well,
because there's multiple ways of encoding the same thing and they're arguably
equally as good. And so being able to, sit there and maintain both perspectives
can be useful. It's also just useful like human skill to be able to see
arguments from the other person's side. But yeah, I definitely think that's
helped me on my programming journey.

Sandy:
In retrospect, do you think that your reverence for Philosophy was well placed?

Jonathan:
A lot of it is a bit silly. I mean, I think I even felt this at that time that
you're studying things that are patently wrong. You know that Plato had this
conception of the Earth as a plenum, which is a solid physical mass. And the
only thing that that caused there to be different textures and different
densities was the swirling currents of this mass. So, he talked about rivers
and eddies, and that was what made things hard or not and it's just obviously
wrong. I mean, it's not entirely wrong if you think of air as being just less
dense particles. But the way that Plato meant it, it was wrong.

Jonathan:
So, there's something that that does feel a bit silly about that. At the same
time, I think there is a redeeming quality in being able to just like treat it
metaphorically or trying to read it graciously. I mean, it's definitely
interesting from a historical perspective. But I guess, to answer your
question, I think that there are a couple of disciplines in Philosophy that are
really worthwhile like logic, meta ethics, maybe ethics, those things.
Philosophy of language is really good.

Jonathan:
But there's a lot that if you're looking for something that's practical, even
from the [inaudible 00:49:39] definition of what philosophers would call
practical. You're just looking in the wrong place. Actually, that there was an
initiative in the Humanities Department at my alma mater to add a coding liner
where they, because they're having trouble getting people into the Humanities.
There's a lot of people saying there's no jobs, which there isn't, so they're
trying to add coding.

Jonathan:
And I thought that was just completely wrong. I thought, I'm like, "You're just
deceiving people. If you want to do programming, do computer science, do a boot
camp. Learn yourself. Don't do a philosophy degree with a computer science
minor." It's just not going to, and it wasn't even a computer science minor,
I think it was a couple of courses and they would call it Humanities with
Engineering or something like that. It felt very silly to me.

Sandy:
True or false, Philosophy is just poorly done computer science?

Jonathan:
I'd say false, because I think that there is a more human aspect that is
interesting to get into. I think early on in the conversation, I talked about
people enjoying the ambiguity of language, specifically, I'm thinking of
English. English is an incredibly ambiguous language. And I think there is
something to be said for living in ambiguity. I think a lot of very powerful
art comes from the fact that the interpretation is ambiguous. So, I do think
there is room for Philosophy.

Jonathan:
On a related note, they used to say in the Philosophy Department, if Philosophy
has done its job right then you no longer need philosophy. And what they meant
is that early on, we had natural philosophers, but Philosophy did its job in
establishing a foundation and they became scientists, and you no longer need
philosophers. You have Philosophy of science, which is like a meta study, but
hopefully, that will do its job correctly and obviate itself as well. So,
I think Philosophy has this contradictory role where it's used to talk about
things that we have imperfect knowledge about. And then as we refine our view
of the subject, Philosophy very kindly takes a backseat and the applied
professionals takeover.

Sandy:
That makes a lot of sense to me. Thanks. You said that one of the best skills
of your philosophy training was the ability to entertain positions that you
don't necessarily believe in. What do you mean by that? And why is that an
important skill?

Jonathan:
So, maybe I can come up with a motivating example, first and then I'll try and
relate it to software. There's the obvious case where it's a debate where there
it's like, "Yes, this is right or no, this is wrong." And to be able to argue
both sides is clearly against you. But another one is when it's ambiguous or
you're entertaining models of the world that you know are incorrect, but it's
worthwhile to entertain the model anyway.

Jonathan:
So, a good example is in meta ethics. So, ethics is like, "Are you
a utilitarian? Are you a deontologist? Do you believe in maximizing the goo and
that's a normative structure? Or do you believe in these hard and fast rules
that you should obey and that dictate what's good or bad?" Meta ethics is like,
"How do we even talk about normativity? How do we even talk about what's good
or bad?" And so there, there was these school of emotivists who said that any
ethical phrase is actually just an exclamation of emotion. It's not even true
fact.

Jonathan:
So when you say like, "Hey, don't steal my bike," that's a moral claim. You're
saying, "It's unethical to steal my bike." The emotivist would say that that's
tantamount to going, "Urg, I'm unhappy that you're stealing my bike," which is
a funny thing to think about. Then there's the realists who go like, "No,
ethics is real and objective, and it's out there in the world." And when you
say, "Hey, don't steal my bike," you're saying, "Hey, there is a fundamental
law, whether it's maximizing the good or the principle that you shall not
steal, but you're breaking it."

Jonathan:
And so, these factions battled back and forth and the prevailing thought
nowadays, or at least back when I studied philosophy was error theory, which is
basically, that when you make an ethical claim, that is just wrong. That is not
true fact. You can't say, "Yes, it's good that they're stealing the bike, or
no, they're bad that they're stealing the bike." It's more like, "Hey, can you
close the door?" That's a statement that is neither true or false, it just is.
You're saying, "Hey, don't steal my bike." And so, the error theorists
acknowledge that it is an error to make an ethically charged claim, but it's
useful to conduct ourselves as if it's real.

Sandy:
Is the error here sort of a type error, in some sense?

Jonathan:
That's interesting. I didn't think of it as a type error, like an undefined
behavior maybe. I don't know. It's funny to think of, to look back on a subject
or a question that I found really interesting and apply what I know about
computers to that now. But the path that I was going with that is that these
error theorists live in this counterfactual world where they say, "Well, if it
makes sense to make an ethical claim, what is the fallout from that? Am I then
a utilitarian? Am I done with deontologist?"

Jonathan:
And it gives you this foundation to speak about ethics, even if the foundation
is somewhat shaky. So, you're able to not throw everything away while still
remaining logically consistent. And there's like it goes back to this two horns
problem and all of this stuff. But the interesting part is being able to hold
those that contradictory idea in your head and still make progress. So, that's
the concrete example.

Jonathan:
How does that apply to software? I think program design is often about forks in
your or decisions that you have to make about your program, but forks as you
move forward. And so, being able to entertain two of those forking approaches
is really valuable. That's a clear concrete example, I think. I think what's
nice about type functional programming, to go on tangent, is that it allows you
to encode those counterfactuals or those maybe not counterfactuals,
hypotheticals about how your program could be in types, see how things play
out. It's like a more zoomed out view.

Jonathan:
And you can establish whether this is a good foundation to move forward and
make progress with or if you should abandon it for something else. So, it gives
you a shortcut. And there are ways, there are tricks with types. I think you
can use to hold to different possibilities or two different possible paths in
your program at once. I might be misleading here. I'm sure someone will call me
out. But I'm thinking of parameterizing a type argument and deferring that
decision to later. That's an interesting way to keep two possible
implementations of the program alive at once.

Sandy:
I strongly believe that a lot of engineering is just pushing decisions as late
as possible until you have more information. And it sounds like that's what
you're advocating here.

Jonathan:
Yeah, yeah, I think that's right. More, I mean, I do think that's right.
I think what I was getting at or why that's so useful to me is being able to
put that stuff, put those thoughts down into the program, have it checked for
me to make sure it's consistent with the rest of my view of the world, and
being able to forget it, and then focus on a more local problem. Because again,
I have a hard time keeping a lot of things in my head.

Sandy:
To take at what, it seems like a jump, but I promise I'm going to circle back
on, you've described a lot of working programmers as being "critical or being
too abstract or getting lost in the abstraction." I wonder what you meant by
that.

Jonathan:
I don't want to be too condescending of working programmers, but I feel like
there is this, I think it's more fear of less well-tested approaches. So,
I think concrete implementation of a solution is very easy to wrap your head
around and there's not as much risk. There's not as much architectural risk as
making a higher order implementation. I think working programmers are really
bad at accounting for risk in the opposite direction, which is the risk of
overwhelming complexity or not being able to reuse your code, or there's
a myriad of other risks. It reminds me of loss aversion to humans. It's like
we'd rather come up with a concrete implementation that works today as we
expect an implementation that we're familiar with, rather than risk
overwhelming ourselves in complexity tomorrow.

Sandy:
Right. And so to circle back, I'm wondering if you can steal man the position
that maybe all of this abstraction isn't necessary. And to entertain the
counterfactual and give me a convincing argument for the other side.

Jonathan:
It always comes down to the premature optimization problem, I think, is when
I've seen the argument play out. And I mean, so if I were to take the other
side of the argument, I think I would make that I would say that you're
worrying about a problem that doesn't even exist today. I do hate that when
that argument comes up, because I feel like it's equivocation of, I feel like
we could say, "Oh, premature optimization is inherently bad. An abstract
implementation is a premature optimization. Therefore, an abstract
implementation is inherently bad." And I find that argument plays out a lot and
I find it really frustrating because it ignores all of the nuance.

Jonathan:
I don't know. I think just the abstract implementations probably require more
upfront thought. And I think the trend in software engineering has moved
towards like shipping things fast and getting something out in front of
customers. So, I think we've lost a lot of that upfront for a thought. And so,
then I think the state of the art and the skill that industrial software
engineers are trained at is concrete implementation. So, it's like this
negative feedback cycle. I would love to champion interesting higher order
solutions in an industrial settings, but that remains to be seen, I guess.

Sandy:
That actually dovetails really well into my next question, which is what are
some of the lowest hanging fruits in civilization right now? And are there any
domains in which you think, are just waiting for a computing revolution, in the
sense of throwing computing at the industrial world and getting really good
rewards from it?

Jonathan:
Maybe, I can frame it a little bit differently. I have been experiencing
recently there's a lot of questions of the structure. Why is it not the case
that we do these things? So, one example is like, "Why is there not an
industrial strength database of the stripe of PostgreS, that has a logic
programming front end. Logic program, it's funny, because I used to have this
strong reverence for SQL. I thought, I was like, "It's a beautiful, it's a DSL.
It's declarative. It's super performant. I can learn it really easily. It's
great."

Jonathan:
But as I learned a little bit about logic programming, I realized that SQL is
it's like chess and logic programming has a very few things. It's got rules and
predicates and from that, you can build up these very expressive queries.
PostgreS has select, which can only go in a certain spot, and where, which has
to come after a group bob. But it's got all these peculiarities that I think
are irrelevant to what it's actually getting at. So, that's really interesting.
I know there are databases with logic programming front ends like Datomic, but
it seems like it just hasn't taken off at all.

Jonathan:
I'm interested in the work of the category theory database work. I was hoping
that maybe they'd be agnostic to a front end. That's pretty interesting to me.
I've been thinking a lot, too, about permissioning. I feel, sorry, these are
all very concrete examples. But they're the ones that I bump up against every
day because every web app that I've worked on has deferred the decision of
being parameterized over permissions. They'd already always move forward with
the assumption of one user type has access to everything. And in the end, they
have all these really ad hoc solutions that add permissions back in.

Jonathan:
And so, I've been trying to think like, "How can you get a really beautiful
declarative permissioning system that you can use from the beginning, and it
adds no technical overhead?" It's as easy as the single user implementation and
then you can, in the future, add permissions. And so, there's a really cool
library. I think, by Simspace called Avaleryar. It's a bit of a mouthful, but
it's a logic programming interface to permissions.

Jonathan:
And I think that's really compelling, like outsourcing your permissions to
maybe a separate service or something and you just ask a question. You add this
question to the beginning of every auction. "Hey, based on some environment, am
I able to do this action? Yes or no." And you run it through this rule system.
And it's probably very easy to test. You could probably print out nice
documents of what your permission system is. So, that's another concrete thing.

Jonathan:
I know it's all logic programming, but I think, really, that's an accident.
What I'm really interested in is how can we throw our computer science
knowledge at problems to make them more declarative and make it easier to make
higher order decisions or more abstract decisions up front.

Sandy:
I'm so sympathetic to that goal. What about in context outside of programming,
of society more in general? Maybe like could you see a world in which we throw
computation at law or decision making or monetary policy or that sort of thing?

Jonathan:
Yeah, actually, well, so I'm a bit embarrassed. But I'm interested, I do want
to start my own startup and there's a bunch of ethical things that fall out of
that about believing in the Silicon Valley's startup ecosystem and all this
stuff. But I guess, I really want to have an outsized impact on the world. And
so maybe, that's just a dream that never gets realized, but it's informed a lot
of my thinking. And one of the things that I've thought about a lot is
government. I believe you're in Canada, as well and so, you're probably keenly
aware of a lot of the government inefficiencies. And as painful as someone who
considers themselves very liberal and believes in government programs and
social programs, but I have a tough time with the inefficiency of government
and it's really hard to reconcile those two beliefs.

Jonathan:
So, I would love to use technology to make government more efficient and
I think that's really actually not that wild of an idea. One of my friends is
a government or was a government worker for a long time and she had to deal
with a botched payment system that they've spent billions of dollars on. And
I was like, "Payment systems are part and parcel for tech startups. It's
a solved problem." How did we spend all this money and not end up with
something usable, and basically have to scrap it? So, that's a very obvious
example.

Jonathan:
Another one that's been interesting to me is the health care system. Canada has
very progressive health care ideals. The healthcare system has a lot of
problems. How could we apply tech to that? There's a lot of things with file
formats being incompatible that causes a lot of stress and that just seems like
very low hanging fruit to me. Parsers are very easy to write in functional
programming languages, so that's probably why I see those problems as low
hanging fruit.

Jonathan:
And then the other one is taxes. I'm not sure that computation can solve this.
Even though you would think just get smarter computers that know all the rules
and have perfect information and have them work out the taxes. I think there's
also a responsibility of the government to simplify the tax code. I think that
complicated tax code provides weird edge cases for people to abuse. But maybe
it'd be interesting to work out from both angles and have the government
simplify the tax system and maybe some property-based testing for loopholes in
the taxes. That's a wild idea, but something that seems like it's directionally
correct. So, I think there's a lot of room for improvement in that area.

Sandy:
Are these particular problems that you could think of throwing a type system
at? It's one thing to say technology would help here, but do you have a sense
of what exactly or what might be a promising approach?

Jonathan:
I think definitely a type system would help with taxes. I wish I just got
a compiler error.

Sandy:
Rather than an audit.

Jonathan:
Yeah. Yeah, I mean, it's such that I think that's one of the beautiful things
of Haskell in particular is that there's so much, so many interesting avenues
of research like logic programming embedded in Haskell, property based testing,
really advanced expressive types. I think as Haskell programmers, we're exposed
to these really beautiful and elegant solutions. And you can't help but see
them in the real world, like a type system for the taxes, more property-based
tests.

Jonathan:
It would be nice if our taxes were algebraic in some way and we could just fold
over them and come up with a number at the end. Or if we could, if our tax
rebates could do some automated clearing when we combine them. It's like it's
easy to play this game of thinking of specific and interesting examples. The
harder thing is dealing with the governments in practice. So, I don't actually
think it's a computation problem, I think it's a people problem.

Sandy:
I think all problems are people problems, yeah.

Jonathan:
That's true. But I've told people who are entrepreneurs about the kinds of
ideas I have and almost unanimously, I'm met with the response like, "Don't do
anything that touches government." Because the whole thing with startups,
you're supposed to move fast and the government is very slow. So yeah, it seems
I've been told it's a nonstarter, but I'm still holding out hope.

Sandy:
So, Jonathan, something that really impresses me is your studiousness. Your
bookshelves are full of serious textbooks. What's your process for getting
through them? How do you stay focused, and what's your purpose?

Jonathan:
My process for getting through them is not that effective. I just, I buy
whatever books are interesting to me at that time. It helps me chart a path for
the learning that I want to do by buying books that are relevant to my
interests at that time. So for example, I've got a slew of category theory
books, but I've hardly gotten through the first one. I've got some startup
business-related books, and I'm starting to work through those. And I like to
give myself the option to read whatever's interesting to me at that time.

Jonathan:
A habit that I'm actually trying to get into is allowing myself to not get
through a book. Because what I've actually found is that is a lot of books are
not that great or not necessarily right for me at that time. So, allowing
myself to get a quarter or halfway through a book, realize that I'm facing more
friction than the benefit that I'm getting and put that down to start something
else has been really helpful. But yeah, I love books. I think that they're
really important. I think it's still a great way to learn. I try to augment my
reading with something else to help my retention.

Jonathan:
So for example, we have planned to read conceptual mathematics and we're going
to try and prove some of the some of the theorems in Agda. I think that's
great. I mean, there's something as simple as taking notes, but generally,
I try and come up with a crystallized artifact from my reading of the book. And
another good way to do that is a reading group and maybe record your sessions
or something like that. But just trying to push myself to be more active
because the flip side is it's very easy to just buy books and skim through them
and feel like you're making a lot of progress and ticking things off list. And
so, a large portion of my learning time has been spent trying to find ways to
not just tick off boxes, because it feels good.

Sandy:
I think that's extremely good advice. I find, often I don't have the self
control to put down a book where I will just push through it and then because
it's such an awful experience, I also have to stop reading in general. And so,
maybe I'll take some advice from you there.

Jonathan:
Yeah, a good example of that for me was Bartosz Milewsk's Category Theory for
Programmers. It's a bit of a tough book to get through because it wasn't
initially set up as a book. It's a series of blog posts, but I've come back to
that three or four times, where I got to a point where things really didn't
make sense and I pushed and put it down and then when I came back, I was able
to get a little bit further. And I still haven't finished the book, but that's
just an example of how, it doesn't necessarily mean that the book is bad, it
just, it might mean that you're not ready for that kind of material.

Sandy:
Yeah, and there's also this idea that not every book is going to be good for
everybody, right? And some people are going to just need different things from
different places. And so, to use something a little more existential, offline
you said that one of your fears about being a nonstandard programmer is that
you're unlikely to ever be best in class technically. And I'm wondering, what
is it that you meant by that? What does it mean to be best in class? And why is
that important to you?

Jonathan:
So, I'll start with why it's important to me. I think the whole point of this
game of life is to try and have as large of an impact as you can. In my case,
I'd like to have a positive impact on the quality of life of a large swath of
humans, so that's a rough, abstract goal. And so, I think the more interesting
part of that question is what does it mean to have to be best in class. And
what I realized is that with a lot of our peers, I'm A, very far behind just
from the time that I started learning programming. But also, I just don't run
in academic circles. I'm not reading papers as studiously or as frequently as
some of these people.

Jonathan:
And so, say being the best type theorist is it's something that I'm probably
never going to achieve, at least in our group. So, what I try to do is I try to
reframe the question or reframe the game and adjust the rules such that they're
conducive to me being best in class. I know that might sound like cheating, but
I do have a lot of experiences that I think provide me advantages over some of
the people that we run with. So for example, I do have a decent amount of
experience in software engineering roles. So, I probably am better at React
Eli's than some of these people.

Jonathan:
I also my philosophy background, I think is really helpful. And I think that
I do have some interpersonal skills and strikes that I can use to position
myself in a way that I can be best in class at something. And I think that's
really good, because hopefully, I can work with the type theorists and the
programming language experts, and the next experts and all those people. And we
can work together to achieve something greater than what we could have
individually. So, that's kind of the game I'm playing as I'm trying to figure
out how I can have a significant impact, reframe the rules such that it fits my
skill set, and then try and double down on my strengths.

Sandy:
Maybe a different way of saying that is you're more aware of where your
competitive advantages are and playing within them?

Jonathan:
Yeah, exactly, exactly.

Sandy:
So, one last question here for you, Jonathan. And that is, what ideas do you
think more people should understand or be aware of? And I don't mean like
programming ideas, but what big life ideas do you suggest that people pay
attention to?

Jonathan:
There's something that I've been thinking about a lot particularly with some of
the group circles that I run in. Some of the groups that are interested in
these more abstract philosophical ideas in computer science. And what I'm
seeing is that there's a lot of really smart academically minded people that
are really comfortable playing around in their abstract ideas. They're happy to
talk to each other about structures that seem like they have no application to
the real world. And I think that we could maybe do with pushing ourselves to
try and apply those ideas or even to just try and apply ourselves to more
practical problems and push ourselves to collaborate and come up with something
more serious.

Jonathan:
It's obviously very scary to try and set a goal because as soon as or to set
a real world goal with implications and that's very concrete as to whether
you've achieved it or not, because then you necessarily invite the possibility
for failure. And I guess what I'm saying is I would suggest that maybe we'd be
more courageous and expose ourselves to the chance of failure more because I do
think that the payoff is worth it. And I do think we complain a lot about the
state of affairs of society, and I think we're more than capable to affect the
changes that we want to see.

Sandy:
That as a fantastic answer. And thank you so much for being on the podcast
today, Jonathan. Really appreciate you being here.

Jonathan:
Thank you, Sandy.