Sarah and I watched the first presidential debate tonight at a friend's house. I'm glad we did, even though I'm trying to keep a little distance from politics for my own peace of mind. I already knew I was going to be voting against Bush. After the debate I'm relieved to also say I'll be voting for Kerry.
His criticism of Bush's foreign policy aligns well with my own views, and I was impressed with how he presented the arguments. I was glad to see him aggressively challenge Bush's performance in Afghanistan, Iraq, Iran, and N. Korea. I'm also happy that he remained appropriately respectful. Bush has half of the country's support and deserves to be treated respectfully.
I was especially encouraged by Kerry's sketch of a plan for Iraq. Bush failed to present any sort of change in how to proceed in Iraq. Iraq is slipping towards civil war and our coalition seems increasingly unable to prevent it. We need help on the ground. Our military is already stretched too thin. We need serious commitments from our allies in Europe and Asia to support the transition of the Iraqi's to their independence. Bush has adopted a posture that makes any request for help a sign of weakness. By contrast Kerry seems to draw strength from the idea of international support. That difference in attitude is the first sign of hope for Iraq I've seen in months.
Also, Bush is too connected to the oil business for the rest of the world to believe that we're sincerely interested in helping the Iraqi's to create and sustain their own independence and not there for the oil. Regardless of whether you think Bush's motives are generous or selfish, you can hardly blame other countries for being suspicious of the Bush family oil ties.
It's not all roses of course. I am settling into a belief that we'd be much better off with powerful State governments and less powerful Federal government. Neither of these candidates offer any hope in that direction. At a glance, that sounds like a Republican ideal. But Bush cuts taxes with one hand while spend-spend-spending with the other. At least with Kerry I know what I'm getting into.
What's especially frustrating is the rhetoric of "The War on Terror". I may be alone in this conviction. Terror is not an enemy against whom you can actually wage war. Terror is a feeling, an internal state of mind. It is intense, overpowering fear. War cannot reduce that kind of fear. War depends on fear. It can only increase it.
Both candidates brag that they're the tough guy who will hunt down and kill the terrorists. Israel has demonstrated for decades that no amount of hunting and killing actually reduces terrorism. England's conflict with Ireland is also an instructive lesson from history on this score. We need a different metaphor to frame our thinking and unfortunately neither candidate has much to offer.
Having said that, Kerry did work a nice sound bite into his closing remarks. "Freedom, not fear" is a pretty good slogan. It is certainly in the right direction. What we need is freedom from fear, not a war on terror. "Freedom, not fear" is close, though. I hope it gets lots of airplay. Unfortunately it is still only a sound bite and probably won't change the world.
My sincere apologies if my comment moderation code has falsely accused you of trying to spam my web log. I try to keep this small corner of the net mostly free from advertising. My programatic censor has been a bit too aggressive since my last modification. I really am interested in your comments and feel especially bad about this particular mistake.
This has been difficult. Writing and publishing encourages me to carefully examine my ideas and helps to clarify them. But looking closely at my own failure hasn't been fun, even if it has been rewarding. Hopefully others can spare themselves the pain by learning from my mistakes.
Back in April, May, and June I had an embarrassingly bad time with the import problem I mentioned. I took three months banging my head against various aspects of the problem. In spite of my post about the importance of knowing when to stop I chased one wrong turn after another for three months. When Rob returned from his vacation he asked Paul to take over who finished it in four days.
Three months vs. four days. That is embarrassing.
It would be easier if I could claim to have solved most of the problem. But Paul's solution little resembled what I had started and addressed aspects of the problem I hadn't even considered. I know Paul is a better programmer. I know he is fast. But I was not prepared for the internal shock and dismay of so glaring a comparison.
With a few months hindsight I can see that I made my most fundamental and most drastic mistake right before I started working on the problem. I assumed it would be easy, but tedious. I underestimated my opponent.
I then failed to notice just how much I was actually struggling. This is especially hard to accept, even in hindsight. How on earth could I go on for weeks, let alone months, without noticing how seriously I had underestimated?
When presented with evidence that conflicts with our beliefs, we dismiss the evidence rather than adjust our beliefs. Getting my butt kicked by an "easy, but tedious" problem is inconsistent with my hot-shot-programmer self-image. I continued to believe the problem was easy and that I was on the verge of the solution, in spite of mounting evidence to the contrary.
The last dimension of failure grew from the same poisoned soil. I couldn't bring myself to ask for help on something "so easy." I didn't want to interrupt Rob and Paul who seemed quite busy on more important matters. I didn't want to admit that this busy-work was kicking my butt. I flailed and struggled and silently suffered along.
As in aikido, getting properly slammed into the mat can really focus your attention. A number of important lessons came hard and fast in July and August.
Sean McGrath's description of the breakthrough syndrome offered some solace, if not a solution:
The syndrome affects all walks of IT professional life but is most acute in software developers. ... The developer "wraps their head" around a problem. ... From that moment of immersion onwards, ideas for solving the problem come thick and fast [and] the developer gets a sense that a triumphant breakthrough is not far away.... That person is likely to feel - really and truthfully - that a breakthrough is just around the corner.
It may be, but it probably isn't.
Paul says "there's no busy-work in programming." I haven't heard that anywhere else, and it's still hard to believe. But there's no question that I would have called for help much sooner if I hadn't thought of it as busy-work.
My failure exposed the underlying importance of a collection of extreme programming practices. For starters, my silence violated three of the four XP values, specifically communication, feedback, and courage. Silence is not an effective form of communication. I was cowardly in concealing my failure rather than courageously admitting that Easy and Tedious had beaten me. I broke the feedback loop and we suffered for it.
By contrast, once my failure was out in the open, I was immediately back into the communication and tight feedback loops that are typical for bivio. Rob offered a couple rules of thumb to measure future progress: most tasks should take less than a day and the hard ones should be done in a week. These rules are hidden in continuous integration. In order to integrate continually, you have to break the tasks into day-sized chunks or smaller. Alarms should be going off if you can't integrate your code at the end of the day.
David called for the planning game -- something we hadn't been doing. For this particular problem, the split would have been especially valuable. I had misjudged the problem and taken on a task that was too big for me to properly get my head around. It would have been useful to get help early in slicing the problem into smaller pieces. Also, regularly reporting and adjusting scope and tasks would cause a failure like mine to fail fast. I would only have gone one week before the alarms started going off. If it went as long as two weeks, serious interventions would have been put in place and a months-long failure would have been averted.
I had to get over my hesitation to interrupt. This is about courage and communication. I had two fears holding me back. First, I was afraid of interrupting Rob and Paul. Second I was afraid of looking stupid. Courage is taking action in spite of fear. I need to trust Rob and Paul to manage their own interrupts. The fear of looking stupid is both simple and incredibly difficult. I simply need to get over it. That is substantially harder than it sounds, and also a story for another day.
Update: We only occasionally pair program. Doing that more consistently would obviously prevent a mistake like mine. If we were always pair programming, it would be hard for me to have even developed a fear of interrupting.
Perhaps the most important lesson of this whole experience is about my coworkers at bivio. No one berated me for my failure -- perhaps it was clear that I had that job well in hand. Instead they offered encouragement and stories of their own failures. In some way we bonded through my failure. We looked at the problem as a team and brainstormed various measures to learn from the experience. My mistake became an authentic opportunity to learn and grow, not to judge and condemn. That's not just a slogan on a motivational poster, but what really happened in action.
Josh Bloch and Neal Gafter spoke at both Denver JUG and Boulder JUG last month. They gave a fairly thorough run-down of the features in Java 5 (that's what they're calling it now). If their show comes to your town and you want a quick boost into the Java 5 features, you won't be disappointed. There was plenty of code to give a flavor of how the new features improve your programming life.
It was interesting to look at Java 5 features after having programmed in perl and with bOP for the past eight months. I'll say out loud that I think they have made many improvements. They seemed rightfully proud of what they have created. But there's clerly a fundamental difference in values. Josh and Neal really appreciate the compiler and want it to do more work for the programmer. Whereas I'm getting much more value from tests these days. I suppose I shouldn't dis' compilers. Dynamic languages need 'em too. But in my experience with perl and python, the compiler is just the first set of runtime errors. :-)
Letting the 'for' loop also behave like 'foreach' is a great improvement. Coupled with type-safe collections you will have to do radically less casting. But I've also grown quite attached to perl's map and grep, and python's list comprehensions. These are related to foreach, but in many cases even more useful. Java still doesn't have them nor the first-class functions and closures needed to really appreciate what these language constructs can do.
Josh and Neal were quite excited about the new enumerations. Until I began work with bivio, I had never used enums. It was very nice to hear someone explain again when to use enumerations and why bother. I have been using enums for months now and implicitly know when to use them, but I don't know if I could have explained it until now. In case you are like I was, here's how I understand it. Enums are a collection of things that you might store in a table in a database except that you don't need to change the list of items at runtime. The example Josh offered was menus in your application. They're a group of related things that behave similarly, but you only change them with new releases of the software.
What Josh and Neal were excited about was that enums are full blown objects, not just integers with names as in C. That means you can add methods to them. Exciting if you're coming from a C or Java background. But Rob and Paul and David wouldn't be so impressed. bOP's enums have had methods for years.
I won't do any more blow-by-blow comparison of new java features with perl or python or bOP. My own experience looking at these new language features just validates Paul Graham's assertion that programming languages vary in power. So Java 5 is more powerful than 1.4, but not quite as powerful yet as perl and python. bOP adds some very useful things to perl. And we'd all be better, faster, and stronger in lisp.