Learning to program: Failing fast and error messages

Today I wanted to talk about error messages and why you should learn to love them. If your mission is to learn programming, they show you your weakness and tackling a weakness is always the fastest way to learn. This is why the whole discussion of fixing error messages quickly turns into a philosophical discussion of a way of life: Walking the  path of the Ninja requires you to fail fast, early on, and often. Let me tell you why…

Should you care about error messages and warnings? Are they secret messages from the universe? Yes, they are.

If you’ve never given a hoot about errors and warnings in your life, congratulations. I don’t either. That is, until the thing doesn’t compile anymore. I am at awe with respect for people who fix mistakes before they become a problem. But I’m not one of them. What does this mean, however, with regard to your attitude towards failure? It probably means you’re avoiding it. You’re ignoring error messages so you don’t have to admit you still lack some skills or that you’ve never learned how to solve the problem at hand elegantly. Error messages remind you of your own imperfection, to set this into a life-wisdom-kind-of light.

Lose your fear of failure concerning code not working straightaway

However, if you’re going to go through with your journey to becoming a LaTeX (or programming) Guru, you’ll have to get comfortable with failing. And facing your failures.  In the case of programming, this means that you have to tackle and solve your error messages. You should also get rid of the warnings if possible. You can leave some after you have given them a good bit of thought. If you decided the warnings only hints at an unavoidable trade-off (like a line-overflow you don’t want to fix just now), you can leave them. But it’s always better to still tackle such things as early on as possible – because leaving them be always means that you could have more errors you just aren’t aware of because they are hidden by that one error you didn’t think worth fixing. If you end up needing to fix it after all, maybe you are in a hurry too, you won’t be laughing anymore. So fix your mistakes and use them as opportunities for growth and learning. Tackle them when they first appear. This might seem like a waste of time sometimes but will usually save you lots of trouble later. Think of it as a good habit to adopt. Once you have it, it will become automatic and not bother you anymore. See error messages as something to gain life wisdom from. What kind of wisdom would that be, you might ask?

Fail fast, early on and repeatedly

Fail fast, early on and repeatedly. Don’t make the same mistakes over and over again though (at least not too many times – try actually learning from them!). Making the same mistakes over and over again is what inevitably will happen if you don’t work on your skills by tackling your weaknesses (i.e. tackling those stubborn error messages now). Don’t let it come that far. Cultivate good habits. They will make sure you learn and progress a bit every day over the long haul. Whereas bad habits will lead you to deteriorate over time. Don’t be that person – be proactive.

If a fear of non-compiling programs paralyzes you, you need to get unstuck now

If a fear of non-compiling programs paralyzes you, you need to get unstuck now. (You might think I’m exaggerating now – but fear of non-compiling programs is definitely a thing with newbies who have never learned to read, interpret and fix error messages!) In climbing, when people are afraid of falling so much that it holds them back in their progress (you only use all your potential when you climb until you fall and you can’t progress without pushing your limits), you would do fall training. That means climb up the wall a bit and fall on purpose. Yes, you heard that right. Fall on purpose. Secured, of course.

That’s essentially what I suggest you do if you’re afraid of failure to the point of being paralyzed by it (and otherwise too probably): Fail on purpose, fast and often.

Being tested is the best way to learn, just as making mistakes is. (15% of failure supposedly is the sweet spot for rapid learning. In the beginning, of course, it can easily happen that you fail way more than that, especially without a teacher giving you challenges of appropriate difficulty. But don’t get discouraged, it gets better. Don’t stop now – this is the spot where most people get lost along the way. Seek out the dip (learn more here and here). Don’t be one of them).

So, dear newbies: Find ways to crash your program on purpose!

My advice is that in every training session, find 5 ways to make your program crash or not compile on purpose. This takes away the fear of programs not compiling and you don’t know what happened or how to fix it. It will help you get better at debugging until it’s not scary anymore. This was my favourite takeaway from the book series Learn Code The Hard Way where, early on, you are asked to find 5 ways to crash your program on purpose. I did that with my students when they first learned XML. Once they had made the program crash themselves, they already have a much better feel for where to look for mistakes and what possible errors can look like (mostly syntax ones though, obviously).

Programming can be 90% debugging – learn to love the challenge

In case you weren’t aware, the total “programming time” can be up to 90% debugging, even for professionals (see the AMADEUS project for example). If you’re serious that you want to become a programmer, you need to get comfortable with debugging, there is no way around that. If every single time causes you stress and agony, programming is not the right job for you. But don’t give up just yet – mostly, this fear only persists while you don’t have this ‘soft skill’, i.e. you just don’t know how to tackle debugging properly. Make this an item on your “To Learn” list (if you don’t have one, believe me, you need one!). Don’t put it off – just make it a habit to tackle mistakes early on and the learning progress will come automatically. Once you have learned to – well maybe not love but at least – like debugging, it’s going to feel pleasantly like solving a riddle.

Always remember: It doesn’t need to work straightaway, it just needs to work in the end.

Hope this helped!

Bye for now 😉

References

  1. Zed Shaw, book series Learn Code The Hard Way
  2. Seth Godin, The Dip: A Little Book That Teaches You When to Quit, Penguin 2007.

[The Dip] is the tenth published book by Seth Godin. It is a 76 page book that illustrates the concept of “the dip”—a temporary setback that can be overcome with persistence—and how to recognize if you are within one worth pushing through or one where you should quit. (Wikipedia)

Buy me coffee!

If my content has helped you, donate 3€ to buy me coffee. Thanks a lot, I appreciate it!

€3.00

I like LaTeX, the Humanities and the Digital Humanities. Here I post tutorials and other adventures.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.