A podcast about software development and developing ourselves as software engineers. Hosted by CJ Avilla and Colin Loretz.
Colin: Welcome to Build and Learn.
My name is Colin.
CJ: And I'm CJ and we are excited
to sit down with Alan Trive today,
the founder and CEO of En Groc.
We're gonna talk about.
The future of software development.
We're gonna talk about how Enro is
solving all of your problems and
abstracting away the tricky parts of
networking and building your application.
We'll talk about global ingress
and lots of other fun stuff.
So let's get into the episode.
Colin: A lot of our clients were
like, Hey, we have Salesforce and we.
have these new iPhone things that
came out and we want an app that's,
tying into our C R M and our cms.
And so it was doing a lot
of, early web hook stuff.
a lot of pubsub, hubub and like
integrations and getting into
ultimately what brought me into
Techstars was we were trying to build
what eventually became like Zapier.
a little bit more like a SendGrid
for integrations though, or Twilio,
like you drop us into your code
base and turns out, you have to
raise a lot of money for people to
want to drop an entire integration
framework into their code base.
But, yeah, mostly a lot of the
things that you guys have run into
with like web hooks.fyi and things
where it's like everyone does this
differently and so we're gonna
make the one API that standardizes
all of it and turns out, in 20.
12 you.
It just wasn't the same as it is today.
And now you have like APIs coming
out that are trying to do this again,
like Merge and Finch and all these
different apps that are going after,
these are all the payroll APIs.
Here's one API to do all payroll APIs.
We were like trying to do all
of them and it was just a lot.
And I think that's where I, I've been in
the webhooks Google group since whenever,
at first, whenever Jeff started that.
So it's I've just been like
on the edges of just watching,
message passing on the internet.
Just still the same, still happens still,
Alan: hasn't changed too much.
Yeah.
Do you know Jeff?
Colin: just a little bit.
we've got some like shared, co-working
background and web hooks and things,
Alan: yeah.
I worked with Jeff back at Twilio.
yeah, it's interesting.
That's, it's definitely interesting, what
you're talking about, a building, an API
that like covers up, a bunch of APIs.
It's.
Kind of like the industry creating a
standard or someone in the industry
trying to create a standard api.
I'm pretty skeptical of those.
I think, if you look at technologies like.
Terraform where it would've been
really easy for them to say there's
a storage bucket resource and we'll
abstract it over GCP and Azure and aws.
And they like explicitly chose not to
do it because I think they recognized,
and I think a lot of other people
have recognized that it is very, very
hard to abstract around those APIs.
It's incredibly hard.
You'd need
something to be like almost, purely a
commodity and very little differentiation
before that thing starts to make sense.
Colin: and most of those services are
trying to differentiate, and so they all
come out with what makes them different.
And then
Alan: Exactly.
So you're not aligned.
right.
Um, which is, which is
really interesting as well.
CJ: Even with even with
standards like OAuth, right?
Like I assume you're running into that
now trying to build like the OAuth
pieces to the ngrok infrastructures.
oh yeah, we wanna do OAuth.
But everyone does it just a little
bit differently with little different
scopes and a little different, like
data you get back and a little bit of
different, is it in the header or is
it in like the response or whatever?
Yeah, just trying to paper
over that seems impossible.
Alan: Yeah.
it's interesting, just for those
listening, EDRO, has added some
recent capabilities where you can
basically put OAuth in front of
anything that you expose via edro.
You basically tell it, put
Google in front and it will
OAuth or redirect you to Google.
and then back.
we've implemented a number of
different providers, for OAuth.
And you're right, that it's
interesting the OAuth spec.
Is mostly followed by everyone to the
point where like you can pretty much build
the same thing and it works for everyone.
The place where all the providers
differ is around things that
the spec very explicitly says,
this is not our problem, right?
this is implementation defined,
and so like you go figure it out.
and so that makes sense that
everyone like has diverged there
into like slightly different ways.
And for the identity piece, of course,
like a bunch of folks got together and
said cool, let's standardize the scopes
and the thing that's returned into what
has become open, ID connect, on top of
OAuth, but even within the, so like within
the spec, yes, there are some places
where it definitely differs a little bit.
the place where we saw the most
deviation from the spec was, air codes.
Air codes are the
least well followed thing,
in the spec.
They're the place where the spec says what
is correct, or like what is to be expected
and the least people actually
implement it correctly.
Whereas scopes, everyone does a
different thing, but the spec says, You
can do whatever you want with scopes.
They're entirely yours to define.
So that makes sense.
But the
air codes are one where the spec
has some opinions and it's still
not tremendously well followed.
CJ: I watched some of your talk at
that conference about error handling,
and I'm curious if this was like part
of it, but basically that like I feel
like errors are so often just like a.
a second.
I don't know, the, it's like a last minute
thing that, yeah, it's an afterthought.
And Deb's tried to throw it in
like at the last second, oh, let's
add some air handling or whatever.
But the reality is that they should
be treated as a first class citizen,
the same way you're treating a return
type or whatever from any method.
Alan: it's one of the things that I'm most
proud of about, the internal architecture
of Enro is our error handling system.
Every, and I think I talk
about it a little bit at, In
the talk from that conference.
but I don't go into,
quite a lot of detail.
There is every single error that N
Rock returns and every one of them.
Every, sorry, user facing error.
Something that we expect a user
to see has a unique error code
that is defined in we have a.
Essentially like a big manifest where
every single error that the product
returns is defined in there, which is
at this point, like thousands, right?
and so there's a unique code for everyone.
And our system basically like reads that
manifest and then like code generates
type safe findings to all the different
languages, that we use internally.
For folks to spit out, errors
that, use that particular, format.
it's really meaningful because, those,
the things that are returned are objects
that are specially annotated, so you
know that they're a user facing air code.
So all the air handling
can treat them differently.
There can be special metrics around them
and really, really beneficial from a.
You know, from a product management
standpoint of like, you can go and
like into our observability and
you're like, what do people, what's
the air people hit the most cool.
we know, right?
Like we absolutely know
exactly what that is.
We know the biggest stumbling
block to using the product.
and so if you think about like growth or
just, user experience, understanding what.
What people are doing
wrong is, is super helpful.
the other place where it really,
provides a tremendous amount of benefit
is, from a customer success, customer
support standpoint of, what we're
trying to do there is make sure that
when people write in, there's nothing
more frustrating than getting an error
report where someone's it doesn't work.
And here's vaguely the error that I
got, and you're like, I can't help you.
Like I have to like, send you a
bunch of emails to ask you like how
to duplicate it and please tell me.
but when
people send us an air code, we know
exactly like the line of code where
like they, they encountered the air,
which is really beneficial to getting
quickly to the root of the problem.
so couple, couple huge benefits that way.
And the last one is, really.
Developers, like when we encount
an air message, like what is the
first thing that you guys do?
you copy and paste that thing
into Google and you're like, what?
What shows up?
and we wanted those things to
be unique strings that you could
put into Google that no one
else on the internet would have.
So you put them into Google and you get
back like our air pages where we can give
you like the best documentation, tell
you exactly like what went wrong and how
to help yourself get out of whatever,
you know, area you were encountering.
Colin: That's awesome.
Yeah.
I think a lot of people think of like an
API or software as like having a contract
and we think about all the things that can
go right, but we don't spend as much time
thinking about, like you just mentioned,
to the error codes, the contract of
what happens when something's wrong.
how do we help write a guide or
even just include the information
in the error itself on what.
What is missing?
What needs to happen next?
having written lots of APIs, it's
okay, if I'm trying to create
something, what do we send back?
If you're missing data, what do
we send back if it's already been
created, like the, obviously we have
HTTP status codes and things, but even
those can be, pretty vague at times.
And you gotta come up with
these like first class.
Error objects.
I know some APIs and client libraries
do a really good job of this.
and it's obviously you guys have a
high, high bar for that developer
experience when you do that.
since we're just jumping in here.
would love to just set the
stage for people who might
not know what ING Groc is.
I think most people
aren't familiar with it.
for things like local ingress for, I
have a rail server running on port 3000
and I want to op, add that to the web.
I wanna expose that to,
to receive web hooks.
Or maybe I want to have a preview app
so that CJ can go hit this endpoint
and view the app that I'm running.
But what would you add to that?
what does enro look like today?
and what are developers using it for?
Alan: thanks so much for that intro.
That's, really helpful.
yeah, en groc, that's definitely
where En Groc started was, about.
Where we started was web
hook development and testing.
I started my professional
career at Twilio, one of the
companies on the forefront of
using web hooks to drive behavior.
And, just, it was a frustrating
experience to develop with, develop
on that platform if you couldn't
get those web hooks directly to
things that were running locally.
over the years, what we.
What we found and discovered was if
you think more broadly about that
problem that Enro was solving, Enro
was creating ingress to your local.
machine, right?
It was accepting traffic from the internet
and it was routing it to the application
that was running on your laptop.
But that's really just one specific
problem in a more general problem,
which is how do I get traffic from
the internet and send it to my
application running anywhere, right?
It could be running on my laptop, it
could be running on my raspberry pie.
It could be running in a container in a CI
job for 30 minutes, or it could be running
in production, serving I don't know, all
of reddit.com or whatever it happens to
be, but like fundamentally the problem.
Of getting traffic in from the internet
and routing it to your application is the
same no matter, sorry, it is different,
but the kind of like fundamental primitive
that you use to do it, is the same.
in, interestingly, I guess I'll walk
that back a little bit, is that, that,
what's happening is very similar, but
the tools that developers have, to use
to actually make it happen in those
like four different scenarios that I
outlined are all wildly different, right?
and that's really where we've moved
over time is, to start handling this
production traffic to being part of
your, production infrastructure, your
CI infrastructure to create ingress
to your applications no matter when
or how or where they're running.
It doesn't matter what
platform or any of that.
it's very frustrating for developers
to have something that works in
development and not being able to
take it to production, have to like
invent something entirely new to get
there, and that's really what we're,
we're trying to solve for folks.
CJ: It seems like the messaging.
That.
I think a lot of people are still
thinking when they hear Enro, they
continue to think of like, how do I
build a local tunnel to my machine?
But I think the key sort of message that
I have heard, like the shift is oh, Enro
isn't just for local development anymore.
Like Enro can be used anywhere to do
this global ingress to your application.
So you can like, Stop worrying about
your whatever reverse proxy solution
that you're cobbling together instead.
is that accurate that you could
think of enro maybe the way that I
think of it as another way to do the
same thing that N Engine X might do.
And obviously as someone who wants
to spend time building on the
web, I am not fiddling with devs.
Like I actually hate N Engine X
just because it's such a pain to, to
get everything right and, so yeah,
just how can we think about Enoc
relative to a tool like Engine X?
Alan: that's a really good intro.
yeah, what we're calling Enro
is ingress as a service, right?
It is, it is that piece of getting traffic
into your network, and or into your
application and basically running it as
a globally distributed service for you.
you were asking about nGenx.
It's interesting that is, if you're like
putting applications out on the internet,
that is certainly a piece, right?
Where That you're using to
do it, but you often have a
number of other pieces, right?
You're layering in front maybe
a content delivery network.
You're maybe layering in front
some kind of, DDoS protection.
you may be layering in front,
some kind of like caching proxy.
You might have an identity aware proxy to
do some piece of authentication for you.
You often have like layer
four firewall rules.
You have ips and TLS certificates,
and maybe an integration with Let's
Encrypt and the list goes on where
you're like, as a, I remember, being,
baby application developer, like
back in the day and learning, Apache
and then Engine X to put my web
applications on the internet and just
being frustrated that it was something
that like I didn't want to learn.
And I didn't like, it wasn't like core to
the thing that I was doing that I wanted
to deliver, which was the application.
And that's really the power is like
we're, enro is talking about collapsing
all of those into a unified layer that
is tremendously developer friendly for
you to basically put your application
on and on the internet, in a way that
you want, secured in the way that
you want, without you having to worry
about all of those low level pieces.
The analogy that, we've been using is
that to put applications on the internet.
you're working with, like the
assembly language of networking.
you're really working with a lot
of these low level primitives
like DNS and tcp, and, ips and.
TLS certificates and things that
as an application developer like
you don't really care about, right?
you want a domain with, you know, an HTPs
s certificate in front of it to receive
the traffic closest to your customers
and maybe enforce some policy, some
authentication and things like that.
But the infrastructure run it and
the configuration to it should be.
A lot simpler than it is right now.
And we're, what we think we're
doing, at enro is really building
that high level language to
abstract that, assembly language.
CJ: I feel like there is a trend in
modern development where it's Let's
give you these drop-in tools or drop-in
components that replace like a lot of work
that you otherwise would've had to do.
So on the, for the Stripe example,
you're getting these embedable payment
components where you can just drop
in some React component and that will
give you these secure eye frames that.
Will handle lots of like validation
and collecting different payment
method types and localizing, and
it's like offloading a lot of the
work of collecting payment to Stripe.
And in this case it's like offloading
a lot of the network level things to
en groc where you can just install
this agent, set up some connect
handlers and, it seems like you've got.
Go and rust.
And I saw some hints of
maybe JavaScript coming soon.
so it's a couple of lines that you add
when you're setting up your server that's
gonna listen and then from there en rock
will handle abstracting away or offloading
like all of this other complexity.
And one of the things that I'm like
curious to double click on is, The, the,
I think you call them points of presence
maybe, or the global globally distributed
concept here, and like, how should we
think about that relative to like edge
functions or Dino deploy or, like having,
yeah, having your, your, your application
deployed to the edge versus having ingress
happening at the edge and then routing
that to some server that might be, Living
in Virginia or Washington or something.
Alan: that's a good question.
you're right.
We've built the Go and Rust SDKs.
We're working on a couple of other ones.
Those are a more modern way of
using NRO that, I don't think a
lot of people are familiar with,
where you're basically embedding
NRO directly into your application.
You don't have this, if you're like used
to using it, you used to have a separate
executable that you would download and now
you have a library where you basically,
Ask and it returns to something that looks
and feels exactly like a socket object.
but it's not listening on a local port.
It's listening on all of our global
points of presence all around the world.
in terms of like how to think about
it versus edge functions, or like
deploying your application to the edge.
what I would say is.
When you're building an application,
sometimes deploying applications
to the edge makes sense, and
sometimes like having them, not
deployed to the edge makes sense.
deploying them to the edge comes with,
basically puts you in the space of as
soon as you have to talk to storage,
you have the problem of cool, I have a
globally distributed storage problem.
r really, I think where
we're going to end up.
Is, there are two possible futures there.
One is, one in which like our
storage layers become so good that
we can run our entire applications
like fully distributed at the edge.
And like all of the synchronization
problems happen in like this
global storage layer, right?
Of what is like the next iteration of
something like spanner and is it good
enough that We can commoditize it and
give developers really simple APIs
where they can just call this stuff
anywhere around the world and give
them, hopefully the right APIs to make.
Cuz you know, even with a system like
Spanner, you still, the application
developer is making the, like the kind
of like cap theory trade-offs, right?
Of do I want consistency?
Do I want, availability,
partition tolerance.
that's one world.
the other is, that we think about
applications being, a little more.
Amorphous in terms of being able
to be split between an origin
application and a piece of it that
it, it pushes out to the global edge.
And like right now, I think a lot of
developers are thinking about those
in like separate ways, but, one of
the things that we're really excited
about, things like the End Rock
SDKs allowing you to do is you can
specify a lot of the configuration
in those SDKs and they get pushed.
To our global edge.
and that's something that's like a stark
contrast to like setting things up with
a technology like engine X or something
like that in that the application in our
world has control over the edge, right?
It has a defined API to say, like,
when I come online, like the.
The reverse proxy, the ingress point
is an extension of the application.
I have an API to set up and control
that in the way that I want.
and I think that will get us into a
world where applications, Can push
configuration and logic, basically
having like pieces of wassom or stuff
that they're like, yeah, you can execute
this out at the global edge because, it
doesn't require like stateful handling
or it requires a minimal amount of local
stateful handling or things like that.
and so we're we'll end up giving
developers a little bit more of a
seamless experience where they have the
control to basically decide, this stuff
runs there and this stuff runs, here.
CJ: Got it.
So you could terminate, ssl, and you can
do your authentication checks and you can.
Do some basic things at the edge, and
then once you've handled that, then
and when you're ready to talk to the
database, then you could like, all
right, now we will make the trek,
the tcp trek all the way across the
internet and talk to the underlying
the underlying application server.
Alan: Yeah, that, that
may be the right model.
It may not be the right model.
it's a little hard to say at,
at this point, but, I think it's
like one of those two models or
like a hybrid of them where you're
pushing like some control out there.
cuz like at the end of the day
you're just making these trade
offs about, you're just making
distributed systems trade-offs, right?
Have you guys like, in, in your
development, it sounds like we
were talking a little bit at the
beginning about, the kind of,
development that you're doing.
CJ you said you were doing a lot of kind
of like web application development, a
lot of, backend stuff, things like Ruby
on Rails, but also some front end pieces.
And Colin, you said you, you'd been
doing, some similar things as well.
I'm curious, do both of you like
have that experience of working
with, with those kind of, of like
setting that stuff up yourselves?
Or did you end up like working
with other people who would
set those things up for you?
Colin: For me it was, usually
I'm the one on a team, like for
consulting and things like that.
Before I was at Orbit, it was not
having an infrastructure or DevOps team.
So I was doing everything myself.
And you really get to learn and
appreciate like, All the things that
not only do you have to learn them once,
but you have to learn them for each
clot provider or each, infrastructure
stack that you're working with.
So the, and then you end up feeling
like you're learning this stuff over
again each time, or there's like a small
differentiation that makes this one better
than the other one that you used to is.
and so I do like that idea, like
standardizing it cuz we're seeing a lot.
It'll be interesting to see, like
a lot of things have been being
automated, I guess is the right word.
But like with GitHub co-pilot and
LLMs, like everyone's so excited about
the idea that we're gonna not have
to write every line of code anymore.
But it's guess what?
There's now even more infrastructure
and more tools and more stuff in between
those apps that we have to deal with
there's definitely a lot of tools that
I'm starting to see that with like
secure data transfer and stuff like that.
It's I definitely don't
wanna do that myself.
if you were to build an app like
a WhatsApp today with having like
end-to-end encryption between two people
talking back and forth, and that might
be a product someone builds today.
Like what?
Tech stack makes sense there.
it's not quite the same thing that
we're talking about today around local
tunneling and things like that, but
it is a very similar thing where it's
let's say GitHub co-pilots helping me
build a chat app with like sockets and
things like that, you're in, you're
probably building a very insecure.
chat app to start or, internet
of Insecure things would be.
The other way to think of it is like a lot
of things get shipped with not a lot of
thought around the security piece of it.
and so I'm really excited to
see like what things we can
do to help automate and read.
We, approach those things, so
that they don't have to be scary.
I think, like I try not to do
the DevOps stuff these days.
I think the jokes of dev, oops, engineer
more than DevOps, its like, what check,
what one thing did I forget to look at?
What one, one setting did I forget
that, I'm thinking that I'm secure, but
like the front door's wide open, even
though I followed like this long list of
security and ingress, like checklists.
CJ: to give some people nightmares,
I think Back in the day, I would
go on Digital Ocean and spin up a
droplet and then just SSH into it and
manually set up, passenger and engine
X and Apache, like all these things.
And like immediately
started getting hacked.
Like just started to get pummeled
by spammers and whatever.
And then, if we, rewind even further,
I remember setting up, like on Windows
server, like setting up IIS to like,
open up certain ports so that they can
like, talk to different applications
and, someone re goes down into the
basement and restarts the physical
machine that was running Windows server.
It's okay, we've come
a long way since then.
And, even back.
pre this is pre and, en rock.
I'm sure.
It was like, oh, if I want to show
someone my local running web application,
I'm gonna log into my, lo my router
and set up, nat address forwarding
so that I can like, poke a hole in my
home router so that people can hit my
machine on, port 80, 80 or whatever.
So I think y most recently I've
been really depending a lot on
tools like Heroku and tools like
Versace to manage most of that.
And like more recently using things like
CloudFlare to provide, these really fancy
SSL termination things where I can have
wildcard domains and set up all of this,
I don't know, more advanced infrastructure
for building a platform, but, for the
most part, yeah, it's been one of those
things where I've been bitten so many
times by building insecure surfaces that,
I now try to just, stay in my lane and
build tools closer to the front end.
Then, then, yeah, I then I thought that
I could back in the day, I dunno, may,
maybe now I can just drop in en gro
Ruby and, depend on the security and
let Alan do all the heavy lifting of
figuring out how to not get attacked.
Alan: that's really what
we want, folks to do.
We, the reason, the kind of like engineer
that I've been for a very long time, and
the thing that like really has always
made me excited is about building a.
Tools and platforms and infrastructure for
developers so that there's nothing more
exciting than for me than like solving
problems and watching developers like
never have to deal with them ever again.
and that's, that ethos is really what
started N Groc and it's what continues it
today is, how do we take these problems
away, so that, folks don't have to
like, think about the things that they
definitely don't wanna be thinking about.
CJ: For
Colin: Yeah, and a lot of us have
these experiences of tinkering
and learning and I do wonder.
Because a lot of these newer tools
make it a little bit harder to tinker.
Like it's amazing to be able to deploy
to, a render a fly, but you're not
actually messing with the digital ocean
box like you, were talking about there.
But where do you then learn these things?
Because I don't like someone coming
out of a bootcamp might learn the
application stack, but they're not
necessarily getting a lot of time or
experience with some of this other stuff.
And, I haven't seen.
Too many dev like DevOps boot camps or
security boot camps, things like that.
cause that would even like a
finishing school for security, right?
it's something that I would take just to
know what gaps do I have in my knowledge.
Because very similarly, like anything,
we used to do a lot of WordPress stuff
and Any website with a slash WP admin
was just going to be added to a list that
was gonna get attacked at some point.
and then you start tinkering around with
Apache or Engine X and things like that.
but you actually could, it's kinda
like tinkering with cars like
you used to be able to actually
work on your car and today.
Very difficult to work on your own car.
And as we get to EVs and things, it's
gonna be near impossible too, especially
when, those cars are mostly software and,
a whole bunch of batteries, But, it, it'll
be interesting to see like where this
goes and what sorts of things, change.
Is there anything that like
you're particularly excited about?
Alan, as far as like maybe future
looking things or, not necessarily
add and groc or if there's stuff that
you guys are cooking up over there.
Alan: Oh man, there's so much
to be excited about today.
one of the things that's really excited
about is that, it's interesting what
you said about, folks don't have, they
don't, someone coming out of bootcamp
may not learn a lot of those things.
that's true.
But maybe that's okay.
Like maybe we're like headed for
a world where really that's okay.
and if you like rewind a little bit,
you're like, most developers like today
don't think about like memory management,
but we're all like, that's a nice thing.
Mo most of us don't really
want to think about that.
and most of us don't think in
assembly language anymore, and
like maybe that's okay too.
so I, I don't know it, there, there
are always these sets of problems that.
Every, everything in, in software
engineering is a leaky abstraction.
When your problem gets thorny
enough where you're like, I gotta
go below, I gotta understand like
the piece underneath and the piece
underneath and the piece underneath.
but I think, as the industry has matured
and our tools and our infrastructure
has gotten better, we have gotten
to a place where you have to get
into those layers less and less.
Just because we've gotten.
We've hardened those under underlying
layers and made the APIs to them so
much better than they used to be.
And I'm optimistic that a
lot of this stuff will, move
in that direction as well.
And that a lot of the problems that
we solve today of that, you would do
in like a DevOps finishing school if
one existed, are things that I hope
the next generation dev developers
like never has to think about.
and that there, there
are a few of us who like.
Spend our time there and that, if
people want to like, understand
those things, just like if someone
like wants to go and understand the
details of the Linux kernel, they
can, but if they're like building web
applications, like they shouldn't have
to and we shouldn't expect them to.
so I don't know.
I'm optimistic and excited about a future
where, those are, those become details
that folks don't have to think about.
So I'm really excited about this,
new generation of, NextGen Heroku
folks who are thinking about,
applications as a service again.
and.
Yeah, I don't know.
I'm excited about that.
What else am I excited about?
There's a lot to be excited
about in software engineering.
web assembly is certainly an area
that's obviously really exciting.
obviously LMS and ML in general are, a
really cool area to be excited about too.
So there's a lot that's going on.
CJ: One of the things that I've
noticed over the last, probably two
years-ish, is that there are a lot
of new developers coming online that
are building with tools like Relet
where they're actually like building
something in the cloud and running it
in the cloud, and that is where they're.
Hosting it and deploying
it and everything.
It's like part of rep.
And so I'm curious, if you have any
intuition or if you've seen the same
thing, around like the future of this next
gen of developers and will they just Yeah.
do we think everything is just gonna
be some cloud-based i d e and you
just say go, and then it's running
like for you and anyone can use it.
I don't know.
Especially like.
They have that ghost writer, kind of
their version of copilot that's built in.
So I don't know, there's some really
cool stuff happening over there.
.
Alan: this is, this is the space of
replica and code spaces and glitch
and that kind of like set of tools.
they're exciting.
in general, I think as an industry we
should be tremendously excited about
anything that lowers the barrier to
entry to creating new, new software.
and so in general, like.
that's what we're doing at Enro
is trying to lower that barrier
to entry, to like building
applications and getting them online.
and, really excited that you can use
Enro with platforms like Rep and Glitch
and things like that to get yourself
this, global ingress with, functionality
that can push out to the edge.
But in general, like.
Anything that lets people like lower
the vari entry and create new software
and get more people into, to the space
being creative and building new stuff.
I think, that's one of the things
that's most exciting about our
industry is getting to see all the
people experimenting with all of
the new and cool ways that, we could
potentially build software together.
That's all really exciting to me.
Colin: Yeah, I think we like to geek out
on the tools and the processes and things,
but ultimately we're doing all of this to
build like a product for customers, right?
And so sometimes it's Does the customer
actually know how we're getting
the web hooks delivered to the app?
They do not care.
they just want the outcome, right?
The, if it's a dog walking app, they,
or, Uber, your Uber driver's showing up.
Like you want to get a notification
when that's happening and,
they're not worried about what.
the infrastructure looks like underneath.
So I think, we tr we've been thinking
in this show in terms of like, how do
we build and learn, as developers, like
how do we develop ourselves, not just
yes we can go learn new languages and
things like that, but it's like, what
other things are we bringing to the table
and think, like thinking about product
and the developer experience all the
way down to what error codes do we get?
You know that's the same for a product.
if your Uber card just doesn't
show up, you can't just say
something happened, right?
It's gotta be like, why
did the car not show up?
And what can I do about it?
Who can I reach out to?
An Airbnb got canceled on me for this
weekend and it was like, You know, you get
a text that's your Airbnb was canceled,
and then you're like, great, now I gotta
go, follow the, literally the stack
trace of okay, go click on the link.
Let's go open Airbnb, let's
go find out what happened.
And, that is so far removed from whatever
tech stack Airbnb is using under the Hut.
So, um, definitely as you're listening to
this, remember who you're building for,
remember what you're building, like what
problem you're trying to solve for, and,
use tools like incorrect to Get rid of
some of those things, the headaches, or
at least make them standardized so that,
on the next project you work on, you
have, a tool that you can reach for sure.
Alan: Yeah, like I
said, I'm excited about.
any tools and any infrastructure
that, that make it easier?
I think they're all like places where gets
more people into software development.
It means more people
are trying new things.
we're as an industry, as a.
A, global populace, like the
speed of innovation is tied to how
quickly can we experiment, like
how many people can experiment.
And so as we see like these new
technologies and services that
lower that cost to experimentation,
we're getting more shots at
building more new and cool things.
And that's something that we
should all be really excited about.
CJ: Totally.
Yeah.
I think this also dovetails really
nicely with the whole no-code
movement, which we've talked a lot.
And I think, I, when I first thought about
NRO and no code, I thought, oh, there's
probably not that many people who are,
opening up the terminal and running NRO
and setting up a local tunnel so they
could do no code stuff because they're
probably using some application somewhere.
But the reality is that now
that might be part of their
stack in some way or another.
okay, we're, building this no code
thing with bubble, but I need.
I don't know.
I need to test something.
Yeah, I need to test
web hooks or whatever.
And, there, there was a bunch
of like use cases, I think.
That I, recently bumped into within groc
too, where I was like, oh, I want to
test something locally, but it needs to
have hdps s and I don't wanna have to
figure out how to set up my SSL cert.
And so I'm just gonna try on in
groc, cuz I know that it gives me
that Hdps s endpoint that I can
use instead so that I can go verify
my Apple Pay domain or whatever.
It's like a test, like some
Apple Pay thing locally.
So there's, yeah, I think there's, I
dunno, there, there's always gonna be like
use cases where people who are building
cool stuff are gonna need these tools.
But yeah, it is a incredibly
exciting time to be alive.
And I also like every time that GitHub
co-pilot completes anything for me that
is like non-trivial or more than a line,
I'm just like, whoa, this is so cool.
still, after a year of using it almost
every day, it's, it still blows my mind.
And, yeah, I think it is definitely
a really exciting time to be alive.
For sure.
Alan: I don't know that I've
talked to anyone who's used
GitHub co-pilot for a year.
do you feel faster when you use it?
CJ: Oh yeah, way faster.
I think that, so I, I initially
set it up in Neo Vim, so you don't
just have to use via vias code.
So if you're using Neo Vim, go download
T Pope's Get Hope co-pilot thing.
There's a way to set it up, and it
basically com like replaced all of my.
My sort of dumb auto completion.
and so now it's, it's very good
and I'm now at the point where
I'm learning type script and it
helps a ton with type script.
But circling back to one of your
earlier points about copying and
pasting errors, like the errors you get
from TypeScript are so they're, yeah.
They're impossible to understand.
They're possible to Google.
They're very challenging.
So I'm like, I feel like I'm still
on the frustrating part of the
learning curve with type script, but,
Colin: Are you getting, you're getting
some type is not a type errors.
CJ: Yeah.
Or it's always like something is not
any, you can't assign something to any,
cuz we, we have it, we have all of the
restrictions cranked, like really high.
So it has to be, yeah, all the types
have to be very happy with each other.
And but yeah, co-pilot has been
making all of that much, much faster.
And when I was at Stripe, we
were working in lots of different
programming languages, go php, java.net.
Ruby python.
It was, we were all over the place
in sw context switching between
them was sometimes tricky and GitHub
co-pilots like, oh yeah, I know that
language and I know that language.
Did I know that last, like, you know,
kind of the, uh, the Rosetta Stone for
you to sit there and help you through
okay, what is the syntax for this again?
but yeah, it's made, it's
definitely made me faster for sure.
Alan: It's, it's again, like another
thing that I'm like really excited
about because it fits into that same
theme of things that make software
development more accessible, right?
Things that give, and for those who
are, those of us who are already like
more seasoned software developers,
it gives us leverage, right?
To be able to like, move faster,
and build things that otherwise,
like maybe would've taken us longer.
Maybe we have to build a
team to build those things.
In some ways, a lot of modern software
development is constrained based on the
complexity of the things that we build.
And, the complexity of the applications
that we build, sorry, like the
functionality, like how much stuff
like an application can do is
constrained by like how complex of a.
Of like a code base you can manage.
And we've built, like so many
of our tools are just about
trying to manage that complexity.
Like how do we create abstractions so
we can hide some of that complexity
and not think about it as we like,
deal with the rest of the problem.
and like software engineering
and management, of like building
engineering organizations is about
like siloing that complexity like
within humans and within teams, right?
Of like, how do we create a team who
can own this like problem so the other
teams don't have to think about it?
And technologies like co-pilot are
really exciting because they give
everyone leverage, which means like
the scope of the things that we can
all solve together, gets larger.
if everyone, can work at higher levels
of abstraction, I, I think of it as like
a kind of like a messy compiler that
doesn't always do the right thing, right?
Or
you're like, I have an intention
and you compile it into, machine
code, but you're not always right.
Which is, an exciting place to be.
that we're in this world where
we're getting to where I see the
scope of the problems that we can
create and tackle, becoming larger.
CJ: Totally.
And com combining with the other
tool, like the other LM tools.
the other day I was, I.
Just trying to do something with
a bunch of unknowns where I wanted
to make a video where the video
was explaining a code snippet and
I wanted all of it to be automated.
And so I wanted to be able to just
say my input is some code snippet and
the output is a video that is animated
and it brings in the code snippet.
It explains what it does with a voiceover
and it shows you like all this stuff.
Basically, like my job as a developer
graphic as right, and I was like,
chat G B T, how would I build this?
like how do I animate this and how
would I animate some code showing up?
And then it just like starts spitting
out different like python blocks
using map plot lib and using like
these other animation libraries.
And then I was like, okay,
and now how do I like.
describe this and it spits out the
description that you take the description.
It's okay, now go to some other tool.
okay, now make this a voiceover.
It gives you like the AI voiceover,
and then you're able to ki it was
like an hour of just playing around
in a bunch of spaces that I had
no idea about, what tools to use
or, how to put things together.
And just like between GitHub co-pilot.
Helping write some of the code between
chat, e p t, writing some of the code.
It went from nothing to having a
prototype in an hour because you can
just whack at it in different ways.
And even copying the error
message directly into chat e p t.
And it will just tell you like,
here's the thing that you got
wrong, and here's how to fix it.
And it's been really fun.
I don't know that style of development,
like chat, G B t is the third
like pair programmer in the room
with you, has been interesting.
Alan: Yeah,
Colin: br brute forest development.
CJ: exactly.
Colin: Oh.
Alan: that's really exciting.
just all of these tools and ways to
develop are just really exciting cuz
we're gonna get to see more stuff.
we're gonna get to build
things more easily.
no, I'm really excited about building
applications on top of all these things.
Colin: Absolutely.
And I think, leverage is a great
place to end this episode on.
So thanks so much for joining us and
spending time with us today, Alan.
It's been awesome.
Alan: It's been a pleasure.
Thanks for having me.
CJ: As always, you can head over
to Build and learn.dev to check
out all the links and resources.
We'll drop those in
the show notes for you.
Thanks so much for listening.
That's all, and we'll see you next time.
Colin: See ya.