From The Challenges - Cat

Exploring the software engineering lessons we can learn from the solutions I've seen.

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

🙏 Thank you for being one of the 75,923 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 Coding Challenges “from the challenges” newsletter I’m sharing some of the common mistakes I see software engineers make when tackling the Coding Challenges.

I’m sharing both the mistakes people make and some thoughts on how you can you avoid making the same mistakes when taking on the coding challenges or when writing software professionally. Sometimes we have to make mistakes to learn from them, somethings we can learn from other people’s mistakes, then make our own new ones! 😀

Recapping The Cat Coding Challenge

In the build your cat coding challenge the goal was to build your own version of the Unix Command line tool cat.

Cat is a seemingly simple tool that reads files sequentially and writes them to the standard output, but when combined with the other Unix command line tools it allows us to create very complex text processing pipelines.

🚨 Just 2 Days Until The Build A Redis Server - Master Systems Programming Through Practice Course Starts!

In the course you build a network server from scratch with guidance and input from me.

You’ll learn about network programming, concurrency, testing, and systems software development in the process of building a Redis Server clone.

You can find out more and sign-up here: https://codingchallenges.fyi/live-courses/redis

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.

Six Common Mistakes Software Engineers Make Solving the Cat 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 - Not Thinking Carefully About Functions And Modules

As a general rule, a function should:

• do one thing,

• have no side effects,

• not change it’s inputs,

• do what the name implies.

All of these are guidelines, not rules.

A function called Read, that reads, processes and writes is confusing for a anyone who maintains the software.

A module should have a clear responsibility. It should be a grouping of related functions and classes (if you have them). Avoid ambiguous catch all modules like “utils”.

Mistake 2 - Hard Coding Paths

If you hard code a path the tool will only work for you on your machine. Don’t find yourself in this meme:

Engineer: It works on my computer ¯\(ツ)/¯

Manager: Then we’ll ship your computer to the client. 😀

The code we build should not depend on hard code paths.

Mistake 3 - Nested Clauses Verus Guard Clauses

Try to avoid deeply nested if statements:

if condition {
  if condition2 {
    if condition3 {
      if condition4 {
        // body
      } else {
        // error and return
      }
    } else {
      // error and return
    }
  } else {
    // error and return
  }
 } else {
   // error and return
 }

One of the solutions I reviewed had five levels of nesting which makes the code difficult to read.

Instead consider using guard clauses:

if !condition {
  // error and return
}
if !condition2 {
  // error2 and return 
}
if !condition3 {
  // error3 and return
}
if !condition4 {
  // error4 and return 
}
// body

Or if a single error is specific enough and there aren’t too many conditions:

if !(condition && condition2 && condition3 && condition4) {
  // error and return
}
// body

Mistake 4 - Not Handling Scale

Not all scale is about number of users. In this case cat only ever has one user per instance. The data it’s processing however has infinite scale. Well, OK, perhaps not infinite but the input can scale from zero bytes to as many bytes as you can fit on your storage device.

So don’t read the whole file into memory before doing anything with it, because all it takes is a file that’s bigger than your available RAM and your software no longer works.

There was a really nice Python solution that used a generator to yield a line at a time from either standard in or the supplied list of files. That’s a great approach! Use the equivalent in your programming language.

Mistake 5 - Don’t Repeat Yourself

I saw a couple of instances of duplicate functions for one small change, i.e. whether or not to number blank lines. This can be handled by a simple if statement avoiding the duplication of all the code to read line by line.

Where possible try to follow the mantra Don’t Repeat Yourself (DRY) in your code. Be careful though sometimes repetition is fine, for example if the logic could become [even more] different for each case in the near future.

Mistake 6 - Cluttered Repo

I was excited to see a solution in a programming language I’ve never used or seen code in before. I was then amazed when I opened the repo and saw files relating to another programming language.

It looks like the author started in one and then switched, but didn’t delete the partial solution. Git keeps the full history of what was committed to your repo, so delete things that are no longer used and keep the repo clean. You can always checkout an earlier version if you want them back.

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 Bluesky, LinkedIn or through SubStack

Thanks and happy coding!

John

P.S. If You Enjoy Coding Challenges Here Are Four 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.

4. Subscribe to the Coding Challenges YouTube channel!