This feed contains pages in the "books" category.
I recently read Mihaly Csikszentmihalyi's seminal work Flow. It's been on my list of books to read since I heard about it last summer, since I've heard for ages that the state of flow is the state in which we are most productive. And besides that benefit, it feels great to lose yourself in your work. So, the idea of finding out what we know about the conditions that produce flow is very appealing to me, and probably is to others as well.
I found that my own distinction of flow as being a state that one achieves only when doing knowledge-type work to be far too narrow. I associated the word "flow" with writing a paper and having the words just roll off the keyboard almost effortlessly, with losing myself in writing some code, with designing and problem-solving. Post reading the book, I see that flow can be achieved in many other contexts, such as in conversation with friends, when playing a sport or a game, or reading a book. In many cases, flow may be easier to achieve in conditions other than work.
Csikszentmihalyi's basic premise is that we are most happy when we are in flow, and that flow is produced when a person is engaged in a goal-directed, rule-bound activity that has ready feedback on how he is doing, and is faced with challenges that are suited to his ability level. Flow can occur spontaneously, but it is more likely that it is the result of a structured activity such as a game or work or of a person's ability to make flow occur. For example, surgeons often report that their work is a source of great happiness and optimal experience for them, and that they wouldn't give up being surgeons even if they weren't well-payed for it. A surgeon's job is practically designed to produce flow experiences. The surgeon has a very specific goal--to perform a certain operation, and has instant feedback as to how well he is doing. He has certain procedures that provide a ritualistic way for him to get in the mindset of concentration and allow him to forget external worries for the duration of the surgery. Flow activities "transform the self" by "making it more complex"—flow activities push us to higher limits and allow us to experience states of consciousness that we have never before experienced. In this way, they are more satisfying than diversions such as watching television, which capture the mind's attention and alleviate boredom but provide no challenge to the self.
While the structure of certain activities makes it more likely for flow to occur for those engaged in them, there are some sorts of people who are able to produce flow experiences despite their surroundings being ill-suited. Csikszentmihalyi says that these people have an "autotelic personality". These people are able to alter their own consciousness to produce flow, regardless of external factors. He gives examples of Nazi prisoners held in solitary confinement who were able to find growth and sanity by inward thought despite horrendous external conditions, and a blue-collar factory worker who was able to turn his assembly line position into a challenge where he was always trying to beat his previous speed records. While some people seem inherently better at being happy and finding flow in inideal situations, we can all improve our ability to control our consciousness and find flow.
One point that I found striking in the book was that, despite people generally feeling that when they are at work they would prefer to be home, people report more optimal experiences at work than they do at home. Sunday morning is the time that people are most likely to feel depressed. I can identify with this premise from experience--when I feel down it's most likely to be a Saturday or Sunday, or another day where I am excused from my normal daily routine and am less likely to leave the house or make the decision to commit myself to an activity. In our culture it is popular to view work as manacles on our freedom of choice, when in reality it provides structure and goals for us. While we can in fact provide this structure for ourselves, and thus have more control over what we are doing and who we are helping achieve their greater goals, work often does provide an easier way to achieve flow without having to realize ourselves how to create it.
Despite being as old as I am (it was written in 1988), I found Flow to be thoroughly informative and enjoyable. Its lessons are clearly still applicable, and not as widely known as they deserve to be.
On the train to my parents' house for Christmas I finished up a wild run through the book Coders at Work. The book isn't even mine, but I'd been borrowing it very often, sometimes to the chagrin of its owner, because I could barely put it down.
The book is a collection of interviews with 15 great programmers of our time, starting with Jamie Zawinsky and ending with Donald Knuth. It's written in an interview style—each interview starts with a brief introduction to the person being interviewed, summarizing what the person is known for and what he or she has accomplished and a few of the highlights of the interview, and then a transcript of the interview follows, with the author/editor, Peter Siebel, will saying something or asking a question, and the interviewee responding. I was skeptical about this format at first because I feel like it can be an easy way out of good editing and make the reader have to do the work of the editor, but on finishing I think that Siebel uses the format to his advantage in this case.
For one, the speech format allows the reader to really form a picture of how the person being interviewed speaks and would act in a conversation. Jamie is somewhat bitter and pretty informal. Brad Fitzpatrick is flippant and energetic, his speech littered with profanity and colloquialisms. Others seem more stately and verbose—Joe Armstrong's responses can go on for a page or more. In this way, not only do readers learn something about what these greats have learned about programming, but we also feel a bit more like we've met or know them, and can connect to them more as people.
I always have this problem where I want to read computer books, but often computer books seem inextricably tied to the computer, so there's this dynamic of reading a bit and then wanting to get on a machine and try something out, write some code, play around—especially with books focused on a specific language. Coders at Work retains some of this computer-book dynamic in that I constantly encountered things that I want to investigate or play around with more: Erlang, OCaml, various papers and essays, Knuth's literate programs, and books such as Higher Order Perl and others. Siebel makes a point to ask each person what her short-list of books and papers programmers should read are, so this book is a great source of pointers to other reading material. Unlike a more specific book, however, keeping a list in a notebook was enough to settle the mind to read away-from-a-computer for chapters at a time.
It's obvious that despite the interview format, Siebel has done some serious editing. None of the prose is boring to read, and I can't imagine that the text is a straight transcript of how the interviews went. He also has arranged the interviews in an order such that different interviews play off each other. In Branden Eich's interview, for example, he disparages the book Design Patterns:
I never bought the Gamma book. Some people at Netscape did, some of Jamie Zawinski's and my nemeses from another acquisition, they waved it around like the Bible and they were kind of insufferable because they weren't the best programmers.
In the next chapter, Joshua Bloch names it as a book he thinks programmers should read:
Another one, which I have slightly mixed feelings about but I still think everyone should read, is Design Patterns. It gives us a common vocabulary. There are a lot of good ideas in there.
Similar plays, such as Ken Thompson and Fran Allen disagreeing on the badness of C, happen in later chapters, tieing together the different chapters and illustrating how even really good programmers disagree on the Right Thing all the time. Clearly the craft of programming is no settled thing.
Besides the general structure of the book being well thought-out, the material is generally thought-provoking and interesting. One thing that stood out to me was Joshua Bloch describing what he called the "empathy gene", which is what a programmer has to have if he's going to be able to design good APIs and programming languages—he has to be able to put himself in the shoes of the person who will be using the language or API. This is one thing that differentiates how different programmers can be good at different things.
Another thing that stood out to me is that many of those interviewed stated that they don't use much in the way of modern tools and IDEs—Joshua Bloch and Simon Peyton-Jones both touch on this, just to name a couple examples, even though some say that they think using these tools would make them more productive, especially when it comes to refactoring. This is a testament to the power of inertia—sometimes there is just no chance to be unproductive now in order to be more productive later. Or perhaps just a sign that a programmable text-editor can stand on the same level as a heavier tool in terms of productivity in the right hands.
I could go on with examples, but the conclusion here is that I thoroughly enjoyed Coders at Work, and I think it is a book that is well-worth the time spent reading the entire thing.