Author Archives: david

Experiments on the theme of cauliflower and cheese

I had a huge (and I really do mean huge) cauliflower from Abel and Cole that I wasn’t sure what to do with – it’s not a vegetable I normally use for much – so I figured I’d give Cauliflower and Cheese a try. It’s not exactly the most innovative recipe in the world and, while it’s one I like, not something I’m massively excited by. But why not? It’s not something I’d actually ever made before, and it’d keep well as a side dish.

I used the Good Housekeeping cauliflower and cheese recipe as the basis for this, but only loosely followed it. You could probably use any recipe for it that works well. But I tried the following variations on it:

I roasted the cauliflower instead of boiled it. Basically all I did was floret it as normal, put it in the dish and roast it covered at 200C for 20-30 minutes with a bit of butter and salt (ok, a lot of butter and a bit of salt). Then I just added the sauce and cheese as normal on top of that.
Additionally I added some leeks to the mix, roasting them along with the cauliflower.
I added halved cherry tomatoes at the same time as the sauce.

This worked incredibly well. It took a nice dish and made it excellent. I had this as the main meal, served with a whole grain bread, and I’ve been very happily eating leftovers of it since.

Am I being boring?

I had an enlightening conversation with Mark Wotton on twitter recently. It started when I gave the following advice:

Writing advice: You should have a constant mental process going asking “Is this bit I’m writing boring?”. If it is, delete or rewrite it.

I’d meant it to apply to prose. I was reading an article which took an important and exciting piece of information and made it deathly dull. I don’t want to link to the article, but I’m sure you can think of examples yourself.

Mark replied:

I thought you were talking about code for a second there – it actually works pretty well there, too.

This wasn’t a context in which I’d thought about it before.

I won’t quote the entire conversation here (you can check it out at the source if you care), but the conclusions from it were interesting.

A lot of code is boring, and sometimes this is ok. Most code does boring things – display a web page, convert data from this format to that format, write out an error message, etc. Boring tasks are ubiquitous and necessary to get things done.

But, like writing, you can write about things which are boring and you can write about things in boring ways.

What does boring writing look like? Well, it could contain a lot of repetition, it could take forever to get to the point making it non-obvious what it’s about, it could include a lot of irrelevancies…

Hmm. None of those sound like very good things to do when coding, do they?

As people are fond of saying, code should really be first about telling other people what it should do and secondarily about getting the computer to execute it. Coding is a form of writing, and as such it needs to keep the reader interested or their boredom will get in the way of their understanding (side note: this is not the same as making the reader work hard to understand it – not being boring is not the same as being overly clever).

So, it’s ok to write code that is boring because what it is trying to do is inherently boring, but you shouldn’t add unnecessary boredom to the code.

Hmm. That sounds familiar.

So, to borrow the terminology from Fred Brooks: There are two types of boredom. Essential boredom, which is inherent to the problem being solved, and accidental boredom, which is introduced by the programmer. Seek to minimize the latter.

Creative cooking on half a brain

Bwrgh. I can’t brain this evening.

Hmm. I should do dinner. What should I do?

What did I have for lunch? Rice, salmon teriyaki and edamame. I should avoid things like that.

Hm. And I just had a croissant for breakfast. Low veg day. I should do something with veg.

Oh, there’s an onion squash still on the counter. Squash is a vegetable. I should do that.

Chop chop chop. Hm. What do I do with it? Well, it’s nice and hollow, I should put something in it.

Needs a starch? Does it? I’ve had a fair bit today and have snacked, so maybe not.

Yeah, it needs a starch. but what? No rice. Had that for lunch. I have bread. Can I use that? No. I don’t feel like bread.

Ooh. I’ve not done polenta in a while. Would that work as a stuffing? Yes it would. Mmm. Polenta. Start the squash roasting and I’ll put some polenta on the stove to bubble away.

Wow, this dish has like no protein.

Oh, hey, pistachios. Let’s shell those and put them in the dish.

Man, shelling these is a lot of work.

Hmmm. What else can I put in this?

Cheese. I have cheese. That turkish cheese. kefa…teria? kefalotyri. like parmesan, only not.

Apparently also not turkish. Oh well.

This isn’t sounding very vegetabley, is it?

What else can I do?

Oh, I have tomato passata left. Tomatoes are a vegetable.

No, they’re not a fruit, they’re a vegetable dammit.

Hm. These squash are smaller than I thought. I can’t fit all the polenta I made in there. And there are more pistachios than I thought. Oh well, still room for a little tomato.

It’s more of a sauce than a vegetable ingredient anyway…

Now add the cheese.

Cool. I’ve made little pizzas on top of the squash.

I like pizza.

Now to wait.

So much waiting…

Waiting…

Ooh, food.

Hmm.

I think next time I’ll save creativity for when I’ve got a working brain.

It’s all the same, really

Daniel Lemire wrote a post recently comparing one of Paul Graham’s essays on startups with the process of doing research.

It reminded me of a book I read recently, and an observation I made on it. The book was 101 things I learned in architecture school, and the observation was that half the advice applied just as well to software development as it did to architecture. I find this is often true: At the general level, good advice is very portable.

Here are some excerpts:

61. Less is more

Minimalism is not something that’s hard to find in software design (or at least software design as we want it to be instead of the endless feeping creaturism that it often turns out as). Particularly epitomized by the Unix philosophy of “Do one thing, and do it well”.

62. Less is a bore

On the other hand, there’s a reason we’re not all still living in the command line…

32. The most effective, most creative problem solvers engage in a process of meta-thinking, or “thinking about the thinking.”

Good advice anywhere, but particularly so in software development where there’s so much capability for abstraction.

81. Properly gaining control of the design process tends to feel like one is losing control of the design process

There’s a good chunk of explanatory text in the book about this one, which I’m not going to reproduce here. In short, this is about not becoming prematurely wedded to ideas and embracing the uncertainty needed for finding the right solution.

17. The more specific a design idea is, the greater its appeal is likely to be

Tools for solving everyone’s problems tend to be tools for solving no one’s problem.

90. Roll your drawings for transport or storage with the image side facing out

Ok. Maybe not this one…

Join me on IRC

This site has a fair few readers. Nothing phenomenal: Google analytics tells me I get somewhere around 100 hits per day of whom about half are repeat visitors. It spikes when someone (often me) posts an article I wrote on reddit and hordes of irate people come here to tell me I’m an idiot (or, every now and then, to agree with me).

But it’s very much a one way channel. I’m talking at you rather than with you. That’s fine, but it only goes so far. A dialogue would be nice too. I don’t really know much about my readers, and I’d like to.

As an experiment to further this, I’ve created an IRC channel for the site. If it takes off, I’ll create a page for logs, etc. here and some more stuff for site/channel integration. But in the meantime, why not join me in #drmaciver on Freenode if you want to have a chat.