Blog



All timestamps are based on your local time of:

[ « Newer ][ View: List | Cloud | Calendar | Latest comments | Photo albums ][ Older » ]

Collapse2013-08-09 21:13:16

Following up to Guns, Germs, and Steel and The World Until Yesterday, I also read Collapse: How Societies Choose to Fail or Succeed by Jared Diamond. This one was a lot harder to read, and much less interesting to me. There were certainly some good lessons here, but I felt like he repeated himself too much, and that the book could have been 30% of the size it actually was.

It was interesting learn about how some past societies (e.g. on Easter Island) behaved and why they eventually died out. It does feel a bit like the world on a whole is on a course to repeat those mistakes.

[ 0 Comments... ]

The Inner Game of Tennis2013-05-12 16:07:18

The Inner Game of Tennis, by Tim Gallwey, despite the title, is not really about tennis. Well, maybe about 3% of the book is actually about tennis, but for the rest of the book he only uses tennis as a concrete example of how to apply the principles of the "inner game" described in the book. The "inner game" here refers to a number of things, but generally speaking covers the ability to unlock your full potential without being held back by your fears, doubts, anxieties, and other insecurities.

Although the book is not really specific to tennis, it is geared towards people who have tried to excel at some physical discipline. It describes the mental obstacles that such people will be able to identify with, and describes in good detail how to overcome those obstacles. That being said, the book does also apply to non-physical activities and daily life, but if those are your primary interests then perhaps one of the other Inner Game books by the same author will be more suitable (I haven't read them so I can't comment further).

Personally I read this book because I thought it would help me with the mental obstacles I encounter while training parkour. It certainly does address exactly the problems I've experienced, but goes above and beyond that. I found the book hugely insightful and would recommend it to anybody who practices a physical discipline (and if you don't, you should). I haven't yet actually tried applying the techniques described in the book so I can't say how effective they are, but even if they are completely useless to me the book was still well worth it for the additional insights it provided.

[ 0 Comments... ]

The World Until Yesterday2013-03-24 20:10:46

Yet another book review: The World Until Yesterday, also by Jared Diamond (author of Guns, Germs and Steel which I reviewed previously). Personally I found this book even better than GGS because it provides more practical knowledge about small-scale societies and specific things that they do better than we do in our large-scale societies (as well as things they do worse). As he keeps saying, the history of the world is filled with natural experiments - different societies tried different things; some failed and some succeeded, and we should try to combine the best attributes of these societies into our own. In some cases adopting changes is hard because it requires large changes to how our society is structured, but there are lots of cases where we can adopt the changes on an individual basis as well.

The book covers different aspects of societies in different chapters - personally I found some chapters (e.g. the ones on food and raising children) more interesting than others (e.g. the ones on wars and peace). However I'm glad I struggled through the early uninteresting chapters as they do provide some useful context for the more interesting chapters later. Overall I found this to a very well-balanced book, and just like GGS, gives me a larger perspective on how the world works, which is really cool.

[ 0 Comments... ]

The Power of Introverts2013-02-10 19:18:55

I recently finished reading Quiet: The Power of Introverts in a World That Can't Stop Talking by Susan Cain, recommended to me by my girlfriend. We're both introverts and, as a result, often have to deal with some friction in the extrovert-centric society we live in. I've mostly made my peace with this, and to be honest, didn't think the book would be particularly useful. However, I underestimated the amount of insight and value that comes from thinking about and researching a topic for many years, as Susan Cain has done here. The book is most definitely a worthwhile read.

The book goes into some depth about research that has been done about the biological and psychological differences between introverts and extroverts. According to the book, somewhere between 20 and 50 percent of humans are introverts (although of course introversion is more of a gradient than a sharp distinction), and so the chances are good that you deal with both kinds of people on a regular basis. Dealing with them effectively, and in particular harnessing their productivity (e.g. at work) requires understanding what makes them tick and what turns them off. The book covers this really well and has plenty of advice for both introverts and extroverts.

The proportion of introversion is higher in disciplines like software engineering just because the nature of the task involves long periods of focus and concentration and some degree of "living inside your head". Speaking from personal experience, I know that many of the Mozillians I interact with daily are introverted to a significant degree, although of course there are many who are not as well.

Culturally, Mozilla provides a lot of freedom for contributors to shape their own environment and work in the way that suits them best. However, there are still times when an extroverted streak comes into play. Work weeks, for example, are usually a source of many extrovert-centric activities. The book has some useful advice on strategies for introverts to make the most of, and recover from, such situations.

Susan Cain also discusses some of the larger effects of western society's bias towards extroversion. For example, schools are increasingly designed to reward extroversion at the expense of the introverted schoolchildren who have just as much (or more) potential and talent. I found the discussion of that topic to also be pretty interesting and I suspect it might be one of the reasons that online learning solutions like the Khan Academy are becoming so popular.

Overall it's a pretty good book and I would it recommend it to anybody.

[ 0 Comments... ]

Guns, Germs, and Steel2012-12-15 00:56:17

Another book review: Guns, Germs and Steel, by Jared Diamond. I found this book really interesting although the subject matter may not appeal to everybody. It basically covers the history of the human race over the last 13,000 years (since the beginning of agriculture) and explains why certain cultures and societies are the "dominant" ones in the world today. When I started reading the book I had my doubts that any one book could successfully explain this, but I came away pretty convinced. Also, it won the Pultzer Prize in 1998, if that sort of thing appeals to you.

One thing I really liked about the book is that Diamond tries really hard to be as scientific as possible in his theories and explanations by citing natural experiments as evidence. The sheer volume of field experience and historical knowledge that he brings to bear on the question is pretty impressive.

The other thing that I found cool about the book is that it reminded me of Hari Seldon and psychohistory from Isaac Asimov's Foundation universe. It seems very much like if you took the explanatory power and analysis in GGS and applied it to the state of the world today, you'd end up being able to predict the future in the same broad strokes that psychohistorians were able to do in Foundation. Of course, that's not actually true because it's a lot easier to see what factors were important in the past than it is to guess what factors will be important in the future, but it still makes me wonder.

[ 0 Comments... ]

The Omnivore's Dilemma2012-11-28 18:50:27

A book that I read recently is The Omnivore's Dilemma, by Michael Pollan. For uninteresting reasons I actually ended up reading both the Young Reader's edition and the regular edition. I highly recommend the Young Reader's edition, and only moderately recommend the regular edition.

The book traces 4 different meals back to their ingredient components. Doing so provides a pretty good picture of what the food industry is like (at least in North America), and was quite eye-opening. This is one of those books that has no real pre-requisites to fully understand, and almost certainly has something new for everybody. More importantly, it doesn't try to change your mind about anything - the author describes what he found, as well as his own feelings and thoughts on the topics; what you choose to do with the information is entirely up to you.

The reason I recommend the Young Reader's edition over the regular edition is simply that it's got 90% of the content in about 60% of the words. The regular edition has a lot of the author waxing philosophical and/or poetic and those bits weren't really that interesting to me. There were also some additional tidbits of information here and there but not enough to be worth it for the average reader.

[ 0 Comments... ]

Pragmatic Programmer2012-07-08 18:19:20

I finished reading The Pragmatic Programmer: From Journeyman to Master. I had pretty high hopes going into it since it seems to always appear on must-read lists, but in the end I was a little disappointed. I agreed with all of the content, but there was nothing really insightful in the book for me. It seemed to me like anybody who would actually bother to pick up and read the book would already know that stuff from experience. It might be more useful as a text for somebody in school who hasn't had much actual experience yet. Also, the book covered a rather broad spectrum of topics but didn't go into a lot of depth for most of them; I would have preferred a more detailed coverage of the topics since that would be more likely to provide me with new insights.

However, after reading the section on digging for requirements, I did dig out the SRS document my group produced for our SE 463 course back in 2005 and skimmed it, just to see if it made any sense in hindsight. I think for a requirements document it was hugely overspecified and really not very useful. If I were to take that document and try to implement the system it described I think I would have a very hard time because of all the different descriptions of things which sometimes contradict each other. Then again I think we pretty much knew that when we wrote the document in the first place.

[ 1 Comment... ]

The design of design, part 32011-01-04 22:26:34

A few final notes on The Design of Design. In Chapter 10, Brooks talks about the "budgeted resource" (i.e. the resource that is the most constrained) when designing something. One of the things he mentions here is the use of "surrogates" - something is used as an approximation for the actual budgeted resource, since the actual budgeted resource is hard to measure. This is basically the same thing I called an "indicator" in an earlier post; he says the same thing I said, but I like the way he says it better. I also like the word "surrogate" more than "indicator", since the connotations are more in line with the idea it expresses.

In Chapter 11, on constraints, he talks about how adding constraints can help narrow the scope of the project and make it easier to come up with a good design. He specifically cites programming language design as an example - a special-purpose language is easier to design well compared to a general-purpose language. This reminded me of an article on language-oriented programming that I read a while ago. The article claims that LOP allows the programmer more freedom of expression, which makes sense. Since LOP allows the programmer to more losslessly express their mental model, it allows for a better design and implementation. (This ties into yesterday's post on mental models).

Another interesting point in the book is in Chapter 15, where he talks about how disciplines have become increasingly specialized, resulting in a greater separation between design, implementation, and use. As an example, he cites how Henry Ford built his own car, but today no computer engineer can physically make his own chips. I think this same thing happens on a smaller scale for individual products as well. When I first worked at RIM as a co-op in 2003, all the employees had a BlackBerry, and used the devices extensively. The designers and implementers were also users, and the process of dogfooding was one of the reasons the devices worked so well.

Today, all the employees still have and use their devices, but something has changed. Specifically, the user market RIM is targeting is no longer the same, and so the employees are no longer representative of the user population. Dogfooding now still helps, but not nearly as much as it used to, since the features the users care about the most are not necessarily the features that get exercised the most internally. This has practical, noticeable consequences. Since RIM's development culture grew up on the concept of using dogfooding to ensure quality, they didn't develop a strong culture for other forms of quality control, such as automated testing. This has resulted in a gradual decline in overall device quality, something that a lot of people have been complaining about lately. The good news is that it's not hard to fix - they just have to stop relying as much on dogfooding and work on other more robust methods of quality control (which is something they're working on).

In general, I think this is a problem for most software projects that follow the Bazaar model of software development. The first guideline put forward by Raymond in his essay is that "every good work of software starts by scratching a developer's personal itch". I don't know if that's always true, but I think that as any such software grows, it will reach a point where it has features not really used by the developer. This also results in a "progressive divorce of the designer from ... the user", as Brooks puts it. Therefore projects that grow past this point have to face the same issues of miscommunication that Brooks talks about in this section.

In Chapter 16, Brooks mentions in passing that "complete modularity also has drawbacks ... optimized designs have components that achieve multiple goals." It occurred to me when reading this that there is a distinction between modular goals and modular components. A component that satisfies multiple goals is good, but a goal that is satisfied by multiple components is bad. He seems to define "complete modularity" as a one-to-one mapping between a goal and a component, whereas I would just leave it at components that don't interact with each other. I might just be a semantic definition issue, but it's something to think more about.

Anyway, that's all I have. It's a pretty thought-provoking book, and full of lots of good advice and insight, so if you're interested in designing stuff, I definitely recommend reading it.

[ 0 Comments... ]

The design of design, part 22011-01-04 01:15:14

This post is about conceptual integrity and mental models. I've mentioned this topic before, but in the years since I've come to appreciate much more just how important it is. Brooks talks about conceptual integrity in Chapter 6 of The Design of Design, in the context of collaboration and teamwork. He says that "the solo designer or artist usually produces works with this integrity subconsciously; he tends to make each microdecision the same way each time he encounters it" and that this results in a distinctive design style and conceptual integrity.

I hadn't really thought about this aspect of it before reading this book, but it makes perfect sense because the best designs are simply expressions of a mental model held by somebody. It starts off when the designer has a complete model that is simple enough to completely hold in her head. In order to do this, a lot of the details need to be omitted from the mental model; the simplified essence of the design is what is imagined. That mental model is then used to generate the design, resolving the details as the design is created. The details are basically the microdecisions that Brooks refers to in the quote above. Each detail is resolved so that it is aligned with the overall goal of the project and the mental model.

Note that being able to hold the complete model in your head is essential for this. If the mental model is not simple enough, then the details will get resolved while only considering a subset of the model, and not the entire project. This results in microdecisions that are not perfectly aligned with the goals of the project, inconsistent style, and finally, a poor design.

In the context of team design, the mental model must be shared between all members of the team in order for the design to maintain a consistent style and remain coherent. I'm pretty sure that this is impossible to do perfectly. At team sizes of greater than two people, the difference in mental models is easily noticeable. Teams of size two are something of a special case - I still think that their mental models are not perfectly consistent, but it's much harder to detect. Brooks has a section in the book titled "Two-Person Teams Are Magical" which describes how the interaction between the members of a two-person team can lead to synchronization of effort and mental models. I think that makes sense, but only for as long as the two people are working together and freely exchanging ideas. As soon as they separate and start thinking about the model apart from one another, their mental models diverge faster and the coherence is harder to maintain.

One of the reasons for this is that transferring a mental model from one person to another is always lossy (at least with current non-telepathic communication channels). If you think about it, this transmission of mental models is something we've been trying to perfect for millenia - the transfer of the mental model from teacher to student is the essence of teaching in any domain. The reason it works better in a two-person team than in a three-person (or larger) team is basically an issue of psychology. If you are brainstorming and trying to explain your ideas to a number of listeners, and one of those listeners understands it before others do, you will tend to favor communication with that listener over the others. This results in any other listeners being "left behind" as the brainstorming proceeds. In the case of a two-person team, there are no other listeners to get left behind, so this situation doesn't arise. There's probably a whole raft of other human psychology factors that come into play here, but I'm pretty sure that the majority of them favor coherence in two-person teams over larger teams.

As an aside, Brooks also says that "any product ... must nevertheless be conceptually coherent to the single mind of the user." This is another point that I didn't pay much attention to before, but that illustrates exactly why a divide-and-conquer approach doesn't result in user-friendly designs. That is, if you have a team of designers, and each of them handles the design for a separate component of the project rather than sharing the same mental model, then each component will have conceptual integrity within itself, but the project as a whole will lack it. This means a user, who needs to use the entire system, will have to replicate the models from each member of the design team, which is much harder to do.

This last point reminds me of the git user manual, currently the single best piece of documentation I have ever read. Very few other tutorials on git (or any other RCS, or any other system, for that matter) try to help the user build a mental model of what is happening under the covers. They mostly give the user a bunch of commands for specific tasks (e.g. creating a new code branch) and expect them to figure out the rest.

The git manual, on the other hand, has a section on "Understanding history" early on, which allows the user to start building a mental model of what git is doing. The rest of the manual the explains the git commands in terms of that mental model, so that git is perfectly predictable and completely intuitive to the user. By "the user" here I really mean "me", since this is what happened when I read the manual. Literally overnight, I went from being a git n00b to being completely unafraid of git, and able to carry out any operations I wanted. If you haven't read the git user manual, and especially if you've never used git before, I strongly suggest you do so. I'm curious to see if it works the same for others as it did for me.

I'm convinced that Linus Torvalds had the kind of mental model I'm talking about when he designed git, and that is the reason why the design is so coherent. Since he was also the one who wrote the original version of the user manual, it's no surprise that it allows the reader to (approximately) re-create that original mental model and use that to understand git operations. I'm also convinced that the design coherence and simplicity of git, a direct result of the mental model Torvalds had, is the reason git is so widely popular today, despite alternatives that arguably offer more features with no significant disadvantage.

[ 0 Comments... ]

The design of design, part 12011-01-02 20:55:13

I recently read The Design of Design - a book by Fred Brooks (he of the MMM). It was pretty interesting, and I would recommend it to any designers in the computer industry. Although Brooks tries to abstract out the design concepts from being tied to specific domains, a lot of the examples he uses are from software/hardware, so people working in other domains might find it harder to follow. There are also some case studies near the end of the book which also look at design projects in other domains, such as home renovations, book writing, etc., but I found the case studies to not be all that useful to begin with. Anyway, as I was reading I had some thoughts about stuff he said. This is the first in a series of posts on this topic.

(Warning: this post turned out to be more rambling than I expected, since I didn't really have a clear point to make. But composing this post helped me think about this stuff more clearly, so I'm going to post it anyway instead of just deleting it.)

In Chapter 4, he talks about how, because of imperfect communication and human "sins", we need to create contracts that identify the deliverables and lock down requirements and constraints. In software, the problem is usually that the contracts are created too early, before a full understanding of the project and its design can be reached. This is partly because with software, it's often hard to tell where the design stops and the implementation starts. However, when I think about my own experiences, I've noticed there's usually a point where I know I've hammered out all the unknowns for a particular component - I have a fairly concrete idea of what I need to do, what data structures and algorithms I'm going to use, and the overall architecture of the code that I'm working on. Although I haven't considered all the details, and resolving those details may affect the component architecture I have in mind, it's highly unlikely that those details will cause a change in the overall design of the project. This is the point where I would consider the "design" done.

The problem is that this point occurs pretty late in the project. For one thing, I tend to favor top-down designs and work on components sequentially. Within each component, I would estimate that the "design is done" point occurs after 60%-70% of the total time I spend on the component. So if I have a project with four equal-sized components, with my usual programming style, I would only be finished with all the design work after completely finishing the first three components and finishing ~65% of the work on the fourth component. This would put me at ~91% done for the whole project. Even if I shifted things around and did all the design work for the components first, it would still take me 60%-70% of the total time spent on the project just to complete the design.

Now if the project is something that I'm doing for my own needs, then this isn't a problem. But in industry, the design might be one of the factors used in coming up with an time/cost estimate for the whole project. Taking ~65% of the total time to provide this estimate is a little unreasonable. But if that's how long it takes to do the design, then that's how long it takes, and I can't think of a way around that. The other option to reduce the estimation time is to find other ways to come up with an estimate - ways that don't require a full design of the project. This is what often happens in industry now - estimates are created based on the amount of time it took for previous projects of similar scope. What I'm afraid of is that by using alternate estimation techniques, people might think there's no longer a need to do any design work* at all, and go straight to haphazardly attempting an implementation which will be poorly designed.

* In this context, I'm using a specific meaning of the word "design" from the book - an interactive process that is used more for helping the customer discover the requirements than for helping the developer determine an implementation strategy. I guess this could largely be called "requirements elicitation" instead of "design work", but the former term doesn't cover everything the latter implies.

[ 0 Comments... ]

[ « Newer ][ View: List | Cloud | Calendar | Latest comments | Photo albums ][ Older » ]

 
 
(c) Kartikaya Gupta, 2004-2020. User comments owned by their respective posters. All rights reserved.
You are accessing this website via IPv4. Consider upgrading to IPv6!