Prototype Wrapup #11

After last week I was hoping that putting a bit more effort into organisation would turn into a higher output of prototypes. Unfortunately it wasn't quite the magnitude I expected. I committed to do one every day, but I only managed 4 days.

Monday

This was the first part of what turned into my post on Beyoncé numbers. I started off by trying to make a clever solver in Haskell, confused myself, and then made a brute force solver in Haskell. It really struggled with the volume of numbers though. I calculated that I could leave it running for an hour or so, but I kept running out of memory. I think I was probably doing something wrong.

Tuesday

This was attempt two. I figured out how to do a clever solver that would generate and solve numbers from a seed instead of brute forcing everthing, but then I got stuck on how to be sure that the seeds were comprehensive. In the end, I gave up on this method too.

Wednesday

Finally, I decided if I can't work smarter, I'll work faster. I rewrote the thing in Rust, which was actually really nice. I had to do a little bit of type juggling until I realised that because my arrays need to index themselves I should just make everything a usize even if the numbers never go above 10. I also got to use magical Rust threads, and not having to worry about synchronisation felt pretty good.

Thursday

I've poked around a bit with Facebook's Flow type checker, but I thought it might be fun to do something else with it. I wanted to make a friendly type parser, so you can write "a function that takes an array of string and an optional number and returns a number" and get back (a: array, b: ?number): number. I got it going, but I'm not sure the types really helped me that much.

I've been thinking about the prototype situation over the last few weeks, and I think the simple fact is that I've been relying on the commitments too much and not respecting them enough. Commitments should be something you are very likely to achieve, and at least for the last few I've been using them quite aspirationally. If I was asked how surprising it would be if I failed that commitment, the answer would be not at all. Not exactly how I meant to do things!

I think, in particular, maintenance goals are a poor fit for the platform. Firstly it gets boring committing to the same thing constantly, but also I don't think public commitments are really granular or focused enough for the kind of thing I'm doing. Doing this properly means steady effort every day, and a system that reflects this. With writing, I have a very short feedback loop from missing a deadline to dealing with it, whereas right now for the prototypes it's often a week.

Which is all to say that I'm going to stop making prototype commitments. I think there is a better system out there, but I'm not sure what it is yet. In its absence, I still have my weekly prototype wrapups, and the habit is fairly well established to the point I don't think I'll just stop doing it. I might look into my monotonic stats idea and see if that proves to be a better motivator. Either way, I think turning down this particular kind of pressure will actually be pretty helpful, because it makes room for a different solution.