Morale

Failing often, making mistakes, struggling, hustling, this is the recipe to build character and success. That's what we hear on the receiving side of the podium.

When I was a kid, I always started by skimming the test to identify the hard questions. My goal was to get them out of the way so I can have a smooth sail afterward. As logical as this sounds, things never went the way I wanted. I'd struggle too long with the hard questions and never have enough time to complete the easier ones. As a matter of facts, under pressure even the easy questions look harder. This is because hard questions can destroy morale.

I quickly changed my ways. In school, the other kids would label you as lazy or a cheat if you started with the easy questions. It was a test, no one was allowed to look at your paper in the first place, no one would even know if you were lying. So when I made the switch, I still bragged about starting with the hard ones first.

Every challenge I tackle today, I start with the easy parts. There are no advantages in starting with the parts that stresses you and make you less productive in the long run. In the programming world, we have the luxury of separating parts of our applications.

Instead of trying to write complex implementation of a feature, you can start by writing how you want the code to behave before implementing it.

class Cat {

    function walk(){}

    function run(){};

    function actCute(){}
}

var sparky = new Cat("Sparky");

if (sparky.feelThreathened()){
    sparky.actCute();
    if (human.guardDown()){
        sparky.attack("!!!");
    }
}

In this trivial code, there are no rules. I can define all the the interaction between the human and the cat, without implementing it. I do the easy parts first because who knows how complex the actCute() method will end up being. This way I can have working code that I can prototype quickly. I could even have it just print text saying things like "Cat walking" or "Cat acting cute", and anyone could understand what is happening.

If I instead try to implement every single functions first before creating the overall design, I might end up spending too much time and energy without producing a prototype. Also, with the other method, I can see bugs in our design even before writing the implementation.

In a more real world example, I built a PHP framework using the same method in my how to build a website from scratch series. If I had to make sure a have a fully working framework before I build my website, I would probably have to make 3 hours videos.

I took the challenge of writing 1000 words a day. When I was doing writing easy subjects, I had no trouble reaching my goal. As soon as I started to write about things I was not familiar with that required more research, I went from writing for 1 hour to 4 hours, and a few days in, I gave up. If I had continued my smaller goals, I would probably still be on a streak.

When you have a lot of work ahead, identify the easy parts first and get them out of the way.

Building a large website does take a lot of time and energy, but if you dissect it into small bite size pieces you will have an easier time working on it.

It's easy to say that failure builds character. But failure also brings your morale down, which makes you less productive than if you were on a winning streak. The goal is not to eliminate everything that is difficult from your life, but to take a different approach. When you have to do hard work, take time to do the small trivial tasks first to get them out of the way.

It is easier to work on an 80 percent completed difficult task than to work on a 20% completed hard task. The state of your morale will determine your speed of completion. So might as well keep it high for as long as possible.

---