Edition 13

7 Lessons Learned from Two 5+ Hour Coding Challenges

Today I want to share with you the best lessons I learned from completing two 5+ hour long coding challenge livestreams. Then I’m going to share some tips on setting up your own challenge so you can get stronger at whatever programming/engineering area you want to.

If you haven’t attempted a challenge like this before then you’ll want to stick around because there are just some things you’ll never learn unless you truly test yourself.

Most people are afraid to test themselves because it’s uncomfortable to face the truth on a lot of things we think about ourselves.

Those who fail to truly test themselves and push their limits and the ones who will truly fail.

In this newsletter I’m going to cover:

The Challenges Summary

I decided to take on two challenges:

I wanted to take these challenges on because I’ve been in a rut.

I wanted to push myself and test myself to see what I was capable of.

And here’s what I learned.

Use it or Lose it

It’s easy to say we’ve mastered a programming language after using it for so long but the truth is unless we’re using all the aspects of the language day in day out the chances are you’re going to forget a lot of it.

Especially over time, our brain is always forgetting things and as we get older our brain leans towards generalising knowledge gained instead of specifics for efficiency.

This article by the Harvard Gazette goes over the concepts of memory and forgetting.

There’s also the Pareto Principle, the 80/20 rule (I wrote about the Pareto Principle in another newsletter in more detail relating to software engineering.)

Most people will only use around 20% of a programming languages features and that’s absolutely fine.

If that’s all you need to do your work then no problem.

But there will be a natural imbalance in what programming challenges you can tackle.

Programming language features are tools and like tools they’re better at certain jobs compared to others.

I didn’t really know the Math functions in JavaScript very well. I didn’t even know what was in the toolbox.

This next lesson is kind of the antidote to this one.

A Lack of Variety

Even if you code for a living chances are you’re working in the same sorts of problems and similar kind of technical problems most days.

Whether it’s front end, back end or infrastructure you’re most likely tackling problems you’ve already faced before.

I know that’s the case for me. I’ve been doing mainly front end work for quite a number of years even though I started out as a true full-stack developer.

This means when I came across more data and algorithmic based problems I struggled once the examples started getting harder.

Specialisation is a double-edged sword.

You’re very good at what you do but what you can do is smaller in scope.

Tackling a wider variety of problems sharpens your pure problem solving skills. You have to critically think about the problem as you can’t just rely on experience to solve it.

I plan to keep doing challenges that take me out of my comfort zone for this reason. I want to become more versatile and anti fragile.

Trying in Public is Amazing Motivation

This was my first attempt at taking on a challenge with full transparency of the public eye of YouTube.

The fact that anyone watching was going to see how bad my code was, how much Googling I was doing (tried to minimize this and practice recall but let’s not kid ourselves) and where I was getting stuck.

This gave me motivation to really zone in and concentrate on this challenge because my pride and reputation are on the line for this one.

It’s also authentic and shows what really happens behind the scenes when people are working. Something you don’t normally get to see unless you work with that person.

Coding live also gave me the opportunity to reach out for help to anyone who was watching through the chat. There weren’t many people on but simply being live in public gave made it a possibility.

It’s also kind of scary to do these things openly which adds a different kind of motivation and fuel. Similar to when people get up on stage to present at a conference etc.

The majority of people respect someone who is willing to get up and take a chance. They know it’s not easy to do and most people will not mock them for trying.

Make Challenges Fun

It’s a challenge! It’s a chance for crazy, funny things to happen!

We choose to take on the challenge and as much as we want to beat the challenge it’s not the end of the world if it doesn’t work out.

People perform better when they’re having fun.

They’re relaxed, they focus better, they get in the flow and the best version of themselves gets to shine.

You’re setting yourself up for failure if your challenge is not at least enjoyable in some way.

It doesn’t mean it has to be easy, quite the contrary, if it was easy it wouldn’t be a challenge but make it an enjoyable or find a way to enjoy the process in some way.

Use your favourite tools and frameworks, use a new tool you’ve wanted to use for ages, make the output something you really want or the inputs something you really like doing.

Your brain remembers far better when emotion is attached to an experience of learning.

Good or bad emotions work just as well.

I remember the absolute cringe I felt when I had to admit I’d never written a Fibonacci function before! I’ll not forget that in a hurry.

Fundamentals

Kobe Bryant was known for being obsessed with the fundamentals on basketball.

He’d be up practicing and drilling the absolute basics over and over again.

You can’t build on weak foundations, only a solid base of fundamentals will allow you to truly grasp the more difficult and advanced concepts and techniques.

This goes doubly and more for software engineering and programming.

You never truly master the fundamentals, you always need to practice to keep things sharp and clean.

These challenges revealed gaps and areas where I know I need to strengthen.

I can go away and target those to build up my fundamental base and become a much better engineer overall.

Time Limits are the Ultimate Productivity Boost

Each of these challenges had a strict time limit. That was the main part of the challenge

And because of that I had to be smart and deliberate on where I spent my time. I had to balance code quality with timeliness.

If I was completely stuck on a challenge I could move onto something else and give my brain space to think about it in the background and get some wins elsewhere.

I wanted to win so I had to focus and stay as productive as possible.

Parkinson’s Law states that “work expands so as to fill the time available for its completion”. So if I have less time to do something I’m going to have to find a way to get it done.

As much as I’ve improved I still struggle to get things done. If I know I have time I’ll naturally ease off a bit. But if I don’t then I’ll make sure I get it done, especially if the consequence is adequate enough.

if you’re struggling to make progress in whatever endeavour it might be try setting a time limit and a no way out clause.

For example writing this newsletter can take up to a couple of hours (I’m a slow typist and improving writer) so I set myself a deadline of 10pm on the night I write it and if I go over I either miss it or publish it incomplete.

Give it a try.

Failure is not the End

I did not complete either of the challenges I set for myself.

Some of the work was embracingly bad for my own standards. No excuses, I just failed.

But I’m still here.

The sky did not fall down, the world didn’t end, the fact that very few people were watching is a benefit but nobody mocked me or anything like that.

We keep moving forward.

Confucius says:

“A man is great not because he hasn’t failed; a man is great because failure hasn’t stopped him.” - Confucius

And I won’t let it stop me from doing more challenges.

Learning and growing can be painful, not always, but definitely can be.

The real failure is never testing yourself and giving yourself the chance to grow.

I’ve grown plenty from these two experiences and also at the end of the day, who really cares if I failed?

Chance are, nobody, except me.

I won’t stand in the way of my own progress because of my own vanity or pride and neither should you.

How You Can Take Advantage of Coding Challenges

Read the lessons I’ve share here. Choose a challenge linked to something you truly care about doing. It can be:

Don’t do 100 LeetCode challenges just because someone told you too.

Make it relevant and make it meaningful.

Don’t forget to enjoy the process no matter how difficult or painful it feels.

Thanks for reading

Remember the saying, “strong men create good times, good times create soft men, soft men create hard times and hard times create strong men.”

Do the hard things, eventually you’ll become strong.

Thanks again 🙏

Knowledge for the healthier, wealthier, long term developers

Sign up to my weekly newsletter for software engineers/developers that want to grow. I share my past successes and failures so you can get a head of the rest.