From The Challenges - jq
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 90,936 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📧
This Post Available As A Video!
I’m trying something new! I’m going to make the newsletter available as a video if you’d prefer to watch / listen. I’m starting with this one!
You’ll find it available on the Coding Challenges YouTube channel as Coding Challenges - From The Challenges: JQ. I plan to make more content available on YouTube so my question to you, dear reader is……
What Videos Should I Make For You?
If I start creating one video per week, what should it be? You can vote in the poll below or hit reply to this email / comment on this post and let me know. I read every response. Thanks.
Ok, on with the lessons….
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! 😀
The command line tool jq is like sed for JSON data. You can use it to and filter and transform JSON data, much like you would with sed. By the way, a past Coding Challenge was to build your own sed.
I’m also giving some shoutout’s to some of the excellent solutions or actions that people take when solving the Coding Challenges.
Recapping The JQ Coding Challenge
In the build your own jq coding challenge the goal was to create a lightweight and flexible command-line JSON processor.
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 also get 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 jq 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 - Using A Built-In JSON Parser / Formatter
Sure, many programming languages have one and you should never write your own for production code.
But Coding Challenges is about learning by doing. By not learning to parse and format the JSON yourself you’re cheating yourself out of many of the learning opportunities.
If you want to improve your programming skills, learning to write parsers is a great way, and the skill is useful for parsing user input, data files and network protocols.
Mistake 2 - Only Testing The Happy Path
Learning to code by building full, working software is an incredibly effective way of learning because it exposes you to all the problems and challenges you face building software of your own.
When you watch a tutorial and copy someone else’s code you don’t see the problems they faced, the brick walls they hit and the edge cases that had them scratching their heads for hours, days or weeks. You just see the final, perfected solution.
Watching a tutorial and just testing the happy path, with simple safe inputs both deprive you of that key opportunity to learn.
So I encourage you to think about edge cases and test them. Think about the ways invalid input might appear and tests your software against it. You’ll learn a lot.
Mistake 3 - Error Handling
The consequence of mistake 2 is mistake 3, not adding error handling. Sure, writing error handling isn’t as exciting as solving a complicated system design problem or coding up an efficient solution to an algorithmic issue, but it is a common and key part of the job of software engineers.
Without good error handling, our software will almost certainly crash very soon after it’s exposed to the real world. Users and/or real life events have this amazing ability to use our software in ways we didn’t intend, providing input we haven’t considered.
By building good error handling we make the software robust to that and create the framework for it to record useful logging and metrics to help us understand how the software is being used and what conditions we need to handle.
In short, learning to consider error conditions, write code to handle them and test the code to ensure the error handling works is a key part of software engineering. It’s a skill you need to keep your job and progress through your career.
Shoutout 1 - Great Readme
Lolo Hänggi provided a great Readme with his solution to the jq coding challenge. I really liked that he provided:
An introduction - what is the repo about.
A description - what does the code implement.
Described how it is built.
Showed the final result.
Explained how to build, test and use the code.
Provided example usage.
Including a Todo/Known bugs list.
Shoutout 2 - Building On The JSON Parser
Shoutout 2 also goes to Lolo, for building his jq solution on top of his solution to the build your own JSON parser coding challenge. It’s an awesome way to really leverage the learning gained solving that challenge.
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!


Thx John for the feedback about my readme - I am trying to make it understandable for everybody and use examples to explain. I just love your challenges
For all others: TIP: nowadays switch OFF copilot or other GenAI because you want to learn it. The AI knows all ahead for you.
Please use GenAI but not for challenges.