From The Challenges - WC

Common Mistakes With The WC Coding Challenge

Hi this is John with this week’s Coding Challenge.

🙏 Thank you for being one of the 60,889 software developers who have subscribed, I’m honoured to have you as a reader. 🎉

If there is a Coding Challenge you’d like to see, please let me know by replying to this email📧

Welcome To Coding Challenges - From The Challenges!

In this new format for the Coding Challenges newsletter I’m going to start sharing some of the common mistakes I see software engineers make when tackling the Coding Challenges.

I’ll be sharing what mistakes people make how you can you avoid making the same mistakes when taking on the coding challenges or when writing software professionally.

Recapping The WC Coding Challenge

In the build your own wc coding challenge the goal was to write a version of the Unix command line too wc, a tool that provides the word, line, character, and byte count of a file or data streamed to it from the standard input.

Five Common Mistakes Software Engineers Make Solving the WC Coding Challenge

I’ve pulled together this list of common mistakes from the hundreds of submissions I’ve been sent privately and the many shared in the Coding Challenges Shared Solutions GitHub Repo.

Mistake 1 - Reading The Whole File Into Memory

The most common mistake I see people making is to load the whole file into memory.

The problem is it doesn’t scale, if someone tries to use the program on a large enough file the program crashes having run out of memory.

If you’re writing code to handle files, do remember to check you can handle large files. Sure it’s not easy to test this - you might not have the disk space for a 100GB test file for example, but there are ways around this. For example to test wc with a large file we can leverage the power of the Unix command line tools to generate one on the fly without actually taking up any disk space.

Here’s how:

seq 1 300000 | xargs -Inone cat test.txt | ccwc

To address this mistake there are two steps:

1. Plan for it and create tests - if your software can read any file, consider what that means, including arbitrary size.

2. Unless you really need to read the whole file, always process files incrementally. For text that might be line by line for record based files it might be record by record. For speed it might be page by page (which refers to the memory page).

Mistake 2 - Not Catering For Locales

It turns out many software engineers still aren’t aware of locales or multi-byte character sets. So I ended up getting a lot of questions about step four of the coding challenge.

The solution to this is reading about locales and they building some real code to handle different locale settings.

Mistake 3 - Not Understanding Standard Input (Streams)

It turns out a lot of software engineers these days don’t know what the standard input is or what the standard streams are.

It’s really useful to know this and to know that they can be redirected. It allows you to chain programs together. You can and should read about the standard streams if you’re not familiar with them.

To read from the standard input check your programming language’s standard library, you’ll often find them referred to as stdin, stdout and stderr.

Mistake 4 - Not Writing Tests

Many of the solutions I’ve been sent didn’t meet all the requirements or pass all of the tests in the coding challenge. It’s common for this to happen when we write code, we make one thing work, then when we’re adding support for something else we inadvertently change the behaviour of something we built earlier.

We can avoid this problem by testing our code meets all the requirements we’ve handled so far. To do that well we need to write tests. You can write manual test scripts, i.e. notes to a person, such as: “run this command and check the output is this”. That’s effectively what I give you in the coding challenge.

I’m lazy though. I don’t like the idea of running and re-running manual tests. So instead I automate my tests. My recommendation is you do the same, then when you add new features you can quickly check that non of the existing features break.

Mistake 5 - Not Reading The Requirements/Specification

This is a common problem I saw across several coding challenges. People skipped the requirements that were hard for them to do or they didn’t fully read the requirement and decided to implement something slightly different.

In a way, I don’t mind, it’s your learning journey, you’re very welcome to make it your own and go your own way. Just don’t avoid the bits you don’t understand or can’t do. It’s taking on these bits that pushes you out of your comfort zone and allows you to learn and grow.

If you’re really struggling, join the Discord server and ask for help or find another way to get feedback. Part of the journey is learning to get past these obstacles.

Request for Feedback

I’m writing these coding challenges and this new from the challenges series to help you develop your skills as a software engineer based on how I’ve approached my own personal learning and development.

What works for me, might not be the best way for you - so if you have suggestions for how I can make these challenges more useful to you and others, please get in touch and let me know. All feedback greatly appreciated.

You can reach me on Twitter, LinkedIn or through SubStack

Thanks and happy coding!

John

P.S. If You Enjoy Coding Challenges Here Are Three Ways You Can Help Support It

1. Refer a friend or colleague to the newsletter. 🙏

2. Sign up for a paid subscription - think of it as buying me a coffee ☕️ twice a month, with the bonus that you also get 20% off any of my courses.

3. Buy one of my courses that walk you through a Coding Challenge.