From The Challenges - Cut
From The Challenges - Cut
Common Mistakes With The Build Your Own Cut Tool Coding Challenge
Hi this is John with this week’s Coding Challenge.
🙏 Thank you for being one of the 64,123 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 newsletter I’m sharing some of the common mistakes I see software engineers make when tackling the Coding Challenges.
I’m sharing 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.
🚨 NEWS! - Build A Better Coding Challenges Community 🚨
In response to numerous requests I'm considering creating a paid Coding Challenges community. It being a paid community would allow me to spend most of my time supporting the members.
I'd love to know if this would interest you so I have a brief survey here. I'd appreciate any feedback. If it goes ahead anyone completing the survey will be sent a discount code.
Recapping The cut Coding Challenge
In the build your cut coding challenge the goal was to write your own version of the Unix command line tool cut!
In short, cut is a tool that cuts out the selected portions from each line in a file.
Five Common Mistakes Software Engineers Make Solving the cut 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 - README’s That Don’t Explain How To Use The Repo
This is a recurring theme for many of the git repos that people ask me to review. There is either no documentation or it skips the basics of what tech stack, what the project does and how to use it.
I know a couple of tech stacks well and can work with several more, but some I haven’t touched for over a decade and some I’ve never used. It’s always a good idea to assume that your colleagues are like this, new members of your team might also be new to the tech stack you use.
It really helps if your repo makes it clear either what the tech stack is or how to clone, build (if applicable) and run the repo in clear simple steps.
Those steps should not include or reference paths that exist only on your local machine.
Mistake 2 - Relying On The Developer Tooling Instead Of Creating A Executable / Shippable Artefact
My goal with Coding Challenges is to have you learn by building real-world projects. I think that should include every part of a real-world project which means building shippable/deployable artefacts.
When I see a readme that documents how to use a Rust project as:
cargo run
Or a Go project that uses:
go run .
It feels unfinished. Include the steps to build a shippable artefact. If that involves creating a Makefile, make a Makefile!
One of the key benefits of doing Coding Challenges and completing the challenge is learning to build a production ready solution - don’t cheat yourself out of that learning!
Mistake 3 - Binary In The Repo
Source code repos are for source code. Binaries do not belong in them. It should be possible to re-create the binary from the source code so there is no need for the binary. Equally it’s not obvious from a binary if the current binary is built from the current version of the code or an earlier one.
Mistake 4 - Not Handling The Standard Input Stream
This may reflect the fact that many software engineers don’t build CLI tools these days, but many of the solutions skip over reading from the standard input stream. If this is because you don’t know what it is, then please learn - don’t cheat yourself out of the learning!
You can learn more about the standard streams on Wikipedia.
Mistake 5 - Testing Only The Happy Path
It’s easy as software engineers to take a requirement, code up the solution and check it works. That’s not enough, we should also think about the edge cases and error conditions and both code to detect and handle them and ensure we’re testing our handling of them.
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 Twitter, 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.
I run a YouTube channel sharing advice on software engineering.