Monthly Archives: February 2014

Fixing Marginal Issues

Sometimes when you’re programming (or working on any project, really) you’ll discover some feature or issue that requires a lot of work to do properly. It’s often something that you completely overlooked during your initial design work, a tricky bug that came up during testing, or a use case that only some users will find.

A few months ago I made a simple Rubik’s Cube page and put it up on the web. More recently, I discovered it had a bug; a pretty serious bug that meant it wasn’t doing at all what it was supposed to be doing, namely simulating an actual Rubik’s Cube. Fixing it was hard. It meant rethinking the entire design of my code. I spent more time fixing this bug than I did on the entire first version of the project. At the moment I’m wrestling with a similar issue on my current project. To make it work well in 100% of all possible use cases is taking considerably longer than it took to make it work 80% right. Programming projects are full of these types of issues that look simple until you start working on them and realise they’re not. Continue reading →

Tea Drinkers of the World Unite!

In London, there are now more coffee shops than people. The rise of the coffee shop has been very good for coffee drinkers of course, and every effort is made to cater to their whims and desires. There are now 237 different ways of introducing beans to hot (not boiling) water, all of them requiring different equipment and all of them tasting exactly the same. It’s now trendy to complain about the coffee in well-known chains; the same coffee that a couple of years ago was being hailed as a vast improvement on the instant coffee and vending machine coffee that most people were used to. Now, apparently, good coffee can only be found in independent coffee shops, not in chains. It’s as though the coffee in one place instantly goes bad as soon as another shop with the same name opens somewhere else. Coffee Grinder

For the tea drinker though, the rise of the coffee shop has been a bit of a mixed bag. We tea drinkers still get to sneak out of the office, returning triumphantly, clutching our branded paper cup (if you keep the lid on, no-one will know what’s in there). And we still get to ostentatiously use our MacBooks in public. But it can feel like you’re a second class citizen when you order tea in a specialist coffee shop. And the same fetishization has not happened for tea as it has for coffee. Continue reading →

The Little Schemer and The Seasoned Schemer

I’ve been working through these two programming books, on and off, since some time last year. I’ve just finished the second of the two, so it’s time for a book review. I’m considering them as a single book because they are both fairly small, and one continues right after the other; even the chapter numberings continue across the two books, and functions from the first book appear in the second one. I took a few months gap between the two books, but it’s probably better to continue straight on so the concepts from the first book are fresh in your mind.

The Little Schemer book cover The books use the programming language Scheme to teach certain interesting programming concepts. They’re not designed to actually teach you the language, although I’m sure the material covered will be useful when I do go on to learn Scheme from a more practical point of view. The first book, The Little Schemer, is all about learning to think recursively, while The Seasoned Schemer is more about functions, and also covers state and continuations. Continuations in particular were a new concept for me before I started the book. Continue reading →

Teams of Three

I’ve worked in a number of different software development teams, and some of the best have been when I’ve been part of a team of 3 people. In this post I discuss some of the features of such teams, what helps them work well, what can harm them and my subjective experiences of working on such teams. I can’t say categorically that 3 is the optimum team size. Clearly, the right size of team is going to depend on many things. But if you happen to be on a team of 3, or you work with one, this might be helpful.

Teams of 3 Are Self-Organising

A long time ago, in a book I’ve long since forgotten, there was a diagram about team size and the number of communication channels required to keep each member informed. It looked something like this:

As the number of team members goes up, the number of communication channels increases exponentially.

Continue reading →