Hello, hello, everyone.
I am super pumped.
Tessa Creasel here, 99Dev Problems show.
We have Noah Harris with us today.
Noah, I would love for you to introduce yourself.
Oh my goodness.
Okay.
I got to ask the hard questions.
I know, I just dumped you right in.
It's the hard questions.
Yeah.
Let's see.
So my name is Noah Harris.
I'm currently living in Buffalo, New York.
I'm a transplant from Atlanta, born and raised in the South.
I've been in tech for professionally for about 10 years, but I started, I started my tech
journey in high school as one of those kids who was learning how to code, but it was rocky
at first and I eventually found my way into some sort of professional engagement, which
kind of led me down the road to here.
So that's my, that's my exceed, that's at least my technical background in a very tight
nutshell.
Yeah.
You're very quick introduction.
Okay.
So what brought you from Atlanta?
This is obviously sort of side topic, but it's great to get to know people.
What brought you from Atlanta to Buffalo, New York?
Cause that is like so, I mean, polar opposites, honestly.
Absolutely.
The short answer is my wife.
So I graduated from Georgia Tech in Atlanta and then moved to Columbia, South Carolina,
where my wife was getting her PhD.
And then we moved to Ann Arbor, Michigan, where she did her postdoc.
And then we moved to Buffalo, New York, where she's now has a faculty position at the University
of Buffalo.
And so working in tech is nice for that regard is I can work anywhere I have an internet connection.
And that's kind of been the ideal.
So it works out very nicely being able to kind of move around as she needs because my
wife's, it's my wife is much more, I don't want to say restricted, but it's more difficult
for her to find work because she's very highly specialized.
Yeah.
For me.
So that's kind of what brought me here and I, Buffalo is pretty cool.
I grew up, I always liked the snow.
If you ask my parents, they took me out in the snowstorm in the winter of 93 and I did
not like it.
But somehow that changed and I love snow, you know, growing up with snow every other year
and a lot of snow being half an inch to now it casually snows a foot or two.
Shovelling, you know, shoveling my driveway is not great.
Snow is very heavy, but, but I do, I do love the snow overall.
I don't like sliding on it in a car, but I'm a little, a little hesitant to drive on it,
but I work from home.
So I don't have to do a lot of that.
I can just enjoy it that way.
It looks that's the longer version of how I ended up in Buffalo.
That is so fun.
I am originally from Minnesota and I live in Texas, very polar opposites as well.
Right.
But I wanted to get away from the snow as being raised in the snow and being around
it, which it made me an amazing driver.
I mean, like I got mad driving skills because I can drive on ice.
My dad taught me how to drive literally on a frozen lake because he was like, we are
not going to have you in an accident, so it's like the cutthroat learned, learned by doing.
Yeah.
But I miss the snow because it's, it's so beautiful.
And like when it's coming down, it's beautiful when it has that layer over everything, like
when the trees are covered.
So we almost got snow here this week.
Danny Thompson did get snow, likely where he is because Dallas got snow.
We missed the cut.
Thankfully, I was a little sad because I, I do really miss the snow.
You'll have to enjoy some snow play time for me.
Yeah.
No, I'm happy to send you some.
I'm sure we might end up as water if we get there.
Fun quick aside, actually living, living in Ann Arbor, we had a lake in our community.
And when it would, you know, it gets cold enough in Michigan to go out on, on the frozen
water.
Yep.
And I saw footprints in the snow to the middle of the, of middle of our little lake and back.
And being a southerner, I cannot walk on frozen water.
I can ice, I play hockey.
I skate all day long, but, but walking on a frozen lake like really gives me the heebie
jeebies because it never got cold enough to do it in Georgia growing up.
And it was always like, if you walk out on the lake, it's going to drop you through and
then you're going to be stuck in like ice water and that's not fun.
And so like, I remember, I remember like putting a foot out on, on like the edge of the water
on the lake and being like, can I do it?
And I was like, no, I can't, I can't do it.
So I met like driving the thought of driving your car on frozen water terrifies me.
So kudos to you for being able to do that.
Well, um, also funny story or sort of additive to this, um, in high school, I probably spent
every single day after school on a frozen lake because I was obsessed with ice fishing
and I still love ice fishing, but, um, I used to bring the little ice out there, get my
heater going, sometimes take the four wheeler, sometimes not.
And so I'm very, very comfortable on frozen, um, lakes.
But when you're in Minnesota or Michigan, very similarly related, right?
Um, beautiful amounts of water up there.
And so you just get very used to sort of what it's like to live in that amazing, beautiful
space that it is.
It was just a little bit warmer.
I would never leave Minnesota.
Um, but yeah, you just get used to it, you know, so.
Yeah.
And eventually the cold gets into your bones and by about February, you're like, all right,
I need some more of the good.
I think snowbirds are onto something.
But they are so onto something because honestly, Texas is awful in the summertime.
And so I'm like, can I do nine months here for the school year and then do our summers
up in Minnesota?
Like that would be the sweet spot.
I've seen, I've seen stories of people like putting, putting a cookie dough on a baking
sheet in their car and letting it cook in the Texas heat.
Oh yeah.
I'm very to me.
It is, it is, but you get used to it.
And then now I can't go to the cold.
Like if I was in Minnesota in the winter, I would, I would like probably just, I'd be
a freeze baby.
And I think it, it got to like, I don't know, I think it was like 40 degrees Fahrenheit
here yesterday.
And I went outside to go just feed the cats because we have outside barn cats, farm cats.
I was just like, oh, I'm going to die out here.
And it was literally the shortest walk ever.
So you get over that.
But sure.
All right.
Let's dive into, so I have a list of great questions I like to ask, but honestly, the
guests always take it, take it in a beautiful direction.
So you alluded to your college education.
Did you go for software engineering or what was the program that you went after?
So originally I enrolled as a double E electrical engineering.
Oh, electrical.
Okay.
Yep.
And, and my first semester freshman year, one of my friends was like, why don't you
switch to computer engineering?
And I said, yeah, right, sure.
And that was that.
I switched to computer engineering, took, took no convincing.
I didn't even have a reason.
And it actually probably worked out much better in my favor.
I like, I like math.
I understand math theory very well.
Like if somebody is explaining, like if I'm sitting in a math lecture, like I can follow
along, but as soon as it comes to solve the math problem on the test, not good, not good
at it.
Is that because of testing or because it's math?
Maybe because of testing.
Okay.
Good question though.
Haven't, haven't, haven't explored that one yet.
But it, I mean, it kind of, that was kind of me across the board, like even, even with
like physics and stuff.
Like I really struggled with Newtonian physics and like throwing bowling balls off of buildings
and, you know, measuring the trajectory and how far out it's going to go with some like
basic calculus or trigonometry.
Like I struggled with that.
Like Sokotoa, like for like tangents and stuff, I wrote that on my paper throughout college.
Like I struggled.
So they're, they're like senior level classes, like, you know, electromagnetic's, which
are, which are very math heavy, very like physics and math.
And I'm glad I did not have to take those.
So if anybody's unaware, computer engineering is, is a hybrid between electrical engineering
and computer science.
So electrical engineering is all hardware, computer science is all software and computer
engineering is the marrying of the two.
So in seventh grade, I became fascinated with computers.
My mom was in software actually growing up.
That is awesome.
Right.
Yeah.
It was, it's interesting to hear her struggles as a woman in tech in the 90s.
Because it was not a, not a happy environment for her.
It was not happy for me when I first started, but we can come back to that.
Like, I believe it.
I believe it.
Yeah.
But I became fascinated with this idea that I hit a button on my keyboard and a light
shows up on my screen.
What, what is this pathway?
Right.
So that, that's the intersection of hardware and software.
Yeah.
And, and eventually when I learned the answer through, I think three years of schooling,
it's, it was still magic.
I was like, that's so cool.
There are so many things that have to happen between the button and the light and it happens
instantly.
It's so fast.
And so I love, like I love, I love all like the, the science memes and the, in the engineering
memes.
It's like we taught, we taught rocks to think.
I love it.
Yeah.
That's really super cool.
Joe Casablanco was a guest on Wednesday and he was actually talking about how he intentionally
went after a specific program.
So he didn't have to do math.
He was very much in the software engineering side as well, but had like a media combination
into the degree.
So we got to skip out on some math.
Yeah.
So I thought that was interesting that it's very much a math plays into, I think a lot
of us in sort of that developer education.
I can't speak to that.
I dropped out of college three times.
I just am not like, this doesn't work for me.
Yeah.
But like we were talking about in the pre-show, right?
It's like putting hands on keyboards and other things, like getting in and actually like
doing the things.
And you know, that's my, my forte.
So here's an interesting, here's an interesting thought that came to me, that came to me,
I don't know, maybe a year or so ago.
And it's how, how most of the hard sciences, physics, chemistry, biology, physics, compare
two things like computer science.
Sure.
Right?
So, so the thing that like Leon or Danny kind of like harp on a lot is that anybody
can learn to program and I strongly agree.
If, if you can tell me the difference between one and zero, yes, no, true or false, you
can learn to program.
That's it.
And, and, and, okay, there's a couple of tangents I was about to go off on, but let me, let
me see if I can stay focused.
It's okay.
It's all good stuff because the viewers are software engineers.
And so they love to hear about this sort of philosophical how you see things.
So you go, you go.
All right.
So then I'll hit this little tangent and I'll, I'll try to circle back is I equate it a lot
like photography actually.
So I'm into photography.
All right.
I've been doing photography since high school and, and anybody can learn to take a picture
and anybody can learn a couple of rules like the rule of thirds and composition and, and
like leading lines to make their photographs better.
But very few people are master photographers and, and the people who are professional photographers
will tell you that you do not take photographs.
You make photographs.
And I think programming is very similar in that it's very easy to learn to code and you
can learn a few tricks to become a, an effective coder, but very few people are like cream
of the crop really see the art behind coding.
And honestly, I kind of see it as, as, as art myself because in my head, it's all pictures
and images and diagrams.
Like I, I'm a very visual person.
So my code is in my head, very visual.
But let's see if I can back up to where I was going.
Okay.
So the original thought was how, how computer science and, and hard sciences are different.
So in hard science.
So if you look at something like chemistry, chemistry is the study of how atoms and molecules
interact, which is based off of physics, which is based off of math, right?
It kind of all, like all the hard sciences come down to being based on math.
It's usually math, physics, and then biology, chemistry, you know, and all the other things
that come off of that, right?
And in these fields, we spend time studying and learning and trying to understand how
it works.
We are actively discovering how photons react with things to, you know, enact with the world.
And we're trying to discover what already exists in, in that realm of science where
computer science is the study of logic and logic at its core, again, ones and zeros.
And so what we have done as, as smart monkeys is taken these ones and zeros built Lego blocks
and we take the Lego blocks and we stack them into big giant Lego blocks that make big systems.
And so in the computer science world, it's not about discovering the things that don't
exist as much as it is building the things that don't exist.
And so it's coming at it from a different angle of what can we build versus what can
we discover?
And I'm not saying that there's, there's a blurry line in there, right?
Because the physics of, you know, electronics certainly plays into an action when you have
large distributed systems and stuff like that.
Like the, the discrepancies between hardware and software are, are big when you start to
go down the rabbit hole.
Like one of my first interviews out of college was a senior manager who said, okay, Noah,
do you prefer analog or digital?
That's a loaded question.
What?
I mean, I know what analog is and I know what digital.
I don't, I'm a student.
I've studied it, but I don't have a preference for it.
But I mean, like coming back now, years later looking at it's like the idea behind, between
analog and digital, digital is ones and zeros, but analog is, is a curve, right?
With spikes and, and you know, signal processing and all sorts of extra complicated.
I mean, that's like the implementation of the math in computer science, but the digital
era sim simplifies it down into ones and zeros.
So it's, it's, I just think it's interesting that the computer science world is, is playing
with Legos and I am very fortunate in that that's exactly how I see my professional work
is I get paid to play with Legos.
I am the luckiest person ever.
I get paid to play and I solve puzzles, right?
So I'm sorry, I'm going to take all, I'm going to take some talking here.
In first grade, I was introduced to logic, right?
Via Einstein logic puzzles.
And if you're not familiar, Einstein logic puzzles are basically like clue in a word
puzzle, right?
So you get, you get like clues and you have like a grid of, of like scenarios and you're
trying to figure out who did what in what room, basically, but of various kinds.
And so this is the introduction of logic because you have clues and through the clues you can
deduce what, what has happened or who's done what.
And so from the very beginning, literally first grade, I was taught that logic is a
game.
The implementation of logic is a game.
And so when I went into computing and engineering and computers, I'm playing now with logic
and it is a game.
And so I mean, I honestly try not to take things too seriously because it's all just
a game to me.
And, and I realized that like, depending on the situation of the scenario, it's not a
game, right, when you're launching people into space, you know, making sure that things
don't blow up is not really a game because people's lives are like at some base level,
it's a game to me.
It's a game.
I enjoy it.
You have found a beautiful way to gamify, you know, what is work, right?
Like what is to some a really painful thing to have to go do.
But for you, you've turned it into something beautiful.
And I love the Lego analogy, which I don't know if you noticed, but the built for dev
logo, which is very small in the top background, but that's exactly what that is based on.
Interesting is actually Lego blocks.
And I have little command terminal prompt arrows in there because it's like, it's like
the Lego blocks of sort of developers, right?
We're like in this, we build things structurally, just like you said, sort of with those Legos,
but I'm like, it's not just Legos, right?
Because there's a, it isn't that simple.
We don't just get to stack things together, right?
It's like our Legos have to be interconnected and they have to work together and yes, maybe
you can do that with Legos and various pieces, but that's where I kind of brought the command
line sort of terminal vibe into it.
Yeah.
So my branding is very much aligned with your, your views on software engineering, which
is I like that.
I like that.
I do too.
Okay.
So what do you do in your actual day to day?
Or if you can show your job title where you work or that sort of element, you know,
what are you up to these days in your, in your work play life?
Sure.
Well, I haven't been told I'm not allowed to tell you.
So I will tell you.
Well, there we go.
The clients are maybe a little restricted, but I can tell you what I do.
So my title, I'm a senior engineering manager, which means that I can manage and run teams.
I've been a team lead, but my, my personal skill area between, you know, the long history
of like speaking in public and being comfortable talking.
And of course, also being really deep down the rabbit hole with tech is I, I excel at
communicating technology to non-technical people.
I can break things down simply and explain it in ways that they understand a little better.
And so I specialize in communicating between like business people, so C-suite senior managers,
directors, into technical teams to make sure are we talking the same language?
And it's, and it's not really like a product role, although it's kind of adjacent, I suppose
in some ways.
But that's kind of, that's kind of where I thrive is, is in that, in that area.
And I also love to be hands on.
Now, I, I'm one of those people who like, I'll code in my free time.
Like in college, I would miss parties to code and work on stuff because like I said, it's,
it's playing.
I'm playing.
I'm having fun.
Like it's not that I'm, you know, stressing out about stuff that sometimes you do.
But so it's, it's, it's very much play.
But for me, my role is to lead and be a leader and make sure that the team is doing what they
need to do.
I love teaching.
One of the things that my father said to me growing up is that Harris men, all Harris
men are either teachers or preachers.
And I, like I said, in my talk at the Commit your code conference, I am not likely to become
a preacher, but I, I love to teach.
And it's funny because I was thinking about that later.
It's like, I preach just not religiously, right?
I'll preach about acting code and seeing the praises of, of, of code patterns.
But I love explaining things to people and seeing the light come on.
That's really what, what really makes me happy.
And I'm sorry, I'm going off on tangents.
Don't apologize.
It's great.
Professionally, it's, it's about, it's about doing that and leading teams and, and making
sure that, that people are, are just, you know, that, that the, I work for a consultancy.
So it's that the client is getting what they want.
Oftentimes, if you've been in the role before, you know that what they say they want and
what they actually want, do not always line up.
Yep.
And, and so it's, it's about trying to understand what do you actually want?
What do you actually need versus what are you telling me?
Because you might have, you know, an exec might have like read a cool tech blog about this
new tech thing.
And it's like, oh, we need to use this.
And you're like, but that's actually not going to fit the problem that you're trying
to solve.
At the end of the day, they're writing the checks.
So sure, if you're, if you're hell bent on this particular piece of technology, okay,
but, but it's my job to be honest with you and be like, that's not going to solve your
problem.
Yep.
That's, that's so interesting because, gosh, I can't remember.
I want to say it might have been the Monday episode with Tim Banks, but I, I cannot recall,
but I do recall this exact conversation where we were talking about the type of developers
that we are and I feel the same exact way as you, like exactly.
I was the lead developer at many agencies before I got into sort of big tech and shifted
into more enterprise work.
And I was the one that talked to the clients and the clients notoriously were like, I want,
you know, this whatever it was, I want this and I want it to connect to this and do that.
And I'm like, okay, what's your end goal?
Right.
What is it?
Where is the end result that we are looking for and had those conversations in the same
way, right, of like, okay, you want this, you're over complicating it because it's really
just this, right?
It's just this feed.
It's just this sort of embed or it's whatever this integration.
And I absolutely loved it because I feel the same way and that I do enjoy technology very
much, but I started in business management.
And so I think coming from sort of a business space and then coming into tech, I look at
things differently, I think than traditional, you know, technical people.
And I think it's so important because at the end of the day, absolutely, we can build Legos
and we can build what we want.
We can have fun.
We can do puzzles.
We can do what we want.
But if we're deploying something for a customer or for an actual use case, the closer that
we are to understanding that, then the better than that result ends up being.
And for me, that's so powerful.
So I love what you shared.
And I think also really instilling that into some of the listeners because it has been a
theme throughout many of the interviews of this, this idea of understanding business in
a technological role, because that's where you will shine.
You will sort of separate yourself from the rest of the herd.
So I don't know if you have opinions on that too with your team, if you try to instill
sort of some of your thinking into that team so they can also level up in that way.
But yeah, I, I so, so, so much agree.
Absolutely.
And I, I've, I'm very team centric.
I love working on a team.
We were talking beforehand, like I struggled to do things on my own, but like I love teams
and orchestrating teams and working with teams because when you work with teams and you all
pull in the same direction, magic happens.
And if you've ever worked on a high performing team, there's this driving urge and this driving
need to work on high performing teams again, because there's so little friction when everybody
knows what they're supposed to be doing.
Everybody understands where the team is going.
There's a lot less, like you don't need to micromanage because the people, the people
already know what they need to do.
And they're already fueled because they're like high, they're like high performance.
So they're like fueled by their own agenda and desires to win.
And I think, I think that the, the leader of a team, whether it's the team leader, the
manager or even the director over like a lot of set of teams can really play a big role
because everybody's motivated by different things.
Right.
Exactly.
Somebody A just wants to be socially recognized in the group.
Somebody B, you know, needs, needs financial incentives.
Somebody else craves work-life balance and you have to give different people what they
need in order for them to thrive.
Everybody's a different kind of houseplant and you have to take care of them differently.
But if you are able to take care of them in the way that they need, they will give back
to you.
It's so critical to focus on the people because without the people, you don't have culture.
Without the people, you don't have teams.
Without the people, you have nothing.
And so if you don't focus on the people, what are you doing?
What's the point?
Right?
Preach.
Look at you.
You're a preacher and a teacher.
I will stand on my soapbox and say it all day long.
I'm, I'm a people person.
Oh, I really, really, really love that.
Okay.
So in obviously leading teams, sometimes you don't have your hands in the, in the works
and building code.
How much of the percentage of your day are you actually writing code versus leading projects
and teams?
So like many answers in the world of software.
It depends.
I've, I've the last time I was a team lead, I said, I, the last, okay.
So the last time I was, I was leading, leading just like one team by itself, I was coding
20% of the time and I, it bothered me.
I didn't, I missed it.
But I, I trusted the people, I trusted the other seniors on the team to, to get the job
done.
And so it wasn't so bad, but I, my whole time was spending meetings.
That's not fun though.
It could have been emails, but it was, it was in a highly regulated industry that has
lots of bureaucracy, 10 levels of management between you and the person who actually makes
decisions.
And, and so things move slow and you have to play the game.
Yep.
And, and hopefully your, your bosses, bosses, bosses, like in a consultancy, like your bosses,
bosses, bosses knows their bosses, bosses, bosses.
And so you have a direct connection to the top and you can kind of like shortcut things
to get to make moves.
Because when you, when you're a, when you're a consultancy and you're being paid top dollar
to make, to, to deliver value, that's what it is at the end of the day.
We as a consultancy must deliver value in the value comes the form of working code.
So if there are things in our way that are preventing us from building working code,
from delivering the value, we got to tell somebody who can make decisions.
Yep.
Because we need to get unblocked.
And I forgot where I was going with that, but it's all about making sure that you can
deliver results at the end of the day.
Yes.
Oh, yes.
About my, my coding percentages.
I did.
I've also been, my, my favorite is probably 80, 20, where I'm coding 80% of the time and
I'm managing 20% of the time.
The 80, 20 rule shows up everywhere.
But for me on a team that is high performing, without getting deep into the weeds of forming,
storming, norming, performing, and how you interact with the different teams that they're
different, you know, synchronization stages.
A team that is performing needs much less coaching.
And so one of the things that I, I am big on, and I'll recommend this to, I recommend
this to everybody from every level, from junior all the way to senior to team leads, even
managers, but the people, especially the people who are ICs, the individual contributors,
the ones who are in the code is you have to do code reviews.
Yes.
Everybody must do code reviews.
And it's not, it's not because I need everybody to make critical comments on the code, but
more code you read, the more code you're exposed to, the better you get, the more, the more
perspectives you're exposed to.
And so you become better because you'll see something and you're like, what is this?
Why are they doing it this way?
And then you can go to the developer and be like, can you explain this to me?
And there's two outcomes from needing something explained to you.
One is because it's a normal pattern that you don't know.
Yep.
You haven't been exposed to before.
Fine.
We've all been there.
We've all done it.
The other reason is that it's an anti pattern and there's another way we're already doing
it and they shouldn't be doing that.
And so instead you uncovered a technical debt that is getting put into the pipeline.
And so my biggest thing about code review is I am strict with code reviews.
I don't let bad code into the code base because as soon as it's the code based, you have increased
tech debt.
And there's always a balance of tech debt versus managing tech debt.
And every time you add tech debt, you are, it's like, it's like borrowing on credit from
your future self.
And you're not going to be able to deliver debt because you are going to need to spend
time covering your tech debt.
And I asked probably one of the greatest scrum masters I've ever worked with.
I was like, can we, can we allocate like a sprint a quarter to tech debt?
And his answer was tech debt shouldn't get into the first place.
And I love it.
That's the theory.
Practically, I know, I know.
So the only way you can manage it is to step prevent it from going in.
And so I will give you a hundred comments on your PR.
I will tell you everything that's wrong.
I will, I will outline all the stuff you need to do.
And I will work with the team so that they understand here's what I expect.
And I will not merge your code.
I don't care for pushing deadlines.
I am not letting tech debt in because that's going to bite me later.
And I'm also big on testing.
I could go on a whole rant about testing.
But that's also part of it is like, is your code not only high quality, is it easily readable?
I want, here's my thing.
Yep.
My wife is much smarter than I am, but she, but she's non-technical.
My goal for any code that I write in a professional setting is that my wife needs to be able to
stand over my shoulder and read my code and tell me what it does.
The code should read like plain English.
People say, so, so there's, there's kind of two camps, right, between comments and not
comments.
I tend to err on the side of not comments.
I do comment when things are weird or like, this is an anti pattern that we kind of need.
And here's why here's the logic behind it.
Come fix it later.
Makes sense.
But a lot of the time, you know, comments get added and then the code changes and the
comments don't get updated.
So they become.
Tech time are not really like that, but like they become obsolete or in worst case, misleading.
And so exactly misleading is awful because you're chasing.
But if you can write your code in such a way where you read it, it makes sense and you
don't have to think about it.
You're going to have a better time because honestly, as a dev, you spend more time reading
code than you do writing code.
Whether you're reading code live in your editor to implement new features or fixed bugs, or
whether you're reading it in pull requests or code reviews, you're reading a lot of code.
And so my whole thing is the more brain cells I need to figure out what your code is doing,
the less I like it.
Yep.
Well, I mean, and speaking to you said a whole bunch of really amazing things in there, but
speaking to you and wanting to code 80, 20, right?
You just gave a whole bunch of hints and tricks and tips to anyone who was a manager who would
like to be coding 80, 20, because essentially that's what it comes down to is good leadership,
right?
So as a leader, if that's what you're looking to do, you want to be able to invest and actually
partake in that team as a contributor with your development skills, you have to be the
leader that you just explained.
You have to be diligent.
You have to be learning.
You have to be teaching.
They have to be diving into things.
You have to be reviewing that, mentoring.
To me, it sounds like you are an amazing engineering leader that has found the patch and hack and
tricks to be able to stay an engineer while also being an engineering leader, which is
not an easy thing to do.
No, it's not.
It's not.
There's something that's critically important about this dynamic, though, that I didn't
touch on and I'll call it out.
It revolves around an idealistic team structure.
So again, I was a Boy Scout and so I relate high-performing teams to my days in scouting
because that's when I was on the highest number of high-performing teams was around scouts.
But putting that in a coding perspective and in a professional software setting, there
are two leaders on the team.
Okay.
I have a lot of side tangents here.
There are two leaders on the team.
One is the team lead by title, by role.
The team leads job is to interact with people outside of the team and make sure that the
team is moving in the direction that the company wants them to go, that they are interacting
with other teams around them in the same way.
So I'll refer to them as an external team lead.
They are spending 80% of their time with external people, functions, teams, et cetera.
And then there has to be an internal team lead whose job is to make sure that the external
team lead is understood and the ideas are properly communicated to the rest of the
team because you have to have somebody with who's basically in there at least 80% of the
time, boots on the ground, making sure that things are running smoothly, that people aren't
blocked because if I'm in meetings 80% of my day, I can't be getting into the nitty gritty
of why your code is stuck.
But I need somebody who I can trust, who the team trusts to do that because it's a critical
role.
It's, again, being very team oriented, speaking about mob programming, it's all about coming
together to overcome the obstacles.
And I will say one more thing because on the tangent of leadership, one of the best pieces
of advice I ever got was from, we call it the people team, which is a nice way to say
HR.
The head of our team was giving a talk and he said, leadership is an active role.
If you want to be a leader on your team, you cannot sit on your heels and be expected to
be called on.
If you want to be a leader on your team, you must step up, you must take responsibility,
you must follow through, you must communicate.
And the reason I tote code reviews is because that is the easiest way to become a leader.
That's a really good litmus test, right?
Because as you start reviewing codes, you start seeing, you start to see the patterns,
you start to understand what the team is doing, you start to call out.
And as soon as you start to make critical comments on people's code and it's not attack
the problem, not the person, be hard on the problem, not the person.
The team is there and you're trying to make the team grow, but be critical of the code
so that it's all contiguous or all looks, the idea, the hope for teams is that no team,
you can't look at a piece of code and tell who wrote it.
Yeah.
That's beautiful.
That would be beautiful, right?
Because the team's working together on the same vein.
I want to throw out a book recommendation for anyone listening, Rise by Patty Azarello
is a very, very good book.
And it speaks to everything that you just said.
And I feel like it's a very enlightening book for engineers to pick up because we're
good at certain things, right?
We're very good at sort of the do better.
We're good.
And so she's got three different sections.
It's like do better, connect better and something else.
But the do better, right?
We are always like, how do we get better?
How do I write better code?
How do I learn new?
And so devs are amazing at do better.
We are horrible at the communication and the actually highlighting of our work and the
impact that we're driving and truly getting to that place of self-advocating for a promotion
or self-advocating for growth and some of those things.
And so you spoke to a lot of different dynamics that I learned in that book.
And so I just wanted to share that because it's just a very powerful book.
It's called Rise.
Strongly recommend.
Yeah.
It's called Rise with a Z. So R-I-Z-E. Patty Azarello.
Two Zs in the last one.
Thank you all on that playlist.
Yeah, you should.
Okay.
Talking to you could, honestly, I could talk to you for hours and hours.
And we're like already sort of nearing the end of the time, but I'm like not even close
to all the questions I want to ask you.
So super quick.
What's your preferred tech stack?
So I know you're in consulting and so sometimes that means you might be working from different
projects and doing different things.
So what do you get to get your hands in then?
Does it vary or are you sort of a specific tech shop?
And that's what you work on.
Personally, again, depends on what I'm doing.
If I'm going for speed and rapid development, I'll pick what I'm most comfortable with.
And that's my general recommendation of anybody.
It's like, what's your tech stack?
It's like, what are you comfortable with?
And the beauty of JavaScript or in my case, always TypeScript, never raw JavaScript or
vanilla JavaScript is going to be a full stack TypeScript application.
I've been learning Go as I miss, I miss, there's something beautiful about Go.
Go is like if TypeScript and C++ had a baby and it's beautiful.
I honestly, I didn't expect to like it as much as I did.
But Go is wonderful for lots of reasons.
So highly recommend checking it out.
But if I had to just pick a tech stack to go and run with, it would be TypeScript.
But I guess that's not a tech stack.
That's a language.
Got it.
So I'm a React front-end React guy.
I actually learned React native before I learned React.
So it may even be Expo because Expo now has React native and React web kind of all together.
So you can build websites and mobile apps because depending on the client, it's like,
we want to cross-platform app.
We also want a website and they all need to be in sync.
And the easiest way to do that is to not have three or four code bases for iOS, for
Android, for web.
So you can just do Expo.
Great.
It's still, you know, we're still getting all the kinks worked out, but Expo is really
good.
And then for backend, it's going to be a Node.js app.
And I've done Nest.
I've done, you know, home done, express, fastify.
I started working with Hono just because I saw people cheering it on.
But if I'm in a professional setting, and this is a key part, if I'm in a professional
setting, it's going to be Nest.
Nest.js.
It's got like a lion, not next.js, but Nest.
Yes.
And the reason for that is because it's a framework.
And personally, I'm not big on frameworks because they're very prescriptive on how you're
supposed to do things.
But the idea behind using frameworks in a professional environment is that it is prescriptive in
how you're supposed to do things.
Because I don't want people making their own patterns for things.
I don't want you to be able to say, I have this issue.
Let me go read the documentation.
How does the documentation recommend that you do this?
And that way, in it's consistent over time.
Because if you have a long lived coding project, if your repo is five or 10 years old, you're
going to have a lot of developers come through.
You're going to have a lot of different leads.
A lot of people are going to touch this code.
And so more consistent, you can keep it the less tech debt you're going to have over time.
And the more, again, value it's going to be able to deliver.
It's going to be more easy to work on.
It's going to be more easy to move around.
And so the hope is you pick something that's mature and tested in high use production environments.
And Nest is kind of my go-to there.
I like that.
Okay.
Yeah.
I love that.
That was a very good answer.
Because you explained why you explained on your personal side, you explained more on
the business side.
That was beautiful.
Okay.
I love that.
So as it relates to sort of your, I guess, like your setup, right?
What are the tools that you use on a day to day basis?
Just the tools that you're like, I can't live without these.
If they disappeared, you'd like maybe shed a tear.
What are those tools?
I don't have any die hard tools.
I need categories of tools.
I know, right?
I need categories.
Oh, categories.
I need a diagramming software.
You can use Xtalligar, you can draw IO, you can use Miro.
Doesn't matter.
I need something to draw pictures.
I'm a very visual person.
You can communicate ideas very easily with pictures.
And so draw IO is cool because for people who use VS code, there's a draw IO extension.
So you can have dry, oh, rendered in your editor and you can commit things.
So if you have like architecture diagrams, you can put them in your repo version control
them and see as they go along.
Excellent.
Love that, right?
It all boils down to like XML at the end of the day.
I've been using Miro.
I use Miro on my last project.
It's great.
I love it.
Very effective, especially if you have like the premium version unlocked.
Yep.
Lots of people use that too.
So sometimes it's nice to just get some of those templates and other beautiful things
that go on the marketplace.
I highly recommend the Jira suite or sorry, the Atlassian suite.
So that's Jira Confluence and the bajillion other things that they do.
Jira for your task management, whether it's scrum or Kanban or however you're organizing
your team tracking and then Confluence for like kind of the wiki aspect of it.
I kind of just, because I think there's beauty in simplification.
And so the fewer tools you need to get the full job done, the better off everybody is.
And that's again why I like TypeScript for a full tech stack because one developer can
work on touch everything.
But the other, to answer your question about like what do I need, I'm going to give a huge
shout out to Vim and specifically I'm a Neo Vim user.
You know, and there's a lot of memes about that, but I won't mean myself.
The idea is that, and it doesn't need to be the Neo Vim editor specifically.
It's what I use.
But like I started with the VS code with Vim motions.
I am a shortcut junk.
Any like really bad, like if I have to go like find something in a menu, I'm mad about
it.
And so VS code is really good at having shortcuts for everything.
And so I'm sitting there working doing a live coding session with my manager four or five
years ago.
And his cursor is in the middle of a word and then I hear his keyboard click and the
word disappears.
And I'm sitting there thinking about it being like, all right, so I use a Mac.
So it's like I could command left backspace, like command left, command backspace to like
jump to the other word and delete the word, but he didn't do any of that.
And what is that?
And he was like, oh, that's Vim motions.
It was just DIW, delete, delete inner word.
And I was like, what?
And so I started down the rabbit hole of Vim motion.
And it's hard to explain to people the beauty of it.
But the best analogy I've come up with is imagine your grandmother copying and pasting
something from a webpage in general.
Your grandmother is on her computer copying and pasting.
She's going to take her mouse.
She's going to go up.
She's going to click and drag and select.
She's going to right click and click copy.
She's going to go into the application.
She wants to paste it and she's going to click right click.
She's going to paste it.
And you're like, grandma, just control C, control V, please, just do it.
It's like that.
But she might also go all the way up to the navigation bar and not even right click because
that might not even be a case.
And so after you get used to Vim motions, it's like this, but for normal developers.
And so that's kind of what it feels like sometimes watching people program that aren't Vim.
And that sounds so elitist.
And I feel kind of bad saying it, but like it's kind of, it's kind of true.
Like people, you don't know until you've been on the other side of it, right?
And Vim is one of those things that you have to rewire your brain for.
But it's to the point now where I get mad if I can't use Vim motions and things.
And it's interesting also because you start to, you start to, you start to like, you'll
hit buttons in non Vim applications and sometimes they work.
And you're like, oh, these developers use Vim.
I noticed.
Like, so example, example in, in, um, in, I use Alfred, but I actually, it may be the
way in spotlight search just in Mac.
Uh, is it?
Yeah, it's all muscle memory.
So like I look at the keyboard and I can't tell you what keys it is, but in Vim, uh,
P and N are for previous and next in a list.
And so in, in spotlight, you can hit, I'm pretty sure it's control N to go down the
list and same thing in Chrome control N to go down the list.
And like, so I don't have to move my hand off of home row.
I don't have to find the arrow keys.
I don't have to find my, I use a track pad, but like, I don't have to find my track pad.
It's just it's hands on the keyboard all the time.
And it's one of those things like Vim gave me a 20% productivity boost.
So I'm, I'm going to shout it to the high heavens all the time.
And you throw AI on top of it, which gives another 30 to 40% productivity boost.
So if you think, if you don't use Vim motions and you think you're productive with AI, try
Vim motions.
It takes like six months to rewire your brain.
And here I'm four years in and I'm still learning about stuff because Vim has been around.
I guess it was Vi before that.
And it was, there were even editors before that, right?
But it's, it's been around for like 40 years, 30 or 40 years at this point.
And so it's tried and true and tested and highly effective.
So it's one of those things like I highly recommend everybody check it out.
It's weird.
It's hard.
You have to have patience with yourself.
What's frustrating is your learning, but learning is that way.
And so when you come out the other side and you feel like a super human, it's, it's worth,
it's worth it.
I remember in college, we had, I had a professor who used Vim and I literally could not keep
up with him as he was coding live in class because he's just jumping everywhere and making
edits and yank and pasting and moving things.
And I'm like, where is your cursor?
I don't get it.
So it's almost like you can move around your editor and your files and your code at the
speed of thought, if you will.
There's just a lot less friction between having to navigate or move or copy and paste or delete
things or it's a deep rabbit hole.
So if you want to embark on it, I highly recommend it, but it's not for everybody.
But you can get the VS Code plugin, you can turn it on if you want to try, you can turn
it off.
The Primogen, who's been a huge content creator in the dev community for years now, has some
great VIM tutorials.
That's how I learned.
I highly recommend checking them out.
His whole shtick is like, learn four, five keys at a time.
Use them for a week.
It used to.
That's nice.
And then as soon as you're comfortable with it, learn a couple more and build slow.
It's like learning any language.
Go slow, take your time, have patience with yourself.
Are you okay?
Yeah.
I love that.
So that definitely sounds like the tool that you would shed a tear over if it were to just
disappear.
Yeah, VIM motions.
I would cry.
I love that.
Okay.
Last question, even though, again, we could talk forever.
When you are stuck, what do you do to get unstuck?
Similarly to apply to that sort of, how does that play into some of your decision making?
I'll let you take that.
As you will.
So I am guilty of the idea that if I'm stuck on something, I got 10 things in my brain I
can try.
So I'm going to just run on the list, right?
This is the most likely.
Oh, that's not it.
I'm going to do a second.
That's not it.
I'm going to go to the third.
And by the end of the 10th, by the end of the 10th item, I'm like, I could try this,
or I could try this, or I could try this.
And the beautiful thing about software is the rapid feedback loops, which is actually what
I wanted to talk about in my conference talk, by the way, was feedback loops.
But the interesting have fast feedback loops.
It takes me a second to try another thing.
And so in an hour, I can try 3,600 things math, you know, 60 times 60, 60 seconds a
minute.
Yeah.
Okay.
That should be right.
So, you know, I can try a bunch of things.
And so I am guilty of, but I haven't tried this yet, but I haven't tried this yet.
So the, the, the idea is that can be, that can be bad though.
It's not good.
Like you have to time box stuff.
So usually it's 20 minutes.
If I'm, if I'm in like a professional setting, it's 20 minutes.
And lately with the introduction of AI, if you're allowed to use it on your projects,
you go talk to AI and you get the problem.
Yeah.
But totally, I might recommend that you talk to your teammates before you talk, like not
necessarily before you talk to AI, but to pretend, but depending on what you're stuck
on, talk to your teammates.
Absolutely.
And I, I could get into my talk and where it was and about talking to your teammates
and building up relations and building community and how that affects your whole like professional
trajectory and it's a whole thing.
I got a rant, but I know we're low on time.
So I'll spare you.
But the idea is you got to time box yourself.
You got to say, if I'm stuck for 15 minutes, I'm going to talk to somebody and that is
just my general rule of thumb for, for my team and I tell them that at the beginning,
it's like, if you're stuck, try it, try, try four or five things.
If they don't work, pay me.
I would rather you bother me because you're stuck because my job, the whole, the whole
idea, okay, try not to make this a whole rant too.
I'm, I'm going on.
That's, that's the name of the game.
Servant leadership.
And the idea behind servant leadership is if you're unaware is that it is your boss's
job to make sure that you are not stuck.
Your boss serves you.
It's not the other way around.
And so, yes.
Thank you.
Preach, preach, preach seriously.
Or my soapbox.
But the whole concept is if I am the lead, I expect you to tell me I'm stuck.
I expect you to post and slack.
Exactly.
Hey team, I'm stuck.
Who's free?
They're, they're neat. I love having a slack channel that's dedicated to junior dev questions.
And it's things, and I expect seniors to post it.
It's like, I don't remember.
I have to Google it.
Like, you know, like there's stuff that it's like, depending on the dynamics around it,
it's actually quite difficult.
Exactly.
And so like, there are things that's like, I should know this answer, but I don't.
And so it's not, it's not to like, you know, harp on junior devs or anything, but it's
like, these are the questions that I, these are like base level questions that I probably
should know, but I don't.
And it's important that again, kind of go back to leadership and team dynamics, that
you foster a team culture where it is acceptable and encouraged to reach out when you're stuck.
Because if you have people who are stuck and they're stuck for hours, they get stuck for
days, they'll be stuck for weeks.
I've seen people get stuck for a month and it's like, this is bad.
This is very bad, especially as a consultant, like I said, our whole thing is to deliver
value.
If you're stuck, you're not delivering value.
So work with me, talk to me.
If I'm not available, I'll, I'll, I'll ping somebody else and be like, Hey, I need you
to go work with this person because they're stuck.
Exactly.
Like, exactly.
And it, and it, and when that happens to like, when that sort of, and it happens quickly,
right?
If you don't ask for help, it, that hour turns into days, days turns into the weeks, weeks
turns into months, and it happens very quickly.
And when it does happen, you end up getting in this like little Kramudjan bucket because
I've seen it happen with developers that I've also led.
Where they get in this very negative depressive state, right?
Because they, they are continuing to try to fight a fight that they are losing and they
don't have the ability to actually, you know, sort of grab the reins and actually chase that
down.
So I love that.
I love that.
That's a very good feedback.
I was going to say something in my brain, just like completely forgot what it was, but
whatever it was you shared was amazing.
So thank you.
I, like I said, kind of before we live is I live a lot of, I live a lot of my life in
my head and I spend a lot of time thinking about my thoughts, which is very meta, but
like I, I like to think that I have things that are at least interesting to hear.
So I, I, I appreciate the feedback.
Yeah.
Of course.
Okay.
So we got to talk about this before the call and I think that it was a really cool fact
to learn about you.
So you shared with me that you had your coffee and that you felt like Superman.
I would love if you're open to it to share your story on coffee, because I first off
think you have some major self discipline and I just think it's very respectable.
Thank you.
I am an open book, generally speaking.
So I'm happy, happy to share.
I don't, it's, it's hard.
I don't, I don't lie because I have a hard time remembering what I lied to people about.
I'm usually going to tell the truth.
So coffee, I drink coffee on Fridays.
Friday is my coffee day.
Every once in a while, I'll take a sip of my wife's coffee if I'm really dragging one
morning, but literally just like a sip.
And the reason for that is that when you drink coffee, if you're not used to it, the first
time you drink coffee, you feel like Superman in my case, you feel like Superman and I can
take on the world and I'm excited and I'm full of ideas.
And the idea behind doing it on a Friday is that usually Friday is the day where you're
dragging your, you've been through a week of work through the slog.
And you're tired and you're grumpy and you just want to be left alone.
And I've certainly been there, but for me, coffee on Fridays really takes the last day
of the week and like cranks it up to an 11.
And it just makes me jazzed and I'm excited and I want to get things done.
And I'm stoked in my to-do list just gets destroyed on Fridays.
And so it's, it's all about, it's all about feeling like Superman.
And so, you know, if you, if you have, if you're not to harp on regular coffee drinkers,
but if you are a regular coffee drinker, which I certainly have been before the first time
you drink it, you feel like Superman.
And then the next day you feel like 75% of Superman and the third day is 50% of Superman.
Eventually you're drinking coffee just to function.
And I, I want to, I want to feel like Superman more often.
Right.
So, so by doing it just on Fridays, I can get that, that, that super charged feeling
by once a week.
So it's, that's, that's kind of my coffee routine.
This is my treat.
I, I loved that so much.
And honestly, so I'm going to be totally transparent.
Um, we have a two year old and my husband normally takes two year old duty.
I'm the one that works.
He's a stay at home dad.
He does actually do some farming and some other stuff, but for the most part he's got
child responsibility.
And so he didn't sleep well the night before.
So I took child responsibility last night.
I didn't fall asleep till like 1am for some weird reason.
And then I, I know.
And then I woke up and that's like, I go to bed at nine.
I'm like, total old person.
I go to bed early.
Um, so that's not cool.
Like I'm anyways, you know how I'm feeling, right?
So I wake up at five and I can't really get back to sleep.
And then my toddler wakes up at six.
So I got maybe four hours of sleep last night on a positive side.
Um, so when I came in to talk with you, you were like just a, like a bottle of energy.
And normally that is, that is how I am.
I'm usually just full of energy, but I came into and I was like, okay, harness the energy
Tessa, you are tired today, but you can do it.
And your energy like absolutely just fueled me.
So I just wanted to call that out because I was having one of those Friday mornings,
non related to it being Friday, but still felt that way.
And you very much, um, reinvigorated my energy.
And it was just really,
Energy is contagious.
I just wanted to share that.
It is, it is contagious.
I agree with that.
Okay.
Well, lots has been discussed.
There is probably a lot of really awesome follow up questions or folks that, you know,
would like to get to know you more.
You're a very interesting, awesome person.
I got to meet you at commit your code.
So side note to anybody, um, commit your code was a conference in Dallas.
The videos are on the internet.
You absolutely need to check out Noah's talk.
He did a fabulous job on a really cool topic.
Um, was it, was it called mom programming or what exactly was the title?
The title was intentionally click baby so that people would come to my talk.
Uh, it was called benefits of joining the mob.
I thought it apt.
Yes.
I thought it was an apt title.
Yes.
It's perfect.
So go check that out.
It's out on the Dallas software meetup group out there.
Um, definitely look it up, but where can folks find you outside of that presentation
if they are looking to connect?
Uh, I'm on, I'm on LinkedIn.
That's probably the easiest way for the general public to find me.
I admit that I'm not good at social media.
I'm, I'm working on it.
I'm getting better.
But I'm also on blue sky and the reason I'm not on Twitter is because I just use Twitter
to troll politicians and I don't want to connect that to my real, my real self.
So you can find me on blue sky.
You can find me on Twitter.
Pretty sure it's in Harris 31.
I can, I can actually look that up.
I should, something I should know off the bat.
Um, hey, that happens sometimes though.
If you don't care about social media as much then, you know, I was right.
And it was 31.
So you could find me there.
Blue sky Twitter.
Um, that's, those are the good ones to find me.
That's, that's, that's where I try to not be an anonymous fly on the wall.
I'm on other socials, but I'm a lurker there.
So you probably won't find me.
All right.
Awesome.
Well, LinkedIn is honestly pretty poppin and pretty, um, pretty active honestly in
the software engineering and sort of technical space right now anyways.
So it seems like most are like, just find me on LinkedIn, which is a, such a change from
previous years, but it's exciting.
Yeah.
This has been lovely.
I have enjoyed this conversation so much.
Um, folks, check out his presentation.
It was so powerful and very good.
Uh, Noah, thank you so much for your time.
Any parting words you want to share with folks before I hit that end stream button,
you gotta find your tribe.
You gotta find your people.
I, I over COVID.
I suffered from self induced isolation and going to commit your code reminded me how much
I needed people in the tech community to talk with, talk shop with, get nerdy with,
because people in tech, if you're in tech, the people in tech around you are going to
get excited about the things you get excited about and build friend.
That's how you build connections.
And so Tessa, I want to say thank you so much for inviting me.
I, I am glad that we got to connect.
I'm glad we got to go to commit your code.
I am invigorated.
I'm actually starting a code and coffee chapter, I guess here in Buffalo, New York to kind
of get that started.
Yay.
And I am, my whole life has been re-invigorated since, since the conference.
So that's my, that those are my parting words is find, find your tribe, find your people,
get out of your house, especially if you work from home and, you know, be, be a light for
others.
I agree.
And just to add a really super quick layer on top of that, I felt the same way about
commit your code.
I have been in my own business.
I got laid off in early last year.
I had been in my own business for most of the year and I just felt like I was just grinding
and it was, I was getting to like a depressive state, honestly.
And when I went to commit your code, it was like, everything just re-lit up again.
And I was like, Oh my gosh, this is it.
This is it.
And this is like, and I said it in a tweet during the event that, you know, definitely
spread a little bit around the event, but developers are not anti-social.
We sometimes we can feel like that.
We feel like we need isolation.
We don't actually need isolation as humans.
We don't need it.
We need people.
But if you do fall into that bucket, go find those developer curated channels is what I
call them.
So Danny decided he wanted to organize that event.
He brought a crew of developers together.
There isn't a corporate agenda.
There's not a 100 K booth setup.
It's a developer event where you can go and spend time with your peers because we desperately
need it.
And when we get it, just like we did, it refuels you for honestly months.
I'm still refueled from commit your code and I'm still thinking about it today.
So you too.
All right.
This has been so lovely.
Thank you, Noah.
And I hope everyone has a fabulous rest of their day and weekend because it's Friday.
Have coffee.
Yes.
Thanks, y'all.
Bye.