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

͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­͏     ­

	Forwarded this email? Subscribe here for more From The Challenges - Head Exploring the software engineering lessons we can learn from the solutions I've seen. John Crickett Oct 11   READ IN APP   Hi this is John with this week’s Coding Challenge. 🙏 Thank you for being one of the 90,475 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 Build Your Own Head Coding Challenge In the build your own head coding challenge the goal was to write your own implementation of the Unix command line tool head. It’s a great challenge for beginners and those new to the Unix command line tools. Head is a command line tool that displays the first n lines or bytes of a file, where the user can provide the value for n. If no file or value for n is provided then it displays the first 10 lines from the standard input. 📌 Next Systems Programming (Redis) Course Starts 20th October I’m running the Coding Challenges Live Redis course again starting 20th of October. It is a live course that runs for two working weeks from October the 20th to October 31st. During the course you’ll implement from scratch a clone of the original Redis server and extend it to support the RESP2 protocol and some additional commands. This course touches on a wide variety of topics that are applicable to general programming, for example: 👉 Parsing skills. These can be applied to a variety of problems including data munging, scraping, protocol implementation and more. 👉 Understanding network programming. This can be applied to making more robust, secure and scalable distributed systems. 👉 Experience handling concurrency and parallelism in software. Giving you the core skills to build scalable distributed systems. 👉 Testing. Network servers are complex system software with components that can interact in non-trivial ways. Figuring out how to test them is a challenge. You’ll explore unit and integration testing. This course is entirely project focused. The goal of the course is not just to learn how to write a server, but also how to approach the problem of server software. Part of the course involves group discussion about problem decomposition, coding techniques, design tradeoffs, testing, and other related topics. The rest of the time is spent working on individual coding. You might not think that you’re ready to write a server, but if you’ve been coding for a while and know the basics of data structures, it’s something that you can tackle. No prior background in network servers is required although awareness of common programming language concepts (e.g., types, functions, classes, scoping rules, etc.) is strongly advised. If you’d like to level up your software engineering skills, check out and sign up for the course: Build A Redis Server Clone: Master Systems Programming Through Practice. It is designed to be intense! It’s 11 hours of instructor-led time over two weeks. With the goal of having you build a clone of the original Redis server by the end of the two weeks. 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 Head 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 Meeting The Requirements Several of the submissions I reviewed didn’t meet the requirements of Step 1. The last line of the step states: “Our implementation should terminate after line 10.” This matches the documented behaviour of the head command supplied with most Unix-like systems, defaulting the number of lines to show to 10. Despite this being trivial to implement, many of the submissions missed it. In several of the submissions the requirement for Step 1 was met, but it was hard coded, meaning they didn’t support the -n option from Step 2. A key part of being a good software engineer is meeting the requirements provided. These issue bring us to mistake 2… Mistake 2 - No Automated Testing Head appears to be a simple program to write and it is, but just because the code is simple it doesn’t mean the combinations of options open to a user isn’t going to be hard or time consuming to manually test. This is a great coding challenge to demonstrate that and to practice building simple automated testing for in order to ensure the user experience is good and the command line options work as expected. Depending on your programming language, you can write these tests using the languages’s default testing tools or as shell/command scripts in your OS. Both of which are useful skills for software engineers to develop and practice. Creating at least some simple automated tests for this Coding Challenge would have caught the issues highlighted in mistake 1. Mistake 3 - Scaling Start a discussion with most software engineers about scaling and you’ll soon hear strong views about whether or not their favourite programming language will scale to handle n million users and/or whether it will be cheaper to scale that another language. Yet oddly many of us forget that scale comes in other forms too. In the case of command line tools like head, or many data engineering tools it can also mean the size of the data being processed/ingested. Too many of the submissions for head assumed the file was trivially small and would fit in memory. If that wasn’t the case, they’d simply crash. Check yours by doing something like this: % seq 1 300000 | xargs -Inone cat test.txt | head -c 102657000000 Don’t forget, scale isn’t just about the number of users. Mistake 4 - Not Closing Files A lot of the solutions didn’t close files and potentially didn’t close then if an error occurred. If the program is short-lived that might not be problem, depending on the operating system. However, ensuring you close files and release resources is good practice and it’s well worth knowing about the idioms and patterns to ensure you do For example it’s common in C++ to use the Resource Acquisition Is Initialisation idiom (aka RAII). In this idiom a resource is allocated/acquired during object creation and released during object destruction. For example in C++ you might use a smart pointer to ensure memory is deallocated and a std::lock_guard to ensure locks are always released: std::mutex m; void lock_possibly_not_released() { m.lock(); // acquire the mutex f(); // if f() throws an exception, // the mutex is not released if (might_be_true()) return; // possible early return // if so, the mutex is not released m.unlock(); // if bad() reaches this statement, the mutex is released } void using_raii() { // RAII class: mutex acquisition is initialization std::lock_guard<std::mutex> lock(m); f(); // if f() throws an exception, // the mutex is released if (might_be_true()) return; // early return, the mutex is released } Not all language support the idiom. Most have something similar though, for example Python allows us the possibility of using try, except, finally or context managers: # try, except, finally (no except shown) lock.acquire() try: _protected_data = updated_value() finally: lock.release() # Using a context manager lock = Lock() with lock: _protected_data = updated_value() Go allows a similar pattern using defer , executing the deferred function when the surrounding function returns: file, err := os.Open(filename) // ... error handling ... defer file.Close() Rust support RAII, sometimes referring to it as Ownership Based Resource Management (OBRM). The typical example is Box. Java has try-with-resources statement and C# uas the using statement. Mistake 5 - External Dependencies You probably don’t need them for head, but if you’re going to use them, include details of what they are and how to install them in your README file. If you’re in a language like Python stick them in a requirements.txt or the language’s equivalent. 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! You're currently a free subscriber to Coding Challenges. For the full experience, upgrade your subscription. Upgrade to paid   Like Comment Restack   © 2025 John Crickett 548 Market Street PMB 72296, San Francisco, CA 94104 Unsubscribe