I helped edit the first 4 chapters. One benefit of the book is it's short. All the information you need is condensed into 150 pages.
It starts out being immediately applicable (Chapter 2: Write Tests First), giving you systematic methods to measure various happiness qualities. After that, it helps you define what would make your life happier. From there it talks about specific ways to address the types of problems people run into when trying to improve their happiness.
Throughout the whole book, it tries to relate the concepts to programming ideas (testing, specs, debugging, etc). This isn't a general public self-help book, it's specifically for people who program or are technically minded. That's what makes it unique.
If I had to knock the book, I'd say that some of the metaphors are stretched a little bit. Overall the concepts map well, but every so often you're kind of like, "huh... yeah, I guess those are the same things..."
I'm not sure you actually understand my phrase 'quantifying their happiness'. It uses tests derived from The Feeling Good Handbook, Dr. David Burns and Beck Anxiety Inventory, Dr. Aaron Beck to track emotional well being over time.
It makes it possible to compare how you feel with various points in the past to track an overall improvement or regression.
This book is by a programmer, for programmers, to help them quantify their happiness and take action to improve it, instead of focusing on churning widgets (GTD) or whatever it is you focus on.
Oprius Software - Victoria, BC, Canada - Full Time, remote
Position: Chief Technical Officer
Oprius' Chief Technical Officer is responsible for the maintenance and development of the Oprius web-based software.
Oprius is a CRM web app designed specifically for individual sales people. It is designed to be approachable by people without a lot of computer experience and yet still powerful. It tracks contacts, appointments, calls, tasks, and emails; lets users create complex sales processes; and includes a powerful phone assistant for use during calls.
This position is a work-from-home/telecommute position.
I feel like the OP misconstrued things like "doesn't work out of the box". What he meant was, "I needed to install the package to get my video driver and sound driver working".
Generally Arch doesn't install something until you ask it to.
I think this is a little disingenuous. The Arch developers do their best to make sure that nvidia and amd drivers work with new kernels.
Sometimes updated drivers are needed, but not released for months, and the developers have to make the choice between holding back the kernel update for that small minority or releasing it to the benefit of everyone not using that driver.
It does, but instead of giving you a library/API access, like Mercurial, it gives you command line access. I feel as though one is a little more black box than the other.
They can do interop at the level DAG level, but higher or lower level abstractions aren't really supported (hg branch information isn't accessible in git, git doesn't have access to mq information, etc).
I guess the big difference is the level of interaction. A Mercurial extension has access to all the functionality that Mercurial offers: applying patches, creating commits, history walking, etc. But it doesn't really modify the underlying representation of that data (queues store their data in the working copy, for example).
Git doesn't give you access to its functionality but instead gives access to its data model. Stashes are just references, commits are created or destroyed at will, notes are just objects that point at commits and are stored in a different set of references, etc.
It starts out being immediately applicable (Chapter 2: Write Tests First), giving you systematic methods to measure various happiness qualities. After that, it helps you define what would make your life happier. From there it talks about specific ways to address the types of problems people run into when trying to improve their happiness.
Throughout the whole book, it tries to relate the concepts to programming ideas (testing, specs, debugging, etc). This isn't a general public self-help book, it's specifically for people who program or are technically minded. That's what makes it unique.
If I had to knock the book, I'd say that some of the metaphors are stretched a little bit. Overall the concepts map well, but every so often you're kind of like, "huh... yeah, I guess those are the same things..."
Edit: Added something negative to say.