ybrikman

This is probably my least favorite of the 3 books in the trilogy, but that's only because the first two were so damn good, and this third one had the arduous task of trying to neatly wrap everything up. Which, for the most part, it does. The good news is that it retains the good writing, strong characters, and unpredictable plot. The bad news is that it moves away from the constrained, rule-based world that I enjoyed so much in the earlier books, and towards a much grander, and therefore, unrestrained, world view. The result works well, is epic and very clever in execution, and is absolutely worth reading, but in some ways, I miss the charm and intrigue of the very first book.

This is a tough book to rate. Some of the content changes the way you approach life and it really could make you a more effective person. I know I'll be managing my schedule and communicating with people differently from now on. However, some of the content feels like fluff, filler, and preaching. At times, it sounds no better than the "self-help" and "motivational" books the author makes fun of. In short, the book is worth reading, but be prepared to skim.



These were the biggest takeaways for me:

* To be more effective, you have to make yourself better, and not just change your outlook or attitude. Think of Benjamin Franklin's attempts at self-improvement rather than all the "think positive" BS.
* Mission statements can be useful in all aspects of life. You could have a personal mission statement, a company mission statement, and a family mission statement.
* Begin with the end in mind. This is also useful in all aspects of life. The idea of imagining your own funeral and what you'd want people to say about you in a eulogy is pretty eye opening.
* There is a difference between "urgent" and "important." Don't let urgent items drown out important ones.
* Seek first to understand, then be understood. To do that, listen to the person, then rephrase what they said (both content and emotions!) back to them in your own words. Only when you can explain their problem as well as they can should you then start to introduce your own thoughts. It sounds obvious, but I've always had a tendency to jump in with my own opinion before I've fully understood the problem. This works in negotiations (clearly explain the other person's wants before getting into your own), presentations (explain the audience's point of view before going into your own), arguments (explain the other person's point of view before going into your own), and just about everything else.




Some of my favorite quotes:

Did you ever consider how ridiculous it would be to try to cram on a farm—to forget to plant in the spring, play all summer and then cram in the fall to bring in the harvest? The farm is a natural system. The price must be paid and the process followed. You always reap what you sow; there is no shortcut.

As Emerson once put it, “What you are shouts so loudly in my ears I cannot hear what you say.”

In the last analysis, what we are communicates far more eloquently than anything we say or do. We all know it. There are people we trust absolutely because we know their character. Whether they’re eloquent or not, whether they have the human relations techniques or not, we trust them, and we work successfully with them.

Where we stand depends on where we sit.

“Inside-out” means to start first with self; even more fundamentally, to start with the most inside part of self—with your paradigms, your character, and your motives. It says if you want to have a happy marriage, be the kind of person who generates positive energy and sidesteps negative energy rather than empowering it. If you want to have a more pleasant, cooperative teenager, be a more understanding, empathic, consistent, loving parent. If you want to have more freedom, more latitude in your job, be a more responsible, a more helpful, a more contributing employee. If you want to be trusted, be trustworthy. If you want the secondary greatness of recognized talent, focus first on primary greatness of character.

In the words of both Peter Drucker and Warren Bennis, “Management is doing things right; leadership is doing the right things.” Management is efficiency in climbing the ladder of success; leadership determines whether the ladder is leaning against the right wall.

Efficient management without effective leadership is, as one individual has phrased it, “like straightening deck chairs on the Titanic.”

The key is not to prioritize what’s on your schedule, but to schedule your priorities.

The amateur salesman sells products; the professional sells solutions to needs and problems.

Notice the sequence: ethos, pathos, logos—your character, and your relationships, and then the logic of your presentation. This represents another major paradigm shift. Most people, in making presentations, go straight to the logos, the left brain logic, of their ideas. They try to convince other people of the validity of that logic without first taking ethos and pathos into consideration.

I do not agree with the popular success literature that says that self-esteem is primarily a matter of mind set, of attitude—that you can psych yourself into peace of mind. Peace of mind comes when your life is in harmony with true principles and values and in no other way.

People don’t care how much you know until they know how much you care.

The second book in the series is also a fun, fast paced read that's hard to put down. Sanderson expands the universe a bit to make things even more epic, there are plenty of twists and turns, and at the end, you're left with no choice but to pick up the third book. This isn't a deep, philosophical novel, but there are parts that will make you think, and in between those parts, is a solid action/fantasy story that will make you smile.

The Mistborn series creates exactly the kind of fantasy world I enjoy: all the "magical powers" have well-defined rules; there is an interesting main plot with something at stake; there is an extensive mythology behind the universe; and there are a large number of fun, deep characters. All of it creates wonderful fuel for the imagination and it's hard to put the book down. It's also well written, full of fun dialog and exciting, vibrant action sequences. I'd love to see it turned into a video game.

A must-read for anyone starting a business. This book contains a solid introduction to just about all the common legal and business issues you need to be aware of. Despite having worked at startups for years and having done a fair bit of research on my own, I was amazed by how much I still didn't know (and didn't know that I didn't know).

The book is comprehensive and works both as an introductory read and a reference manual. It manages to strike a good balance between being technically (and legally) accurate, but still fairly readable. It's not exactly exciting reading, but still far better than trying to work your way through actual legal documents. There are tons of real-world examples ("from the trenches") and a single hypothetical example that is developed throughout the book, both of which are very helpful in seeing how the laws work in practice. The only downside is that this book makes you realize how complex some of these laws are and that, despite reading this book, you'll still need to consult with a lawyer. But at least now you know what to ask.

A quick read that provides a clear and concise intro to Docker. This book does a good job of helping you wade through the buzzword soup that has been created by the Docker community. The debugging, deployment, and docker at scale sections are particularly valuable, as they are difficult to find in online documentation and blog posts.

As implied by the "Up and Running" subtitle, this is just an introduction, so don't expect too much depth or nitty gritty details. The biggest downside to the book is that the Docker community is moving so fast, that a larger and larger percentage of this book will become obsolete with each passing day. Of course, this gives the author a chance to publish new, updated editions periodically, which means you'll probably want a digital version of this book.

An instant sci-fi classic. The premise of how a lone astronaut stranded on Mars could survive is great, the main protagonist is awesome (the supporting cast is fun too), and the writing is intense and engaging. As is typical of programmers, Andy Weir has an obsession with getting every detail precisely right, so at times, the book straddles the line between fiction and a Mars-survival-how-to-guide, full of math and science details (as a programmer, I enjoyed nerding out on these parts, but they are not for everyone). However, other than that, it's an edge-of-your seat thriller similar to Gravity. Great stuff.

This book started off great. Fun Forrest-Gump-Esque premise, interesting characters, and good humor. And then it kept going. And going. And going. It kept repeating itself, retelling the same joke over and over, and got to the point where I didn't want to keep reading. It's a fun tale, but it would have been much better at half the length.

I listened to the audiobook version of this book and found it very entertaining. The writing is good--clear, sometimes moving, sometimes hilarious--and Poehler's reading of it, as well as random cameos from Patrick Stewart, Carol Burnett, Seth Meyers, and Mike Schur made it even better. The book can be a bit scatter-brained, jumping backwards and forwards to random parts of Poehler's career, side stories, a long apology, poems, recordings from live performances, songs, and an occasionally-confusing jumble of other thoughts. That said, for the most part, it holds together well and gives you an appreciation of what it's like to be an actor, comedian, writer, work for SNL, do improv, work in show business, and do it all as a woman and mom.


Some of my favorite quotes from the book:

That is the motto women should constantly repeat over and over again. Good for her! Not for me.

Great people do things before they're ready. They do things before they know they can do it.

Is there a word for when you are young and pretending to have lived and loves a thousand lives? Is there a German word for that? Seems like there should be. Let’s say it’s Schaufenfrieglasploit.

You have to care about your work but not about the result. You have to care about how good you are and how good you feel, but not about how good people think you are or how good people think you look.

Emotions are like passing storms, and you have to remind yourself that it won’t rain forever. You just have to sit down and watch it pour outside and then peek your head out when it looks dry.

Everyone lies about writing. They lie about how easy it is or how hard it was. They perpetuate a romantic idea that writing is some beautiful experience that takes place in an architectural room filled with leather novels and chai tea. They talk about their “morning ritual” and how they “dress for writing” and the cabin in Big Sur where they go to “be alone”—blah blah blah. No one tells the truth about writing a book. Authors pretend their stories were always shiny and perfect and just waiting to be written. The truth is, writing is this: hard and boring and occasionally great but usually not. Even I have lied about writing. I have told people that writing this book has been like brushing away dirt from a fossil. What a load of shit. It has been like hacking away at a freezer with a screwdriver.

I wondered if I was just doing this as some kind of ego trip. Then I decided I didn’t care. Not enough is made of the fact that being of service makes you feel good. I think nonprofits should guarantee that giving your time and money makes your skin better and your ass smaller. Why not? There are so many people in the world with so little. Who cares why you decide to help?

Nobody looks stupid when they are having fun.

I found this to be an eye opening book. I think just about anyone, man or woman, would too. It's well researched, well written, succinct, and discusses many important issues: how successful men are perceived differently than successful women, the differences in self confidence between men and women, the need for more women in leadership positions and more men doing household tasks, and, perhaps most importantly, why we should all talk openly about these issues. I'm not a huge fan of the marketing style phrases ("sit at the table", "lean in"), but perhaps they make the message more sticky. I liked all the personal anecdotes that show Sandberg as a human being, vulnerable, imperfect, and learning many of the lessons in this book the hard way. Also, this book has a fair number of good lessons on leadership, career progress, and communication that go beyond gender relations.


Some good quotes from the book:

A truly equal world would be one where women run half our countries and companies and men ran half our homes.

While compliant, raise-your-hand-and-speak-when-called-on behaviors might be rewarded in school, they are less valid in the workplace. Career progression often depends upon taking risks and advocating for oneself--traits that girls are discouraged from exhibiting. This may explain why girls' academic achievements have not yet translated into significantly higher numbers of women in top jobs. The pipeline that supplies the educated workforce is chock full of women at the entry-level, but the time that same pipeline is filling leadership positions, it is overwhelmingly stocked with men.

Gymboree once sold onesies proclaiming "Smart like Daddy" for boys and "Pretty like Mommy" for girls. The same year, JC Penney marketed a T-shirt to teenage girls that bragged, "I'm too pretty to do homework so my brother has to do it for me." These things did not happen in 1951. They happened in 2011.

Many people, but especially women, feel fraudulent when they are praised for their accomplishments. Instead of feeling worthy of recognition, they feel undeserving and guilty, as if a mistake has been made. Despite being high achievers, even experts in their fields, women can't seem to shake the sense that it is only a matter of time until they're found out for who they really are--imposters with limited skills or abilities.

The real issue was not that I felt like a fraud, but that I could feel something deeply and profoundly and be completely wrong.

Success and likability are positively correlated for men and negatively correlated for women. When a man is successful, he's liked by both men and women. When a woman is successful, people of both genders like her less.

If you're offered a seat on a rocketship, you don't ask what seat. You just get on.

An internal report at Hewlett-Packard revealed that women only apply for open jobs if they think they meet 100% of the criteria listed. Men apply if they think they meet 60% of the requirements.

Anyone who brings up gender in the workplace is wading into deep and muddy waters. The subject itself presents a paradox, forcing us to acknowledge differences while trying to achieve the goal of being treated the same.

The laws that protect women and minorities and people with disabilities, among others, from discrimination are essential, and I'm not suggesting they be circumvented. But I've also witnessed firsthand how they can have a chilling effect on discourse, sometimes even to the detriment of the people they are designed to defend.

Currently, only 24% of women in the United States say that they consider themselves feminists. Yet when offered a more specific definition of feminism--"A feminist is someone who believes in social, political, and economic equality of the sexes "--the percentage of women who agree rises to 65%. That's a big move in the right direction.

In the future, there will be no female leaders. There will just be leaders.

A quick, pleasant read, wonderfully illustrated with large, lovely photos. Actually, the writing is largely secondary to the photos, but it does provide some context and a few interesting facts about the trees (e.g. strangler trees are fascinating). The book gives you an appreciation for trees: how long they can live (4000+ years!), how huge and varied they can get (from a tiny bonsai to a 15,000 ton behemoth), and how beautiful they can be (Baobabs are amazing). They really are wondrous life forms.

As someone who is moving to Tuscany soon, and as a fan of A Year in Provence, I thought I'd enjoy this book. The truth is that it's OK, but nothing special. There are some great depictions of the Italian countryside, Italian people (especially workers), and lots of great descriptions of Italian food (I got very hungry reading this book). And that's about it. The rest is an unfocused mix of the author's thoughts, travels, and recipes, and it can be a chore to get through. This book would be a delight if you dropped the irrelevant material and cut it down to half its length, but as it is, it's hard to recommend it.

A few good quotes from the book:

A Chinese poet many centuries ago noticed that to re-create something in words is like being alive twice.

On my way out, I see a man in a sweater, despite the heat. The trunk of his minuscule Fiat is piled with black grapes that have warmed all morning in the sun. I'm stopped by the whiny, musty, violet scents. He offers me one. The hot sweetness breaks open my mouth. I have never tasted anything so essential in my life as this grape on this morning. They even smell purple. The flavor, older than the Etruscans and deeply fresh and pleasing, just leaves me stunned. Such richness, the big globes, the heap of dusty grapes cascading out of two baskets. I asked for un grappolo, a bunch, wanting the taste to stay with me all morning.

How Italian will we ever be? Not very, I'm afraid. Too pale. To unable to gesture as a natural accompaniment to talking. I saw a man step outside the confining telephone booth so he could waive his hands while talking.

A fun, fast paced, hard-to-put-down read that does a great job of telling the story of John Carmack, John Romero, and the groundbreaking games they created (Wolfenstein 3D, Doom, Quake). By the time I was done, I had a massive desire to a) play games, b) play old school games like quake, and c) spend all night coding and eating pizza.


My favorite quote from the book:

Video games don't let people really live their dreams. They let gamers live a developer's simulation of a dream. The action is digital. It's confined to a computer or television or a handheld device. Players experience it thought their eyes, ears, and fingertips. But when they're done careening down the Daytona Speedway or storming an interstellar military base, they feel as if they've really been somewhere, as if they've momentarily transcended their sac of fat and bones, their office politics, their mounting bills. Games let them escape, learn, recharge. Games are necessary.

This isn't a book about "computer programming", but about computer programmers. It holds up remarkably well more than 40 years after its publication date because even though the technology changes rapidly, the people creating it do not.

Of course, not everything in the book has aged well. The discussion of "other programming tools" in the final chapter is fairly specific to an era of punch cards and shared terminals and should mostly be skipped. Also, there are some fairly dated views on the roles of women in the workplace and how they can't match up to men--not that Weinberg endorses these views, but it's clear that this is a book from a different era (that said, women in tech is still a problem now).

Overall, a very worthwhile read. We need more tech books that focus on the people and not the technology itself.

Some of the key ideas I found especially memorable:

* We should look at programming as a human activity, not just a mathematical, scientific, or technological one.
* Most programs are built by teams, so we need to look not only at how an individual interacts with a computer, but also how many individuals building software interact with each other.
* In most professions, you look at the work of others to learn. Not so in coding. We rarely read other people's code and prefer to learn by writing things ourselves and repeating everyone else's mistakes. This situation has improved slightly since Weinberg wrote the book thanks to the explosion of open source, but it's still very rare for a programmer to sit down and just read code as a learning exercise.
* Egoless programming: see the code you write not as part of yourself, but as independent objects owned by the team. That way, you don't see flaws in the code as flaws in your character, and you become much better at seeking out feedback and handling criticism.
* Good programming language design is primarily about taking into account the limitations of the human mind. We can't hold or process too much information in our heads, so languages need to be designed around the principles of uniformity, compactness, locality, and linearity.
* Programming is a nascent field and we need a lot more research to figure out how to do it effectively. Sadly, more than 40 years later, we've done relatively little rigorous research and still don't seem to be much closer to knowing the answers.




Some of my favorite quotes from the book:


The material which follows is food for thought, not a substitute for it.

Computer programming is a human activity. One could hardly dispute this assertion, and yet, perhaps because of the emphasis placed on the machine aspects of programming, many people--many programmers--have never considered programming in this light.

Programming is, among other things, a kind of writing. One way to learn writing is to write, but in all other forms of writing, one also reads. We read examples--both good and bad--to facilitate learning. But how many programmers learn to write programs by reading programs? A few, but not many.

Specifications evolve together with programs and programmers. Writing a program is a process of learning--both for the programmer and the person who commissions the program.

The average programming manager would prefer that a project be estimated at twelve months and take twelve then that the same project be estimated at six months and take nine.

Fisher's Fundamental Theorem states--in terms appropriate to the present context--that the better adapted a system is to a particular environment, the less adaptable it is to new environments.

Psychology is the psychology of 18-year-old college freshmen.

Maxwell, the great physicist, once said, "To measure is to know," and his words are often taken as a motto by other sciences. What Maxwell probably meant was "To know how to measure is to know," or even better, "To know what to measure is to know."

The organization chart is a nice toy for a manager, but little programming work would ever get done if interactions among programmers has to follow its narrow, straight lines.

John von Neumann himself was perhaps the first programmer to recognize his inadequacies with respect to examination of his own work. Those who knew him have said that he was constantly asserting what a lousy programmer he was, and that he incessantly pushed his programs on other people to read for errors and clumsiness. Yet the common image of von Neumann today is of the unparalleled computing genius--flawless in his every action. And indeed, there can be no doubt of von Neumann's genius. His very ability to realize his human limitations put him head and shoulders above the average programmer today.

As a rough rule, three programmers organized into a team can do only twice the work of a single programmer same ability--because of time spent coordination problems. Moreover, three groups of three programmers to do only twice the work of a single group--or four times the work single programmer--for the same reason.

The basic rule for size and composition of programming teams seem to be this--for the best programming at the least cost, give the best possible programs you can find sufficient time so you need the smallest number of them. When you have to work faster, or with less experienced people, costs and uncertainties will rise. In any case, the worst way to do programming project is to hire a horde of trainees and put them to work under pressure and without supervision--although this is the most common practice today.

Programmers, being people who tend to value creative event and professional competence, tend to put their stock in people whom they perceive to be good at the things they do. Thus, it is easier to exert leadership over--to influence--programmers by being a soft-spoken programming wizard than by being the world's fastest-talking salesman.

If a manager wants to run a stable project, he would do well to follow this simple maxim: If a programmer is indispensable, get rid of him as quickly as possible.

It is a well-known psychological principle that in order to maximize the rate of learning, the subject must be fed back information on how well or poorly he is doing. What is perhaps not so well known is that people who feel that their performance is being judged but who have no adequate information on how well they are doing will test the system by trying certain variations.

The hierarchical organization, which so many of our projects seem to emulate, comes to us not from the observation of successful machines or natural systems, but from the nineteenth century successes of the Austrian Army.

Whenever a supervisor is responsible for work he does not understand, he begins to reward workers not for work, but for the appearance of work. Programmers who arrive early in the morning are thought to be better programmers than ones who are seen to arrive after official starting time. Programmers who work late, however, may not be rewarded because the manager is not likely to see that they are working late. Programmers who are seen taking to there are not considered to be working, because the manager has an image that programming work involves the solitary thinker scratching out secret messages to the computer.

The amateur, then, is learning about his problem, and any learning about programming he does may be a nice frill or may be a nasty impediment for him. The professional, conversely, is learned about his profession--programming--and the problem being programmed is only one incidental step in the process of his development.

A large proportion of the variance between programmers on any job can be attributed to a different conception of what is to be done.

Lacking any objective measure, we often judge how difficult a problem is by how hard a programmer works on it. Using this sort of measure, we can easily fall into believing that the worst programmers are the best--because they work so hard at it.

Once the solution has been shown, it is easy to forget the puzzlement that existed before it was solved. For one thing, one of the most common reasons for problem difficulty is overlooking of some factor. Once we have discovered or been told this factor is significant, working out the solution is trivial. If we present the problem to someone else, we will usually present him with that factor, which immediately solves nine-tenths of the problem for him. He cannot imagine why we had such trouble, and soon we begin to wonder ourselves.

The explanations for success given by some programmers bring to mind the story of the village idiot who won the monthly lottery. When asked to explain how he picked the winning number, he said, "Well, my lucky number is seven, and this was be seventh lottery this year, so I multiplied seven times seven and got the winning number--63. And, when someone tried to tell him that seven times seven was forty-nine, he merely answered with disdain, "Oh, you're just jealous"--which, of course, was true.

The two major influences we can exert on a programmer's performance are on the desire he feels for working and on what he knows that is needed for the job. The first is called motivation and the second is called training, or, if it is sufficiently general, education. But little is known about why programmers program harder, or whether they are already programming too hard for their own good. Possibly even less is known about educating programmers, even though vast sums have been spent on training schemes.

In a way, the reason it is so hard to attribute the source of programming inefficiency to either programmer or programming language is that if we had ideal programmers, programming languages would be be necessary. It is a psychological which prevents us from writing out problem specifications directly in machine language.

Let's face up to it: people don't think the same way that computers do--that's why we use computers. Programming is at best a communication between two alien species, and programming languages with all their systems paraphernalia are an attempt to make communication simpler for one of those species. Which one? Not the computer, certainly, for nobody ever heard a complaint from a computer that it couldn't do the work.

An important read for everyone in software development. Although the book is not executed perfectly, it raises the level of debate in the software industry from anecdotes and opinions to hard data and research.

The second half of the book is a great collection of research results across a variety of important software topics, such as:

* Learning programming: Why is it so hard? Do better tools or visual programming help?
* TDD: Does it reduce bugs? Does it lead to better design?
* Pair programming: Does it reduce bugs? Does it increase or decrease productivity?
* Code review: Does it reduce bugs? Should you do it in groups or individually?
* Women in computer science: Why are there so few? Is it due to genetic differences or cultural biases?
* Team organization: Is Conway's Law something to avoid or embrace?

This book is now my go-to source for a variety of software decisions. I just wish I had read it long ago.

The reason for 4 stars instead of 5 is that the way this information is presented is not particularly compelling. Most of the chapters in the first half of the book, and a couple from the second half, are written in a dry, academic style that's too focused on the nitty gritty details of software research methodologies. I suppose that's OK if the target audience is other researchers, but my impression is that the goal of this book is to bring evidence-based software engineering to the typical programmer, and to do that on a large scale, you need a much more approachable writing style. In other words, if the goal of this book is to motivate change, then the authors need to pick up a copy of "Made to Stick" and learn to simplify the message (e.g. gloss over the research details), make it more concrete (e.g. explain what it means in the real world), involve some emotion (e.g. these are controversial topics, feel free to make some jokes or have an opinion every now and then), and tell stories (e.g. give examples of how these results affected an actual project).

Overall, a very worthwhile read, but if you're not a researcher, be prepared to do a lot of skimming, especially in the first part.


Some good quotes from the book:

We hope the questions and answers in this book will change how you think about software development. We also hope these essays will persuade you to say, “Citation, please,” the next time someone claims that one way of laying out braces in C or Java is better than another.

Convincing evidence motivates change.

Evidence is not proof. In general, evidence is whatever empirical data is sufficient to cause us to conclude that one account is more probably true than not, or is probably more true than another.

Qualitative research has to precede quantitative research and will look at situations that are more complicated. When only few different factors are involved (such as in physics), one can proceed to quantitative investigation quickly; when many are involved (such as in human social interactions), the transition either takes a lot longer or will involve premature simplification. Many of the credibility problems of software engineering evidence stem from such premature simplification.

We found that programmers deviated from a reference group in that they are lower on Extraversion, lower on Emotional Stability, and higher on Openness to Experience. [...] Programmers are also more homogeneous than the population as a whole; that is, programmers vary less in personality than do people in general. This confirms the stereotype of programmers being neurotic, introverted, and intellectual—and, by the way, male (which I know for a fact some people consider tantamount to a personality trait!).

It makes a significant difference whether you ask someone how much time he needs to complete a given amount of work, or whether you ask how much work he can complete in a given amount of time.

Thus a possible corollary of Conway’s Law is: A software system whose structure closely matches its organization’s communication structure works “better” (defined broadly) than a subsystem whose structure differs from its organization’s communication structure.

Every page in this book has been checked over by an editor. Why? Because even if you’re the smartest, most capable, most experienced writer, you can’t proof-read your own work. You’re too close to the concepts, and you’ve rolled the words around your head for so long you can’t put yourself in the shoes of someone who is hearing them for the first time. Writing code is no different. In fact, if it’s impossible to write prose without independent scrutiny, surely it’s also impossible to write code in isolation; code has to be correct to the minutest detail, plus it includes prose for humans as well! (You do write comments, don’t you?)

A mixed bag.

The first part of this book focuses on coding advice, but It's not particularly concrete or actionable, what examples are present are very C specific, and I could only see it being useful for beginners. It has sentences along the lines of "make sure to handle errors" and "make sure you know how to use co concurrency constructs" and "always employ sound engineering techniques that minimize the likelihood of unpleasant surprises." These are all correct, but a bit obvious and not particularly useful. It also repeats itself a lot, introducing TDD, KISS, and DRY principles in the first part, and then repeating them over and over and over again, but not in a new way that would make the message more sticky.

The other parts of the book focus more on the sociology, psychology, and philosophy of programming and are stronger, especially Part III ("Getting Personal") and Part V ("The People Pursuit"). The chapters about programmer ethics, continuous learning, and working with other great programmers are the high points. The sense writing style is fairly informal, with lots of attempts at humor, some of which miss, but a few others, especially The "Generic Manifesto" and the Hitchhiker's Guide satire, are great.



Some good quotes from the book:

An interesting and beneficial side effect of working with good coders is that you're far more likely to end up working with good code.

I conclude from what we've seen here that there are (at least) two levels to the ethical programming career: the mandate to "do no harm" is the base level, to not tread on people, or be involved in work that exploit others. Beyond this is a more involved ethical mantra: to only work on projects that provide sound social benefits, to specifically _make the world better_ with your talents, and to share knowledge in order to advance the program and craft.

Working with your programming language is a relationship you have to work at each day.

Being accountable to other programmers for the quality of your code will dramatically improve the quality of your coding.