From The Challenges - Calculator
From The Challenges - Calculator
Common Mistakes With The Build Your Own Calculator Coding Challenge
Hi this is John with this week’s Coding Challenge.
🙏 Thank you for being one of the 68,049 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.
Recapping The Calculator Coding Challenge
In the build your own calculator coding challenge the goal was to write a simple calculator.
It’s a great coding challenge to use to try out Test-Driven Development and to use some of the data structure and algorithms lessons you’ve learned by using a stack to implement the shunting yard algorithm.
If You Enjoy Coding Challenges Please Consider Supporting It By Signing Up For A Paid Subscription 🙏
When you sign up for a paid subscription you can think of it as buying me a coffee ☕️ twice a month, as a thank you.
But you also get the bonus that you also get 20% off any of my courses.
And I’ll shortly be adding some mini-guides on software engineering exclusively for paid subscribers.
Five Common Mistakes Software Engineers Make Solving the Calculator 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 - Copy And Pasting Code For Repeated Actions
If you find yourself writing the same code over and over again with only minor changes to some of the values try to extract the commonality into a function and pass the differences in as parameters.
This will save you a lot of typing and make it easier to change the code without having to change dozens of instances of what is near identical code.
All of which also makes it easier to understand when you come back to the code in the future or when someone else tries to read it. Both of which happen regularly when you’re working in a team on a long lived project or product.
You’ll often see this referred to as the DRY principle of software engineering, you can learn more about the history of it from one of the first, if not the first ever wiki’s the C2 Wiki. See what it says about DRY, there’s some great lessons there.
Mistake 2 - Not Making The Solution Runnable
The projects I share are intended to be built as real-world shippable/deployable projects. The benefit you get from doing them comes from working though all of the project to get to that stage, just as you would have to when working professionally as a software engineer.
If you don’t finish the project you’re depriving yourself of that learning experience. So don’t just create a main.py, a main.go or an index.html and a bunch of related files. Instead create a shippable / deployable solution.
For Python, create a pyproject.toml and include instructions to build and ship the package. For Go, C, or C++ and Rust have a Makefile or build instructions. For Java Maven etc. etc.
Mistake 3 - Including Dependencies In The Repo
Don’t put the dependencies in the repo. Python’s site-packages, Node’s node_modules and any other dependencies or object files etc. shouldn’t be there. Keep your repo clean with just what is need to build the project, nothing more.
Mistake 4 - Not Applying The Shunting Yard Algorithm To Convert To Postfix Notation
Building your own calculator is a great way to practice using some data structures and algorithms in a real-world project. I saw a few projects that implemented some hand crafted and convoluted solutions. That missed the learning opportunity and made it harder to handle precedence leading to code that was harder to test and therefore more likely to have errors.
Mistake 5 - Misleading Comments
I noticed comments in several of the solutions that were out of date. They might have helped write the code - forming a pseudocode version before writing the full code - but as they’ve become out of date they’re misleading and potentially confusing.
I often use comments as pseudocode myself, it helps to sketch out what I’m going to do. It’s good practice to remove the comments when done or ensure that they are actually adding value.
Commendable - Tests and CI!
It was great to see the use of good testing in some of the solutions and even better to see the tests were run in a CI pipeline! I encourage you to do both for any Coding Challenge you complete.
If in doubt, read about how to use Github Actions for CI.
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.