Episode 06 Transcript

Episode 6 Transcript

Welcome back to The Main Thread!
Today,
we're going to be talking about introducing new tech to your company and your code base.
Is it worth it?
How do you decide whether that shiny new front end framework or that highly performant memory-
safe back end language is really going to solve your problems.
What if you work for a small company with highly constrained resources where investing time in a costly migration could mean the difference between staying within your runway or not?
Heck in 2023 even Big Tech has to deal with resource constraints.
Let's join our guest,
Eric Justusson.
As we talk about how to leverage quick experiments,
tracer bullets,
green-field projects and hackathons, how to avoid yak shaving or bike shedding and generally how to responsibly evaluate the benefits and costs of onboarding new tech for your team.
Let's get into it.
Hi,
everybody and welcome to The Main Thread.
My name is Alex Gaiser and this is Brian Ogilvie.
I'm here with Eric Justusson,
a good friend of mine.
Uh He's the VP of engineering at Project X Media.
Uh Eric is somebody I've known for a long time.
He's one of the first people that I ever talked to about getting into software engineering and he's somebody who really helped me get my start.
So it's really great to have him here talking with us today.
Uh Eric,
why don't you tell us a little bit about yourself?
Hey,
Alex,
good to be on here and Brian as well.
Yeah,
as you said,
I'm the VP of engineering at Project X Media.
We have a uh our business is comprised of a managed services agency where we buy and sell out-of-home media.
Uh on behalf of our clients,
we started off as a technology company,
basically a platform for the out-of-home advertising industry.
And so we're really,
we're born out of tech and then at some point along the way,
maybe we'll talk about it on this podcast,
you know,
we started an advertising agency and so we're sort of going down both roads now,
but VP of engineering and sort of an early member of the team here at,
at Project X.
Yeah.
So our topic for today is going to be generally speaking,
like introducing new technologies to an engineering team.
And we thought that as somebody who is ultimately responsible for the technologies used by your company,
uh that'd be an interesting thing to ask you about, something that we all deal with regularly.
We all as people who are responsible for at least certain areas of our engineering organizations.
We are always thinking about needs and what types of technologies that we need to introduce potentially or which ones are working and which ones aren't?
When do you decide that you have a need that could be filled by changing a technology? How to identify which technologies would be helpful?
What does that process look like for,
for you?
Yeah.
And first of all,
I just want to say Alex,
very impressed with you sticking with this.
As you mentioned that you,
you did reach out to me,
I think early on in your journey here and I'll say a lot of people have reached out to me over the years with a similar interest in all of this.
Um But I think it's,
you're in a club of maybe two or three people who've actually done it.
So kudos to you,
man,
you,
you seem to have actually done it.
And this podcast is a great example of that and you pushing yourself so good work with that.
I love,
I love the industry.
I love the work,
obviously.
Otherwise I wouldn't be doing a podcast talking about it in my spare time for,
for no money.
Not to mention how much we love accolades from our mentors.
We do love it so much.
It,
this is one of the that has made it all worthwhile! Anyway,
What do you got?
Yeah.
So it's a good topic,
you know,
certainly something that I've dealt with quite a bit over the years.
I should preface this by saying,
my experience even before Project X has been at fairly small companies.
So,
you know,
we've been anywhere from like 2 to 12 people on the engineering side and you know,
bigger in the whole company.
So,
you know,
that has its unique set of challenges.
But in general,
from an engineering team's perspective,
you should really question why you're trying to introduce new technology.
For one,
I think a lot of times people get excited by new tech and want to use it without a good business case.
So I'd say,
first of all,
you should figure out why you're doing it.
Most of the good technology switches that I came across either came from a really good business reason to do it or basically,
like we saw a problem that was just going to be a big problem down the road and it really lent itself to uh introducing a big new set of technologies.
Now that being said,
you know,
I should also say it depends on the cost.
I'm very open to using new technology at a smaller scale,
right?
Like if it's,
if it's just somebody wants to play around with a new library,
somebody wants to try something a different way and the cost isn't high.
Um There's almost no downside to that.
And,
you know,
another thing that I've found useful over the years is I actually,
you know,
it,
it helps a lot if somebody already has some experience with some new technology that you're gonna use.
And so one thing that I've always encouraged really heavily is side projects and,
you know,
people doing that type of thing out of work and,
you know,
even going to the point of helping them out with those projects because,
you know,
we've seen time and time again and it's happened even recently where someone's done something on their own and it's that process,
that sort of convinced me like,
all right,
maybe we do... take on this,
this new project with,
with this new technology,
given your experience,
with it outside of work.
I should also say it depends on whether you're trying to introduce new technology into an existing project.
You know,
I have right now,
some code that's,
you know,
a decade old or a code base,
at least that started a decade ago,
verse Greenfield projects,
you know,
projects that we've started in the last year.
And obviously,
it's a lot easier to introduce new technology in a Greenfield project,
especially if it's sort of big and impactful than it is on,
you know,
a legacy code base.
Uh So I think,
you know,
I think the evaluation and everything goes into it,
it really depends on,
on those types of things.
So one of the things I want to ask you about,
you mentioned earlier that you've primarily worked at smaller companies.
And when you're in that type of environment,
your resources can be incredibly precious.
Maybe you're in your Series A.
A but you've got some kind of runway under which time you are meant to be finding a product market fit and finding a user base.
And when you want to run,
say an experiment,
someone has an idea,
they want to use a new technology to solve a certain problem.
How do you define the parameters under which that experiment can be run where you feel safe?
Saying I'm comfortable with you doing this for a,
a month,
six weeks after which time I need to see XYZ in order to prove that it is worth allocating these very precious and scarce resources towards continuing this experiment.
How do you,
how do you go about that process?
Yeah,
it's a,
it's a good point,
Brian.
And,
and it's definitely something that I think about. Resource allocation is one of our is always one of the trickiest things for us to balance.
There's a lot of things we would love to do if we,
if we had,
you know,
the resources to do them.
And so I do spend a lot of time saying know to um to on all sides,
you know,
on the business side and on the tech side and,
and I hate to do that but look like you,
you,
you,
it again depends on the scale of the project.
But overall,
like I'm always looking for ways to do experiments like that sort of as cheap as you can and so I think it's always good to,
I think it's always good to try to scope,
find a way to introduce the new technology in sort of a scope that can be encapsulated into a sprint or two,
let's say,
maybe,
you know,
run a couple of weeks on it,
see what you learn,
um,
maybe a couple more weeks if it's going well,
but don't fall victim to sunk cost fallacy and,
and make sure you're taking measurements pretty often.
Some of that.
Sometimes in our case might just be literally like we still think this is worthwhile doing,
but we actually think it's going to take us a lot longer to do this than,
than we have budget for,
you know,
in time or anything else.
And so we need to kind of table it for now,
maybe sometime down the road that,
that reintroduces itself or we can find another way to do it.
But I'd say,
you know,
overall I'm looking for cheap ways to do it that could be easily done these days,
you know,
a lot of things that,
you know,
sometimes there's so many features that you can essentially write as like a micro service.
And so,
you know,
again,
it depends what we're talking about.
But if somebody's like,
I wanna try,
I wanna try it in with this library and this language or whatever it is.
And especially if it's like some sort of backend service rather,
you know,
we can throw that even on like a,
a lambda function or a step function to test it out in that regard.
Right.
It doesn't have to be like replacing your entire backend framework or something like that.
I do have some examples of that too where we did decide to go that route for,
for various things that were much bigger changes.
But,
you know,
there are lighter weight ways to do it.
Usually we have,
you know,
especially in our,
in these small companies that I've been involved in,
we're always trying to push ourselves and find like new product market fit.
Um Even when we have established products,
we're always trying to push it,
develop new products.
So I find a lot of times um we can use some of the greenfield projects as like a testing ground for new tech and,
you know,
use that as a way to sort of learn about it.
And then with that knowledge,
we can decide,
is this something we think we could bring back to our larger code base or to other areas.
Is it worth refactoring?
You know,
that's for me,
always,
honestly,
like one thing that people don't seem to understand,
trying to get into the industry is it's a,
it's a,
it's there is a big advantage to,
to doing um something greenfield,
right?
And so,
you know,
a lot of times when people are starting out,
you know,
I know this tech,
I know this tech and I know that tech,
I'm like,
that's great.
But what about when you're trying to decide how to implement that feature on a code base that has all sorts of other considerations and side effects to making a change like that?
So,
one of the things that we find is really helpful when we're proposing a new technology is to say,
all right,
well,
what is one step shy of a minimum viable product?
Like a little bit short of an MVP that you would actually put in the hands of users--
what they refer to in the pragmatic programmer as a "tracer bullet,"
which is putting together something that goes all the way through the components of the system,
right?
All of the important stuff that needs to be in place
if you were going to use this for real.
It's not a prototype,
it's not fake,
it's not a toy,
it's like it's really gonna use the front end,
it's really gonna use the API layer,
it's really gonna use the database you're thinking, of it's really
gonna use the logging framework,
but like identifying some feature,
some small thing that would prove that the whole thing can work and that it's worth going ahead with.
Is that something that you pursue or is that a little bit too big for like,
say one engineer to be able to go tinker with and,
and show you?
No.
Uh I think that's great and I like the way that you phrased all of that too,
especially,
you know,
I'm thinking of our biggest code base here,
the one that's been around forever.
Um Well,
in our world:
10 years. For that
we,
we've totally done exactly what you're describing with new tech and because especially the front ends,
I mean,
all the tech really has evolved,
you know,
since we started that project,
we've had all sorts of things that we've done,
like moving to React,
even things like that or moving to a real front end build system.
Everybody's classic case is like migrating their JavaScript framework.
And how long are we really gonna spend doing this before we're actually shipping features again?
So if you find a way to actually continue shipping features while you're in the midst of that kind of a migration,
that's uh you know,
kudos to you. Or you do what we did where you get halfway and then it's stuck in this weird Frankenstein,
half AngularJS getting mutated into for,
for,
for literally like five years.
So I'm not.
Serializing your component state across frameworks? Something like that.
That leads me to like the next question I have is like the there's always this push and pull between introducing new technology and the cost therein versus fracturing your code base,
you introduce React (a clear upgrade over AngularJS to the point where AngularJS is not even supported any longer).
But you do have this problem where a large portion of your code base, unless you do a clean break and just start over, are in Angular JS uh moving on in a micro service architecture.
Like you mentioned,
you can have,
if you all you have a,
if you also do a multi repo,
um you can have your repositories in different sections of the code that can look completely alien to each other.
And then so when you have somebody onboarding,
right?
It can be very difficult because we have portions of our code base that just have not been touched for a long time and that and,
and they're different.
So when someone needs to be onboarded it,
it's like kind of like relearning the whole code base all over again,
you know,
and that's partially because we've done several clear upgrades and that can cause,
you know,
fracturing of the code base.
And so I wonder how do you deal with that?
Oh yeah.
And I mean,
you know,
to use that,
so we were using initially Backbone.
I was doing it before there were frameworks like this at all.
And I mean,
so all of these things along the way,
felt like great upgrades.
They always do.
But there is a cost like you said,
and it is an upgrade and then hence the like Greenfield,
you know,
sort of bias and just like,
you know,
hey,
we should use this because it's better and I would say like that is part of the equation,
right.
You know,
and I wouldn't get too hung up even in your case where you're like,
well,
some stuff's in React and some stuff's,
this. React's clearly better.
I mean,
that is part of the equation,
but the other part of the equation is,
is just like you can't go rewrite your code base every few years when there's a better way to do it.
If you architect stuff reasonably well with the technologies that you have at the time and it works,
you should keep it until it's becoming sort of cost prohibitive to add to it or add new features and even there.
So like what we ended up doing in that case,
I mean,
we had to move at some point to even just like a front end build system using webpack and stuff which we didn't have originally.
And so that was even a even a process in itself which we did.
And we also introduced React, and for React,
like what we did was what we do with a lot of stuff,
right where there was like one component of the system.
And it's like we'll do like this,
you know,
manager for,
for this thing in React and see how that goes.
It's like,
oh,
it's pretty good.
And then we built a way to kind of cook it into backbone components for certain cases.
So we could like,
all right,
we can add new stuff with React but we're gonna keep backbone and we did do that dabble in rewriting some like core components in Backbone.
I mean to go back to your question,
Brian,
it was like,
you know,
I think I gave somebody like take,
take like this sprint to see if you can write this,
rewrite this,
you know,
sidebar list view that is like jQuery and Backbone and using just tons of event bindings and all these things as a React component.
And you know,
after we ran the experiment for a little while,
it was like this,
this is just going to be hell. Like it's not worth it.
And so like,
you know,
for in those cases,
what you end up doing is being like,
let's save it,
we'll save it until there's sort of a either a more compelling reason to kind of rewrite this in a more significant way or just maintain this code.
And I mean to the fracturing point like that does happen,
it can be hard if like somebody's joining on and it's like Backbone and React and this and that,
but I would go back to just the most important thing usually is just decent practices in writing code that's easy to read.
And you know,
just suggest that as a general rule of thumb is,
is,
you know,
when you're doing code reviews or,
or just writing code and pairing with your team,
like definitely have a strong bias for like, I might come back to this later,
I might be using a whole different technology.
I might not remember how Backbone works.
But if the code's organized,
you know,
in a,
in a way that it's readable,
you'll still be able to figure out what's going on.
Right.
And,
and I think that just comes with experience,
maybe somebody who's more junior,
um,
will have a harder time with that.
But that's just kind of part of the process of being a junior engineer.
And I would just generally recommend people get exposed to different languages and become fairly language- and framework-
agnostic.
You know,
I don't think people should get so hung up.
I mean,
people do,
right?
People get very like ideological about what languages and frameworks and all these things that they're using.
And I find for me that usually doesn't matter as much as a lot of other things. That makes sense.
So I'm curious about if you ever make decisions like this,
like big technological choices based,
not solely on the merits of the tech itself,
but on how that choice will affect your hiring pool.
Specifically,
I'm thinking about, like we've been talking about React.
React is really popular right now.
Every bootcamp is teaching React.
People are coming into the industry,
at least with the expectation that they should be familiar with React because that's what everyone's hiring for.
And so if you are hiring for it,
maybe you get a lot more high quality candidates you can choose from versus if you choose something a little more obscure,
like,
say Scala,
which Alex talks about a lot,
like there's a much smaller community for Scala,
right?
And maybe,
maybe if you're looking to hire a very senior engineer,
you can probably find someone who's very skilled at Scala.
But if you need to fill out your engineering corps with juniors who can be mentored and brought up,
you know,
do you ever make a technological choice based solely on that?
I would say,
not solely,
but it definitely does factor in. React is a good,
you know,
continues to be a good example in this conversation.
But,
you know,
that definitely did factor into my consideration there.
You know,
it wasn't the only thing I,
I guess what I'll say is if it aligns with everything else,
then that's also some weight that I would add to it,
especially if there were a couple of technologies that,
you know,
I was choosing between that were sort of more or less equal and one is wider adopted,
in fact,
React,
you know,
really was that, right?
Because I had friends at the time that we were doing it who are like no Vue is cooler,
you gotta do this,
you gotta do that like,
you know,
there's all these different kind of things and,
and one of the considerations really was like,
React has a much wider adoption that people are learning it.
You know,
it's just going to be,
like you said,
easier to hire against it,
but I wouldn't do it,
I wouldn't do that if I also didn't think it was the best or on footing with being the best technology.
I think overall I'm trying to,
if I'm going to make a shift,
I'm trying to usually bet on what I think is going to have a good community around it.
Um,
in part because even if somebody doesn't know it,
are they going to be able to learn it?
Are we gonna ourselves be able to find a community of people who are gonna help us answer the questions we have around it?
Is it going to continue to get support?
So all that factors in but not so much what like I'll say,
you know,
for a while,
I feel like all the bootcamps were teaching Ruby on Rails and I would not have chosen to use Ruby on Rails just because they were teaching it because I'm just not a huge fan.
So I,
I didn't want to use it when I was being taught it in a bootcamp.
And I've never touched this at all since.
So how do you vet a technology?
What do you do when you like have to pick something?
You're like,
we've already decided we want to do something.
We have a number of different things,
ways that we could do it.
How do I pick which one?
Yeah.
I mean,
it's never in isolation.
Part of it is you want a good culture around these things,
right?
Like in the same sense that you don't want people to be like ideologues about what technologies they're using.
I think it's good to encourage the whole team or,
or whatever team is sort of relevant to that decision,
whoever is going to be using it to participate in that.
And,
you know,
I,
I usually ask people like,
bring ideas for,
bring,
you know,
whatever ideas people have about the direction we should take.
And then,
you know,
I think it's just good general life practice to be a good critical thinker,
right?
And so don't get too attached to one technology or another because of hype or this or that,
but really go just have that conversation,
basically try to try to argue for and again all of them and usually you'll end up with a couple of front runners and from there,
usually it is running an experiment,
you know,
finding a finding a future that we can try,
right?
And then seeing what we learn and,
you know,
that's,
you know,
honestly,
usually how,
how we arrive at a consensus for a new tech.
I mean,
I don't find that it's usually like choosing between 30 things.
It's usually choosing between maybe 1 to 3,
you know,
two or three things.
In my experience,
we've talked a bit about running an experiment and in that context,
you mentioned,
like you would ask one engineer to maybe spend the next sprint experimenting with something--trying to replace a,
a nav bar or something like that.
Ff the experiment would require a few more resources,
uh a lot of companies have a strong culture of hackathons.
Uh And I...
I mean,
obviously my company is a huge hackathon culture,
but a lot of uh smaller companies do as well.
And I'm wondering if that's something you've ever entertained doing, and if you wanted to entertain it, for the benefit of getting a lot of people in the room for a few days to,
to hack on something that may be thrown away at the end or may be expanded upon later,
uh what would it look like trying to get buy in for that kind of culture in,
as we mentioned,
a smaller company's environment with constricted resources and maybe a limited runway?
Yeah,
great.
So,
you know,
we actually,
I should say I'm,
I'm a little hesitant to admit that we haven't done one in a while,
but we,
you know,
historically have done them.
I don't know what the most frequently ever did them was,
but,
you know,
let's say like at least several times a year,
you know,
sometimes more frequently than that.
And again,
it's been a little while now,
but we always,
I,
I think especially in the beginning did find those really helpful.
I mean,
for a bunch of reasons,
I,
I don't think it was ever that hard to justify it to the company because just for,
like,
team building alone,
it was great.
You know,
we would use those as a way to play sometimes with technology that we had no real use case for.
But just somebody was interested in,
you know,
somebody's like,
I really just want to write something in Go,
you know,
or whatever,
like,
you know,
whatever we were trying to do.
I mean,
you know,
I remember we did all sorts of fun ones but like,
you know,
like we'd make billboards and out-of-home advertising and stuff like that.
So we made something at some point.
It was like Instagram kind of,
but just for like billboards and,
you know,
it's like you get to like play around with a simple idea like that you can use like basically any front end framework you want the back end was in Go because we were like,
that sounds fun.
And,
you know,
that was,
that kind of thing is great and you end up maybe learning like one useful thing out of that experience.
Um We've had other ones that are a little bit more focused on like a specific technology that we are vetting and we just do some project in a way to explore it.
If we don't have like an easy way to do it in another way,
it's like,
well then let's just let's just do this in a hypothetical situation.
Or maybe something that's sort of tangentially related to work.
But we know,
is mostly,
it's almost,
definitely not gonna actually be used,
you know,
like,
you know,
do some sort of like fun app that's sort of quasi related to work.
But it's not,
you know,
we're not expecting it to go to production or anything.
It's more for "mess around internally."
And I,
I do think that,
I think that's a really important part of engineering culture.
I mean,
that and you know,
the other thing that we do a lot would be like Brown Bag kind of things right?
Internally.
We'd also,
especially since we were small,
there was one point where we had this office in Soho and there were a bunch of other startups around and we do it with other offices in the building too.
So,
you know,
and that was a good way to share knowledge,
right?
So we'd have,
you know,
just have lunch together and have somebody talk about their experience or something.
So like there's a corollary from running an experiment, trying out a new technology and,
and say,
you love it and you decide you want to start using more of it.
There's a corollary to that which is deprecating old technology and they often go hand in hand, and how do you go about bridging that subject with your employees? Say,
because it's easy to get excited about a greenfield project with new tech.
It's a lot harder to get excited about.
You know,
now I have to start changing what I do day to day.
I have to start saying goodbye to this code that I've been a part of for a while or maybe start pulling it apart again and redoing bits.
Um How do you manage that?
Uh at a,
at a company your size?
Yeah,
that's a good question.
Or at any company,
really?
Yeah,
it's a good question.
I think,
I think overall,
you know,
again,
a lot of these,
a lot of this is gonna come back to just like trying to create a good culture around these kinds of things.
I mean,
some of it is just bouncing it.
You know,
I always try to pay a lot of attention,
you know,
for lack of any other sort of pressing priority.
A lot of times I'll prioritize based on what I think will be the most fun,
honestly.
You know,
it's for people because I think it,
it just creates,
you know,
people do their best work and when they're having fun.
But part of that is also demonstrating and encouraging,
you know,
people to see the fun in almost any project.
You know,
it can actually be a lot of fun to remove a ton of code.
I love when there's like a diff where it's like negative,
you know,
like 10,000 lines.
We have something called a Dead Code Society where if you show your diff where you deleted like 10,000 lines of code or,
you know,
it can even be a collection of diffs, you get like a t-shirt that says Dead Code Society and membership in this group and a badge on your profile.
It's great.
I gotta bring that to my work.
I,
I just got a couple of those in,
man.
Yeah,
absolutely.
Um,
and I'd say a lot of times that's coupled with replacing it with a new technology so that can make it more fun.
Right.
So,
you know,
if it's deprecating something,
you know,
I,
I think like in general,
I,
I always encourage people and,
uh,
you know,
I've been lucky to have great people to work with,
um,
which,
which helps.
Um,
but I think,
you know,
overall I don't,
I don't want anybody who's gonna have that sort of attitude about it,
either of just like,
you know,
I gotta change the way I do it.
It's like,
you know,
we all have to evolve in this thing,
right?
Like I'm, almost nothing that I'm doing today is stuff that I was doing when I started,
you know,
or that was even around.
And so like,
it's,
it's always constant evolvement and I think that's part of part of being engineers,
it's just,
you know,
and this is what gets people on their journey all the time,
is that impostor syndrome.
And part of that's because you have to spend a lot of time having no idea what you're doing.
Um,
and it really,
it really has,
it does not matter how good you are at the thing you're doing right now.
You'll be doing something different in five years and you won't know what that is when you start.
It's a never ending cycle. If you're very comfortable with what you're doing.
Like,
that's almost,
I'm almost more scared of that.
Right.
Like,
I,
I feel more uncomfortable with that than if I'm feeling uncomfortable about what we're doing.
And I think part of that is just you want to be continuing to push yourselves,
right.
Push yourselves to learn more.
I definitely believe in the,
like,
you know,
run off the cliff and then,
like,
build the ground underneath you kind of thing.
Right?
Like,
I mean,
within reason,
maybe at least have some building materials with you when you jump off the cliff,
at least know how,
know how to build a glider or whatever before you jump. Or have some,
have some reason to,
to,
to,
to jump off the cliff,
don't just do it for no reason.
But,
you know,
if there's some reason that that's the direction you should be going,
go a little bit further than you're comfortable with pretty much at all times,
I would say.
Um,
and,
you know,
some,
some of my,
we had one the other day,
you know,
some of my,
um,
favorite times are honestly like tracing down some terrible weird elusive bug or some fire drill that just pushes you in a way that where,
where,
you know,
some people might consider that,
you know,
really mind numbing work or,
or just kind of despairing in a way.
But I find those sometimes to be the most fun adventures because you're just like in,
it's like a big puzzle and you're in this mode of,
like,
I have no idea what's going on,
but that's a fun state to be in,
uh,
That means you're learning,
that means,
you know,
it will resolve at some point.
And so I don't know.
So I guess a lot that just comes down to trying to instill that as part of the culture and just not being afraid of change.
I think that's really important for,
for us to adopt as engineers unless you want a job where you're just writing in a api adapter the same way,
very slightly different for the same thing for a big health insurance company or something,
which I think is a great way to go absolutely nowhere.
And I felt bad whenever I had interviewed people, and I did a few times,
you know,
who were basically in a job like that,
you know,
who started off in a great place,
but then went somewhere where they were basically doing the same thing for five years.
And you really saw the downside of that,
you know,
as opposed to being a full stack engineer,
as opposed to being able to jump around to different things or get really niche in one thing,
but kind of stay up and solve different problems with it.
So that's a long way of getting around it.
But I,
I think like a lot of things,
it just comes down to,
to culture and,
and,
you know,
also bringing people into the decision making process,
right?
I,
I would never just tell people to do something without kind of explaining why we're doing it.
And so I think,
you know,
you get people invested maybe in engineering one level up,
which is just,
you know,
we're also trying to grow a business and like,
so,
you know,
bringing just engineering thinking to business decisions and,
and how we think about the business and the business strategy and what the tech we're doing,
uh how that plays a role in it.
So,
you know,
I think you get your team,
if you get your team invested in it,
then,
you know,
we all roll up our sleeves and do the work that needs to get done.
Yeah.
So important to be the person who draws the lines from the business priorities to the code being written: here is the connection between this hard work that you're doing and the business that... the impact we're actually trying to have in the world as a company. 100%.
And that,
you know,
I think you said it great there.
I mean,
that's maybe some of it is just right,
explaining why it's important because if it isn't important then,
well,
then you shouldn't be doing it.
That is kind of silly.
But if,
but if,
if you're deciding to do it as a business,
even if it's not on the surface,
exciting,
it probably has business impact or is important in some other way.
And so,
you know,
being able to understand its importance and also just,
you know,
not kind of making one person do all the terrible jobs like that or something.
You know,
I think it's just a balance of all those types of things,
right?
On the uh on the subject of balance,
I do think it's time to move us over to the other side of the ravine with Picks and Plugs.
So first,
yeah,
I'll plug my business.
Why not?
It's uh you know,
PJXmedia.com.
We will help you buy billboards,
wall scapes,
subway ads,
anything out-of-home.
We have a tech platform that's well known in the industry that buyers and sellers use to,
to do these types of transactions.
And it's a really exciting company and we do use a lot of tech to be competitive in our space.
So I'll definitely plug that a little bit and then in terms of some like useful stuff for the pod,
I mean,
one thing that I just think,
you know,
doing,
doing a lot of reading is always helpful.
I know you guys have talked about book lists,
one thing that I just,
you know,
I always like love.
I've always loved looking at Hacker News,
you know,
by YComb.
Like,
that's something that's like literally just up as like a placeholder tab for like the last 10,
12 years on my browser.
You know,
just skimming it every day I think is,
I think it's just good to have a sense of what's going on and I mean,
you know,
take a pulse on the industry,
right?
You know,
have an idea of what technologies people are using,
read,
you know,
quick fun blurbs,
but then go deep too,
right?
Um And then,
you know,
I,
I looked it up actually to see if it was still going on,
but back when I was in the city more,
um there was a great,
like meet up called,
I think like CTO School or something like that,
but I'm sure there's something else now, that seems like it's defunct but,
you know,
where,
where people would meet up in person and go through all these like hypothetical scenarios together and really just help each other.
So I think if people are trying to,
to go that direction,
like looking around for other people who are in that space and just kind of again,
just like helping each other is a great way to go.
Um So I just plug that as general advice.
Um And then,
you know,
just for people's amusement because these are this kind of like a fun thing for me.
Um,
I love,
like all the engineering,
like random idioms.
I don't know if you guys are,
are fans of those too,
but,
you know,
if people aren't a fan of them,
I would recommend,
you know,
learning and using,
uh,
some of my favorites,
like yak shaving,
bike shedding,
you know,
running into the spike,
obviously,
rubber duck debugging.
I've heard,
I heard you guys talk about program,
uh,
Pragmatic Programmer but um Cargo Culting,
you know,
all of those are worth looking up and using and,
and um you know,
even teaching your uh we use a lot of those just even in like leadership meetings at our company,
you know,
non tech people.
Um And I think like applying engineering thinking um and problem solving to uh business problems is,
is a great way to contribute more than just um to the code at a,
at a company.
Like bring,
bring your thinking because engineering thinking is very strong and anyone individual contributor,
anybody can go um kind of like go talk to other people and try to help them problem solve,
think about things,
you know,
and just,
you know,
have a genuine interest in solving problems at the business.
And that's just another great way to grow. Alex,
what do you got for us?
I'm reading the Gang of Four book again.
It's uh the Design Pattern book.
Uh I've read it at least in pieces several times.
Um But this time I'm kind of going through the intro,
which is really cool because the intro is like,
how you would use the design patterns to build a WYSIWYG.
A "What you see is what you get" um text editor,
which is kind of a really cool case study that I've seen a number of different places like how to build a text editor.
And that's a kind of a common sort of example because it's like a application that touches a lot of different things and it doesn't really get into the web side of things.
So it's kind of like a nice concrete unit.
And then this case study goes through and you how you would use each of these design patterns to,
to build it.
But what's really cool about it in this case is what I never really noticed before is that it's just really a good book about design generally,
like it gets a lot of problems because it is very object oriented and a lot of the specific patterns kind of are only really an issue in SmallTalk.
And C++ and Java,
um you know,
a lot of the patterns are,
are also just like built directly into languages now.
And then like the kind of like the focus on functional programming has made a lot of them like irrelevant.
But then this time I'm going through it with the idea of,
well,
what can you teach me about just just answering a question in,
in any way,
like,
regardless of,
like,
the paradigm,
like,
how does it address the problem?
And it's actually really,
really good at that.
It's like,
it just kind of like re evaluating this book kind of is,
like,
really open my eyes in a lot of ways.
It's been really fun to just re go through it and see what it has to say.
Just,
yeah,
that's a really good idea.
It's been,
it's been a couple of years since the last time I read that and I think it would be great to go back and explore it the way you said,
instead of trying to memorize all these design patterns,
which I'll mostly not use.
I mean,
there's a few that I go to all the time,
but most of the time I'm not gonna use them because,
yeah,
like you said,
they're built into the language or I'm writing more functionally anyway these days.
But uh the idea of like,
how did they approach this problem?
And then how did they arrive at a solution is pretty,
pretty cool way to look at it.
It's uh it's still good,
like Picasso said,
right?
Learn the rules.
Like a pro so you can break them like an artist,
I think,
you know,
it's good to know them and then,
you know,
do what makes sense and do what is fun and do what is readable.
I,
I can't stress readability,
it matters so much more than people give it credit for.
Everyone's trying to be very,
like,
clever with code all the time and I'm like,
please just make it so we can read this.
Yeah.
And I remember the very first time I saw code that the,
the most senior member of my engineering team wrote and,
you know,
when I was new in the industry and I just remember thinking like,
is that all there is? Like,
that's,
it's so simple and like,
there's not that much to it.
And he was like,
yeah,
that's right.
Yeah,
anyone can read this.
Anyone understands what it does.
It is not overly clever.
You don't feel like you need a PHD to like get started in this code base,
right?
It's simple.
It does what it says
It does. Cool.
So I'm gonna go entirely analog for my pick here.
So we,
my family and I enjoy sometimes,
especially if it's raining outside, doing puzzles together.
And we found this uh company called Unidragon Puzzles.
And they make these absolutely gorgeous wooden carved puzzles.
The patterns and art on them are already beautiful,
but every single piece has its own distinct shape.
Like some of them are actually in the shape of birds or dragonflies or stars or hands and things like that.
So some of them are identifiable shapes and others are totally random but they're so intricate.
Um And the,
the puzzle is hefty.
It's like,
it's you know,
done on,
um,
what do you call it?
Like Marley Board?
And so it's really thick,
beautiful.
It smells great when you open it because it's cut wood. Anyway,
so I love them.
And if you are someone who enjoys doing old person things like I am, like sitting down and doing puzzles on a weekend when it's raining,
these are really great. And then with that,
that brings us to the end of the show.
I can't believe it happened so fast.
But Eric,
thank you so much for the time.
Great,
hearing about your company,
uh about Project X and everything that you guys are doing.
And thanks for sharing your insight on how to manage these introductions of new technologies.
Hey,
it's been a lot of fun guys and now of course,
I'm thinking of all sorts of other stories.
So we'll have to do,
uh to do a part two sometime.
Yeah,
we'll do a sequel,
do a sequel.
Yeah.
Well,
thanks again,
listeners.
Really appreciate you tuning in and we will catch you next time.
Thanks for listening to The Main Thread.
As always,
the views expressed by the hosts and guests of The Main Thread are our own and do not reflect those of our respective places of employment.
Are you enjoying the podcast?
Do you have a topic you'd like to hear discussed in a future episode?
Well,
please reach out to us with any suggestions or feedback we are @themainthread on all major social media platforms including Facebook,
Twitter,
Instagram,
and of course Threads. Or if you prefer,
you can send us an email at mainthreadpodcast@gmail.com.
For links to resources mentioned in today's episode or to download a transcript of the podcast.
Please refer to our show notes. That's all for today's episode.
Thanks again for listening and we'll catch you next time on The Main Thread.