Weeknote 5: Broken Input

I was thinking about debugging tools last week. The same theme continues this week.

My big insight is that many development and debugging tools must work with broken or incomplete inputs. Here are a few examples:

  • A debugger must work with programs that crash. In fact, that is exactly the time when many of us reach for a debugger.
  • Your editor should work even if there are some syntax or type errors in your code. You expect features like syntax highlighting and autocompetion to work while you’re in the middle of writing code.

This also applies to the visualization tool I’m working on. If you want to use it for debugging, it’s not enough that it works for the kind of well-behaved data that we’ve got in production. It also has to work on the kind of data that we get when things are not ready yet and we’ve got some debugging to do.

Dynamic typing is possibly another example of allowing broken input. I’m a big fan of Python’s type system, but I’ve enjoyed not using mypy while prototyping new code. It’s convenient that you can have slightly broken code and you can just run it and see how it behaves. When you’re experimenting and playing, you don’t need to handle every None or other corner case.

You should read the article How to Monetize a Blog. I guarantee it’s worth your time even if you don’t have a blog or plans to monetize one.

Upcoming events

I’m going to be at Heart of Clojure the next week. If you’re coming, come say hi to me!

Photo: Geese in a park in Münich.


Comments or questions? Send me an e-mail.