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.
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.
I'm finally working through a few books by "famous authors who are influences on William Gibson". William Burroughs was a bit of a disaster. Ballard looked potentially tricky, so I went for one of his more conventional novels.
This book is not surreal, unlike much of his other work. In fact, it's rather more hyperreal than surreal. It's a ray-traced pile of chrome balls on a checkerboard versus the complexity of reality. A simplified model of the world to try an idea.
Cocaine Nights is ostensibly a whodunnit, set in the ex-pat community on the Costa del Sol. In reality, it's a musing on the nature of crime, and the environments of retirement communities. It makes me think of a generation-earlier version of Chuck Palahniuk - indeed there are thematic similarities to Fight Club.
For all that, it's a rather staid, repetitive novel. Perhaps this is a commentary on those timeless retirement communities where nothing changes. The crime involved has an airless quality, colour drained by the sun. Much of the repetition can be laid at the feet of the protagonist, who is fascinated by the underworld. It seems that it's this character's voice, rather than the author, who is bludgeoning the message home rather artlessly.
It's a funny book. Not quite the whodunnit it suggests, unsubtle in its motives and message but restrained in its detail. The writing is enjoyable and brings in a good sense of place. I feel I now need to read a bit more Ballard to separate out the novel from the author.
I've been holding off on reviewing this for a while. I thought What Got You Here Won't Get You There was a bit annoying. This is a whole different ball game.
Ricardo Semler is the owner of a reasonably large company (Semco). He inherited a reasonably successful company from his father, changed it massively and grew it. This book is about his management style.
His management style is, in his words, "democratic", and in the view of someone like me "anarchic". Well, it is a democracy, but rather more a direct democracy of everyone involved. Power is delegated, but there's also no centralisation of a wider strategic direction. There are good parts to this, in that people on the front line have control to make things work and do things right. There are bad things, such as when a firm that does environmental assessments got clobbered for breaking environmental laws - laws they knew they were breaking, but couldn't actually prioritise fixing.
This is perhaps the strength and weakness of the company's approach: It centres around managing by not managing - on any tricky issue which divides the company, the default action is to do nothing. I'll admit this is an often-effective and underused technique in most companies - most places feel they must make some action, and try to do too many things, and are ineffective at "wait and see". However, I think "do nothing" should be an active decision, rather than an incidental side-effect of a political log-jams.
It seems that the Semco empire is highly siloed. If every decision has to be made across the entire group affected, those groups can't grow too large. Everyone runs their own infrastructure. The global inefficiencies are weighed against local agility. It seems the business models they've chosen work like this, although I don't think this model can scale for everything. Having worked at both a siloed company and a company with large and effective horizontal projects, I now appreciate what effective strategic steering can do.
And at the top of it all is Ricardo Semler. He does rather go on a bit about how his job is very nice, and largely involves taking himself out of the loop and going off having a nice time around the world. I'm not quite sure what the message is, here. Being the capital owner of a large stake of a successful business is nice, perhaps?
I don't disagree with everything in the book. However, it takes things to extremes for reasons that are unfathomable to me. It's like a annoying, hyperbolic person arguing for something you believe in a way that makes you feel less convinced afterwards.
As for the book itself, it's quite tedious. Perhaps the book is a model of Semco? It's pointlessly long, rambling, doesn't particularly make any conclusions and for all that is apparently very successful in the marketplace.
More accurately, "What Didn't Stop You Getting Here Will Stop You Getting There". The core thesis of the book is that people limit their success by holding onto various destructive behaviours. As they've been successful in the past, they don't realise that these behaviours are a blocker on further progress, and may think they're part of their success.
There are 20-odd specific behaviours listed in the book, but they can be boiled down to "Don't be self-centred and arrogant". As people get more successful and rise up an organisation, they both need to get other people doing the work and learning new skills themselves. If they keep taking on the work themselves and shooting everyone else down, this doesn't happen. Leadership needs teamwork.
The other part of the book is about how to change. It's about gathering feedback and using it. This is where I really start to disagree with it, although the disagreement extends to the behaviours, too. Basically, the suggestion is "When someone says something to you, nod and smile and thank them and don't say anything". I disagree with this. Sure, when you have a senior role people take your opinion seriously, but gentle, positive and constructive feedback helps others grow, and if someone has some constructive feedback for you - well, you should engage with it. Not deny it, certainly, but at least dig in and truly understand what they're saying.
The higher you go, the more gently you need to steer and provide feedback, and perhaps this is really my main problem with the book. It's for executives - pretty much people trying to break through to being CEO of a large company, and being held back by their bad habits. Perhaps it's just a bit lost on me. Indeed, given it's a bestseller, I suspect more people have bought it than are actually in its true target market.
Burroughs is one of those authors that other authors keep refering to, so I thought I should go read some, and, well, this is his most famous book.
The issue I have is that Naked Lunch is uninteresting, unintelligible and unpleasant. If it weren't for all of those, I could probably cope. A not-nice subject is discussed in not-nice terms. However, those terms are also tied into the slang and culture of a distant decade. I'm sure I'd find modern junkie culture pretty much unintelligible too, but this is... rather worse.
And, at the end of it all, I don't really care. There are very few books I've given up on (I read all of Gravity's Rainbow, and I still have no idea why), but this is one.