NLPhilia Blog

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.

—Brian W. Kernighan, computer programming pioneer

The “P” in “NLP” stands for “programming,” as in “computer programming.” I’ve found it very useful to learn basic computer programming and to read what programmers write about what they do.

Programmers work in teams, and “soft skills” are increasingly important in the field. Today I found a reference to one of NLP’s Presuppositions:

I began to realize that nobody–including myself–was really taking the time to understand the motivations of their colleagues. When John presented the situation to me, he thought he understood Gargamel’s motivations, and I didn’t question that understanding. Similarly, Gargamel thought he understood Dr. Claw’s motivations and neither he nor his manager questioned that understanding. But I had met both Gargamel and Dr. Claw. They are both very nice, generous people who don’t resemble their cartoon villain namesakes in the slightest.

What happens when we just assume positive intent?

Some of you may remember Michal Wallace. I lost track of him a long time ago and sort of accidentally found him recently. He has a blog called “without an e” and it’s very cool. Mostly about programming, it also approaches non-computer-programming problems from a programmer’s perspective.

Here’s a recent example: “Refactoring GTD (Getting Things Done) for Email”. He uses Python code to illustrate two ways of thinking about what he’s doing. (If you’re unfamiliar with David Allen’s “Getting Things Done” productivity philosophy/practice, see Mr. Allen’s Web page.)

I’ve said it before, and I’ll say it again: one of the best things I have ever done for myself was to learn the basics of computer programming, and I recommend it to anyone. Michal’s example above is one reason why.

EDIT 2022-05-16: Michal no longer maintains the above-mentioned blog and I haven’t yet found the python code I referred to in this article. His new blog is here, and it’s currently a list of ways to find him elsewhere.

Productivity goddess Gina Trapani from Lifehacker has been studying the Unix Philosophy and applying it to personal productivity. I think it’s an unusual idea, especially considering that, as the old saying goes, “philosophy is to real life as masturbation is to sex.” If you’re familiar with Linux or Unix you know what I mean.

Let’s think of these points as applying to the practice of NLP, though, and see where it takes us:

• Write simple parts connected by clean interfaces. (Rule of Modularity)
• Clarity is better than cleverness. (Rule of Clarity)
• Fold knowledge into data so program logic can be stupid and robust. (Rule of Representation)
• When you must fail, fail noisily and as soon as possible. (Rule of Repair)
• Programmer time is expensive; conserve it in preference to machine time. (Rule of Economy)
• Prototype before polishing. Get it working before you optimize it. (Rule of Optimization)
• Design for the future, because it will be here sooner than you think. (Rule of Extensibility)

What do you think?

Go read the full article: Applying Unix Philosophy to Personal Productivity

Once I was more interested in the Java programming language than I am now. I joined the Java Lobby so as to keep up with developments. I never learned to write Java code, but I still keep my Java Lobby newsletter coming. Sometimes there is something powerful in it. Like this past issue, which pointed me to The Philosophical Geek‘s article on the Top 5 Attributes of Highly Effective Programmers:

• Humility
• Love of Learning
• Detail-orientedness
• Adaptability
• Passion

Please don’t just read the list and think you’re done. The article is wonderful. I especially enjoyed the part about humility… what it is and is not. Go read it all.

I attended a Belief Craft training a little while ago and was very impressed with what I learned to do. Combine Jonathan Altfeld’s Knowledge Engineering with Doug O’Brien’s Sleight of Mouth and you get an amazing set of modeling and personal change tools.

If people learn to listen well enough to track the larger belief systems, then, they can then use Sleight of Mouth skills to wire completely around a problem belief, without actually attacking the problem belief. Then you can change someone’s mind without them feeling defensive about it, and sometimes, without them even knowing. That represents the most elegant use of Sleight of Mouth possible.

They’re doing it again in June of 2008 as the first module of a Master Practitioner training. Here’s your chance to grab it up before it’s all gone.

Belief Craft – Elegant and Pervasive Belief Change seminar

My old friend Chad Amberg is an interesting guy. Definitely not the type to march in time with the popular crowd, but not at all “weird” either. I think he’d make a great NLPer. I should mention it to him.

Chad is a computer guru. Mostly Windows, poor guy, but he can do pretty much anything that needs doing on pretty much any system you’re likely to be running. He’s the one who got me turned on to OS/2 back in the mid-1990s. Definitely old-skewl. Especially when it comes to programming.

We NLPers tend to spend a lot of time on the “N” and the “L” but not so much on the finer points of the “P”. Remember that Richard Bandler was learning computer science when he began poking around in subjective human experience, and that one of Jonathan Altfeld’s more popular courses, Knowledge Engineering, is pulled directly from Jonathan’s experience and training in the modeling of human decision structures using the Lisp programming language.

I know that when I learned the basics of programming in Rexx, it helped me to think much more clearly about structure. (I wouldn’t recommend Rexx right now, though, even though it’s excellent; I think Python is much more useful for the majority. If I had it to do over again, I’d have started with Python.) Learning to write a simple structured program, even in a scripting language like Rexx or Python, is a tremendous gift you can give to yourself.

Chad wrote a short article today on what he believes are the Keys to Programming. It’s brief, high-level, good advice with no language-specific ideas… more like “how to think like a programmer” than “how to write a program”. He references an essay by Paul Graham titled, “How to Hold a Program in Your Head”, which is what we’re interested in doing, yes?

Update March 30, 2022: Chad doesn’t maintain that blog any more, so I thought I’d include a link to Paul Graham’s article here: How To Hold A Program In Your Head