A nightmare of a day at work.

We have a major release planned for 17:00. Four hours before release, key functionality that we really, really want to get out to customers is still not release-ready.

The web site is down already when I get into the office at 8. Infrastructure issues at our hosting provider. At 15:40 the application, the thing our customers are paying for and the thing we want to upgrade, also goes down.

At this time I go out for a long walk to clear my head of all the frustration, and take some photos of the neighbourhood.

(When I come back, all the servers are still down. We take a pizza break and start preparing ourselves mentally for having to cancel the release that we’ve been planning for since before summer. At the very last moment, when we are minutes away from cancelling, the servers come back online and we forge ahead after all.)

Eric is reading Harry Potter for Ingrid every other night. (The other nights, I read Supilinna salaselts.) I also listen because Harry Potter is fun, even in Swedish. Several evenings now we’ve heard about about quidditch games.

[I note that my text editor recognizes quidditch as a valid English-language word. Unlike recognizes, which it thinks should be spelled with an S instead of a Z.]

The programmer in me cannot help but wonder about the magic controlling the quidditch balls. I mean, since the balls fly around on their own, they must have some kind of instructions. If you want to control something by magic, you must know precisely what you want it to do.

How could you instruct something to behave the way the Golden Snitch behaves in the books, for example? “Fly around, fast and unpredictably, but not too fast. And keep yourself hidden, but not too hidden – no burrowing into the ground or someone’s pocket!”

It’s Thursday so it was Ingrid’s turn to cook dinner again.

Today we got hajkbomb, which is a meal that probably only those with a background in Swedish scouting will recognize. It’s a meal designed to be cooked over the hot coals of a campfire, but a normal kitchen oven works equally well. A “bomb” is an aluminium foil package filled with any kind of ingredients: chopped vegetables, potatoes, meat if you prefer, etc. (Potatoes and other harder veggies need to be pre-cooked.)

As is often the case, Ingrid likes things to be the same as they normally are, so the hike bombs in our family always consist of potatoes, salmon, bell peppers and one or two other child-friendly vegetables.

It’s a quick and simple meal and would probably take me about half an hour to prepare, plus some time in the oven. Peel and dice the potatoes, chop the rest while the potatoes are cooking, wrap into foil packages, season, done.

It took absolutely forever for Ingrid. 80 minutes, to be precise. I was so bored and itching to actually do something (other than hover around and be ready to help her when needed, remind her to turn off the stove, etc). I was needed often enough that I couldn’t go off and read a book for example, but not often enough to actually keep me busy. I could perhaps have been even more hands off and let her figure more things out on her own, but everybody was so hungry that I felt I needed to direct her a bit to speed things up somewhat.

It was just like watching a junior programmer take an hour to painstakingly solve a task that in my mind should take all of 10 minutes. Excruciating. Frustrating.

But just like a junior programmer can’t get any faster unless they get to spend that hour on a 10-minute task, Ingrid can’t learn to cook unless she gets to practise, on her own, without me interrupting to tell her how to do things faster.

In fact the process of cooking this dinner reminded me of pair programming. The senior programmer takes on the navigator role – keeping an eye on the goal, making sure the pair stays on the right track, warning of upcoming obstacles. The junior programmer does all the actual coding. Just like we cooked: me making sure we are moving in the right direction, Ingrid performing all the actual cooking.


Our developer team took a day off from ordinary work and had a “dev day” with a few discussions but mostly with coding for fun together.


Adrian, very tired at dinner.

We went to the Ahhaa science centre today. They had a spy themed exhibition with a lot of activities that we really enjoyed: recognizing fingerprints and tire tracks, trying out an airport-style baggage scanner and a hand-held metal detector to find fake guns and such, climbing and crawling through a dark corridor criss-crossed with green laser beams, and a “stepping stones” memory game (just like the entrance to El Macho’s lair in Despicable Me 2) and so on.

We also saw an awesome “science theatre” show about the chemistry of fire, which was basically a demonstration of lighting things on fire, and of different ways of making the fire burn stronger and faster. I love fireworks and explosions – at a safe distance.

The fires ranged from tame (a cotton ball in normal air) to really impressive fireballs (a propane-filled balloon). The final fireball (another balloon containing a mixture of 1 part propane and 5 parts pure oxygen) was such that all members of the audience were first instructed in the proper technique of covering their ears, and the presenter wouldn’t proceed until everybody was following those instructions. It made a very satisfying bang and the heat could be felt several rows away.


Ingrid found science experiments on the internet. The one in the front is water (with food colouring) and oil. With some salt it behaved like a lava lamp. (Description here.)

The two glasses at the back were an attempt to make a two-coloured flower. (Split the stem, put one half in one glass and the other in the other.) The experiment description called for a carnation but we didn’t have any. A white Aquilegia was the best I could find in the garden but it did not take up much colour at all.

I set out yesterday to photograph one of our cherry trees in its autumn colour. What I got is not at all what I had hoped for.

Here’s what the tree looked like a year ago, almost to the day. That was what I wanted to capture again but from a different angle. And next to it, what it looked like yesterday:

Compared to last year, the tree looks rather unimpressive. Where’s that fabulous fiery red gone? The top of the tree is already starting to look sparse so waiting will not help.

I thought that the colours we see in autumn leaves are always there, but hidden by the strong green of chlorophyll. In autumn they become visible as the chlorophyll is broken down before the leaves fall. But if that was really the case then a tree should look pretty much the same year to year.

I’d noticed already last year that there was more red on the side of the tree that faces the sun, and mostly yellow in the shadier parts. So there’s obviously some dependence on sunlight.

Now I did some reading and found out that the schoolbook explanation for autumn colours is only half of the truth at best.

The orange and yellow pigments (carotenoids) are indeed there all year round, as the schoolbooks say. But the red pigments (anthocyanins) are only produced in autumn when chlorophyll starts breaking down. And some kinds of autumn weather lead to more anthocyanins than other kinds:

The range and intensity of autumn colors is greatly influenced by the weather. Low temperatures destroy chlorophyll, and if they stay above freezing, promote the formation of anthocyanins. Bright sunshine also destroys chlorophyll and enhances anthocyanin production. Dry weather, by increasing sugar concentration in sap, also increases the amount of anthocyanin. So the brightest autumn colors are produced when dry, sunny days are followed by cool, dry nights.

(scifun.org)

Additionally I learned that anthocyanins are also the pigments in cherries, but also eggplant skin, blueberries, raspberries, blackcurrants, apples and all sorts of other red and purple fruit and vegetables. And the dependence on sunlight explains why often only one side of the apple is red while the other is greener.

The new MacBook is awesome. Saving a photo in Capture NX (Nikon’s editor for RAW files) went from about 15 seconds to 2. My workflow used to be “edit, press save, browse the Internet for a while, come back”. Not any more!

After four and a half years of dedicated service, I have now retired my old MacBook Pro and bought a new one, of roughly the same kind. (The battery on the old one has warped with time and is now so bent out of shape that it puts pressure on the trackpad from underneath, so after about an hour of use the trackpad stops working properly.)

In addition to a working trackpad, unaffected by a misbehaving battery, the new one has one really cool thing: a Retina display.

The Retina display seemed like an unnecessary luxury. I was pretty happy with the old screen. But the model with Retina display had other things that I wanted (more memory compared to the non-retina one, and Flash storage instead of a hard drive) so I bought it anyway.

And now I am in love with the new display. Everything looks so crisp. It’s a pleasure to look at, and especially to read – or write.

PS: If anyone is interested in buying a cheap 5-year-old 15″ MacBook Pro with a badly warped battery, then let me know. The battery can be replaced, I’m sure.

Recruitment-related tasks have been filling most of my days at work since January. Now I am finally seeing a glimpse of light at the end of the tunnel. We are close to signing a contract with a good back end developer, and today for the first time we had a really promising candidate for the front end role.

By now I have a pretty solid and stable process worked out. First I read their CV and/or cover letter, and ask for clarification where I their background really seems to not fit our needs. Well over half of the candidates get discarded at this stage – surprisingly many candidates seem to apply for any job that seems even remotely related to their skills, and don’t hesitate to apply for jobs that they are clearly under-qualified for.

Next I ask them to do a coding task at home, at their own pace. After this we have a brief phone interview. I used to do it the other way round, because I didn’t want to do give them unnecessary work – the task takes a couple of hours to do at least, whereas a phone interview is no more than 30–40 minutes. But it turned out that a lot of people who sounded knowledgeable on the phone failed the coding task, so it ended up wasting a lot of my time instead. And since I get to decide, I’d rather have them waste their time, not mine. The coding task not only filters out the candidates who can talk but not do – it also gives us something concrete to discuss during the phone interview, and therefore makes the interview much more effective.

Now the funnel works quite well. Occasionally I say yes to someone who I am unsure about, and thus far these candidates have always disappointed in the next round. So if the candidate doesn’t seem to have enough relevant experience, they don’t do well on the coding task. And the ones whose coding task does not impress don’t make a better impression on the phone.

All the coding tasks until now have been sort of mediocre, “good enough” at best. We’ve been trying to weigh them against each other but never really come to any firm conclusions. Is one kind of mediocrity better than another? What’s worse, stupid variable naming or badly organized code? How bad is too bad?

The one we got today stood head and shoulders above all the previous ones, and the interesting thing was that this time there was no discussion, no hemming and hawing. The moment we saw the code it was obvious to all those involved that this one was in a completely different league from the others. Distinguishing a really good solution from a mediocre one is so much easier than comparing two mediocre ones. Even if we for some reason end up not hiring this guy, he has at least given us a yardstick for evaluating future candidates.

Another observation we made today was that the good front end developers we’ve met (including those in our team) are all ex back end developers. In other words, they are developers who have chosen to specialize in front end work. The ones who come from the other direction – the designers, the web developers – lack the necessary fundamental development skills. Their solution may work but just it’s like a house of straw: you can see at a glance that it is structurally weak. They don’t build, they hack.

PS: I just counted: I have received 43 applications for this job, reviewed 13 coding tasks, had 10 phone interviews and 2 face-to-face interviews (with 2 more already booked).