Wednesday, October 31, 2012

Same as It Ever Was

The more things change, the more they stay the same, or so they say.

I frequently wonder about this, at least in regard to people. Do people ever really change?

I would like to think so. I spend most of my time operating under the assumption that people do change. However, there are times when I wonder, "Does anyone ever really change?"

Sitting with Ben and Brian last night, listening to each talk about the same personal issues he'd wrestled with for years, hearing each confidently express how he'd finally got to the point of overcoming them, I wondered. I was glad to hear them so confident. I was enthusiastically supportive of their efforts. Yet, something about what each of them said (or perhaps how they said it) rang untrue. It led me to do more than wonder about whether or not they'd change; it led me to believe they wouldn't.

At first blush my thoughts may sound negative or pessimistic. However, I don't believe they are. After the guys left, I continued to think about what each of them had said or done to set off my NO-CHANGE alarms. I thought about their facial expressions, their gazes, their cadences and uses of inflection. I'd love for each of them to change in the ways he'd expressed desire to do so. I wanted to try and nail down the missing ingredients or the hidden gotchas.

I've spent much of my life around people who have what is sometimes called "addictive personalities." A common theme among them is the repeated expression of desire to change. The expression is usually accompanied by compelling reasoning that explains why, this time, the change will really happen and why it will last. I've seen change occur and even flourish for periods, but rarely if ever have I seen it endure. Over time, I've come to recognize patterns of behavior and action that are consistent with short-lived change and ones that are consistent with change that seems to endure.

I don't know how directly or indirectly these patterns influence the sustainability of change, but I thought I'd share some of them in case they could prove useful.

Act, Don't Talk
The first thing that sets off my internal NO-CHANGE alarm system is the proportion of talking to acting, or for that matter, thinking-about versus acting-on. People who really change spend little time talking about it relative to the time they spend acting upon it.

Every Day
They say that if you do something consistently, every day for twenty-one days, it'll become a habit. I don't know if the number is twenty-one, twenty-eight or forty, but I do know that doing something (acting) every day, significantly increases the likelihood of it taking hold.

Further, doing something every day is much easier and more efficient than doing it some days. You avoid all those internal conversations about whether or not to delay until tomorrow. You don't even open the door to thoughts of delay. You simply never let the day end until you've done it.

Psychologists tell us that people with a strong sense of purpose are much happier, more energetic and more optimistic than those without it. The purpose needn't take on global proportions; it can be something simple and mundane. However, it must be clear and strong.

Creating a strong sense of purpose is like attaching a weight to the end of a fishing line. With the wait secured to the end of the line, you can cast your hook wherever you want it to go. Without it, you lose control. No matter how hard you focus, your casts are carried astray by the wind.

Purpose anchors change.

As Soon As
You know that someone's not going to change when he consistently uses phrases like "As soon as..." or "Once I..."  My favorite is, "As soon as I get into better shape, I'm going to start working out." The likelihood of change occurring decreases significantly when beginning it becomes contingent upon other factors, specially when those other factors are out of the control of the would-be changer (e.g., as soon as I find a girlfriend or as soon as this economy straightens out.)

If you want to change, then act immediately and consistently. You don't have to take big actions, just small steps. However, you gotta start right away.

Attachment Disorder
People often confuse purpose with attachment-to-outcome. It's one thing to have goals or to be goal oriented (purposeful). It's another to make your happiness dependent upon your having achieved those goals (attachment-to-outcome). A common theme among changers who've lost it after having made great progress is that, as they make progress, they begin to attach their happiness to making more progress. Before you know it they become unhappy because they haven't made as much progress as they intended. Rather than celebrating what they did do or simply enjoying the act of doing it, they become unhappy. Unhappiness is the primary reason we give up.

Defend Yourself
I can tell that someone's about to quit her program of change when she begins getting defensive of how well she's doing, specially when she gets defensive in the absence of any offense. People who make lasting change have nothing to defend. They're not doing it to prove they can. They're doing it because they want to.

Take Delight
This last one is really important, at least if you really want change to last. You need to learn how to take delight in whatever it is you're doing. Whether it's taking delight in not-drinking or taking delight in working out or taking delight in listening to others, the key to doing it forever is taking delight in it.

Up To You
Anyway, that's what was on my mind after talking with Brian and Ben last night. I love it when people decide to reinvent themselves in ways that they find truly appealing and desirable. I want to do whatever I can to help them succeed. Perhaps the real challenge is that lasting change is much simpler than it looks. It's one of those situations where you say, "That can't be the answer; it's too easy."

Happy Wednesday,

Tuesday, October 30, 2012


My favorite aspect of our relationship (mine and Iris') is how we manage adventures. We have just the best time when adventuring; we work well together; we complement each other; we laugh a lot.

I think it begins with both of us seeing the adventure in the situation. There are lots of people who see adventure when others see challenge or disaster or impossibility. OK, maybe not lots of people, but certainly some people. However, it's not often that both partners in a relationship are adventurers.

Our mutual enjoyment of adventures is there because we both see them. Further, when one or the other of us has missed the adventure within the challenge, all the other has to do is to say, "Hey, it's an adventure", and before you know it, we're both on the same page.

Seeing the adventure in the challenge changes everything. Any sense of being overwhelmed melts into hope.  The noise of random chaos dissipates, revealing patterns. You remember to flip the coin to see the opportunity that is always on the other side. Challenge becomes fun. Being down by twenty points in the fourth quarter becomes the opportunity of a lifetime. Your world changes.

The change of perspective has a functional impact on results. You see solutions that would have otherwise evaded you or that you wouldn't have seen simply because you weren't looking. You perform tasks better and faster. You learn as you go making your performance even better as the challenges increase. You think more clearly and you have tons of energy.

It's just a perspective, but one that can make a pretty big difference when the odds are against your and others have lost hope. It's not a problem; it's an adventure.

Happy Tuesday,

Saturday, October 27, 2012

That which doesn't kill me ...

To really do justice to the photo above (taken at Houston’s Bush International Airport baggage claim area earlier this month), you‘ll need to imagine upraised arms and a throbbing soundtrack first . That’s because it marks our triumphant return from Rithvik’s first-ever* Expedition to the Old World. Over nine eventful days, he and I covered 20,000 miles all told (air, train and road), sustained by a large support crew of family members at both ends (US and India). In this globalized era where long-haul air travel has become commonplace, a trip like this might not count as significant, but for the aforesaid travelers, it was a whole ‘nuther level of challenge.

* Sowmya assures me that Rithvik has made not one but two trips to India before the age of 3, but in my mind, that was in a previous life.

Given Rithvik’s diagnosis of autism and associated medical issues, specifically his food allergies and asthma, travel has always been a fraught activity for us. Road trips were limited to destinations where we could stay with relatives; hotels were ruled out after a couple of tries. After a hellish experience on a flight to Florida in 2005, we completely swore off air travel. But as he began to mature and make progress with his medical issues, we began a carefully calibrated program to test his flightworthiness. First was a half-hour flight from Houston to Austin in 2009, one way only. He passed with flying colors; no sign of the sound sensitivity that had plagued him up to that point. Then in 2011, with some trepidation, we undertook the 4-hour nonstop flight to visit his cousins in New Jersey. Passed that test easily too. Then, this past summer, we did that trip again, but this time we tacked on a four-week stay, with about 3,000 miles of road trips to destinations as far afield as Virginia Beach, Boston, Montreal, Gettysburg and Washington DC (one highlight being the stop at Great Barrington to visit Iris and Mark). He loved all of it, and we were thrilled to see how well he adapted to the varied company, locations and situations.

Accompanying his journey of growth has been a corresponding expansion of our own capabilities, as his parents. I remember a key moment in early 2010, when to make up for an earlier blunder, I volunteered to take both my kids (then 10 and 7) to the Houston Rodeo. At the time it seemed foolhardy to even consider singlehandedly managing these two easily-overstimulated lads, at Houston’s sprawling multi-stadium complex, through crowds, livestock and rides. But we pulled it off without incident, and we’ve continued to raise the bar ever since.

Of course, all this bar-raising works only on the back of painstaking arrangements made by my devoted wife Sowmya, who is typically exhausted by the end of each trip. So when she first floated the idea of Rithvik making a trip to India, I was ‘volunteered’ to be his sole chaperone. This time, after I picked myself off the floor, cleared out the wax buildup in my ears, and confirmed what I thought I heard, I didn’t feel energized by this chance to conquer another frontier. For some reason, probably due to assorted family factors surrounding this trip, I was having trouble framing the trip in any kind of positive light. Visions sprang up of all the things that could go wrong. Rithvik could have an anaphylactic reaction or severe asthma attack right on the plane! He might have a meltdown in Security or get lost at Frankfurt... He might be in hospital the whole time in India (it's happened to other family members we know)...  And the full doomsday scenario – me returning with just a body bag, violins playing in the background. But all the heaviness and negativity began to drag, and finally, the day before departure, I’d had enough. I decided that if I was going to take the trip, by golly, we’d make it an adventure! And instantly the clouds lifted, the energy returned and all was well again.

Armed to the teeth with preparations, including backups for backups, we set off. On the outbound journey, in my best Red alert mode, I didn’t have much time to take in, let alone explore, the world’s largest airplane, the ginormous A380 with an upper deck running the full length of the plane. The meal arrangements, though not perfect, worked out fine and I found
 myself breathing easier about halfway through the second of the two ten-hour flights. Rithvik took in all the new experiences with wide-eyed anticipation, and even a long wait for our baggage at Chennai airport couldn’t dampen his enthusiasm. My parents were delighted to see him after 6 years, and basically waited on him hand and foot the whole time we were there. Even though his surroundings were night-and-day different from what he’s used to here in the US, he took them in his stride. After two days in Chennai, we took a quintessentially Indian trip by train to Coimbatore (in interior Tamil Nadu), and a day-trip by car the next day deep into rural Kerala for a consultation with a doctor we know. We took the night train back to Chennai - another unique experience – and before we knew it, it was time to pack our suitcases for the return trip to the States, passing through the mini-city that is Frankfurt airport, culminating in that euphoric touchdown.

Three weeks later, in the cold light of day, when I reflect on this whole experience, a variety of thoughts flood my mind, most of which have been explored on these pages over the years. The expansion of one’s comfort zone is by definition uncomfortable, but we have a choice to make that discomfort either comfortable or uncomfortable. The feeling of being overwhelmed can be all too real and an overpowering disincentive to change, but it can evaporate in the face of even one speck of the conviction that it’s good for us. The more often we give ourselves this experience, the stronger those comfort-zone-stretching muscles get. And regular exposure to comfort-zone breakers can really help transform the experience from holding-on-for-dear-life to how-hard-can-this-be. Happy zone stretching!

Thursday, October 25, 2012

The Best Muffin so Far!

Over the last ten weeks or so, I have adjusted my diet to be totally gluten and wheat free and to also avoid spices and molds that my body was responding to. This has really helped to minimize my lifelong intestinal track issues, and I have found many other unexpected side effects like healthier skin, new hair growth, and being more active.

A diet without yeast, means you really cannot trust any processed food. It is amazing how yeast extract has found its way into almost everything you can possibly eat. For fun, take out the packaged foods you ate this morning and look at the tiny letters on the label. If you are not an label reader, you will be surprised what gets added to your cereal, milk and other products.

Anyway, since I cannot rely on any processed products, I have started to bake and cook. After running, cooking has probably been the activity I have avoided most. An area I never felt like addressing living with a fantastic cook. Thank you Mark!

But there is more than just dinner, and like a true Dutchie, I really like to eat some kind of bread to still my early morning hunger. So it was time to learn how to bake. After some experimenting I now have some favorite bread, muffin, pie and lasagna recipes. It has been really fun finding recipes and adjust them to our taste. Read: remove lots of sugar and fat.

This morning I baked another batch of muffins, see picture. They are to die for, and half is gone already. So, I decided that I better share this recipe with you. If you like a moist and not too sweet muffin, I recommend you to try this out. It seems to be the most forgiving recipe ever and I have not been able to make a batch that was not nice. No, they only seem to get better...

Iris’s favorite muffin
Dry ingredients:
3/4 cup buckweat flour
1/2 cup teff flour
¼ cup arrowroot starch
1/4 cup flaxseed meal
2 teaspoons baking powder
1/4 teaspoon baking soda
1/2 teaspoon xanthan gum
3/4 teaspoon salt
1/2 teaspoon cinnamon

Wet ingredients:
1/3 cup safflower oil
1/2 cup applesauce
2 large eggs
1 1/2 cup very mashed ripe bananas (about 2 medium bananas)

Ideas to change it up:
Add 1/2 cup chopped walnuts or berries
Add 1 teaspoon Honey for sweetness
Replace bananas with peanut or almond butter
Use a mix of apples, raisins and cinnamon
Use pine-apple or strawberries

  • Preheat the oven to 375°F. Grease a 12-cup muffin pan
  • Whisk together all the dry ingredients. Set aside.
  • Mix together all wet ingredients. I found it helpful to use the mixer to help add some air into this mix
  • Add the dry ingredients to the wet mixture
  • Use a ladle to quickly fold in additional ingredients like apple, walnuts, raisins etc.
  • Scoop the batter into the cups of the muffin pan. Depending on ingredients your amount of dough can be for 11 – 12 muffins
  • Bake the muffins for about 20 minutes. Remove from the oven and let rest for a couple of minutes before removing from the pan.

Enjoy your meal!


Wednesday, October 24, 2012

Het is Een Mooi Ding

Het is een mooi ding. 

It's dutch for "It's a beautiful thing." 

The "is" has an 's' sound, not a 'z' (at least that is, if you say it as Iris does). "Een" sounds like the 'ane' of propane. Mooi (beautiful) sounds like "boy" with a slight emphasis on the 'y' and 'ding' is pronounced just as you might think. If you wanted to say, "It's a very beautiful thing, you could add the word "heel" which sounds like the english "hale". Het is een heel mooi ding.

Go ahead. Try it. Loosely, it sounds like: Het iss ane hale moy ding.  Het is een heel mooi ding.

I usually use the phrase in conjunction with the word "when". It's a beautiful thing when...

It's a beautiful thing when someone's ice-hard resolve to stay angry melts into vapor. It's a beautiful thing when the blinders drop and what was incomprehensible becomes clear. It's a beautiful thing when the first buds emerge and you know that your long years of labor will indeed yield fruit. It's a beautiful thing when a plan comes together. 

The last one is a misquote of the A-Team's Col. John Hannibal Smith who regularly said, "I love it when a plan comes together." 

On the surface, a plan coming together may not seem beautiful. Other adjectives are more appropriate, e.g., rewarding or satisfying. However, when invoked in the manner of Hannibal Smith, I think beautiful is appropriate. For everyone involved, the details of his plans were never fully clear until they'd been carried out. His plans were at best rough sketches, never detailed drawings. They were riddled with holes and places where either a miracle occurred or they'd just figure it out.

Nonetheless, when the battle was over and his team stood victorious he'd say, "I love it when a plan comes together", as though everything had gone exactly as he'd imagined it. 

For me, it's a beautiful thing when a plan comes together because I'm often as surprised as the next person, not so much in the fact of it having come together, but instead in how it came together. I start so many projects for which I haven't a clue as to how I'm going to actually pull them off. Generally speaking, without a change in circumstance, I won't. Yet start them I will.

I move forward until something stops me. If I can't move through it, I move around it. If I can't move around it, I work on something else until circumstances change. Sometimes the roadblock simply disappears. Sometimes I figure out a new approach. Sometimes someone shows up with a roadblock remover. Serendipity creates a path forward.

Fast-forward a few months, I've completed another impossible project and I think, "It's a beautiful thing when a plan comes together."

Het is een mooi ding als een plan bij elkaar komt.

Happy Wednesday,

Sunday, October 21, 2012

No One at Apple Understands Software (Part II)

In response to No One at Apple Understands Software, Mark K wrote:
So explain it in detail here. I'm fascinated.
For several reasons I thought not to explain here why I believe that no one at Apple understands software. First, it's one of those things you'd like to explain in person so that you can see if people are following you or not. Second, it's one of those things that might only interest two or three people in the world, one of them being me and one of them being Jonathan. Third, by the time I finish writing, Mark K's fascination will surely have passed.

Then I thought of the words of Iris' little friend Quinn who recently took to repeatedly saying, "What the heck!"  After all, if there's anyone who might enjoy a post posthumously, it's Jonathan, and how often is it that Mark K gets fascinated by anything.

So here goes.

A Little Background
The following background is about me. I wrote it for anyone who likes to determine someone's credibility based on what she's done or what others say about her, rather than by simply evaluating what she has to say. You can skip it if you like, or to make it short and sweet, I'll quote a article, The Linux jihad:
As soon as I met Tuomenoksa I realized that this was not your average CEO. A blond, earringed, intense-looking fast talker, it was clear after a few seconds that Mark was a geek, a true hacker. His cred was unimpeachable.
My background in software is unconventional, but then, I'm of a generation of computer scientists in which pretty much everyone's background was unconventional. When I started out, the idea of a university degree in computer science was dubious. People who worked in computer science had degrees in math or engineering or physics or linguistics; it was only the newbies who had actual computer science degrees. While my formal education at Berklee College of Music still placed me in the four-sigma range of backgrounds for computer scientists, it wasn't completely unheard of.

Of course I never actually intended on becoming a computer scientist. I just wanted a day-gig with healthcare benefits. I got a clerical job at Bell Labs where I was the document librarian for a project called 3B5. The pay was good and the company had a great healthcare plan. With a wife and child at home and another child on the way, I felt more than lucky to have the job.

The problem was that I knew next to nothing about computers. Taking notes and recording action-items in meetings, I'd struggle to keep up with all the acronyms, jotting down each one and later seeking out people to decipher them. Since I was, shall we say "desperate" to keep the gig, I decided that I'd better learn something about computers.

After work each day, I'd sit before my TI Silent-700 using a UNIX program called "learn" to learn ed (a line editor), the Bourne shell, a scripting language called AWK and a programming language called C. To put what I learned into practice, I  wrote scripts to automate my clerical job. Within a couple of months I was moved into a testing gig on a skunkworks project called 3B2. Skunkworks being what they are, the testing gig transitioned to driver-development; the driver-development gig transitioned to kernel development.

While working on UNIX kernel, I went to night school at Elmhurst College where I earned a bachelor of science in Computer Science. After we shipped the 3B2, the company put me into a program called OYOC (one year on campus). My wife Rene, our three kids and I all moved to Champaign-Urbana for eight months while I earned masters degree in Computer Science. My degree in hand, we headed to New Jersey.

A few years later, I led a skunkworks to develop a binary-translation system that could (among other things) translate Macintosh to run on SPARC (I had SPARC-stations with serial numbers 00000004-0000007) or MIPS. Turns out that applications generated by our translation system not only exactly preserved the semantics of the originals, but they also ran about five times faster. The system worked so well that the folks at Apple decided to use it to migrate stranded Mac applications from the Motorola 68000 to PowerPC.

Since what we were doing was commonly considered impossible, a group from research was asked to audit our project. Among that team were Al Aho, Peter Weinberger and  Brian Kernighan (the A, W and K of AWK with Brian being the co-author of a programming language called 'C'). Not long after the audit, I was invited to join basic research.

My first boss in research, Tom London and his partner John Reiser developed what we called VAX-UNIX (the UNIX operating system that ran on Digital Equipment's VAX 11/780 minicomputer). Tom's the guy who flew to Berkley (the other one) with an OS tape in hand and gave it to Bill Joy who went on to create Berkley UNIX and to found Sun Microsystems. Working with Tom was fun. We daily came up with ideas that would change the world.

Over the years I've developed operating systems, compilers, and embedded systems. I've written applications for the PC, the Mac, IOS, UNIX and even implantable medical devices. I was CTO and VP of Marketing at small-cap public company in Boston that we sold to Intel. I founded an Internet security company for which I raised fifty-three million dollars in venture capital. I've been granted eleven software patents.

Mainly though, I like to code. Strike that. I love to code.

No One Understands
Enough about me; let's talk about what I think. In particular, I want to make sure that we're clear on what I mean by "No One at Apple Understands Software", or perhaps, what I don't mean. I don't mean that know one at Apple knows about software. I'm sure that most of the software developers there know much more about software than I do. It's just that, from everything I've seen of late, no one actually "gets" it.

I'd liken the phenomenon to an expert guitar player who can't tune his instrument without a tuner or a pianist who can't play without sheet music. Believe it or not, there are many of each. They can play fast. They can play cleanly. The guitarist knows her gear up and down. Yet she doesn't hear when a chord is slightly out of tune because one or more fingers are stretching a string just a bit too far. The pianist can play from pages black with notes, yet he doesn't hear that his time drifts.

Despite how well they play, despite all they know, they don't quite understand music because they don't quite hear music. You record them and they sound great. However you can't use the recording because when you put it in the mix with other instruments the guitarist's pitch doesn't match that of the horn section, the pianist's hits are not in sync with the drummer's.

Similarly, there are programmers that can tell you about every nuance of a programming language. They can recite command line arguments to the most obscure UNIX or DOS commands. Yet, when you look at their code, something is off. It's out of tune, out of sync. The naming of elements and levels of detail are inconsistent. Their code is so verbose that it's nearly impossible to determine or maintain context at a glance. They miss opportunities for abstraction, repeating long sections of code that perform the same functions, but on the surface appear different.

They know all about software and programs, but they don't quite get it.

Which Harry?
In many ways, writing a program is like writing a story; each of the characters must have a name that distinguishes her from the other characters. In a program the characters are items like variables and constants, classes and structures, functions and procedures. When you create any one of these, you must name it so that you can refer to it in your code. The name can be pretty much anything you like, it just needs to be unique within the context in which you're working.

For example, if you want to keep track of how many times you've done something, you can create a variable called count or counter. Each time you do the thing, you might have a line of code that says: count = count + 1.  Easy, right.

What happens if you need to simultaneously keep track of more than one count? You'll need more than one variable. However, they can't have the same name. So, you might have count_1 and count_2 or countA and countB. When you complete an iteration of taskA you write the code: countA = countA+1; when you complete an iteration of taskB, you write: taskB = taskB+1.

What happens when your programming partner also has tasks A and B and uses the same naming convention? Well, it's kind of like what happens when you have a band with three guys named Harry. You have to determine a way to distinguish Harry from Harry from Harry. You might have HarryTheDrummer and HarryTheGuitarist and HarryTheSinger. If two of the Harry's play drums, then you might have HarryTheDrummerWithRedHair and HarryTheDrummerWithBlackHair.

Anything that belonged to a harry (e.g., a counter) would include that Harry's name to distinguish it, e.g., WalletOfHarryTheDrummerWithRedHair or CounterOfHarryTheDrummerWithBlackHair.

When rehearsal's over and the Harrys go home, each returns to being just Harry. There's only one Harry in the house. At Harry's house, to distinguish Harry's wallet from Frank's, you can refer to it just as WalletOfHarry, not WalletOfHarryTheDrummerWithRedHair and of course, when Harry's by himself or talking about his wallet, he can use just MyWallet.

What happens at a battle of the bands where you never know if another band may have a HarryTheDrummerWithRedHair? How do you distinguish them? One way is to use the band's name along with the person's name. HarryTheDrummerWithRedHair becomes HarryTheDrummerWithRedHairOfTheThreeHarrysBand versus HarryTheDrummerWithRedHairOfTheTwoHarrysBand. The broader the context, the longer the name. The narrower the context, the shorter the name. In the battle of the bands, naming things could get pretty cumbersome.

What's this got to do with Apple? Keep reading.

In the early days of programming languages, there were no contexts for names. Every name in a program could be referenced in every part of a program. There were no homes or band rehearsals; everything was the battle of the bands. So you had to use names like HarryTheDrummerWithRedHairOfTheThreeHarrysBand and CounterOfHarryTheDrummerWithRedHairOfTheThreeHarrysBand. The problem was that computers didn't have a whole lot of memory and a name like CounterOfHarryTheDrummerWithRedHairOfTheThreeHarrysBand was untenable (not to mention prone to errors). To preserve memory, names had to be short. So, for example, CounterOfHarryTheDrummerWithRedHairOfTheThreeHarrysBand might simply become i and CounterOfHarryTheDrummerWithBlackHairOfTheThreeHarrysBand might become j. This worked pretty well as long as you knew what i meant and what j meant. If a program was small, remembering i and j wasn't too difficult. However, as programs grew, it could become problematic.

Another problem was that no matter what you called it, each program element took up memory. To save memory you would reuse elements. At one point in the program, i might be used to count snare-drum hits.  In another it might be used to count bottles of beer. This worked as long as you never tried to count snare-drum-hits per bottle-of-beer. If you did, then you needed to add another counter, say k.

So, not only did the name i tell you nothing about what i was or did, but what it was or did could change from moment to moment.

You Can Call Me Al
As program languages developed and as computers became bigger and faster, the problem of having names that were too long or too short to be manageable went away. The primary improvement (first through the introduction of structured programming and continued in the development of object-oriented programming) was the creation of structures (classes and objects) that created contexts for the use of names.

With languages such as C and Pascal, programmers could define reusable structures suitable to the needs of their programs. Each language provided basic structures or types (e.g., constants, variables, integer and decimal numbers, text strings, lists or arrays, data structures, and data types) from which other structures and types could be built. Each data structure provided a context in which names could be created without concern that they might have been used elsewhere.

For example, every single structure could have a counter named counter or a counter named i. For that matter one structure could use i as a counter and another could use i as a text string. It didn't matter, because each structure was a sovereign domain for names.

When the elements of one needed to combine values from two different structures to compute a value (e.g., the ratio of drum hits to beer bottles), one could reference both values by naming the instance of its structure (e.g., hits.count / bottles.count). The new languages made it possible to implement meaningful names that were also manageable and easy to use.

So what does all this have to do with no one at Apple understanding software? Although Apple's programming environment is based on the C++ language (developed by Bjarne Stroustrup who worked for Al Aho at Bell Labs) and although Apple's OSX is built on UNIX, the Apple development environment and coding examples provided still use names like BandsInTheBerkshires.SKABandsInGreatBarrington.ThisSKABand.ThisSkaBandDrummers.HarryTheDrummerWithRedHair.NumberOfDrumHits. 

OK, that's slightly exaggerated, but not much. Sure, the programs work. Sure, from reading a variable's name, you can tell what it's about. However, when good programmers see names that are overly long and/or filled with redundant information or information that could be garnered from the context, they respond as a musician would to an out of tune solo or as most would to nails being scraped along a chalkboard.

Context, Context, Context
There are many problems with overly long names. First they're difficult to remember and therefor use, specially when you must learn a different term for the same element based upon the structure in which it is used.

Second, their use is error-prone, specially when you have two twenty-character names that differ in only the nineteenth character. Sure, to help reduce errors and increase speed, the programming environment offers lists of names that match what you typed thus far. However, when good programmers work with well written programs, this kind of function is never needed.

Third, overly-long names make it nearly impossible to intuit how to use a structure. With well written programs, you get an immediate sense of how the programmer used names. Once you've got it, you can pretty much do everything you need to do without looking up anything. There are instances of this in the Apple environment, but they're by no means common let alone pervasive.

Fourth (and perhaps most importantly), shorter names allow you to fit more context on your screen. The more context you can see simultaneously, the shorter the names can be. If for example, you write a section of code that runs through a list of items counting the ones that are checked, and the entire section easily fits on the screen, then using the name i works. You don't need to tell anyone that i is a counter because anyone looking at the code can see the entire lifespan of i.

Seeing the semantic of context is to programming what hearing chordal structures is to music. A dominant -7 chord has a distinctive sound regardless of the key in which it's played. A sharp-9 chord is easily distinguished from an augmented-fifth chord. You don't have break the chord down into its individual elements arpeggiating  them one by one to know which chord is being played. You wouldn't want to because it would just slow you down. You hear the notes all at once, and from the color of the context, you know the chord and you know the role of each of the notes. There are musicians who hear music this way and there are people who don't.

There are programmers who can look at a section of code and, without working line-by-line through each of the details, see what the code does, just as a musician would hear a chord and immediately know its structure. For them, the most important thing is brevity and consistency. These programmers are often ten-times more productive than people who don't look at and see code in the same way. It's easy to tell which type of programmer an organization employs; you can see it in the software they produce.

I Could Go On
There are lots of other little indicators that no one at Apple understands software. I'll give you a couple of them and then I'll stop.

There's the demise of the 17" MacBook Pro. It's something lamented by every good programmer I know. There are two reasons for this. Real programmers are all about context; big screens mean more context. Sure, you could move to a tower/desktop system and use an external monitor, but then you'd have to use a mouse or track ball. That leads us to the second reason.

In my experience, there's nothing faster than a keyboard with an integrated trackpad. You can type with both hands, move the cursor, scroll and click, all without changing hand positions. To move one or the other hand away from the keyboard and back slows you down, specially when it's happening every couple of seconds. This may not seem like a big thing for your average computer user, but when your working as fast as you can to keep up with your mind's production of code, little things like this can be a real problem.

With the demise of the 17" MacBook, it would seem that no at Apple gets this, though of course it could be that they do but just don't care. From a marketing and profitability perspective, it might make perfect sense to discontinue the model. However, from a programmer's perspective, it's a disaster.

The last thing I'll reference is simply how buggy the Mac's code has become of late. I've seen lots of companies go through a process we used to call "losing control of the base". It occurs when the software core becomes overpopulated with bad code. Oftentimes each of the individual modules work, but when you bring them together, the interactions among them cause problems that are nearly impossible to trace. Microsoft lost control of their base with Vista and it took them a long time to reign it back in. Apple seems to have lost control of their base, at least large portions thereof.

That's All for Now
If you've read this far and are not Jonathan, I guess I've got one question. Why? I don't mean it factiously. It's just that I'd be amazed that anyone would be interested enough to read all this or that they wouldn't see all this as lunatic ramblings.

For me, it's been fun to write why I think no one at Apple understands software. I love coding as much as I love playing music. If I could figure out a way to do it for an audience, I might like it even better than music. It might seem a bit bizarre or silly, but this kind of stuff matters to me.  Thanks for listening.

Happy Sunday,

Friday, October 19, 2012

Cut Some Slack Friday

Here we are again. Time for another Cut-Someone-Some-Slack Friday.

What is Cut-Someone-Some-Slack Friday? It's a day to let it slide, give someone a pass, allow someone to catch her breath and try again. It's day where you recognize that all that stuff that seems so important is, well, not so important as it seems.

It's also a day to look away from what's not there and look at what is there, to shift your focus from the 2% that's incomplete to the 98% that is well done. It's a chance to celebrate all someone did even if he didn't do all that he intended.

The best part about Cut-Someone-Some-Slack Friday is that it starts with you cutting yourself some slack. It's a well-documented fact that you can't effectively cut slack for others if you can't do it for yourself. You can try, but you'll end up with a strange side-effects and a funny aftertaste. Nope, to effectively cut slack for others, you must begin with you.

So, what slack will you cut today? What disappointment will you magically transform into accomplishment and celebration? How will you celebrate Cut-Someone-Some-Slack Friday?

Happy Friday,

Tuesday, October 16, 2012

Shame-Free Tuesday

Think of that of which you're most ashamed. Perhaps you betrayed a trust. Maybe you screwed up when everyone was counting on you. It could be a secret that you've kept for years and are too embarrassed to share with anyone. It might be something that you do all the time and hope that no one ever discovers.

For me, shame always comes down to my being in one of three states: an idiot, an ass or just bad. All shame can be traced to one of them and bad overlaps the other two. So, for now, we can just go with idiot and ass.

The distinction between idiot and ass is one of intent. For example, driving in the left lane, 20mph below the speed limit and not realizing that you're leading a parade of would be passersby would qualify as idiot whereas driving in the left lane, 20mph below the speed limit to annoy the guy behind you would qualify as ass.

The characteristics of my ill-fated exploits are pretty much evenly split between idiot and ass with a slight favoring of idiot, though given my general level of intensity, others would likely characterize the vast majority as ass.

Either way, one thing is certain; when you come to the realization that you've been an idiot or an ass, a likely response is to feel ashamed. You can use other words like embarrassed, bad, guilty or wrong, but the point is that you likely feel badly about yourself. If you don't feel ashamed or if you feel insufficiently ashamed, then others will assist you in doing so.

To eradicate the bad feelings of being ashamed you berate yourself. You become contrite. You promise never to do it again. You apologize profusely and repeatedly. You decide that you're just not good enough and never should have tried. You might become sullen or even angry.

So there's a cycle that goes:

The reason I say cycle is that the recovery techniques often lead to more ass/idiot phenomena. You make a mistake. To avoid future mistakes, you feel ashamed. To recover from feeling ashamed you do things that increase the likelihood of making another mistake.

Why do these things to recover? To feel better.

To feel better from what? From feeling ashamed.

But who made you feel ashamed? You did.

Sure, others may assist you in shame, but it only works if you buy into it yourself.

So shame doesn't actually work very well. It's a distraction and a hindrance.

What would happen if you were and idiot or an ass, but you didn't feel ashamed? Would you continue making the same mistake? In the absence of feeling badly, what would cause you to change?

The funny thing is that the absence of shame increases the likelihood of doing better. Shame doesn't help you to see your mistakes clearly; it shrouds them in haze and causes you to avert your eyes. Being unashamed by mistakes allows you to see your them more clearly and to respond better when others point them out. Seeing mistakes more clearly allows you to analyze and deal with them. Not being hindered by the shame-recovery process frees you to deal with them more effectively.

Without shame, a mistake is just a mistake. You can stop yourself in mid-sentence and say, "Wait a minute. I am being such ass. Let's start over, shall we?"

Think of all the time you might save if you were never to succumb to shame or if you were never to aid others in succumbing to shame.

Big shame, little shame, it doesn't matter. How about making today shame-free. Each time you make a mistake, rather than feeling badly, just say to yourself, "Oh well, I was doing the best I could. Let's take a step back and try again, shall we?"

Happy Shame-Free Tuesday,

Monday, October 15, 2012

A Thought for Today

An adventure is only an inconvenience rightly considered. 

An inconvenience is an adventure wrongly considered.

G. K. Chesterton

Friday, October 12, 2012

No One at Apple Understands Software

There's a great little book that I recommend to anyone who's ever found themselves at odds with traditional learning methods or formal education. The title is Surely You're Joking, Mr. Feynman! (Adventures of a Curious Character) by Richard P. Feynman. It's a fun and easy read and it provides a perspective on learning and understanding that could completely change how you think about, well, everything.

About the book, the New York Times reviewer wrote:
"In this phenomenal national bestseller, the Nobel Prize­-winning physicist Richard P. Feynman recounts in his inimitable voice his adventures trading ideas on atomic physics with Einstein and Bohr and ideas on gambling with Nick the Greek, painting a naked female toreador, accompanying a ballet on his bongo drums and much else of an eyebrow-raising and hilarious nature."

If you haven't read it, do.

I've been thinking about Feynman lately as I've been developing software for the iPhone and iPad. Learning the programming environment and working through all examples I've come to the conclusion that no one at Apple actually understands the nature of software design.

This seems a bizarre statement. Apple is a huge, successful company that depends on its software. Their systems are admired and emulated the world-over. Yet looking through the examples they provide on how to develop programs and working through the complexity and redundancy in their systems, I'm pretty sure that no one there fully understands software.

Again, this probably sounds bizarre or presumptuous. OK, forget the probably. It's a ridiculous statement, one that I would dismiss except for my having read Surely You're Joking Mr. Feynman.

Feynman came to love Salsa and wanted to learn to play. He decided that there was no better place to learn than Rio De Janeiro. So he took part in a state-department-sponsored exchange program where he would teach physics in Brazil. Brazil would get a nobel-prize winning physicist to teach their top graduate students and Feynman would get to play bongos with a Salsa band.

When fine arrived in Brazil, his students were bright, energetic and engaged, hanging on his every word. They were the cream of the crop in Brazilian physics. He taught them according to the course syllabus he'd been provided. However, when it came time for the first exam, he decided to throw in some questions of his own. Ones that related to the material, but were not taken directly from the examples.

The entire class failed the exam.

Reviewing the test results, Feynman wondered what he'd done wrong. Perhaps his questions hadn't been clear. Perhaps he'd made leaps in logic that were flawed. He engaged his class in discussion, asking them questions about topics they'd covered, using the examples from the book. Hands went up. Students responded with correct answers.

He asked the questions again, but this time using a different context and different examples. No hands. No answers.

Feynman realized that the students had learned physics by rote as one might learn spelling or history or even mathematical formuli; none of them actually understood physics. Concerned, he approached the chair of the university's physics department. As he explained his concern, he realized that the chair of the department didn't understand physics either.

Eventually Feynman came to the conclusion that no one teaching physics in Brazil actually understood it. It wasn't that they were bad or not smart. It's just that they didn't understand some very basic principles of learning and understanding. The effect was systemic and therefore, pervasive. It's one of those things about systems that can be so hard to grasp. From computers to economics to education to governments, when systems fail, they fail completely. It's just their nature.

At the end of the academic year, Feynman was asked by his students to give a talk about his time in Brazil. Given his prestige, the audience would include not only students, but professors, administrators and government officials. Feynman asked if he could say whatever he wanted and was told, 'yes'. Feynman explained what he'd discovered; his words were received and considered.

Any way, working on iPhone apps over the past weeks got me to thinking about Feynman. I don't have  anything like a Nobel Prize in software, but I think I could explain why I believe that no one at Apple understands software to someone who wanted to hear about it. I'm just not sure of to whom I'd explain it, and of course, no one there has asked me to give a talk.

Happy Friday,

Thursday, October 11, 2012

What You Didn't Do

Yesterday morning, Iris and I got up early. We had a lot to do.

Iris starts off a little more slowly than she wants. It's one of those walk-into-a-room-and-then-try-to-remember-why-you-did-so type of mornings.

As I work at my desk, I catch Iris passing back and forth through my field of vision. She walks to various points in the room, pauses for a moment as if to think, and then pulls a 180.

A half hour passes. I look up from my Mac to see Iris standing before my desk. Seems that she has something to say. I stop typing and give her my attention.

She looks at me. I look at her. That's it.

I notice that she only seems to be looking at me.  Her eyes appear to be focused on me. However they don't follow my movements. Her expression is set in stone and there's a distance in her gaze.

I wave my hand in front of her face.

She regains consciousness.

"Adderall?", I ask.

"Oh yeah, Adderall.  This is the fifth time I've walked in here to take my Adderall. Where's my purse?"

Iris rummages about the office seeking her purse, finds some errant socks, picks them up and heads toward the laundry room.

I call out after her, "Adderral! Purse is hanging on the back of the door."

"Oh, yeah."

I monitor Iris' progress. She finds purse and retrieves the prescription bottle. She takes out a pill and heads into the bathroom to get water.

From the bathroom, I hear the water running and then, to relieve me from my watch, "I took it!"

Fifteen minutes later, Iris sits across from me typing. She works her way through her list of todo's trying not to interrupt me with questions, comments or the sound effects that she emanates when reading. Another fifteen minutes passes and she succeeds: no more interruptions.

An hour passes and she's out the door to stack wood and clear the driveway of leaves. An hour after that I hear her up in the kitchen cleaning out the fridge and washing dishes. A bit later and she's down in the office again, grabbing her coat and heading out the door to visit her friend Quinn.

I walk over to kiss her good-bye and I say, "Hey, you had a great morning. You really got a lot done."

Tossing her bag over her shoulder she says, "I don't know. I didn't finish the wood and I still have a stack of papers to go through."

"Say what?"

"I just don't feel like I did that much."

"Who are you and what have you done with Iris?"

"What do you mean?"

"I think it's good you're going to see Quinn. You could use a little Zen-mastering."

Iris looks at me and smiles. "Oh yeah, I guess I could celebrate what I did do."

"Yeah, you did a great job!"

"I did. I did a great job. Yippee!"

Laughing, we bask in the glory of Iris' morning's accomplishments, listing them one by one. Iris starts with the email she got out. I roll it back to making the bed. She smiles and says, "You forgot getting out of bed."

What did you forget to celebrate today?

Happy Thursday,

Friday, October 5, 2012

What Comes Naturally

Don't you think that there are some people who are just meant to play music and others who aren't?

What do you mean?

You know, like there are people who pick up an instrument and before you know it, they're playing it. Other people work at it for years and never seem to get it. Some people sing like birds and others can't carry a tune in a bucket.

So you're saying that the people who get it quickly are meant to do it and the others are not?

Well yeah, I mean, it sure seems that way, right?

I agree that different things seem to come more quickly to different people, but...

But, what?

I don't know that it says anything about their potential to do the things that don't come quickly.

Like, if they kept going, they could do just as well as someone who got it quickly?

Yeah, something like that.

But, it seems that there are things that come naturally and things that don't. Shouldn't we go after the natural things? I mean, it'd be going against nature to try to do something else, right?

I don't... um... hmm... You drive a car don't you?

Sure, every day.

And when you drive, are you constantly thinking about where the gas and brake pedals are, where the gear shift is, and how to coordinate them.

No, of course not.

So driving feels pretty natural to you, even intuitive? Your body knows what to do so well that you can talk on the phone or listen to the radio?

Yeah, sure. What's your point?

Was it that way the first time you drove?

You mean, like the very first time?

Yeah, the very first time.

Well, um, no. My dad took me driving and we had to stop every five minutes so that he could get out of the car and smoke a cigarette to calm his nerves. Thank god he smoked, otherwise he might of killed me.

So driving didn't come right away? It took some time?

Yeah, sure.

And now it feels natural?

Yeah, so...  Ooooh, I get it. Just because it doesn't come naturally doesn't mean it can't become natural?

Yup, something like that.

So you're saying that, even though I've never been able to play trumpet, if I stuck with it, I could become as good as if it came right away?

Yeah, something like that.

But what about all the people who have stuck with it and it never got natural?

Bad training.


Bad training. It's not their fault. Well, only partially their fault. A good teacher is one who can help you transform something that feels foreign into something that feels natural. It's your job to find the right one and then really do what she says.

OK, so then what about some things coming naturally and some things not? What does that mean?

Whatever you want it to mean.

You mean, I can make it mean anything I want it to?

Yup, like pretty much everything else.


Happy Friday,

Thursday, October 4, 2012

Bad Idea or Bad Execution?

Have you ever tried something new (perhaps at the suggestion of someone whom you trusted, but thereafter no longer did) and afterwards thought, "Well, that was a bad idea!"

The thought might have been accompanied by a companion such as, "I'm never going to do that again!"

Maybe "ever" is to infrequent. How often do you or how many times have you tried something and afterwards thought, "Well that was a bad idea!"

Why did you think that? No doubt what you attempted didn't go according to plan or work as well as promised. Perhaps it had undesirable side-effects such as embarrassment or paint drops all over the persian rug. Perhaps the psycho-emotional experience was too intense.

All these are common reasons that one might conclude that something was a bad idea. However, they're not actually reasonable reasons. They're associative reasons. Not working as planned, feeling embarrassed afterwards, or having undesirable side-effects are all good reasons not to want to try something again. However, they don't make the something a bad idea.

There are actually three possibilities: 1) the idea was bad, 2) a good idea wasn't implemented very well, or 3)  a bad idea wasn't implemented very well. (Note: the last one can actually turn out OK).

Sure, there are bad ideas, e.g, chick-sashimi or line-dancing with buffalo. However, many good ideas get a bad rap because they weren't implemented well.

The problem is that we often confuse "bad idea" with "bad execution". If you're concerned about things like being embarrassed or if you're trying to prove a point, there's incentive to confuse them. Fact is, not-working-out doesn't necessarily mean that something was a bad idea. By itself, it doesn't prove a thing other than, it didn't work out.

My friend Jonathan and I used to look through old technical journals to find good ideas that were dismissed as bad because they couldn't be implemented with the technology at the time they were conceived. It's amazing how many there are. For example, the patents on the cellular technology used pervasively today expired twenty years before they could be implemented.

There are gazillions of good ideas that have been tried and dismissed as bad ideas; they weren't, they were just poorly implemented. No doubt, each of us have tried thousands of bad ideas that aren't bad.

How can you tell? Hmm... Good question. I guess one way is to ask whether or not it would have worked if something skilled had tried it. Would it have worked if Michael Jordan tried it or if Shaun White tried it or if BB King tried it?

If the answer is "yes", then it's probably a good idea suffering from bad execution. Jonathan always used this approach with apparel; something was bad if "not even Sean Connery could make that look cool."

Anyway, if you've run out of good ideas, you might have a bunch of them lying on the refuse heap just waiting to be tried again.

Happy Thursday,

Wednesday, October 3, 2012

Our Driveway

Our driveway is a great friend-filter. There are times when we know that the people visiting us, must have really wanted to see us.

In the best of conditions, it's steep and narrow. In the worst, it's traversed by miniature versions of the Grand Canyon or it takes on the form of a down-hill skating rink.

There are times when incident-free passage becomes so questionable that  Iris and I leave our cars at the bottom of the steepest section that starts about halfway up and walk the remaining quarter mile to the our house at the top. Walking at night, it can get so dark that you can't see your hand in front of your face. You have to sense with your feet where you are on the roadway. If you've lived in the suburbs or in the city, you come to realize that it never actually gets dark there.

There are times when passage has indeed resulted in incident. Iris, Mark K, Scott and the home inspector each managed to slide backwards down the driveway while heading up to the house, there cars coming to rest in pretty much the same place just off to the side.

Our driveway loves snow and snow loves it. They cling to one-another like honey on molasses. When the snow falls, you  have to plow every hour or so just to make sure that the icy love affair doesn't turn into one of those infatuations where there's no room for anyone else.

Our driveway is scenic. Over the half-mile from the road to the house, it climbs along a ridge-line that rises steeply to the left, the road dropping precipitously to the right. The rising and falling slopes are covered with wild grasses to prevent erosion. However, in late summer and early autumn, they're dense with yellow coneflower and evening primrose and white aster. As it rises, the grasses and wildflowers are displaced by dense thickets of trees. Halfway up, it veers left into the trees, zigzagging the remaining distance to the top.

Our driveway lives in two states and three towns. The steepest part is bisected by the Massachusetts/New York border. On your way from the road to our house in South Egremont Mass, you pass through both Copake and Hillsdale New York. If you drive all the way to the top, while you're in the house in Massachusetts, your car will still likely be in New York.

Our driveway is intense and varied, which seems oddly appropriate. It's an experience unto itself, perhaps alone worth the visit.

I love our driveway. It's awesome.

Happy Wednesday,


Monday, October 1, 2012

Your Safe Place

Yesterday during rehearsal, as we discussed learning, teaching and coaching, Will pointed out that in his experience, one of the most important things for a teacher to do is to create a safe place for people to try what they're being taught. You want to create and environment that encourages experimentation and exploration, one in which there is no shame in trying and not succeeding.

I've been thinking about Will's words since then. I agree with them. People are more open to learning when they feel safe and accepted. We all seem to perform better when relaxed and clear and an environment that feels safe makes it easier to do so.

When I think about Iris working with kids, I'd have to say that the corner stone of what she does is to create an environment that feels safe and secure. Her approach goes beyond providing a sense of being accepted. There's something about her level of focus, her in-tune responsiveness and plain old confidence that puts kids at ease.

I'm definitely not a fan of guilt and shame as motivators. It's not that I'm altruistic; I just don't trust them and I don't like what they yield in terms of relationships.

When I think about environments for myself, it occurs to me that it's not so much about feeling safe as it is about not being distracted by people with agenda other than my learning.

All that said, there was something about creating a safe haven that nags at me. It's one of those I-agree-but-I-disagree scenarios where I can't put my finger on the "what" with which I disagree. For example, I know that there are times when not feeling completely safe is a necessary component of optimal performance. Your adrenaline kicks in, your senses become hyper-aware, etc. However, that isn't what's nagging at me.

Hmmm...  What about all the kids growing up in the US who have an increased likelihood of being run over by a car should they ever travel elsewhere in the world because they've come to believe that cars should stop every time they step into the street. I guess I would cast this as an artificial (or perhaps, false) sense of safety. But that isn't it either.

OK, here it is. It occurs to me that the best safe place is the one that goes with you. Ideally, you would teach someone to know how to feel safe and secure independent of the situation, to know what she's about regardless of what others might say, to have confidence to spare no matter what parts of her plan fail, to know that she's OK, period.

Of course, I have no idea how you teach that other than to provide opportunities to try it. So I guess it comes down to this. I love the idea of creating and maintaining a safe place for learning; I just don't like the idea of it becoming a necessary condition for learning.

So what do you do?

Happy Monday,