Author Archives: david

How to hard “boil” an egg

Boiling an egg is reputedly easy. It’s not. It’s ridiculously easy to get wrong and to end up with eggs which are under or over cooked, or which break the shell while cooking, or are mangled when you peel. Also you’re not actually supposed to boil the water the egg is in – it results in a sulphurous yolk and a rubbery egg. Apparently about 80C is the right temperature for hard cooking an egg.

The internet is full of advice on how to do it right, as is basically every cookbook. I’ve found a lot of the proper ways are very hard to get consistent, depending on cooling rates or the age of the eggs you’re cooking. Here’s what I’ve found works:

Cover the eggs with cold water. There should be quite a depth of water above the eggs – at least an inch, preferably two
Add a heaped spoon of baking soda. Don’t skip this step. It makes the eggs dramatically easier to peel (apparently because it changes the pH of the water)
Put the pan on high heat until the water just starts to boil – it shouldn’t be boiling violently, it should have just started to bubble slightly
Turn the heat way down to its lowest setting. You want the temperature to drop but not too rapidly (standard advice seems to be to turn the heat off at this point, but I’ve found the results of doing that incredibly variable)
Leave it for about ten minutes on the low heat
Pour out the water and replace it with cold water. Leave it a few minutes
Your hard boiled eggs should now be warm but not hot and perfectly cooked. If you want to keep any you should pour the water out again and replace it with more cold water. Any you want to eat now should be cool enough to touch and easy to peel

(Hat tip to Tim Ferris for the baking soda trick. I can’t make the egg blowing work but they’re so easy to peel with the baking soda it hardly matters)

A heuristic for detecting expertise

Earlier tweet:

Tentative rule of thumb: if they don’t appear obsessed with details you regard as irrelevant they’re probably not actually an expert

— David R. MacIver (@DRMacIver) June 13, 2012

It seems to have struck a chord, so I thought I’d elaborate slightly.

Firstly, this is of course a heuristic for non-experts to determine expertise in a field with which they are only passingly familiar. If you are an expert then using your own lack of knowledge as a heuristic isn’t very useful, and you probably have much better ones to apply.

The basic idea is this:

It’s usually not obvious what the important features of a problem are. In particular what looks important is often different from what’s actually important, or requires you to address some more fundamental issue as part of dealing with it. Therefore your perception of relevance as a non-expert probably has an awful lot of false negatives.

Someone who has acquired expertise in a subject understands it a lot better, and thus has a much more finely tuned perception of what the relevant problems are. Therefore there are a lot of things they would consider relevant that you would not.

Examples:

Why is this developer talking about things like “refactoring” and “testing” which you don’t care about. You just want the software to get new features quickly and not crash!
Why is that security person asking all these strange questions about validation? You just want to make it so people can’t hack your site
Why is the tennis coach obsessing about where your feet are? You just want to hit the ball!
Why is this cook talking about knife skills? You just want to know why your food isn’t cooking evenly!

I’m not 100% sure how useful the heuristic is. I suspect it may be too permissive in the sense that it’s easy to let babble through. e.g. “Why is this guru talking about chakras? You just want your cancer to go away!”. Perhaps it needs the secondary heuristic that they have to be able to explain why the detail is important?

Salad for breakfast

I was in Israel recently for a friend’s wedding. Israel, it turns out, is full of good food. Additionally, as a country with a rather large farming industry, they also have very good fruit and veg. (Side note: I am aware of some of the political implications here. I would rather not get into them right now. This is a post about salad, not politics).

One place this manifests is in their breakfasts. The “Full Israeli” breakfast contains quite a lot of salad. This wasn’t something it had really occurred to me to do before, and I found that I quite liked it, so I’ve decided to have a try at adopting it and make salad my breakfast food for a while and see how it goes.

(Also I figured a bit of a dietary shake up might help take off the most of 2KG I added to my waistline while there. This was less due to the salad breakfasts and more due to the pastries that went with them. The giant lunches and dinners probably didn’t help either. Did I mention the food over there is rather tasty?)

in future I’m planning to pre-prepare some things to use as the base of the salad, but I haven’t done that yet so this morning’s salad was fairly basic. I did novel-ish things with seasoning it though and the result was rather tasty:

About half a romaine lettuce, quite finely chopped (I don’t like large leaves in my salad)
About a quarter of a cucumber, coarsely chopped
A raw yellow pepper, coarsely chopped
A handful of toasted almonds
A drizzle of olive oil
Juice of half a lemon
A heaped spoon of za’atar

Dressing it was very simple – just added the olive oil, lemon and za’atar on top of the salad and tossed it all together. Didn’t bother to premix anything.

I think it’s more Israel-inspired than necessarily something you would get over there, but the result was both tasty and filling. Also the use of za’atar + lemon as a salad dressing is definitely a winning combination and you should try it.

Against Human Readability, Part 2 of Many: The toolchain argument

One of the biggest promoted arguments for using text based formats (which is not the same as human readable of course, but is a prerequisite) is that you can use your existing unix toolchain on them.

I am skeptical.

You can of course use your text editor on them. Rather by definition. But being able to use the other tools limits you to very specific sorts of text formats – in particular ones which are quite heavily line oriented. The thing is, the unix tool chain is actually a very specific tool. It works very well for things which are Unix shaped and quite terribly for anything else. You thus end up needing tools for converting to and from unix shaped formats if you want to be able to use your tool chain on your data. Witness jsonpipe as an example of this sort of shenanigans. And if you’re going to be converting it into and out of a different textual format, why do you need your source format to be text based at all?

This still leaves you with your text editor.

I think if you’re going to be designing a binary format, I think you really need some sort of pretty printer for it. In our discussion in #againstreadability, Andy and I had the following conversation:

21:19 < andyjpb> if you have a pretty printer you have to do most of the hardwork anyway ;-)
21:19 <@DRMacIver> Not so! 
21:19 <@DRMacIver> Generators are much easier than parsers
21:19 <@DRMacIver> Because you don't have to worry about the ambiguity introduced 
21:19 < andyjpb> well, I suppose it depends on whether you have a reader or not.. but once you've got a printer, a reader is not so far away
21:19 <@DRMacIver> Yeah, but don't do that :)
21:20 < andyjpb> whynot? modifying bits in a blob is a solid usecase

I think I’ve changed my mind. If you really find you need to be editing the format directly in a text editor, it’s not completely unreasonable to have a reader as well as a pretty printer. This does require you to have a semi-defined textual format in parallel to your binary one, but because it’s not a primary method of interchange the requirements and costs of it are lower (in particular it doesn’t have nearly as serious performance and security concerns)

But I think this is the wrong way to do it. I realised on further thought about this that the tool chain argument misses out something really quite crucial. It’s not surprising – I think it goes back to before this was actually a valid point – but once I realised it I was kicking myself for how blindingly obvious it is.

UNIX is not your only toolchain

There are programming languages other than shell, many of them with very good interactive shells. As soon as you’ve got bindings to python, or ruby, or erlang, or even freaking javascript, you have an interactive environment and a rich set of libraries with which to operate on your data format.

By manipulating your data format in these languages instead of in shell, you gain a much finer degree of control and greater degree of expression than you can manage in the primitive language of shell. Further, you do it without any requirements on representation – the bits that are human readable you can manipulate easily as strings. The bits you aren’t you can either ignore or process using whatever libraries for operating on that binary data your language offers you.

Against human readability, ongoing discussion

I ended up setting up an IRC channel for continuing the human readability discussion that had started on twitter. Alas, two of the three participants needed to go to bed so the conversation in question never continued. Still, I had the IRC channel anyway and it did end up spawning an interesting discussion on the subject with someone else entirely.

So I figure I’ll leave this channel around. I’ll be in it for a while, we’ll see who else is. If you want to talk about these issues, come on by.

We’ll be in #againstreadability on Freenode. The channel is publicly logged, and logs will be available here/