I’ve never been officially tested, but I am almost certainly a supertaster. (This explains, among other things, my aversion to most vegetables and my status as a nationally ranked beer judge). I’ve never been medically tested, but I did go through the BBC test and some rough taste-bud-counting with blue dye and a mirror.

So I do not generally follow accepted wisdom with tea. To prepare tea, I get a nice glass of cold water and plunk in a tea bag. Same goes for other tea-like substances, such as yerba mate. The result is a much slower steeping process, where subtle flavors shift throughout the day and with different refills. Does it get bitter? While tannins are part of the tea flavor, you don’t get that intense, mouth-puckering astringency like you would hot-steeping tea for too long. It’s more gradual and interesting.

Different kinds of tea have different spectrums of flavor, as revealed over the course of a day. Earl Grey and green tea are particularly nice. Some interesting combinations are possible too, by combining two teas which reach their flavor peaks at different times.

I say keep an open mind, and don’t knock it if you haven’t tried it. :) -m

“A good programmer will spend most of his time doing work that he hates, using tools and technologies that he also hates.”

While I disagree with many of his supporting arguments, I think the overall theme is pretty accurate. Working with software, the good parts seem to disappear away, so what you spend most time on are the grotty bits. In fact, I’d go as far as calling disappearability one of the defining aspects of good code-level software tools & techniques.

More collected Geek Thoughts at http://GEEKTHOUGHTS.info.

Ready to start: Full of adrenaline and excitement. Audacious goals seem readily reachable.

5-10% through: Whoa, this is difficult! And I’m only 1/10 or 1/20 of the way through? What was I thinking? It is important to ignore these thoughts.

One third point: Things seem to even out by this point. The hard slog presses on.

Halfway point: Wow, that’s halfway? Feels more like 90%!

Two-thirds point: Things are getting difficult. Should have treated this more like a marathon, less like a sprint.

90% point: There are two distinct kinds of endeavors from here. In what I call ‘type 1′ projects, the goalposts are strictly fixed, in which case a fresh burst of energy propels me through the glorious finish. But in a more sinister ‘type 2′ project, the finish line keeps receding away, as fast as or faster than I can approach. Depending on my level of stubbornness and anger, I will often finish anyway, just to spite the universe and the project masters, but at significant personal cost.

For anyone out there that has influence over large, ambitious projects, one of the most pivotal things you can do is make sure it is a type 1, not a type 2 project, as seen from the 90% line.

Finish.

More collected Geek Thoughts at http://geekthoughts.info.

Best of all, perhaps, is the word “scientometrics”.

More collected Geek Thoughts at http://geekthoughts.info.

Without stretching the imagination too much, one can think of a no-fly list as a distributed database. The list apparently changes frequently, and it needs to be accessible from thousands of airport gates and reservation desks. Thus CAP Theorem applies. In a nutshell, that theorem states that of Consistency, Availability, and Partition-tolerance, you can only pick, at most, two. Hit the link above for a much better, more complete description.

If there was one centralized list, the system would be Consistent and Available, but every time a name needed to be checked it would require an immediate network round-trip–should the connection to that central list go down, no further checks would be possible–no Partition tolerance.

Of course, the airline could set a policy that if said network connection goes down, no passengers at all would be able to get on planes. This would be a case of lack of Availability.

Or, the complete list could be periodically copied to each location that needs it. This provides good Availability and Partition tolerance, but fails Consistency, since it’s possible to miss out on late-breaking updates. Apparently, something like this is what happened.

More collected Geek Thoughts at http://geekthoughts.info.

Dora: Who do we call when we don’t know the way to go? That’s right, the map! (He’s the map, he’s the map, he’s the map!)

Map: Dora and Mr. Fawusu need to 1) get your bank account info, 2) transfer funds, and 3) proft!

Dora: Say it with me: Bank account, transfer funds, profit!

Dora: We need YOUR help to complete the transaction.

(clicking sound)

We did it, yay, lo hicimos, etc.

More collected Geek Thoughts at http://geekthoughts.info.

More collected Geek Thoughts at http://geekthoughts.info.

Game producers keep upping the ante in terms of real-time strategy games interacting with the real world. Take the latest for instance, a free iPhone app called Lose It!. Everything in this game runs in real-time–a game day is always a full 24 hours. Instead of conventional points, it uses “calories”, which are gained by the actual foods you physically eat, and subtracted via actual exercise. The app includes a massive database of food items and exercises to help you keep an accurate record, apparently on the honor system. The goal: to set a calorie target for each day and come in under it. A secondary scoring system is based on your own weight, though you will need an accurate scale (not included with the app) to measure it.

So far I’ve done pretty well at the game. I’ve averaged better than 1000 calories under my goal for the last several weeks, and have done well on the weight number too. And it’s pretty interesting to have a log of everything I’ve eaten. What will they think of next?

More collected Geek Thoughts at http://geekthoughts.info.

What happens then?

More collected Geek Thoughts at http://geekthoughts.info.

More collected Geek Thoughts at http://geekthoughts.info.

• Enjoy a DVD over the weekend
• Mail it back on Monday
• Tusday, Netflix gets it, ships a new one
• Which you get (and watch) on Wednesday
• Return in Thursday mail
• Friday, Netflix gets it, ships a new one
• repeat

This can scale up to multiple discs at a time, but at a time management level, it starts to suck. In particular, you get very little done Wednesday evenings. If you miss either mailing deadline, you fall back to 1 DVD for that week.

A better system is to reward yourself with some movie time after meeting a milestone. That way, as long as your task remains uncompleted, you’re racking up a $15 (or whatever) a month penalty for your own sloth. It seems like most people I know who have Netflix subscriptions tend to slip into a slow pattern anyway–in the mailing room I see the same mailer sitting there for weeks at a time–so why not harness human nature for motivation purposes?

More collected Geek Thoughts at http://geekthoughts.info.

First revision: Quick pass over everything. Get the obvious flaws fixed. Wordsmithing, checking for horrible words, passive voice, adverbly writing, etc.  Skip over the hard stuff. About half of the markers get fixed here.

Second revision: Careful read over everything. Cross checking notes. About half of the remaining markers get fixed here.

Third revision. No excuses. It ends here, today. To opportunistic skipping around. Once you start fixing the chapter, you finish it.

Final polish: Wordsmithing, checking for horrible words, passive voice, adverbly writing, etc.

More collected Geek Thoughts at http://geekthoughts.info.

More collected Geek Thoughts at http://geekthoughts.info.

Joel said something similar lately in the article The Duct Tape Programmer. There is a strong tendency for many coders to over-engineer a system, building towering heights of abstraction. In contrast, a Duct Tape Programmer gets the job done by making something ugly (and with fewer layers) but at least it works. So far this is a fit with what stability theory predicts.

But then he speaks out against unit testing, referring to it in similar terms to the extravagant tower. Quoting JWZ: “If there’s no unit test the customer isn’t going to complain about that.” Here stability theory makes a different prediction. Particularly in the lower levels of the system, flakiness is disastrous. You have to be sure that your foundation is stable before building upon it, or you’re in for keyboard-on-forehead-induced head trauma. This is true no matter how tight the deadlines are or how much pressure is on. In fact, when you don’t have time for a write-over, its even more important to get it right the first time.

The top accomplishment for a coder is shipping software. Duct Tape Programmers make this happen by avoiding needless complexity, which is a great principle to live by. I’m reminded of what Brian Kernighan is attributed as saying:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Debugging, or more generally making software that works well all the way to the user-facing layer, is hard. Anything that provides fundamental assertions about the stability of your foundation is a useful tool, so don’t slack off on the unit testing.

What about you? Have you found stability theory to be supported by the facts? Comment below.

-m