From The Challenges - Diff
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 74,881 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! 😀
🚨NEWS: Book Club Launching!🚨
Coding Challenges now has a book club! The focus is on books that would be interesting and useful to software engineers looking to deepen their knowledge, though anyone is welcome. Selected books will be focused on a specific software topic, not on philosophy of software in general.
It should be possible to complete the book in two to three months by reading one to two chapters per week.
Some good example books would be:
Designing Data Intensive Applications
Computer Systems: A Programmer's Perspective
Structured Computer Organization
Crafting Interpreters
Structure and Interpretation of Computer Programs
Database Internals: A Deep Dive into How Distributed Data Systems Work
Please come join us on the Discord server in the book-club channel if you’d like to take part. it’s free! We’ll start the first book in the next week or two.
Recapping The Diff Coding Challenge
In the build your diff coding challenge the goal was to write your own diff command line tool.
It still amazes me that the diff tool has been used by software engineers since 1974. Next time you knock legacy code or code written in C remember that diff is still providing value today!
This is a great coding challenge to use to level up your algorithm skills - to solve the coding challenge you have to implement an algorithm to solve the longest common subsequence problem. You can work that out from scratch or implement one of the algorithms linked from the challenge.
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 Diff 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 Writing Tests
If you’re doing a DSA interview you’ll be expected to write and talk about the tests you’re using, even LeetCode gives you a couple of test cases to get you started.
If you’re writing production software the algorithms you develop should have tests to verify they behave correctly. That should often include the non-functional requirements, i.e. the time and space complexity or execution time.
In the diff coding challenge I provided several test cases, it’s a mistake to not at least use those to verify your implementation of the LCS algorithm works correctly.
Mistake 2 - Only Covering My Example Tests
As per mistake number one, if you’re doing an interview and you only use their test cases it will probably count against you. Especially if like I do in the Coding Challenge, they say: “I’ve deliberately not covered some of the test cases you’ll need to think about. Your challenge is add your own test cases and ensure you code passes them all.”
Think about the edge cases and the error conditions and then create some tests that reflect them. Ideally automate the tests too.
Mistake 3 - Single Letter Variable Names
One of the first lessons I was taught as a software engineer was to use meaningful variable names. Single letter variable names were fine for the idiomatic i as the index in a loop or i and j if there were nested loops. The same applies to two letter names, i.e. it is idiomatic in C++.
I know Go encourages short variable names, but if your function just consists of short, single character variable names it is hard to follow and therefore hard to maintain.
Mistake 4 - Overuse Of Object Oriented Programming And Design Patterns
This is a great project to use to refine your ability to read about and implement an algorithm. In this case it’s an algorithm for the longest common subsequence, which can be implemented in a few tens of lines of code. Despite that i saw a few solutions that were significantly longer and made use of OOP and some OOP design patterns.
There are some great benefits to OOP, it can help clarify the design of software. It can also be overused, making software more complex than it needs to be. Unfortunately it’s become increasingly overused over the last couple of decades since Java pushed the idea that everything should be a class. It shouldn’t! Some things are Plain Old Data (POD) and are better represented a plain data structure with no methods (what C programmers would call a struct).
Classes are good for representing real-world concepts, like a bank account where the operations on it are closely tied to the state of it.
I’m not against OOP, but I do encourage you to be intentional and considerate with your use of it. If it makes the code clearer and creates a useful model of the domain, use it, if it doesn’t consider something else.
Mistake 5 - Reading The Whole File
Diff can be run on very large files. Unless the processing you are doing requires the whole file, you should always process it in parts. Sure you should avoid reading character by character or line by line as it’s inefficient, but you can often read in 4 or 16KB chunks very efficiently.
Bonus - Cool Feature
I really like the examples where the authors added some useful features to their diff, for example colour coding the output to make it clearer in the console.
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, 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.
Subscribe to the Coding Challenges YouTube channel!