From The Challenges - Sed
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 82,732 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! 😀
🚨Learn Go By Building Coding Challenges! 🚨
I’m running the Coding Challenges Learn Go By Building Live Course in June.
It is a live course that runs for three working weeks from June the 2nd to the June the 20th. During the course I’ll introduce you to ever aspect of Go that you need to build the following five real-world projects (based off five of my coding challenges):
🏗️ cat - By building cat you learn how to build and run command line programs in Go.
🏗️ sort - By building sort you learn how to use Go's data structures and control flow to implement sort.
🏗️ curl - By building curl you learn how to write network clients in Go.
🏗️ wc - By building wc you learn how to process text data and handle locales with Go.
🏗️ Memcached (Capstone Project) - By building a Memcached server clone you learn how to build efficient network servers in Go.
Having built these five real-world applications you will be well equipped to take on new projects in Go!
If you are a paid subscriber you can get 20% off - please visit the paid subscriber benefits page for the code.
You can sign up for the Coding Challenges Learn Go By Building Live Course here.
Recapping The Build Your Own Sed Coding Challenge
In the build your sed coding challenge the goal was to write a clone of the command line tool sed.
This challenge is to build your own version of the Unix command line tool sed (short for Stream Editor)!
Sed is a Unix command line tool that parses and transforms text, using a simple, compact programming language. It was one of the first tools to support regular expressions.
The Unix command line tools, like sed, are a great metaphor for good software engineering and they follow the Unix Philosophy which I encourage more software engineers to adopt.
If You Enjoy Coding Challenges Here Are Three 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.
Five Common Mistakes Software Engineers Make Solving the Sed 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 - No Tests
Modern programming languages and toolchains like Rust and Go make it so easy to write and run tests, Python has several great testing frameworks as does Java, C++, C and many other languages.
Please use them!
Writing tests helps ensure your code works, helps avoid regressions in future, and now, in light of the rise of AI in software engineering, it is a good idea to strengthen your testing skills. Consider this recent view on AI:
“Everyone will need to get a lot more serious about testing and reviewing code” — Steve Yegge
In other words if AI is going to take over writing code in many software development organisations, the ability to review and test that code will become a key skillset to have. I still think that’s a big if, but it’s certainly going to be used, so getting better at reviewing and testing code is going to be a worthwhile investment of our time.
Mistake 2 - Reading The Whole File Into Memory / Not Being Scalable
Not all scale is about number of users. In the case of a command line tool like sed, it only ever has one user per invocation. 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. Besides sed is an abbreviations for stream editor, it’s designed to edit streams of data which could therefore be arbitrarily large.
Mistake 3 - 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. For command line tools work from the current working directory - that’s what it’s for!
Mistake 4 - Doing The Project On Easy Mode
You can tackle this challenge at two different levels of difficulty:
Easy - use the regular expression library from your programming language.
Hard - implement your own regex engine.
Whilst it’s fine to stick to the easy level, it would be ideal to ensure everything else is perfect if you do. To date I haven’t seen anyone tackle the hard-level and that’s where you learn the really useful data-structure and algorithm skills.
Mistake 5 - IDE Settings In The Repo
When you’re working alone it really doesn’t matter if you put your IDE settings in the repo. When you’re working with a team it will. Sooner or later someone will have your settings overwrite theirs and they’ll be upset about it. Play nice with your team mates!
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!