On Scientific Knowledge, Weight Loss, and Being Very Wrong

I have been wrong, very wrong, about diet and nutrition for my whole life. I hate being wrong.


As a critical thinker and trained research scientist with a Ph.D. in biology I feel that I should have done better. My only defense is that when one is an expert in a field, one tends to trust the opinions of experts in other fields.


I know I have the tools and ability to become an expert at many things, but it takes some serious motivation. If I was diagnosed with cancer, I would devour the literature and trust no one until I mastered it. But for everyday matters like nutrition I have always just done what I was told.


I have been blogging on and off about my weight loss efforts (roller coaster) since 2007 (read the whole mess in reverse chronological order here if you want), but the roller coaster actually started much earlier. The short version goes like this: 300-220, 270-213, 280-220, 285-225, 270-219 (current). As you can see I am really very good at losing weight, but pathetic at keeping it off.


So what is different about this time? Why do I finally think I have found the answer? Easy: I am not on a diet this time. Oh, it started out as a diet (Slow Carb from The Four Hour Body), but it has morphed into a simple and hopefully permanent lifestyle change.


The change is this: no grains and no sugar and no starchy vegetables. Or more prosaically no bird food or hippopotamus food (hippopotami eat sugar cane).


OK, that's a little over-simplified, but the whole thing really is just to minimize insulin production - eat few enough carbs (especially fructose! - no fructose that doesn't come from whole fruit!) so that you are losing or not gaining weight and stop worrying about fat intake, especially saturated fat. Other than that, eat anything in any quantity, especially meat and vegetables. But beware things that can cause insulin spikes even if they are non-caloric like artificial sweeteners.


I weigh less than I have in ages. I have more energy than I have had in ages. My teeth feel cleaner. I am less irritable and more positive. I am never hungry. I don't have to measure or record what I eat. I get to eat lots of things I love (bacon, eggs, cheese, steak, broccoli, kale, collard greens). I do miss a few things (bread, beer, sweets), but there is no formula for weight loss that doesn't require some changes/sacrifice - I should know, I've done enough of them.


So do I have my own brilliance to thank for this? Alas, no. I must give full credit to Gary Taubes who devoured the literature for me and laid out the arguments in a clear logical fashion. I can't overstate this - my entire view of nutrition, science, and even human history has been altered in the last few months as I digested these ideas and then proved them out on my own body.


A huge fraction of the conventional nutritional wisdom is wrong. Demonstrably wrong. Scientifically wrong. Gary certainly isn't the first person to espouse reducing carbs (neither was Atkins), but he lays out the history and arguments extremely well. From a scientific perspective we don't even really know that carbs are the problem (the telling experiments have not been done), but I now believe that the carbohydrate hypothesis is highly compelling and most likely true (with a fructose hypothesis as a close second - but that's another post).


Gary Taubes is a an excellent science writer who frequently writes for Science magazine, often on the topic of bad science. He has written two books and some articles on the carbohydrate hypothesis. You can see him speak here. if you are going to read just one book, it should be Why We Get Fat: And What To Do About It. His other book, Good Calories, Bad Calories, is excellent, but be warned that it is dense with literature references and the like - it is very complete - doctors and scientists will likely want to read this one.


These books and the seminar are all top notch stuff. Two thumbs up. Go watch. Go read. Why We Get Fat is also available on audible.com, so you can listen too.


These are not diet books, so don't expect that. You'll have to go elsewhere for low carb diet advice (or make up your own as I did - the principles are easy).


I do not believe that a thinking person can read Why We Get Fat without changing their diet, so be warned about that as well. If you'd rather live with your head buried in the sand, stay far away.


The really scary thing is that if the carbohydrate hypothesis is correct, we are royally screwed. Only a tiny fraction of the planet can afford to eat properly and our entire global food production system is set up almost exactly wrong to address it. But that too will have to be another post.


David

Yes, I Think Your Project Sucks

I am a software/systems architect in a very large corporation for which software and IT are not core business. In this role and previous roles I have frequently been called upon to participate in project code reviews.

When I perform these reviews I usually generate pages of notes and constructive criticisms that I share with the project team. I don't pull punches in these reviews. If I spot some code that is smelly I will highlight it and explain why it is wrong. I will call out shoddy code organization and poorly thought out build scripts and stupid package naming and bad error handling and crappy unit tests and useless comments and other details ad nauseum.

But all of these details are the trees. What makes me like or dislike a project is the overview of the forest. To be sure, one element is the sheer number of details that I have to call out. An overgrown forest stands no chance. Here are some other higher level things that I look for:

• Evidence of a professional developer attitude
• Evidence that the end goals are understood
• Evidence of higher order design/architecture

Evidence of a professional developer attitude

Show me that you have a process. That you care about the quality of the project and the code. That you care what other developers think. That you are trying to set a good example. Some indicators:

• Clean, well organized repository
• Repository is up to date and has regular check-ins (with comments!)
• Clear build scripts that serve as documentation for the build process and dependencies
  
• Unit tests and TDD thinking (even if you don't do TDD)
  
• Continuous build (or at least nightly)
• A single central build environment (NOT your IDE, doofus!)

Evidence that the end goals are understood

Show me that you understand the user. That you aren't going to show the user error messages like, "Database Error: Code 5387". That the user interface doesn't freeze or time out. That you have processes in place so that you can quickly debug problems in production. If this is an API, show me that it is clear and understandable and that the contract utterly explicit. Some indicators:

• A system for handling errors/exceptions that is logical, that logs details, that presents the user with a message that is clear and simple.
• Asynchronous UI processes
• Sensible timeout logic where appropriate
• Integration/unit tests that monitor task time and alert when changes to the code may have slowed something down
• For APIs do the error messages contain the extra details that a developer would need?
• Do you eat your own dog food?
• Are you logging in such a way and at an appropriate level of verbosity such that you can troubleshoot unexpected problems?
• Documentation for any APIs. Yes, documentation. If you can't clearly explain in a document how to use your API, then what good are you (or it)?
  

Evidence of higher order design/architecture

Show me that you have thought about reusability. That you understand the value of layered abstractions. That you understand what an object is and what a process is. Every time you look for a library to do X for you and don't find it, do you then write a decent library to do X? Or do you just hack some code to do X into the middle of some poor unsuspecting class? Some indicators:

• If you are writing a service that does Y, do you have a well orchestrated class/library that does Y, upon which you have layered a service? (as opposed to building the functionality directly into the service classes/methods)
• Are complex tasks broken down into small logical slices? (as opposed to long confusing methods)
• Are things that could/should be reusable actually reusable? (as opposed to having unnecessary interdependencies with the rest of the project)
• Are your objects named like (and function like) nouns?
• Are your method and object names indicative of actual behavior?
• Is the project an assembly of small pieces that fit neatly into a bigger picture? (as opposed to a monolithic beast)
  

It isn't shocking to me that I have never seen a project that scores perfect on all of these indicators. Perfection should be rare. But it is shocking to me how many projects I have seen that score zero.

David

Jumper Cables

I am not normally a political activist, but I'm going to make a rare exception.

Let's see if we can bring the 4th amendment back to life and send a message to our elected representatives that we do not want to live in a police state.

Pledge here if you agree. I'll forgive you if you don't.

Winner's Laws

A while back Alan Schoonmaker had an article in CardPlayer Magazine (Winners Are Brutally Realistic: Part II) in which he discusses his concept of four Winner's Laws.

These laws are brilliantly universal and I wanted to share them you. They are:

1. Admit that you overestimate your abilities and other virtues.
2. Admit that you have some unrealistic expectations
3. Get an objective assessment of yourself.
4. Select your games very carefully

Aren't they great?

I suppose that to be truly universal you have to restate the last one. Maybe something like:

• Select the opportunity that maximizes your expectation

Or maybe that is still too gambler-speak. How about:

• Select the opportunity that is most likely to produce either short or long term benefits.

For everything that I have excelled at I have (knowingly or unknowingly) followed these rules. For everything that I have not done as well at I haven't.

1. Admit that you overestimate your abilities and other virtues.

• Confident people are generally winners and expect to be winners, but confident people are insanely likely to be guilty of overestimating how good they are.
• If you overestimate how good you are you won't improve. You won't even try to improve. Pretty soon you will suck.

2. Admit that you have some unrealistic expectations

• You are a confident person. You expect to do well. But some of your expectations are ridiculous. Admit it. You aren't going to win the Nobel prize or cure cancer. You also aren't going to get a glowing review followed by a promotion every year.

3. Get an objective assessment of yourself

• You overestimate your abilities and you have unrealistic expectations. How can you possibly be objective about yourself? You can't. Find someone who can.

4. Select the opportunity that is most likely to produce either short or long term benefits

• Opportunities come and go. If you choose the one that is convenient, or the one that is most "fun", you are probably costing yourself.
• Either choose opportunities that have demonstrable immediate benefit (e.g. the job that pays better) or the opportunities that can have long term pay-offs (e.g. the project that will force you to learn something new that you expect to be useful in the future).

Hope you liked these.

David

My Political Compass

I am a bit hesitant to enshrine this for all time on the 'net because it is bound to change over time. But the results surprised me a little, as did the layout of the compass itself and the descriptions surrounding it. So here is my political compass:


To put it in context, this puts me dead center on the left-right line between Milton Friedman and Ghandi, but a bit more libertarian (in the classical sense) than either of them.

I don't think this test is anywhere near the whole story. I am socially liberal and economically conservative. Someone who is the opposite could have the same score and we would agree on almost nothing. I think that some multi-dimensional visualization techniques could give a more useful view. Still, it is an interesting exercise.

David

(via PharmaGiles of all things)

Hiring Programmers

This is a great list of things to look for when hiring a computer programmer.

This, of course, should not be confused with a list of things to look for in a new hire in general. You have to add all of those on top (or you'll be mighty sorry).

These are the things I look for now when I interview someone, but I have never been this explicit about it. Maybe I'll make a checklist.

David

(here is an old related post)

Sweet, Sweet Reason

Why, oh why aren't there more people like Radley Balko?

Who? Yeah, well, I'd never heard of him either. But based on this article over on FOX News and this YouTube footage I like him. These are two of the best counters to the UIEGA that I have heard.

And of course I had to subscribe to Reason Magazine after that introduction to one of its Senior Editors.

My thanks to Bill's Poker Blog for pointing out the articles.

Always remember: UISGE is good, UIEGA is bad. (I really need to get a T-Shirt of that made)

David

Hiring Resolution

I have been having so much fun reading the coding horror blog that I have decided it deserves a permanent link. Not that I always agree with what he says, or anything. But he manages to be thought provoking for sure.

He wrote a post a while back on the vast chasm between those who can program and those who cannot. That post, especially when you dig deep into some of the source material, really gets you thinking about who you should (or should not) hire. Now he has a very scary post up about how most programmers can't program that should be required reading for anyone who has to hire programmers.

"But wait!" I hear you cry. "That is just the opinion of a few jaded people, it isn't scary at all." Regrettably these observations dovetail very neatly with my real world experience. That is the scary bit.

So even though it is well after the beginning of the year, I have a new resolution. I hereby resolve to FIND OUT if people can actually program before I hire them or recommend them for hire.

The Lack of Consequences

OK, I admit it. I read Wil Wheaton's blog. Like many trekkies I absolutely hated Wesley Crusher, but I started reading Wil's poker blog when he started playing and, well, he doesn't seem like such a bad fellow.

Anyway, he has this wistful post up about the disapearance of video arcades, which I remember even better than he does being 7 years older. The whole thing makes for good reading, but he makes a point at the end that really clicked with me.

My kids' generation, with their online gaming and its associated sense of anonymity and unaccountability, aren't getting the same social workout that we all got when we were kids. When I played a two player game against another kid and I beat him, if I taunted him mercilessly and made explicit references to his mother's sex life and my role in it, he would have justifiably kicked the everliving shit out of me; so I learned that it was always a good idea to be gracious in victory and defeat. Contrast that with the foul and profane behavior exhibited in today's online gaming worlds, by players who are old enough to know better, or young enough not to care.

I have played a fair bit of MMORPGs and I have to say that while most of the people you meet online behave fairly well, there is a distinct trend for a significant fraction of the younger crowd to behave in ways that are more than two sigmas outside of the normal distribution of social behavior. Sometimes way more than two sigmas. It has made me a big fan of /ignore.

I wonder how I will overcome this with my own son? Will gaming and social interaction get more and more anonymous as he grows?