For as long as I can remember, I've been interested in why things are the way that they are. Over time, that intense curiosity has driven me to learn as much as I can about object orientation and software development in general. I like to find out what works, and what doesn't and tell people about the boundary conditions. Working with Groupon, I'm able to really dig into various areas of software, solve problems with people and communicate what I've learned.
Knapsack books:
Concepts, Techniques, and Models of Computer Programming - Van Roy, Peter and Haridi, Seif
The Corporation - Joel Bakan
Nonzero: The Logic of Human Destiny - Robert Wright
Ahem, geek stuff (which I still love):
I'm currently using the Io Language and thinking about better ways of teaching design.
I can be reached at mailto:michael.feathers@gmail.com
Blog at michaelfeathers.typepad.com 
On Singletons Are Evil you said you were writing a paper about that topic; I see people asking how that was going, but no response. Did this paper die before seeing the light of day? -- Doug Merritt
No, I never finished that, but I've just finished writing a book on working with legacy code. Nearly all of my arguments against singletons are in there in one form or another.
Irony: In the olden days, we just had Goto-oriented Spaghetti Code. These days, we must deal with Design Patterns-influenced Spaghetti Code. --Phl Ip
Don't be shy, go ahead and tell us about it, ISBN and all. :-) -- dm
Okay, here is a brief description: It can be very hard to make changes in large complicated code bases. When we make changes its important to know that we are making them one at a time. Too often we think we are changing only one thing but instead we end up changing other things unintentionally: we end up introducing bugs. If we can write tests against old code we can figure out when it's behavior is changing. This helps us know that we've added new code properly and it also supports us when we refactor. Unfortunately, it's often hard to get tests in place in complicated code. You have to refactor to get tests in place in order to refactor. The book shows you now to safely get tests in place to support your work and start to make the code better.
When you do this often enough you start to see code that doesn't have tests as legacy code. The differences between code bases that have tests and those that don't are so significant in most cases that they swamp most other criteria for good design. When you have tests you can make things better, when you don't often you don't really know whether you are or not.
"Working Effectively With Legacy Code" ISBN 0131177052 released September 16, 2004
I would think that a title like that would appeal to a lot of people without even knowing the contents. Don't forget to have some friends seed the Amazon reviews; the system is biased against authors who don't do that. (When I do this for friends, I do full disclosure on the existence of a personal relationship, but doing so is very much in the minority.) -- dm
WEWLC is a fantastic book. Right up there with Refactoring and Agile Software Development. Thanks for writing it. - Bill Dehora.
Michael Feathers was the original author of Cpp Unit and Cpp Unit Lite
Recently, I've written a tool that creates Feature Diagrams for Java classes. I have a few pictures here that show what Ward Cunningham's Framework For Integrated Test looks like in Feature Diagrams: michaelfeathers.typepad.com
See original on c2.com