Comments on eXtreme Pill: The difficulties of grasping complexity

I already rely a lot on your first heuristic, but ...

2008-03-27T16:17:00.000-07:00

I already rely a lot on your first heuristic, but I find it clearly not sufficient. I believe I now need more lucidity and courage to apply the second; thanks for the advice!

Here is another great suggestion I recently had from my good friend Régis: when the time comes to decide which book to read next, take your time and think hard about which one on your shelf is most likely to respond to your current profound motivation.

Pascal, my reading method is intended to reduce co...

2008-03-27T07:18:00.000-07:00

Pascal, my reading method is intended to reduce complexity. It has two major heuristics:

1. I don't read books that aren't worth reading (I rely on my friends to recommend books).

2. I don't finish reading books that don't live up to their promise.

These two speed up my "reading" enormously.

Thank you for all those valuable links, Gerald. My...

2008-03-27T00:44:00.000-07:00

Thank you for all those valuable links, Gerald. My bookshelf already contains many books awaiting for my reading (among which 5 are from you), but the list is about to grow again!

I often wonder how some people manage to read loads of books in a year, without sacrificing the quality. Maybe they (consciously or not) apply some speed reading method...

Pascal,
Here's a few really fine books from whi...

2008-03-26T21:03:00.000-07:00

Pascal,
Here's a few really fine books from which software people can learn a bit more about engineering. I hope they're not too hard to find.

Whyte, R. R., ed. Engineering Progress through Trouble. London: The Institution of Mechanical Engineers, 1975.

Bignell, Victor, Goeff Peters, and Christopher Pym. Catastropic Failures. Milton Keynes, England: The Open University Press, 1977.

Petroski, Henry. To Engineer Is Human. New York: St. Marten's Press, 1985.

(Really, anything by Petroski, but start here.)

Holt, L. T. C. A Short History of Machine Tools. Cambridge, MA: MIT Press, 1965.

Roe, Joseph Wickham. English and American Tool Builders -- the Men Who Created Machine Tools: Lindsay Publications Inc., 1987, reprinted from the 1916 Yale University Press Edition.

I find the machine tool industry the closest analogy we have to the rise of the software industry--tools that build tools.

As for handling conflicts, the classic is

Fisher, Roger, and William Ury. Getting to Yes: Negotiating Agreement without Giving In. New York: Penguin Books, 1981.

(There may be a new edition.)

And, of course, a number of my books, but I don't want to make this an advertisement. People can always visit my website if they want to see that junk pile.

Thank you very much for your support and your advi...

2008-03-26T16:39:00.000-07:00

Thank you very much for your support and your advices!

We can certainly learn a lot from the experience of other, more mature, engineering disciplines. I would be very grateful if you could recommend us a book or a lecture in particular, accessible to non-specialists.

Studying the dynamics of teamwork, as well as the psychology of the individual is another fascinating subject, that we (with friends of mine) have recently been trying to explore. For instance, we are today thinking hard about a recipe for consistently getting a positive, constructive outcome from difficult conflicts between two persons.

Reading from experienced authors (like you) is an invaluable help, but it does not replace the experience and the daily observations in the workplace.

Very fine essay, Pascal! Tres bien!

I would...

2008-03-24T21:10:00.000-07:00

Very fine essay, Pascal! Tres bien!

I would suggest to your readers that they spend a little time studying the history of other engineering disciplines. They will find a wealth of hints and principles that can be adapted to software. Yes, software is different, but human beings are not.

And so, of course, study people, too. Get your nose out of the code for a bit of time every day. You won't regret it.