Perl Weekly Challenge 107 - Self describing numbers... live coded

Having an additional day off this week (extending the UK Easter break) I decided to do another short live coding session.

Once again the subject being the (Perl Weekly Challenge)[https://perlweeklychallenge.org/blog/perl-weekly-challenge-107/#TASK1] by Mohammad Anwar.

This weeks task #1 is to write a script that produces a list of the first three "self describing numbers". I tackled it without any prep (pre-reading or planning), which is always risky, but it went OK.

As ever I try and work in a Test Driven Development (TDD) style. This means I try and work out small steps with tests that confirm my hypothesis as I go along. I am not super strict about what that means. I use TDD as a tool to help me solve problems, rather than a strict approach. Especially on this sort of recreational coding; I don't worry at all about coverage or too much about being strict TDD... whatever your definition of strict TDD is.

I use warn and Data::Dumper too. The mindset is the same as TDD, I am testing the idea of what is next.

There has been a discussion on Twitter about TDD (as always) and I think I fall into the camp of thinking that TDD is about driving my design, not providing coverage of edge cases. That's a different issue. Unit tests may still be the tool, but the objective is different. If you watch the video you'll see I only really code the "happy path"; intentionally so. I am trying to determine the solution to the problem. So it's about interfaces and making it easy to make changes without regressing.

You'll see in the video that I end up in a muddle a couple of times. I notice that that's when I have not been using tests to guide me. I also notice that at the end I was easily able to demonstrate changing the if statement from eq to == and know immediately if it was OK as the tests proved it still worked. This is what TDD gives you. That ability to refactor (even if it is only going from eq to ==) with some confidence. The confidence encourages me/you to refactor more than as it's not scary.

Another observation I should point out (and I have done so before) is that I tend to start with minimal test and package... as it saves me from typo bugs that can be ever so frustrating. I try not to write a full set of tests of examples.

The last thing I will add, is that if you watch the video... you'll see I end up with I think 3 working solutions to the task requirement. Starting with simply returning an array of the three numbers expected with no real logic. My test proves that the call works. It also provides the foundation that the next piece of coding provided. The second solution was looping through all the numbers from 1 to 30,000 and checking (via a new sub) if that number was self-describing. Again, I did this the "cheats way" of looking for the specific three numbers and returning positively with three simple if statements.

Only then did I write a solution that actually worked across any number.

If this was a professional coding problem. I would ideally do it the same way. Why? Because I had a provably working solution I "could" ship very quickly. The later solutions were better and more in line with what would actually be wanted; but getting those first two solutions coded up and tested is important at it allowed me to learn quickly and in small increments and if I'd committed the code at the right points a colleague could have carried on the project if need be. Or having gotten it out the door fast; maybe it turns out we don't need that feature and we revert with minimal time invested in the feature.

In this example, it's not such a big deal. But I've been in the situation where the code changes are hundreds-thousands of lines of code for a new feature that we didn't know would work. And watching a huge piece of work fail and being cancelled is far more painful emotionally as a developer (and financially as a business) than a small change.

Thanks again to Mohammad for this awesome project of his!