- Correctness versus performance.
So this is a big one for me, because we've also been trained
as developers to kinda focus on performance, again,
as a priority, and we tend to write code
with the idea that this gonna be faster than that.
The reality is is that unless you've done a thousand times
and you already know, you're guessing,
and usually code that's focused on performance
is clever code.
I wanna reverse the tables on this.
I don't wanna optimize for performance.
I wanna optimize for correctness when we're writing code,
I wanna use our debuggers and our profiles,
not really our debuggers, I apologize, our profiles,
our ability to benchmark, our ability to trace,
to identify where we may have a performance problem,
and then fix the performance issues like that,
still trying to maintain levels of correct or readable code.
Look, the performance of your software
is gonna come from four places,
or I should say the lack of performance
is gonna come from four places.
First is latency, and it's gonna be latency on networking
and IO, disk IO, those types of things.
That's going to be a real killer of performance,
and those are things you probably want to focus on first.
Your next potential performance strain
is going to be on memory allocations.
We're gonna talk about that in this class,
and memory allocations can cause performance problems,
and we'll see that when we start
talking about the garbage collector,
and the garbage collector's doing an amazing job,
but we don't wanna walk away from it.
When we talk about performance in GO,
it's not about is it the fastest,
it's about is it fast enough,
but garbage collection and memory allocations,
that will be your number two.
Number three is going to be how you access data,
how efficiently you access data.
We're gonna talk about that in this class as well.
And then, number four would be algorithm efficiencies,
can we streamline an algorithm to take less steps than more,
and we tend to, if we're optimizing performance,
focus on that piece, and the reality is
the hardware's gonna be so fast
if we solve the first three problems,
that we can have a little algorithm inefficiency,
and still get more than we need in terms of performance,
and now we're optimizing for correctness,
and this is really where we wanna go.
And there's some great quotes
by some amazing people in this area.
Wes Dyer, "Make it correct, make it clear,
"make it concise, make it fast."
I want us to listen to this history.
These are people who've already learned these lessons.
I don't wanna make the same mistakes.
Alright, JBD who works over at Google, and again,
you gotta look her up,
she's also a tremendous thought leader in this space.
Engineering's not about finding the perfect solutions,
it's about understanding the trade-offs,
we talked about this.
Engineering's about understanding the costs you're taking
for the benefits that you need.
It also is about optimizing for correctness,
knowing what we're doing in terms of our code.
And correctness of the implementation
is the most important concern.
Listen what Al is saying here,
"but there's no royal road", listen to Al again,
what he's gonna say is that it takes several things,
invariants, that's the engineering costs,
testing and code reviews.
And testing and code reviews really require our ability
to read and understand code.
Without our ability to read and understand code,
we're really going to be lost.
There's a great quote that says that
we are one of the few industries where we ask people
how to write code before we teach them how to read,
and this is really mind boggling
when you start to think about it,
because everything that we're gonna talk about,
about correctness,
is going to stem from our ability to read code first.
And this class is all about our ability to read code,
to optimize for correctness, to be productive.
That's what we're trying to do,
that's what GO is trying to do,
and if we continue to look at quotes even from Bryan, right,
the basic ideas here of good style, of correctness,
they're fundamental to writing clear and simple code,
and we've known this, he's known this for over 35 years.
I'm not telling you anything new,
these are not my ideas, these are not my philosophies,
I'm trying to bring to you industry leaders
who are telling us over and over again
correctness over performance when it comes to the code,
and to do that, we've gotta be very good at reading code.
But I love what Jason Fried said here, maybe again,
next to Sarah May, one of my favorite quotes here
in the material,
"Problems can usually be solved with mundane solutions.
"That means there's no glamorous work.
"You don't get to show off."
Okay, you build something, it works, you move on, okay?
And this is really important.
This is one of those quotes
I want you to put in front of you at all times,
because if you are a back-end developer, like I am,
and what you're looking to become if you're not already,
then the idea is that your software
should be working 24/7 without issues.
The reality is nobody should know your name
if you're doing your job well.
If somebody knows your name,
probably means your software's failing or causing problems.
You want people to know your name?
Become a front-end dev.
Front-end devs get the oohs and the aahs,
but I promise you this,
you're gonna spend two weeks working on a screen,
killing yourself to get things in a certain location,
certain words, and the first thing somebody's gonna do
when they look at it is point something out
that they don't like.
Aah, that used to drive me crazy.
I'm a back-end dev, okay?
I build systems to the point
where nobody knows I even exist.
That's a good day in the office.