I finished up Rocannon’s World, which was pretty fun. I’m afraid it wasn’t Le Guin’s best book, but it seems to have been her first. It was a Hero’s Journey straight from the Book, which isn’t necessarily a bad thing.
In a bit of an aberration from my current reading practice, I took up the non-fiction book How Big Things Get Done by Flyvbjerg and Gardner. This one is a bit of an unrepentant corporate self-help book with possibly sensationalised conclusions, but there are some useful ideas in here. I’m deeply worried about the potential of my new project to fail, and I wanted to get a bit of expert wisdom on how I can set the project up to avoid known pitfalls. One of the biggest lessons I’ve taken so far is to plan slow and build fast; in the past, I’ve never really planned at all, and I think that this might be apparent from the “research quality” of the software I’ve built.
I grew up as a programmer in the startup world, where planning is really frowned upon. Planning was identified with the “waterfall method” (which is, by the way, not as bad as people say). Instead, we taught each other to build first, test, confront problems, fix them, and then keep building. This is a really good way to build something very unwieldy and difficult to evolve (…like Forester). This time I am thinking carefully about the key components of the system, what is needed to make them work, and how to conceive of them modularly enough that they can be combined together. My Pterodactyl blog is a trace of this planning process… Some parts of the system, I have spent the last ten years learning how to build. Other parts, I need to learn from scratch.