You Gotta Love Red
"Gosh, it failed again! ðŸ˜"
We've all been there, haven't we.
Early on in my career, I dreaded those gnarly errors so much. They made me panic, it felt like the whole thing was crumbling down and I was running out of time. It felt like a ticking time bomb.
As human beings, we naturally hate failure, we dread it. It is painful, soul-crushing even, sometimes. But as we also know, a pendulum swings higher from a lower point. There's more momentum when we go through the highs and lows.
This is no different when writing code, and even more pronounced in entrepreneurship.
When writing code, the lows are failing tests, broken pipes to databases and other dependencies, crashing servers, and sometimes even the hardware our code runs on can fail us. When building abstract things like software, a million things can go wrong, so when you get a few, worry not!
What you need to learn is the art and the patience of an eagle - from on high, it sees a bunch of prey, focuses on one, and locks it's eye to the one single prey on it's high speed flight down.
When I was first learning to write tests, I would get like 20 test failures and fret a lot, wondering how I was gonna fix all of them, then I would fix one, run the whole test suite and get a bunch of other tests failing, heightening the anxiety.
It was until one engineer, Kwahalf, told me to focus on one thing at a time!
Say it again - focus on one thing at a time!
Run a single test, watch it fail, then fix it. Move to the next. And watch as the pile of rubble comes down one by one and soon you will have a clean surface to work.
When building large and complex abstract systems, focus on making small and singular units work first, even if it means a single unit test, then work your way up to an entire system that works, yes bottom up works.
Now, having errors won't end in your programming journey, they might get lesser as you learn how to avoid them, but you'll definitely get new errors each time, some that you have not seen before. The key thing here is to have a mindset that likes red, erm, errors.
And when they appear, wear your detective hat and go on a hunt - hunts are exciting. Be excited to get that bug out of your system, and celebrate that win. If anything, at the least, you come out with new knowledge!
One other thing I learnt early on, from a friend Justmesam, was that if you can't outrightly fix an error, at least aim for a different error. Now, I used to get surprised seeing him celebrate a different error. I didn't get why anyone would celebrate seeing another red? That was until I understood it meant progress, and it meant the original error was fixed, just that there was another error upstream preventing the whole thing, or the test, from passing.
So yes, if you can't fix the error, at least get a different error and keep going all the way up until the runway is all green.
Once you have all the bases covered, now you can test the whole thing together, to test the pipes, the glues and the tapes. Confirm that the whole thing works as expected.
In programming, errors are our friend, they're the red lights showing us that we went off track and we need to look for the green lights. See them as so. They're not there to remind you that you are a bad coder, or that you are a failure, no, they are just guides to the right runway!
Have that mindset.
And say it one more time - You Gotta Love the Red!
Happy coding.
We've all been there, haven't we.
Early on in my career, I dreaded those gnarly errors so much. They made me panic, it felt like the whole thing was crumbling down and I was running out of time. It felt like a ticking time bomb.
As human beings, we naturally hate failure, we dread it. It is painful, soul-crushing even, sometimes. But as we also know, a pendulum swings higher from a lower point. There's more momentum when we go through the highs and lows.
This is no different when writing code, and even more pronounced in entrepreneurship.
When writing code, the lows are failing tests, broken pipes to databases and other dependencies, crashing servers, and sometimes even the hardware our code runs on can fail us. When building abstract things like software, a million things can go wrong, so when you get a few, worry not!
What you need to learn is the art and the patience of an eagle - from on high, it sees a bunch of prey, focuses on one, and locks it's eye to the one single prey on it's high speed flight down.
When I was first learning to write tests, I would get like 20 test failures and fret a lot, wondering how I was gonna fix all of them, then I would fix one, run the whole test suite and get a bunch of other tests failing, heightening the anxiety.
It was until one engineer, Kwahalf, told me to focus on one thing at a time!
Say it again - focus on one thing at a time!
Run a single test, watch it fail, then fix it. Move to the next. And watch as the pile of rubble comes down one by one and soon you will have a clean surface to work.
When building large and complex abstract systems, focus on making small and singular units work first, even if it means a single unit test, then work your way up to an entire system that works, yes bottom up works.
Now, having errors won't end in your programming journey, they might get lesser as you learn how to avoid them, but you'll definitely get new errors each time, some that you have not seen before. The key thing here is to have a mindset that likes red, erm, errors.
And when they appear, wear your detective hat and go on a hunt - hunts are exciting. Be excited to get that bug out of your system, and celebrate that win. If anything, at the least, you come out with new knowledge!
One other thing I learnt early on, from a friend Justmesam, was that if you can't outrightly fix an error, at least aim for a different error. Now, I used to get surprised seeing him celebrate a different error. I didn't get why anyone would celebrate seeing another red? That was until I understood it meant progress, and it meant the original error was fixed, just that there was another error upstream preventing the whole thing, or the test, from passing.
So yes, if you can't fix the error, at least get a different error and keep going all the way up until the runway is all green.
Once you have all the bases covered, now you can test the whole thing together, to test the pipes, the glues and the tapes. Confirm that the whole thing works as expected.
In programming, errors are our friend, they're the red lights showing us that we went off track and we need to look for the green lights. See them as so. They're not there to remind you that you are a bad coder, or that you are a failure, no, they are just guides to the right runway!
Have that mindset.
And say it one more time - You Gotta Love the Red!
Happy coding.