What a crossword puzzle can teach us about programming
I enjoy doing the USA Today Crossword puzzle every day. It’s fun and I like to think it keeps me sharp. It’s also free. If you google it, you’ll find it rather quickly. This particular crossword puzzle has 2 modes: expert and casual.
In expert mode, there is no feedback. You type letters and they just show up. It is possible to come up with a word that matches the clue and number of letters but is not the correct word for the puzzle. It is also possible to introduce typos. In both cases, there is no indication. You only find out when the intersecting clues don’t fit. Sometimes you can even find a potential answer to an intersecting clue that does fit. Then the situation just compounds because you are building on something that is itself already wrong, but you just don’t know it.
Finding the problem, in this case, is often hard. I’ve gotten to the end of a crossword and had a single typo and wondered why the little banner that says you are done hasn’t popped up. Then I have to go back through every single letter and double-check.
Casual mode gives you instant feedback. As you type each letter, if it is the incorrect letter, then you get a red slash through it. Because you know instantly it is not correct, it saves you lots of time. You no longer have to worry about building onto something that is incorrect. There is no time spent at the end of the puzzle figuring out what is not correct.
Writing code is already hard don’t make it harder.
Too many of us write our code in expert mode. There is no feedback. We have no Continous Integration system set up to automatically run our builds and tests. In many cases, we don’t even have tests. Often we end up introducing a bunch of code at once. We do all our testing at the end. At that point, we’ve got multiple changes to sort through to find out which one is causing the problem. We may have even built more code on top of that bad code. This makes debugging really hard.
The Solution
While doing the crossword on expert mode can be seen as a badge of honor, of showing how smart you are, there is no such badge when writing software. There is no shame in getting quick feedback. In fact, I would say it is imperative. I’ve been writing LabVIEW code for 15 years and I still make mistakes every day. I haven’t figured out how to not do that. If you have please let me know your secret. The way I cope with that is that I try to get feedback as quickly as possible (using Unit Testing and Continuous Integration) so I can catch my mistakes before I write code on top of them and it becomes harder to undo. By taking really small steps and getting feedback each step of the way, it becomes very easy to undo changes. Gee Paw Hill writes a lot about this.
Favor Fast Feedback
I was listening to the Mob Mentality Show the other day and they were interviewing Luis Martinez. He had a really good quote that stuck with me, so I’ll leave you with that quote. I think it will serve you well.
Favor Fast Feedback.
Luis Martinez
Need Help Setting Up Unit Tests or CI?
If you are tired of writing code on expert mode and would like to try casual mode, we’d be happy to help. Let’s set up a call.
