On and off, I've tended to read quite a bit. So, I thought I'd put up some reviews of books as I read them. I am fully aware that they're really more about me than the books, so caveat lector. This page contains the most recent reads - if you want more, I recommend you go to the full index.
I went on my Level 1 RYA sailing course in April, and didn't get as much practice in as I'd have liked. On the other hand, I like reading up on the theory of things, the "Start Sailing" book was a bit shallow, and I wanted to fill the practice gap. So, I bought this book.
It covers single-handed and double-handed dinghies, at the level of recreational sailing, regatta sailing, and high-performance sailing. I wasn't sure what "regatta sailing" was, and the book never says so explicitly, but it appears to be "trying to sail fast without buying a fancy high-performance boat". As well as the time on the water, it covers rigging and launching. There weren't any topics I was surprised to find present, but it seems to cover most stuff.
Is it any good? I don't know, as I'm not very good! Dinghy sailing is one of those things where you need hands-on experience. Reading from a book is insufficient. There are lots of parts where, when I read it, it either just makes no particular sense to me, or I can pull out the meaning of the sentence, but it's just unrelated to sailing as I've done it at my level. Having said that, little bits are now falling into place as I've been learning on the water, and I can see the book being something that I can come back to as I get better.
While it doesn't really give me next steps in what to do and how to learn, it does still give me an idea of the more advanced skills I know nothing of at the moment - of spinnakers and trapezes, for example. Having said that, I very much doubt I'll ever get into high-performance sailing. :)
Books on practical skills are hard to do well, but it tries hard - there are copious photos and illustrations throughout the book to make things clearer, and they've pulled in some impressive-sounding sailors to demonstrate. Different boats do things a little differently, which makes the book a little trickier to make accessible, but it works around this by using a good number of different boats (even if it occasionally feels like an advert for RS!).
All in all, I think this falls into the category of "books I'd probably recommend, but I don't really know enough about the subject".
This is partly a follow-up to How Google Works by the same authors, and partly a paean to the late Bill Campbill. Well, really, it's mostly the latter. Mildly internally hyped at Google with a talk, I thought it interesting enough to buy a copy.
On the former subject, How Google Works mostly focused on the individuals - the "smart creatives". This book fills that out with discussions of teamwork. In particular, it glosses over/builds on Project Aristotle. However, rather than try to build on the research there, it really just tries to tie back Bill Campbell's intuitive approach to this, when they happen to match up.
Really, though, the book is about Bill Campbell. He was hugely influential across big chunks of Silicon Valley (in a kind of hidden power kind of way), and his main contribution at Google was to act as a team coach - he would coach the executives, but in such a way as to make them work as a team and be effective as a group - he would ensure that any inter-personal problems would not simmer.
I find it amusing that we have this high-tech organisation fully of really bright people, and there's this person who's all about the feelings and stuff, and being all Deanna Troi in Star Trek: The Next Generation, except it's an ex American football coach whose main techniques appear to be giving people bear hugs and telling them to pull their head out of their ass. I would love to see TNG redone with Troi replaced with Campbell.
Aaaanyway, it does sound like Bill Campbell was exceptionally gifted as a person who could make executives work together as a team and bring out the best in people. There are a few hundred executives for whom reminsicing about Bill is enough. For most of the readers, though, there's a question of "are there lessons to be learned here that can make me better at leading?", and it's really not clear to me.
Before his life at Google and generally coaching in Silicon Valley, he was CEO at Intuit, and before that an exec at Apple back in the early days (and before that, an American football coach). So, he had a deep background in tech coming from the sales and marketing angle. His coaching seems to have been coupled to his networking, so he had the power to make or break careers (did he identify talent or did his blessing create the success?).
What of the advice? There are general platitudes about treating people as people, supporting them, coaching, being there for them, practising radical candour, etc. There's also some pleasantly specific ideas sprinkled through - how to pair leaders to work on a problem to build up a leadership team, how to do peer feedback surveys, how to run effective 1-1s, etc.
Some other parts are more "Why we liked Bill", and don't say anything useful, or are contradictory. Bill apparently had no time for bullshitters, but at the same time had unwavering faith in Steve Jobs, for whom the phrase "reality distortion field" was created. Bill was very generous, but also very, very rich, which makes generousity a lot easier. Part of the book talks about trusting people and helping them grow, but then there was an example of letting someone go because, in an area that had been growing rapidly, they had demonstrated their ability and said they wanted more responsibility, and Bill's view was not to give it. Apparently it was a "team first" decision, but never really explained.
I think this is where the limits of the book lie, and it's a huge limitation - it's easy to talk about keeping positive and supporting people, but sometimes businesses fail, and sometimes people problems can't be solved with more trust. The book fails miserably to cover genuinely difficult cases with anything like nuance that would provide meaningful insight.
The book touches on Bill's belief in "operational excellence" from time to time - you can't just coach people and bring them together, you also actually have to Deliver Stuff and make the business happen. The trade-offs here aren't clear either. As Intuit CEO there was a quarter where it looked like they weren't going to make their numbers. The board were ok with this, as various things were going on which explained the situation. Bill drove to hit the numbers anyway - deeming this important operationally. What were the costs in human terms of this decision? Not discussed by this book.
This is, in other words, a cheerleading book that lacks substance. Rather ironic, given the subject matter is a person who, from what everyone says in the book, backed up his people skills with real leadership strength.
It's also not clear to me who this book is for. Or rather, it seems to me clear who it's for, and that's going to be a much smaller number of people than copies of the book that'll be sold. To give you an idea, it's got a section on how to run board meetings. It's pretty much written for C-suite execs of silicon valley companies, people who probably knew Bill in the first place.
This is the freebie book when you go on the RYA "Level 1 - Start Sailing" course. You can tell how far beyind I am on book reviews, since I went on the course on 13-14 April!
Let's ignore the book for a moment, and focus on the sailing. I'd last tried sailing something over 20 years ago, and never got on with it. Cold and wet wasn't my thing, and the physics of sailing towards the wind was not intuitive to me. Fast-forward, and I'm a lot better at ignoring discomfort and non-intuitive physics. I've got to an age where vague exercise in the outdoors where you're not thinking about computers or maths seems a good idea. Being in London, there's plenty of water nearby (including docks, as well as the Thames), so it's pretty convenient.
The book is pretty basic. Sailing, like many other sports and physical activities, is best learnt by tuition and practice. The book covers everything you learn in the course, but more as a reminder than teaching. It'd be foolish trying to sail on your own having only read the book, but it does provide value as it's very easy to forget bits of the course over time if you don't have a reference.
I believe you can buy this book separately from the course. Don't. It's useful if and only if you've been on the course. For those who've been on the course, it's pretty handy.
If anyone else had written this, perhaps it'd have been called "A Sociology of Music". This is David Byrne's multi-hundred-page treatise on how music fits into society - music as played vs. as listened to, venues, classical vs. pop music, the music business and much more. His eclectic background fills out his (quite personal) argument.
Overall, it's very thoughtful. I was never into Talking Heads at the time, but visiting it now, there's so much of interest there. Growing up, I only ever really saw self-assured, extrovert Rock or Pop Star, and retrospectively filling in the gaps with people like David Byrne is fascinating.
I'd bought it for my wife, who's more of a fan, and she dipped in and out of it, while I'm much more of an end-to-end reader. It's a chunky, well-designed and pleasant-to-read book. I don't think it's made me fundamentally rethink music (or rather, how it fits into society), but it's certainly made me think more about it.
You have to be of a certain age to remember Johnny Ball, a kids TV presenter from the late '70s and '80s. He did popular education shows on... maths! Yep, kids TV did maths, without being dull. Amazing. I received this book some time in the earlyish '80s, and must admit I never read it properly.
My son's now inherited it and given it rather more attention than I did at the time. Re-reading it now, it's pretty awesome. There's a whole pile of dumb maths jokes, tricks, etc. For example, it teaches you how to know the day of the week any date falls on. It covers some real maths stuff, too. For example, it covers the platonic solids - complete with how to construct pop-up versions, find all the possible nets to make them etc. It mentions simple versions of the Brouwer fixed point theorem in passing. That kind of thing. It's surprisngly good, and I'm sad I never appreciated it at the time.
But then I'm glad my son's reading it. :)
According to the receipt, I bought this on February 4 last year! I got it the last time I was in Seattle, so I could identify the various birds I was seeing while out there (as they were mostly completely different from what I'd seen at home!). This means I've been doing my limited dabbling in birdwatching for well over a year now. Time flies, I guess! I'm still not terribly good at it.
This is a pretty simple field guide. Nice and pocket-sized, with each bird covered on two facing pages - one big colourful photo, and then a list of facts and notes. There's always the question of how to organise such a book. Here, they've gone for organised by primary colour, and then by size. Mostly this is pretty intuitive, although there are some birds where you have to decide what the primary colour really is. Oh, and sometimes the same bird occurs on a couple of pages because the male and female are distinct colours. In any case, the structure works well.
Why did it take me a year to read? Well, it's a reference and not really compulsive reading. However, I plodded through it because it's kinda fascinating to see the variety of birds that exist several thousand miles away - for the most part they're very different, with a few world-wide classics chucked in. As usual, I can't vouch for the factual accuracy, but it did help me identify those species I did see, as well telling me about a hundred other species I didn't!
Sounds like a New Year's Resolution thing, doesn't it? It's older than that, honest. :) Several months ago I finally made good on my plans to use the work gym. Waaaay back when I was finishing off my thesis I used to do 6 hours of judo a week and rather enjoyed being healthy. Then I got a job, moved to London, and... stopped. So, I thought I'd get back into some kind of exercise. I'd not kept up with Stuff, but apparently just doing strength training is a reasonable option nowadays - there seems to be much less emphasis on endless hours of cardio now, which is more than fine by me...
I had no idea what I was doing, and joined a few of the classes at work in order to learn how it's done, but booking up limited slots was a bit annoying. I wanted to just pop in at other times, and decided I wanted to learn a bit more, and as always needed a book. As part of the whole feedback effect, I bought this book because it was popular, thus making it more popular. :)
The book suggests just doing the training at home - that gyms are hassle and distracting and you only need a few bits and pieces that you can store at home. And... I've tried that, and it's just so much more convenient than the work gym. Less faff, no other people looking like they know what they're doing, and no waiting for equipment (even if the equipment is way better than what I've got. :).
However, I should probably write a little about the book. I like it. The fundamental thesis is "do dumbbell excercises at home". Back when I was doing judo at uni, I used the college gym a bit, which had lots of weights machines. Switching to free weights is a strange because you have to keep the weights under control rather than just push/pull hard, but I see their point of how it's better to actually have some control, so that's nice.
The book is divided into three sections - effectively "how to exercise", a large number of exercises arranged by body part, and then a few suggested programmes. The exercise descriptions are good, with lots of tips and nice anatomy diagrams of what's going on. I thought it'd be a bit overkill to have so many exercises described, given you might only want a few, but it seems in practice having a good selection of exercises and variations can help to both find something that works better for you, and staves off boredom.
I'm not totally convinced everything in the book is grounded in science, but the authors have a bunch of experience and I've found it really helpful to get started. As always, I'm nervous about recommending a book in an area I know little about, but I think it's worth a look if you want to try strength training.
I recently saw the Videogames exhibition at the V&A, and I saw this in the shop, and... eventually decided to get it. Caroline bought Death by Video Game by Simon Parkin, which despite the title appears to be pretty good and is referenced by this book.
This is a pretty lightweight book - it's all of 120 pages long, with lots of pictures. However, it's just the right level for me - it names a few really big-name indie games that I readily recognise, talks about a bunch of others I've heard of, and told me about some more I didn't know about. It's fun and pretty and hardback, but not really worth its price.
I think one of the best things from reading this was finding a reference to Indie Game: The Movie, which I then watched. Writing indie games had kinda looked fun. The film very much dispelled this illusion - the multi-year soul-crushing slogs were eye-opening. So, that film at least is recommended!
John Ousterhout is a Stanford CS professor, and has done many things, including having his name on the Raft paper. On the other hand, the thing he's most well-known for is Tcl, so maybe I'm not totally convinced of his philosophy. :) However, I'm interested to hear what he says.
The book is small - both A5ish, and only 170 or so pages of content. Surprisingly it seems to be Amazon print-on-demand - perhaps he's expecting most people to take the e-book? It talks about good design, and it repeats much standard wisdom. The main thing it brings to the conversation, though, is the concept of "deep" modules - modules with simple interfaces and complicated internals, that make powerful abstractions.
This sounds very straightforward - for example a sorted map structure that hides a balanced tree implementation fits this well. Ousterhout is also willing to name and shame examples of bad interfaces - pointing out that to deserialise a Java object you need to construct and chain a FileInputStream, BufferedInputStream and ObjectInputStream. And Unix is given as a good example, with open, read, write, lseek and close forming most of the interface.
However, I think there needs to be more subtlety. Sometimes you need the control - Unix's interface gets into a messy pile of ioctls and fnctls to handle all the other cases, and TCP/IP's simple abstraction through the socket interface doesn't help you when the abstraction leaks and you need to debug production. Simple interfaces need escape hatches for advanced users.
The Java file I/O situation is interesting, because it provides the escape hatch by default - you get all the grubby details and can build a stack of Streams as you like - but it's almost certainly the wrong interface by default. However, it's still an attractive design for the implementation, separating out concerns. Some factory methods can build the useful default stacks, and you could break out individual constructors if you need something non-standard, but this wasn't discussed.
The idea of deep modules is to give you a lot of functionality without having to put much in your head. This is almost the exact opposite of various Haskell combinator libraries, where you get dozens of combinators that each do very little, and you know what's inside them, yet you're still expected to assemble them together. I think the idea behind these combinator libraries is to change the way you think and work, without constraining the functionality you build. In contrast, Ousterhout's deep modules don't tell you how to approach coding, but have strong opinions on the functionality they expose to you.
Deep modules make me think of hi-fi separates - big chunks of functionality with clear and simple interfaces that you can plug together without needing to know the details. Haskell combinators are like individual components.
Both in my current role as a Site Reliability Engineer, and indeed on the edge of my previous software engineering roles, things have got most interesting when abstractions leak. One could claim that good modules don't leak their abstractions. I think this is not the case - especially for the kind of modules that this book proposes, that try to make life as easy as possible for the user, encapsulate more, and thus have more that can leak when reality strikes. This book doesn't talk about leaky abstractions, and how to leak safely and effectively, which I think is a shame, as that's where things get really interesting.
The chapter on comments is quite refreshing, since not only does it do the usual "What/why, not how" spiel, but it also gives some real-world examples and they're way more verbose than I'd normally expect. I read them and... understand what the intention is. When I've looked at random pieces of open source code, this has not been the case, and I've felt that maybe I'm dumb. The book makes me feel vindicated. :)
The chapter on naming conventions is also interesting. In particular, it talks about a bug where the same variable name, "block", was used repeatedly to reference file and disk block ids, and a horrific bug that resulted when this lead to one value being used in the other context. The book suggests using "fileBlock" and "diskBlock" instead. I find this fascinating because at this point I'm just jumping up and down shouting "Type systems! Different types would prevent this!", and I assume this is just a generational thing, and there are just a bunch of super-senior engineers who are never going to get type systems until they retire! :)
Overall, though, I like this book. Having come at the world from a slightly different angle, there are bits I disagree with, but there are large swathes I really like, backed up by a solid career designing many systems, and teaching software design. On the whole, recommended.
As you may have noticed, I'm trying to get the hang of bird-watching. My wife bought this for me as a present. It's a book on birds from 1979, of the "with some colour plates" school. It's fascinating, partly as a record of the time. It's an astonishingly pre-internet book, from a time when knowledge and connections were hard-won - it's really rather informative, and has a bibliography and list of societies you can join etc. The author is clearly an expert, not just someone who fancied writing a book and had dabbled in the field!
The structure of the book is strangely "birds in time and space" - after an introduction talking about birds, how to observe them, equipment, etc., there's a long chapter on half a dozen or so really good places to spot birds, followed by a chapter on month-by-month spotting. Being pre-internet, the locations include instructions on how to get there, since you can't just look it up on Maps.
As well as being a time capsule on the subject of amateur science in the '70s, it has plenty of interesting content on birds. Lots of detail. Indeed, it's kind of depressing. As someone who's just starting out and recognises about ten kinds of bird, reading about someone who's spotted over 300 species in Britain, over several decades, and understands all the minutiae of their behaviour... the depth to the field is astonishing. I think I'll remain a happy beginner.
I mostly try not to review books before I've finished reading them, but I'll make an exception in this case as I feel I've read a fair amount and can reasonably comments.
This book is something of a classic, and I must have bought it something like 20 years ago. At which point it basically sat on my shelf. (<checks> Oh, yes, it's got the Johnian crest on it, so I got it with my undergrad book grant!)
It really doesn't look like it should be read end-to-end. Each chapter is pretty self-contained and deals with solving different problems. So, I've been dipping in and reading whatever chapters look fun at the time. It's also not a book you're going to fully understand by reading lightly. However, I'm mostly interested in a survey of numerical techniques, so I'm reading lightly and shrugging at the fact I don't get all the subtle details. If I ever really need to get into the subtleties, I can always re-read!
My impression at the time I bought it was that this was the Monster Fun Manual of Numerical Algorithms. Reading it now, it reminds me of Knuth. Numerical Algorithms are a huge subject, and this book alone, as an overview, can't do it justice. Each subject is an overview, some hints and tips, maybe some results without proof, a chunk of implementing code and a bunch of references to more in-depth texts. In reality, the minimal introduction to numerical algorithms is about 2 feet of textbooks. Even then, we'll probably have Knuth Disease, and you'll end up with textbooks that represent the state of the art 20 years ago, and everything should be superseded by research papers, if you can find the right ones.
One of the great things about the book, the thing that sets it apart for me from similar books, is not the included code, but the hard-won experience. The part that says "Algorithm A is, in theory, better, but in practice Algorithm B is a lot simpler, more stable, and generally does the job really well". I wonder how well that part dates?
One of the other things this book reminds me is that not all code is self-explanatory. I must say, I hate the style of the code in the book - it's very, er, scientist code. You can almost taste the Fortran. However, when I look at the code, I see no way it could be written to make it self-explanatory. If you received the code without comments and without vast numerical knowledge, there's no way you'd work out what the code is supposed to do! This is very different from the kind of code I'm used to working on, and I think it's useful to remind myself that not every algorithm can be made intuitive or transparent (*).
((*) Or maybe it can. But that's beyond my abilities!)
In short, I have no idea whether the contents of this book are a good idea of real-world practitioners. Maybe it's a good starting point to build the base knowledge on which to get the latest and greatest from the internet. However, I'm not deep into this stuff, but it's interesting. It's still a great start for people like me, who don't really care if their knowledge in this area is 20 years out of date. :)
Time to catch up on some books I read a while ago!
Men Explain Things to Me is a short book of feminist essays. Or put another way, a bunch of notes on how men make life crap for women. Which is to undersell it, because Solnit is clearly incredible bright and incisive, and these essays are a lot more than just that.
It's another one of the recommendations from one of work's book clubs. In places it's fun. It's not preachy. It just talks about stuff. As a man, I really don't feel qualified to judge it or deeply analyse it. I just read it and remind myself to try to be a better human.
This was a birthday present to me, a book on the subject of video games design. Previously, I'd read A Theory of Fun for Game Design by Raph Koster, which was definitely a lot more theory than fun. This book is... the opposite.
It's a really concrete and practical book on game design. There are chapters on level design and characters and cutscenes etc. - all very practical and down-to-earth. Some of the things are pretty obvious patterns if you play a bunch of games and think about how they work, but the presentation is fun (and highly illustrated :) and thorough.
I don't intend to make video games (beyond the occasional foray into Pico-8 with my children), but sometimes it's interesting to read up on how to do things you don't intend to do. And, to be fair, my son loves it when he gets the chance to read it. I expect to find it dog-eared under his bed in a couple of weeks.
Grand summary - is it worth reading? I'd say so. Lot's of fun, not particularly hard work, and enjoyable and interesting.
Apparently I bought this at least 7 years ago, as I bought it along with The Prize (a doorstep about the history of the oil industry) and Lolita. These were all at the recommendation of a colleague, and I think it says something that I managed to get through the doorstep quite quickly, but took until now to finish this. I never got through Lolita.
Ignore the first half of the book, with run-of-the-mill logic/paradox puzzles. The second half is a fantastic introduction to combinatory logic, under the guise of puzzles about birds!
I'd stalled in a couple of previous attempts, when the trickier puzzles and subtleties unaddressed by the text started to pile up. This time around, I just wrote myself a solver to bypass the more tedious pencil-work, and pushed through the theoretical questions - which were often answered later in the book!
My workings are on github, along with some more in-depth thoughts on the book. The summary, though, is that this book is worth it if you're a fan of theoretical computer science, but not a hardcore expert.
Keith Devlin wrote one of my favourite maths books, so I was interested to see how he approached this subject. The Millennium problems are seven problems with a million dollar prize offered by the Clay Foundation. The level of difficulty in explaining them... varies significantly.
The early chapters deal with e.g. The Riemann hypothesis and P = NP, and it ends up with the Hodge conjecture. It's the usual kind of pop maths start-at-GCSE-level explanation. So, you'll be reintroduced to complex numbers yet again. By the time you get to the Hodge conjecture, which is genuinely difficult to explain, they've basically given up.
So, I'm at a bit of a loss with the book. It was effective at explaining easy things I understood, and not effective at explaining the things I didn't. After "Mathematics: The New Golden Age", it was a bit of a disappointment. Ah well.
I read "Why Buildings Fall Down" by the same author a decade ago. This is actually the better book!
It's the engineering of buildings, as described by an architect. The architect in question is actually pretty snooty about structural engineers, perhaps to counter for the fact that they're spending so much time talking about structural engineering questions. The book describes engineering principles, illustrated by famous buildings (such as the Eiffel tower and Brooklyn Bridge). Quite frankly, I found that fascinating.
It's also a book of its time. Written in 1980, it's surprising to see quite how much things have changed. You can see what the trendy things of the day were. Apparently the future of architecture was going to be plastic. And maybe inflated domes.
So between the retro-ness and the architect's need to be an insightful polymath (there's a chapter on the semiotics of structure!), there's a lot of amusement. Combined with learning all about construction materials, and how buildings carry static and dynamic loads... it's actually something of an awesome book. Better than the sequel. :)
I want to get better at public speaking. I'm taking a couple of approaches. One is to join Toastmasters, which is a freakily American public speaking club, to get the practice in (there's a branch at work). The other is to read up and get some theory.
My boss at the time recommended a video of a talk by Cara Hale Alter, I watched it, and I bought the book. The book's all about how to present in such a way that you achieve, well, credibility. So, it covers standard "how to present" skills, but with an emphasis on those things that make you clear and authoritative. Quite a lot of "stand up straight and speak clearly", to be honest. It's a short book, and not terribly dense.
On the other hand, it does the job - the advice provides nicely concrete things to work on. Videoing yourself is the core to the book's way of improving yourself, and I've been doing that. Learning how I look when presenting is both painfully unpleasant and very useful for learning with!
A younger version of me would be very wary of faking-'til-you-make-it authoritativeness in this way. Current me is happy enough that I'm not much worse at making it up as I go along compared to everyone else, and that my audience deserves to get my ideas explained clearly and in a non-distracting way. I'd happily send my younger self a copy of this book.
Another book from work's book club.
This book is a letter from black American journalist Ta-Nehisi Coates to his son. It talks about his life and the injustice of America to black people. It does so viscerally - makes it clear that in the end, it's about violence, about permanent fear that the police will kill you with impunity.
It's a journey through Coates's life, powerfully told. It covers the events of his life, and his struggle to come up with a coherent philosophy. It made me think about things from a different angle. He highlights how strange it is that America builds up MLK as a hero so much, sets up as role models people who are beaten and killed rather than fight back against violence with violence. How convenient this kind of message is to those in positions of privilege!
It's not a terribly hopeful book. It doesn't give up, it wants to fight on, but victory is not near.
Another pocket book on birds, and a Christmas present to boot. Compared to the Dorling Kindersley book I bought previously, it's smaller and thicker, and does a bird-a-page approach, roughly organised by some grouping of birds I don't really understand. It's pretty comprehensive, or at least I know there are a bunch of birds I'm never going to see in here. Is it any good? What do I know? I'm no expert. :) I like it, though.
This book was featured in my workplace's bias-busting book group, and deals with talking about race. It (unsurprisingly) is American-centric, but interesting nonetheless in how to talk about a difficult subject.
The main idea is that race is the elephant in the room that many white Americans fear to discuss. The primary approach is "color-blindness" - by trying hard to ignore race, the problem goes away. Unfortunately, the problem hasn't gone away, and claims that you can't see race make those problems impossible to discuss.
Part of this is that being white is a race, is a culture. If you're white, it doesn't mean you have no race, it means you are in the socially-dominanting race, and are seeing the world through a lens that is sufficiently predominant you don't know it's there. Acknowledging that you are white is fine as long as you can build up a racial identity that contains understanding of history and privelege, is not ignorant of other races, and actively helps people in disadvantaged minorities - as there are so many structural disasdvantages (let alone overt racists!), doing nothing (or being neutral/"color blind") is insufficient.
Unsurprisingly for a book on "race talk", it also discusses how to talk about race. The key point I'm taking away is that experience of race is subjective - as you can't live in someone else's skin, you should believe their experiences and acknowledge their emotions, and by approaching it that way you can learn to understand the world through others' eyes.
This is all, of course, a dramatic over-simplification of a whole book. There's plenty of subtlety and detail.
Indeed, the book's got a fairly academic tone, and is hard work, consisting of pretty dry, slow material. And the human interest examples are generally of people having a bad time due to their race, or having bad and dispiriting discussions about race. Furthermore, the title of the book makes it sound like it's either neo-fascism or incredibly right-on, which means I didn't dare to read it in public for fear of worrying people and/or drawing out the loonies. All of which meant I read this book incredibly slowly, and I think this has really slowed down my overall reading rate, with a big queue of books building up after it.
I learnt less from the book than I had hoped (especially considering the material's US-centricism), but it was interesting nonetheless. Would I recommend it? Not really, unless you're a masochist, or have particularly strong needs or interests in the area.
A pocket-sized Dorling Kindersley book in association with the RSPB, it's subtitled "The simplest ID guide ever", which gives you an idea of the level we're talking about. Lots of nice, colourful pictures.
Whyyyyy? Birds are these things I've never understood. I see birds fly around, but they're just birds, like trees are trees, and rocks are rocks. Caroline knows all about birds, and would occasionally say "That's an X", and I'd nod and know nothing. I thought I'd change that, and learn a little, and this is my starting point.
For that purpose, as a really basic introduction, it's great. It still leaves me wanting to know more, and it's not a huge amount more than nice, big, bright pictures (unlike the actual birds which are small and far away and generally difficult to identify - bah!), but that's still a great introduction. Did I mention the book was on special offer and really cheap?
Also, it's a convenient size. I carry it in my work bag, just in case I see something unusual on my commute (for me, almost anything is unusual, and seeing a jay was really cool).
So, I like it.
I visited Boston with work, and while I was there I took a look around MIT and Harvard. I picked this up at the MIT Museum (which is well worth visiting!). It is a book about MIT "hacks", which are generally clever re-decorations of part of the campus. The hacks are a combination of demonstrating engineering aptitude, subversion, and effectively student ownership of the campus environment. They're unofficial creativity, and I find it fascinating how books like this show the university is well in control of its own mythos. Oh, and the hacks are quite fun! A nice souvenir.
Oh my, it's been far too long since I put up a book review. And so few books I've read. Work is... keeping me busy. And I'm slowly plodding through a book that I'm not finding terribly engaging, which has slowed me down somewhat.
While reading that book, I've read this book. It's a couple of short stories, both the book versions of films. They're perfectly fine to read, I guess. The film of The Third Man is, er, extremely well regarded. The book is... fine.
It's a nice, quick read. I enjoy Greene, and they're pleasant enough, not much more.
I haven't read any Austen in ages, so when my wife re-read Emma it seemed a good opportunity for me to read it at the same time. It's good. It's long. It's annoyingly long, because it's also good, so you can't properly begrudge the excessive length.
Emma herself is a great heroine, because she's basically silly and annoying, but not excessively so, and works out her flaws over the course of the book. Embarassingly, having watched Clueless before reading Emma gave me a much better understanding of Miss Woodhouse's character - the parallels are excellent.
As I said, it's good. I can't really judge it much better than that, as right now I have a sore throat and am really irritable. Some of the sentences test the limits of my comprehension in this fuzz, but it's still an enjoyable read.
I've been meaning to read this book for some time now, and having got sufficiently nostalgic about Haskell, I finally did. "Real World Haskell" is apparently one of those oxymorons, like "ML for the Working Programmer", but I don't care. I still like Haskell.
This is not a short book. There's about 600 pages of proper content. It took a decent number of commutes for me to read (don't worry, I take public transport :p ).
I was intrigued as to how much theory they'd use, and how they would introduce the more algebraic structures. I feel the start of the book is pretty darn good, building up slowly, so that when you hit monads, around page 300, you've already seen the pattern a few time, and then you get the general version of it.
The code examples didn't convince me in a few cases - I was suspicious of some of the corner cases, and the barcode recognition code just seemed messy to me. Still, they helped move things along.
Once monads are introduced, a few extra topics like monad transformers and error handling are presented. I'd never really played with "ap" before, or studied MonadPlus, so I got to learn some new tricks, as well as seeing various style points written down that I'd only previously inferred. This was pretty much the high point of the book.
Then, from around page 450, the "real world" kicks in. Various programs introducing real-world interaction are given, and sadly this is pretty dull. Databases, web clients, GUIs, meh. Why do all books with network programming examples always have to re-explain TCP vs. UDP? There are some cool bits mixed in. "Concurrent and Multicore Programming" is pretty interesting, as is "Profiling and Optimisation". The book ends on a reasonably fun note with "Software Transactional Memory".
A few of my pet favourite subjects were missing - for example, no untied data types. Mutable arrays are hidden carefully in the Bloom Filter example chapter, without a sensible index entry. Indeed, many of the chapters feel ordered arbitrarily, sometimes using functions which are only described chapters later. There's no category theory, which I think is a good thing for a book like this.
Then there's the errata. I felt the start of the book was pretty good. By about halfway, I think everyone was tired out. I started spotting sufficiently many bugs that I started reading the book with the errata web page open. "Yep, thought that was a mistake."
A six-hundred-plus page book is a massive undertaking, especially if you're trying to produce nice code examples and cover a bunch of platforms, and write things to only use the features you've described so far. I'm still a bit disappointed. I must admit, there's a good book on Haskell in there somewhere, covered in a layer of errors and flab. Is it good? I don't begrudge the time I spent reading it, but I wish it had a little more confidence and didn't have to spend quite so much time and space justifying its "real world" nature.