Monday, May 18, 2009

I have a doubt

There are the things you know, there are the things you don't know, and there are the things you don't know that you don't know them. Well, that you know by know. There are still other things, however, namely those things you know about -- and are wrong.

Let's restrict the discussion of this predicament to programming. I've been learning some new frameworks and tools over the past months. In one of them I noticed a missing feature that would make it much easier to achieve my intention. Open source to the rescue, I just patched it to my liking and went on. Later, in a discussion with more experienced people, I complained about this missing feature. To my embarrassment I found out that not only was the behavior I had been asking for already supported, but that the change I'd made was ineffectual and never executed. Had I not seen with my own eyes that this framework was doing the wrong thing without my help? Yes, indeed, but somehow the details were different and that special case didn't apply anymore.

That's a harmless example, of course, almost benign in dealing the small shock to shake ones certainty. But isn't certainty a good thing? It sure feels good -- until you find out that you have been wrong. The latter, the worse. "I thought we were measuring distances in imperial units" -- Kaboom, you may just hit Mars. "Oh, weeks start on mondays in your country? How weird, isn't saturday the last day of the week anymore?". You can probably add countless other similar examples, after the fact that is.

But how do we avoid falling into the certainty trap, to know what isn't so, to begin with? Constant vigilance is not the answer, I'm afraid. Don't become the central scrutinizer, or you won't get anything done beyond being skeptical of everything. A first step, I suggest, is dragging certainty out of the cozy corner. Yes, I have already admitted that it feels good, but you will have noticed the price tag by now. Whenever you find yourself thinking or saying "I'm certain that ...", "I know that ...", pinch yourself and make a note to investigate if your certainty is well founded. As a second step, get into a habit of friendly caution, every now and then utter to yourself I have a doubt.

Saturday, May 21, 2005

Don't be an avoider

In my earlier interview with Frank Westphal I noted that Contemplative Programmers, when stuck on a problem, defer it and direct their attention to another needy task. I realize that this practice, even more so when given as an advice, can be misunderstood, even abused as an excuse for unhealthy conduct. To be clear, Contemplative Programming doesn't license Ersatzhandlungen (substitute acts). We want and we want you to stay on track. There are times when this is not easy at all.

Some problems mount up to terrifying heights. Then there are problems who look innocuous, whereas they are anything but. They inspire fear -- the fear of failing. In order to avoid such a problem all kinds of other "really urgent" things spring to mind. Most likely they aren't very urgent at all -- they just lead to Ersatzhandlungen. They make you appear busy while not doing what needs to be done. One of the core values of Extreme Programming is courage and that's the apt cure from a Contemplative Programming point of view, too. Still, we tend to allot a different dose.

Avoiding problems that need to be tackled is bad, that much we have established. But clinging helplessly and undproductively to a problem is only slightly less bad. Yes, by all means muster the courage to attack the really important problems -- but be brave enough to let them go for a while if you don't make any progress. The point here is to tackle a problem on your terms, when you are in the best position to actually handle and solve it.

So, don't avoid problems, you may defer them, though.

Sunday, April 24, 2005

Interview on Contemplative Programming

Recently, Frank Westphal conducted an interview with yours truly. Originally, the interview was in German and published as part of Frank's Tonabnehmer ("pick-up") podcast. After some rough and ready translation work, here's the transcribed interview.

F: Hi Greg!  I appreciate your taking the time from your busy schedule for this phone interview. I know you also speak German. Would it be okay if I addressed you in my mother tongue?

G: Hello, Frank. Yes, sure. I speak a little German. You know, I have lived in several countries in recent years.

F: Tell us a bit about yourself! Only very few listeners will have heard of Greg Woydnilek. What's driving you?

G: Driving is not really the right word. Because I recommend something we call "Contemplative Programming". You know, most programmers are always under stress -- very extreme. That's no good!

We not only want to achieve good code and good programs. We also want good programmers who feel well. We say: "Be one with your code" and "Be kind to your code". That's for the first part. The second, more important part, is "Be kind to others and yourself", because first of all we're concerned with people.

Sometimes I'm reminded of an anecdote told by the eminent philosopher Bertrand Russel. In the 1930s he noticed how American and German naturalists reported on animal behaviour. In the americans' reports, the animals are running around and there's always a lot of action. In the Germans', reports the animals are sitting and thinking -- almost like this famous Rodin statue. You see, I have been in America for a couple of years, but I'm a European and have lived here most of the time. I'm not surprised that Extreme Programming originates in America and Contemplative Programming emerged in Europe.

The Americans are learning, though. I think it was [Pete] McBreen, who told of a programmer who didn't hammer on his keyboard wildly, but looked at the ceiling. His boss in outrage asked him what he was doing. To that he [the programmer] answered: "I'm thinking". -- You see, that is it! That's the Heart of Contemplative Programming.

F: Programming by contemplation. My dictionary says: Contemplation - concentrated-introspective cogitation and mental immersion into something. How are we supposed to picture this? Do contemplative programmers enter some kind of trance state?

G: No, no, that's not how it is, of course. Just as little as Extreme Programming has to be extreme all the time. We are not programming Yogi Flyers. So, what we intend to emphasize is the value of thinking [Nachdenken] and advance thinking [Vordänken] -- actually, thinking in general. What have I just done? What have we done in the project recently? Has it been successful? Can we improve on it? We differ from other approaches in that we don't only do this kind of retrospective post mortem, when everything is dead. Rather, we conduct Continuous Retrospectives. It goes so far that we even do Prospective. Only short-term, of course, for even Contemplative Programming is no crystal ball.

An important difference compared to other methods -- and here I'm thinking of XP and RUP and so on all the same -- is that we Contemplative Programmers stay much more relaxed. Relax, there's more to life than work! Kent Beck once wrote that Extreme Programmers get home tired in the evenings. Contemplative Programmers then are still fit for the important things in life. Believe it or not, but Contemplative Programming has improved the love life of lots of practitioners, for real, whereas XP constantly talks about practices -- we do it for real!

I don't intend to conceal that there are critics. An Englishman, of all things, Rosendorn or something. He calls us Lethargic Programming. I'm sure he's just envious.

F: How much post and advance thinking [Nachdenken, Vordenken] do contemplative programmer indulge in in practice? You may have guessed it: It instantly came to my mind what we extreme programmers sneer at as BigUpFrontDesign, or more picturesquely: BigFuckedUpDesign. How do you make sure that, at the end of your relaxed day, you get executable code, not just relaxed thoughts?

G: O no! Jeer all you want. We'll visit you in hospital after your heart attack. But let's not quibble. In fact our positions are pretty close. Contemplative Programming is about Business Value as much as XP is. However, XP appears to be overly fixated on thinking at the keyboard and in the code. We take the liberty to spend the time it takes to consider a question thoroughly. No action, just thinking. We easily take a few minutes for this. And when we realize that we're stuck, then we defer a problem until the next day and take care of something else. The point is that we don't force progress, we encourage it.

F: How about Pair Programming? Do you do it? Do you like it?

G: First of all, I need to set straight a misconception. We Contemplative Programmers are no homogeneous group. We're a variegated mix. Yes, that describes it pretty well. Contemplative Programming rather is a mixin, an aspect. Quite a number of us really like XP. With some concerns, though, they want to intercept and apply an advice, an aleck, that is, to the base method. This way we break the Tyranny of the Predominant Method and keep our peace of mind.

So, to get back to your question. Yes, sure, some [Contemplative Programmers] like Pair Programming, others don't.

F: Contemplative Programming has gained a considerable number of adepts in recent years. Definitely caused by lots of developers being fed up with the predominant methods. They feel burned out by their jobs. And the fun, the reason they became programmers in the first place, has died off over the years.

That's why people try to lead their lives more mindfully. People are more sensitive for their work-life balance, how it is trendily called. Regarding this, Contemplative Programming appears to be consequential.

G: Yes, exactly. I'm no longer burned out from my work. Instead, I have sore muscles from workout. You don't grow any younger [Man wird nicht jünger], or how do you say in Germany? Nonetheless, I prefer the aching muscles by far.

F: Let's get back to the motto: "Be kind to your code". How are we supposed to understand that?

G: First and foremost, it is meant as an admonition against thoughtlessness. You have to realize that there are still hordes of programmers doing something they call "churning out code" [Code raus hauen]. That's exactly what the code looks like: thrashed. Disfigured into a monster, a Behemethod. Well, okay, they don't feed on small children, but often they play bad pranks on the next programmer.

That's not good, but what can we do about it? Well, many of us Contemplative Programmers think that code needs a good upbringing. That calls for empathy and oftentimes leniency, too. That's what we mean by "kindness". But no laissez-faire! We set firm limits through unit tests, like you Extremists do. In contrast, though, we don't think of harnesses or corsets or similar coercives. Our notion is of a sturdy pole where a young tree can grow up straight. The Java programmers can think of a bean pole.

F: Yes, I know exactly what you are talking about. How do you handle the conflict when you very thoughtful people come or work together with those code-churning programmers? Does this conflict exist? How do you go about it?

G: Indeed, there is a lurking conflict. It's only kept from erupting because lots of Contemplative Programmers have stayed under cover. But that we are going to change! I'm currently working on a somewhat theoretical book, tentatively titled "Contemplative Programming Considered". An associate is working on a practical book, presumably titled "Contemplative Programming for Fun and Profit". The later book addresses questions like yours in particular.

So, what do we do? There are quite a few options. By our presence alone we exert a calming influence on our coworkers. Where that is not sufficient, there are kinds of tea with a desirable effect. In cases where even that doesn't work, we demonstrate the advantages of Contemplation. While the others are hacking off their butts, we look for the right way with a clear mind. You probably know the fable of the hare and the hedgehogs? ... When the hacktic finally crosses the finishing line we're already there. At least one of us.

F: Up to now, most of your ideas have been handed down by word of mouth. Those in the community know each other. In the near future, we're going to see the two books on the subject. What can an interested listener do to find out more today? When I search with Google, I hardly find anything.

G: Right, that's been true so far. Publicly we kept very quiet. For the most part our discussions are going on in private forums and mailing lists. But we're in the process of opening. Hence this interview, hence the books. Nevertheless, we intend to proceed without haste. So we don't suffer what we've witnessed in the case of XP. If we, too, step out into the street at high noon, we only provoke the gunslingers. They're only looking out for something to gun down with their twitchy fingers. We endeavour to be a bad target.

That way it'll take somewhat longer until Contemplative Programming makes it into the mainstream, admittedly. But we're not in a hurry. Sustainable Development, that's what counts.

F: Do you have any advice for novices?

G: First of all they ought to work on becoming good programmers. Know your tools. Keep your eyes open. Don't be narrow-minded, but always prepared to learn something new. In my childhood there was this mean piano teacher, Dr. Terwilliker, who had one true sentence: "Practice makes perfect." That's true for all keyboards.

Specifically regarding Contemplative Programming, I'd like to add that doing alone does not lead to happiness. It's of paramount importance to reflect on what one has done. Was it good? What wasn't good? How can we improve it? In short: Learn from your mistakes. Even better: Learn from the mistakes of others.

F: Have you been born with this contemplative streak? Or what has made you into such a reflective practitioner?

G: No, unfortunately it wasn't that easy for me. I've been young, too, and a little bit impetuous. Accordingly, I, too, have experienced what it's like to believe in cracking problems with infinite power. Then it's only a matter of time until burn-out. I wasn't hit that hard, in fact. But it was hard enough so that I didn't take any enjoyment in computers for two years.

I'm not the only one who fared like this. People tend to be embarrassed by it and they don't talk about it. But, cross your heart, once you've grown older than twenty-five, you're cured of thinking it's cool to work yourself senseless. Enthusiasm and commitment are great, of course. But definitely not when they destroy you. -- There has to be another way, for that one's a dead end.

F: Uh oh, how true! Last year I had the chance to experience this myself.

Say, Greg, does Contemplative Programming only relate to us geeks? How about managers, domain experts, testers and all the others hanging about in software projects? Any food for thought?

G: Well, if you look closely, Contemplative Programming isn't about geeks. There's no antagonism, but no positive feedback either. In this conversation I've pointed out the relationship to software development and the name "Contemplative Programming" refers to it, after all. However, the ideas are much more general -- and hardly new at all, I have to add. But as it is, I'm not about to promulgate a Weltanschauung, much less a doctrine of salvation for all. I talk about areas where I have first-hand experience. As it is, that's software development. -- Anyway, I won't hide that I enjoy it when other project members are contemplatively enlightened.

F: Possibly the best project manager I know makes his round in the evening and throws out all his people. He's pretty extreme: He goes so far to switch off the power.

Are contemplation and work-life balance the two forgotten practices that must not be missing from any software development process? Simply to remind us programmers, sitting self-absorbed in front of the screen, that there's our body and beloved ones to care for just as well as our code and computer?

G: I've been wishing for a project manager like that in my earlier days, too. Back then I had a coworker who I often met in the office early. He had been there all night.

Regarding work-life balance I'm ambivalent. It's an important issue for sure. Everyone should heed not to overbalance. But I'm getting uneasy when a business or process mandates how I have to keep my balance. Something like that can be not enforced, but it has to be facilitated.

F: Any famous last words?

G: How about "Stay alive"? Yes, that sounds good.

Friday, April 22, 2005

Staying sane in a chaotic industry

Keeping your mental and bodily health intact while writing great code and creating software your customers love. That's one of the missions of Contemplative Programming, once the Basic Premisse of Stay Alive is no longer in danger.

Stay tuned for some wisdom from the depths of Contemplative Programming. But don't hold your breath -- everything on this blog will only move at moderate, sustainable pace.