This is a good lesson!
We should write tests.
I also spent some time debugging an error that a small test would help to avoid (or flag). If you target finish in top 100 (for a day), I don’t think that it is possible to do that writing tests. The top 100 finished the first four days under 6 minutes. Yesterday, it was average 15min.
I can see how tests speed up the development of harder (simulation) problems. I did until day 15 last year and there were few problems that were difficult enough to split in pieces and have tests for them.
I’m a smalltalk TDD, HTDP style developer so /most/ of the time I write a test first
I think that’s part of the reason why Matthias said that he dislikes this kind of contest. It encourages people to not developing good programs if you want to get high ranking.
Good and bad are trick words. But I get want he means. Programs in those competitions are small and self-contained and that is not how the real-world looks like.
By the other hand, one can craft several skills in those competitions that are useful in real-world problem solving: deep focus, habit to search for corner cases, top-down analysis (time and space for example) and how to prototype something fast.
Did you learn to program using the HtDP style or you started to use it later?
Later.
How was your experience applying it and how painful was to overcome the old habits? Feel free to ignore my question if you don’t feel like sharing your experience.
I am asking because I somewhat incorporated the design recipe in my process but I always feel an internal resistance to apply it. By other hand, I wonder if people like Matthew (that builds tons of complex, big and good software) use it daily.
May the lambda be with you. Have fun guys.