From The Challenges - CronTab Tool

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 90,280 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! 😀

Did You Know I Have A Podcast?

If you enjoy Coding Challenges you might enjoy my podcast Coding Chats. Every week I interview someone about an element of software engineering or progressing your career as a software engineer.

If you’re new to it, here are two episodes that might interest you:

• How to grow beyond Senior Software Engineer and thrive in an engineering leadership role with Gregor Ojstersek

• How to prepare for and ace behavioural interviews with Austen McDonald.

If you like the format and would love to see me interview someone, please hit reply and suggest who I should interview in future. Thanks!

Recapping The Crontab Tool Coding Challenge

In the build your own crontab tool coding challenge the goal was to write a tool to explain crontab expressions.

As I explained in the coding challenge, on a surprisingly regular cadence I find myself introducing software engineers to crontab, explaining that there’s no need to build a tool to schedule jobs because the server OS - whatever flavour of Linux (or Unix) we’re using has a tool built in.

It’s called cron and it’s been on Unix and Unix-like operating systems since 1975. Like many of the great Unix tools it has one job - scheduling other jobs and it does it well. One area I’ve seen many engineers struggle with however has been configuring it. So this challenge is both a chance to learn about cron and configuring it via crontab.

📌 Next Systems Programming (Redis) Course Starts 20th October

Would you like to build a network server from scratch with me?

Learning about network programming, concurrency, testing, and systems software development?

If so check out my course: Build A Redis Server Clone: Master Systems Programming Through Practice.

It is designed to be intense! It’s 11 hours of instructor 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 sign up before 6th October you can get $100 off using the code: EARLYBRO25

If You Enjoy Coding Challenges Here Are Four Ways You Can Help Support It

1. Refer a friend or colleague to the newsletter. 🙏

2. 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.

3. Buy one of my self-paced courses that walk you through a Coding Challenge.

4. 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.

5 Great Things Or Common Mistakes Software Engineers Make Solving The Crontab Tool 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.

Shoutout 1 - A Great README

I liked the README that Ferran provided in his solution. It covers implementation details, features, how to run the code and tests (including requirements), and how to run the application. That’s what a README should be!

Plus…

Shoutout 2 - Referencing Papers

The README also linked to a paper on Monadic Parser Combinators, to quote the paper:

In functional programming, a popular approach to building recursive descent parsers is to model parsers as functions, and to define higher-order functions (or combinators) that implement grammar constructions such as sequencing, choice, and repetition.

I love that the README referenced the paper about the technique implemented in the project and l loved skimming the paper, I learned something new! Check it out if you’d like to learn about building recursive decent parsers using functional programming.

Mistake 1 - Checking In Boilerplate Unchanged

At the opposite end of the spectrum there was a solution that was created with the starter template generated by a tool. Nothing wrong with that per se, but it’s not great when you then check in a collection of generated files that are unchanged and irrelevant to the solution you’ve built.

It’s even worse when you check in the README, unchanged and therefore no longer relevant to the project you’ve built. The benefit of building real-world projects like Coding Challenges is that you’re building real-world software, practising the skills you’ll need on the job. You cheat yourself out of the learning and development if you don’t do the whole job.

So, use a tool to generated your starting point, then once you’re building, delete the bits no longer needed and update the README to be about your project.

Mistake 2 - No Tests

There are a lot of different combinations of crontab entries and a lot of potential for human error in the input. To build code that handles all the combinations and detects and gracefully handles the error cases - when a human enters an invalid crontab entry - requires a lot of testing.

As such, I don’t believe you can efficiently develop software like this without automated tests. Without automated tests, every time you make a change you either have to do a lot of manual testing or just hope you didn’t break something.

Hoping isn’t a strategy professional software engineers should be relying on.

Mistake 3 - Utils

Maybe it’s just a pet hate of mine, but please try to avoid creating folders and modules that are called “utils”. Be specific about what things do. Use a name that helps maintainers of the code know what they will find in that file / directory / module / package.

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

1. Refer a friend or colleague to the newsletter. 🙏

2. 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.

3. Buy one of my courses that walk you through a Coding Challenge.

4. Subscribe to the Coding Challenges YouTube channel!