This is what is known in software engineering as test driven development, or TTD in test driven development.
We start by running tests because, number one, your code should always have tests.
And number two, running the tests.
First forces you to think about how you expect your API to work, and it allows you to make sensible
design decisions without being distracted by implementation details.
So you see how this applies to every machine learning algorithm, not just linear regression.
And a lot of my older coding videos, I unfortunately decided to just write the code straight through
this helps some people, but it's not ideal for others.
In addition, the coding videos will appear without warning.
Generally, the lectures appear in the same pattern.
First we do theory and then we do the corresponding code.
It pretty much always works this way.
So after the theory lecture, you can be pretty sure we are going to implement that theory in code soon,
unless it's so simple that it can be an exercise now to avoid treating everyone like they're in kindergarten.
I don't have videos telling you that it's time to code.
You're all proactive and independent adults.
So when you learn some theory, you already know that it's time to try to put that into code by yourself.
Sometimes you might get stuck and have no idea what's a writing code or what the data set is, in that
case, it's fine to watch the next coding lecture, but don't watch it all the way through.
Watch just enough so that you know what the general idea is and what we're trying to accomplish and
then try to finish the rest of yourself.
Now, let's say you've watched just enough so that you know what we're trying to do, you know the theory,
but you still can't complete the code at this point, you may want to revisit the lecture theory to
make sure you really understood each part.
Failing that, you may want to try and get clarification on the discussion board, feeling that you
may want to look at external resources as well.
Sometimes you might be missing some important computer science background that I've assumed everyone
already knows.
That's perfectly fine because everyone has a different background.
It's highly encouraged to do your own research.
And this is also perfectly normal.
It's not a bad thing.
It's a good thing.
Ask any university student if this is what they do and they'll tell you that they do it all the time.
This builds a level of mental toughness and initiative taking.
That's important.
If you want to learn this stuff, there is a lot to learn and I myself am still learning new things
every day.
So let's say you've watched the theory lecture, you've looked at some external resources on the theory,
and you still don't understand how you would put it into code.
Well, at this point, there are some great exercises you can do.
Watch the coding lecture or look at the phone on GitHub, go through it and make sure you understand
each line.
The next step is without looking at the code again, try to implement it yourself.
This by itself is a great learning tool.
Many of the algorithms I've learned, I didn't understand them the first time I learned them by looking
at someone else's implementation and dissecting it.
I looked at each part and I asked myself, which parts did I get right and which parts did I get wrong?
This helps you understand the mistakes you were making previously.
The cool thing about implementation is it works backwards to we go from theory to code, but thinking
in the reverse direction, the code actually helps us understand the theory better.
Also, I always say that if you can't implement the code, then you don't understand the theory.
So if you can learn the theory 50 percent of the way, try to implement the code, look at an existing
implementation and then finally get it working.
Then you can be guaranteed that you now know more than just 50 percent of the theory.
The act of coding helps you understand more of the theory than if you had just learned the theory by
itself.
So implementation helps you understand the theory, but it also helps you understand the intuition as
well.
Intuition is a tricky thing.
In fact, I would go so far as to say it's a trap.
In many or maybe even most cases, intuition is built on experience.
That means driving the theory from first principles or in other words, driving the theory from facts
you already know to be true and from implementation.
Students often want to hear intuition from people with lots of experience, but the problem is that
this intuition is built on hindsight.
Intuition is often both the first thing and the last thing you want to focus on, you want to have a
little bit of intuition at the beginning so you have some general idea of what you want to accomplish.
Then after you learn the theory and implementation, you can reflect on the details and summarize them
at a high level.
This is real intuition built on hindsight and experience.
The big mistake beginners make is that they read some intuition written by someone else who actually
has experience when they themselves do not, from an outsider's perspective, it's hard to tell the
difference.
Why is there.
Well, if the beginner can regurgitate the same high level ideas as the expert, then it would sound
like they are also an expert when in fact they are not.
There are unfortunately, too many courses out there that do this, they want you to feel good that
you learn something and they want to avoid you having to do anything too difficult.
And because you can repeat the same high level intuitions, it actually sounds like you're an expert.
So this is why I call it a trap.
Knowing intuition not only makes you feel like you know something, it also makes you really confident
about this fact.
And then because your ego wants to maintain this confidence, you'll start making crazy statements like
the theory and implementation are not important because you already understand the intuition.
But as you know, this is completely backwards.
Let's summarize this lecture, since that was a lot of information to take in, remember, this lecture
is all about how and why you should code by yourself.
First, we talked about why this is because it ensures you are thinking about the details and filling
in the blanks using your own pattern recognition skills.
It ensures you don't just assume you know what's going on, but that you actually know what's going
on.
There's a big difference, especially if you're the type of person that likes to assume you know everything.
Next, we talked about how we talked about how all data is the same.
And it doesn't really matter what domain or industry your data is from.
The same algorithms all apply.
Next, we looked at the interfaces to the algorithms, which are also conveniently all the same.
So we have a kind of mix and match type of scenario where we can input any kind of data into any kind
of model.
For example, you can use linear regression with financial data or you can use a neural network on ecological
data.
All data is the same and all models have the same interface.
Next, we talked about a strategy for how to actually apply this, you've probably already seen that
we always alternate between theory and code.
First we discuss the theory and then we implement that in code.
Sometimes you might have to go back and revisit the theory or sometimes you might have to look things
up on the Internet.
That's perfectly normal.
This is pretty much the day in the life of a university student.
We're trying to build the same level of mental toughness and initiative taking in this course.
So the strategy is stop after you learn the theory and try to code yourself.
Sometimes you need a little more detail, so you might want to watch a little bit of the coding lectures
to see what's going on and then try to implement the rest yourself if you can't get it by yourself and
maybe try watching the whole thing or looking at the expected result and then trying to implement it
from memory.
This by itself is a great learning tool because it allows you to ask yourself, what did I get right
and what did I get wrong?
So you can understand the mistakes you were making.
Finally, it's important to understand the difference between intuition, theory and implementation
and how they reinforce each other.
It's important to not fall into the trap of only understanding intuition written by someone else, and
then assuming that this equates to actually understanding everything in many cases, it's not about
waiting for someone to tell you some nice phrases that trick you into thinking.
You understand the intuition, but rather you should seek intuition by working through the theory and
the implementation.
And lastly, don't forget, when it's time to code, you must code.