Last updated on

 

What sort of things make you cringe?

For me, it usually boils down to either something stupid i’ve said to someone who’s caught me out or something i’ve done which I look back on and think “Oooh! That wasn’t great!”.

Cringing at bad code

What about the time you went to approach that guy / girl and fell flat on your face (possibly quite literally).

Or that time you wore that really weird jumper at school and no-one said anything but thinking back they must have been talking about you (yes, that one still haunts me).

We’ve all had those moments I guess – when you remember something you’ve done and want to instantly forget the memory.

It happened to me the other day at work actually.  I found some code I had written about 6 months ago and instantly thought “Oooh! That wasn’t great!”

My Bad Code

I have had to be quite brave here in sharing this with you but below you can see the offending lines of TypeScript which gave me that cringing feeling.

The code (if you couldn’t work it out) was to trigger the update of a Form Control in an Angular project.  This didn’t happen by default because there was a jQuery plugin being used to provide a datepicker for certain form elements.

jQuery and Angular 2+ don’t play very well together by the way.

There’s several and probably many more things wrong with this monster crap code.  Here’s some of the key highlights for you which jumped out at me when I found it:

I dissect and explain the code fully in this video.

OK, so hopefully you can agree with me that the code is bad and it makes me cringe looking at it.

But can we say that it’s a good thing to write bad code?

Is it good to write bad code?

Well, no it isn’t…

I’m not suggesting you write code badly intentionally.

In fact, if you’ve just typed in some new function to your favourite text editor and you know you’ve rushed it.

Stop.

Take a minute.

And look back over it to approach the problem in a different, better way.

However, it is inevitable that something you write on Day 37 of your career as a Junior Developer isn’t going to be as good as something you write on Day 137.

It is good to recognise bad code once you’ve written it.

For me, 6 months on down the line I am glad that I did write the bad code in the above example, because I can recognise that this code isn’t great and can do something about it.

This provides two benefits:

  1. The overall project’s codebase becomes better.  This means that the code will be safer, more robust and scalable.  Also, the next developer who has to take a look at this won’t want to jam forks in to their eyes in order to never see something so ghastly as this again.
  2. I can see an improvement in my own coding skill / ability.

I think point number one is quite important.

I want to know that I don’t have things in my code which might be confusing for other developers and that the whole project is that little bit more maintainable.

But as a developer always looking to improve, I feel number two is of the greatest benefit to me.

I want to know that i’m getting better.  

I want to know that my code is of a higher quality than it was 6 months ago.  

I would like to think as time goes on that I am improving and edging towards promotion or a ‘gold star’ from my employer.

But mainly on a personal level, the greatest feeling of accomplishment comes when you can look back at some code and think ‘Who the heck wrote that?’

Conclusion

OK, so I think i’ve made the point here that it’s OK to write bad code as long as you don’t think it’s bad code at the time.

If you naturally come across some of your own historic code and think ‘What on earth was I doing here?’ then that’s great!

It means you’re getting better!

If you look back at code that you wrote 6 months ago and can’t see anything wrong with it, I would worry.

Go back to your tutorials, training and books and do some learning.

Got a ‘bad code’ story? Share it in the comments below.