Hi this is John with this week’s Coding Challenge.
🙏 Thank you for being one of the 91,694 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 Redis CLI Coding Challenge
In the build your own Redis CLI coding challenge the goal was to write a command line tool for working with a Redis server.
It’s a great project to learn more about building network clients and pairs really nicely with the build your own Redis server project.
Whilst I will always encourage you to try to build it yourself before referring to a tutorial, if you get stuck I do have courses on building your own Redis server in Python and Go.
🚨 NEWS: I’m Starting A Monthly Live Workshop For Paid Subscribers
The first one will be Friday 12th December at 17:00 GMT and will cover tips for AI-assisted software engineering. Paid subscribers will be able to request and vote on future topics.
🚨 NEWS: More Videos Added To The Coding Challenges YouTube Channel!
I’m continuing to add new videos to the Coding Challenges YouTube Channel, if you’re interested please consider subscribing to the YouTube channel. If you have suggestions for content, please hit reply / send me a message with them.
Recent videos cover:
You can find these videos and several others on the Coding Challenges YouTube Channel.
If You Enjoy Coding Challenges Here Are Four Ways You Can Help Support It
Refer a friend or colleague to the newsletter. 🙏
Sign up for a paid subscription - think of it as buying me a coffee ☕️, with the bonus that you get access to a monthly AMA and 20% off any of my courses.
Buy one of my self-paced courses that walk you through a Coding Challenge.
Join one of my live courses where I personally teach you Go by building five of the coding challenges or systems software development by building a Redis clone.
Five Common Mistakes Software Engineers Make Solving The Redis CLI 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 - Everything In One File
Keeping all your code in one massive file might seem convenient at first, but it quickly becomes a nightmare to manage.
When everything is lumped together, it’s hard to find what you’re looking for, understand how different parts interact, or safely make changes without breaking something else. Large files slow down your workflow; editing, navigation, and testing all become more cumbersome. In teams they also make collaboration more painful: if multiple people are working on the same file, merge conflicts are more likely, and reviewing code takes longer.
Breaking your code into smaller, focused modules or files helps you organise responsibilities clearly, makes testing and debugging easier, and allows you to scale your project without drowning in complexity.
Mistake 2 - Not Abstracting The Protocol
A common mistake I see when tackling the Redis Server and the Redis CLI coding challenge is not abstracting the RESP protocol.
If you hard-code parsing and serialisation logic throughout your code, you end up duplicating effort and making changes painful. If this was a production system and the protocol evolved you’d have more work to do handling the changing protocol.
When you add a new command, you potentially have to hunt through your code to update multiple places, increasing the risk of bugs. By creating a dedicated RESP layer or module, you put all the encoding and decoding logic in one place, which makes your code cleaner, easier to maintain, easier to extend and easier to reuse.
This abstraction also lets you focus on implementing Redis commands themselves, instead of getting bogged down in low-level protocol details for every command.
Mistake 3 - Assuming The Entire Message Arrives At Once
A frequent mistake when building a Redis CLI or any TCP-based client or server is assuming the entire message arrives in one go and can be read in one piece.
TCP is a streaming protocol, so data can arrive in chunks of any size (up to the maximum transmission unit of the networks over which they travel).
If you expect a full message in a single read, your code will break on larger responses or split packets, leading to incomplete parsing, errors, or crashes. Instead, you need to design your client or server to handle partial messages, buffering incoming data and assembling it until the full message is received. This approach makes your implementation robust, prevents subtle bugs, and mirrors how real-world networked systems actually behave.
Mistake 4 - Not Testing
You should be testing your code and ideally that testing should be automated.
Writing automated tests gives you fast, reliable feedback, which is key to building software you can trust. When you write tests for your own code, you don’t have to wait days or weeks for manual inspections or post-development testing to catch mistakes. You see immediately whether a change broke something, which makes it way easier to fix issues early, when it’s cheapest.
Automated tests remove the bottleneck of slow, repetitive manual checks, letting you release more often and with confidence.
Writing tests for your own code also changes how you approach the code itself. You start thinking about how to make it modular, maintainable, and easy to test, which makes your code better overall. Tests can also act as living documentation, providing examples of how to use each function, class or module.
When testing is part of your workflow, quality stops being “somebody else’s problem” and becomes part of how you write software every day.
Mistake 5 - Assuming The Data In A Bulk String Is A String
Redis bulk strings can contain any bytes, not just readable characters, so treating them as UTF-8 or ASCII by default can cause your client to misinterpret binary data, fail on non-text payloads, or even crash.
The safe approach is to handle bulk string data as raw bytes, only converting to a string when you’re sure the content is text. This ensures your implementation works reliably with all types of Redis values and mirrors how real clients handle arbitrary data.
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
Refer a friend or colleague to the newsletter. 🙏
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.
Buy one of my courses that walk you through a Coding Challenge.
Subscribe to the Coding Challenges YouTube channel!
“Writing automated tests gives you fast, reliable feedback, which is key to building software you can trust. When you write tests for your own code, you don’t have to wait days or weeks for manual inspections or post-development testing to catch mistakes.”
100% this! It’s such an important part of modern software development and maintenance. Great post John!