communication

Are We Smart Enough to Use Kind Words?

My title might seem oddly out of place on a tech blog, but a slashdot post today led me to an email thread for linux kernel developers, and the thread and its fallout leave me troubled.

Apparently, a veteran contributor is leaving the kernel dev community because she feels like the communication style there is too harsh. This is unfortunate, but what seems even more lamentable to me is the lack of sympathy in Linus Torvalds’ reaction. It seems to me that his attitude is: “That’s just the way us kernel devs are, and we aren’t going to change to accommodate anybody. If you can’t take the heat, get out of the kitchen.”

This feels sad to me. Kind words can be such a joy.

Secret 3
[Image credit: Glen J. Photography (Flickr)]

Linus is a brilliant guy, and I’m grateful to him. I use linux and git every day; the tools he’s built do a lot of good in the world, and they replace earlier approaches that are clearly inferior. I also agree with his complaint that an explicit standard of “professionalism” in communication can, in some cases, lead to opacity, disingenuousness, and inefficiency. Sometimes we need to say things that are difficult for others to hear, and we need to say them quickly–and that may not jibe with the communication style of a slick politician.

However, I find it ironic that a profession so passionate about message passing and interfaces and producer/consumer contracts could lightly dismiss communication concerns when they involve humans. Do the messes created by DDoS, attackers probing vulnerabilities, and poorly behaved clients teach us nothing?

We certainly need clarity in our careers, and we may occasionally need bluntness as well, but we don’t need ridicule, sarcasm, or disdain. I applaud the sentiments of Marvin J. Ashton:

Continue reading →

Exploring the Power of Deixis

The other day my daughter was in the backseat as I pulled out of the driveway, and she instructed me to “turn that mirror over here.”

“Which mirror?” I asked.

“That one,” she said, without any clarification.

Image credit: fofie57 (Flickr)

“Which one?” I said again. “I don’t know what you mean when you say ‘that’…”

Eventually I cracked the teenage code and tilted the center rearview mirror toward her so she could check her makeup. :-) But it was harder than it should have been.

A lot of frustration could have been avoided if I could have turned around to face her to see which direction her eyes were pointing–or if she’d just stretched out her finger.

Deixis

In linguistics, deixis is a sort of pointing—the juxtaposition of something against a reference context to provide meaning. Although we can define words like “here” and “there” in the abstract, their specific meaning always depends on the physical or metaphorical location of the speaker when they’re used. Likewise, “now” and “then” are deictic with respect to the time of an utterance; pronouns like “we” and “you” use deixis that relies on interpersonal context; honorifics are deictic with respect to cultural relationships.

Since the web now permeates our collective experience, think of deixis as a kind of hyperlink. Imagine if I had written my daughter’s sentence like this: “Turn that mirror over here.” It sorta fits, doesn’t it?

Continue reading →

Add some more extra redundancy again

It’s the season for coughs and sniffles, and last week I took my turn. I went to bed one night with a stuffy nose, and it got me thinking about software.

What’s the connection between sniffles and software, you ask?

Let’s talk redundancy. It’s a familiar technique in software design, but I believe we compartmentalize it too much under the special topic of “high availability”–as if only when that’s an explicit requirement do we need to pay any attention.

Redundancy can be a big deal. Image credit: ydant (Flickr)

Redundancy in nature

Mother Nature’s use of redundancy is so pervasive that we may not even realize it’s at work. We could learn a thing or two from how she weaves it–seamlessly, consistently, tenaciously–into the tapestry of life.

Redundancy had everything to do with the fact that I didn’t asphyxiate as I slept with a cold. People have more than one sinus, so sleeping with a few of them plugged up isn’t life-threatening. If nose breathing isn’t an option, we can always open our mouths. We have two lungs, not one–and each consists of huge numbers of alveoli that does part of the work of exchanging oxygen and carbon dioxide. Continue reading →

Steve Jackson: Lead with Passion

guest post[Note from Daniel: This guest post, from my friend Steve Tolman, is part of an occasional series about important career role models. I also worked with Steve Jackson, and I agree with Tolman that his energy and dedication instilled many great skills in those who worked on his teams.]

While I worked at PowerQuest, and Symantec after its acquisition of PowerQuest, I worked with a man named Steve Jackson.  He started somewhere around 1999 or 2000.  In our organization we had about seven or 8 Steves so we all went by our last names.  I was simply, “Tolman” and he was “Jackson.”

Jackson was the director and VP of all software engineering.  He was my manager and quickly became my friend.  He took his job very seriously and I learned a great deal from him.

By the time I left the team in 2008, I had learned how to run a team, how to build and release software, and how to work well with people.  One of my peers, Lane Johnson (one of the best managers I have ever known, who left the team at the same time) asked me what it was that made Jackson so dang good.  We thought about it for a while and concluded that there was not that proverbial one-thing-you-need-to-know that made him great, but more along the lines of about a bazillion qualities.  A little time brainstorming gave us a list of 45 different skills, techniques, or approaches.  Here are just a few of the highlights.

Believe in the individual

Jackson’s default mode was to trust people.  Trust them to fit into the team and trust them to do their job, but expect them to do a stand-up job for you.  Get the right people on the bus (read the book Good to Great for more info), give them an assignment, then get the heck out of their way and let them shine.  Continue reading →

Convoys as a model for distributed architectures

It occurred to me this past week that convoys–especially the kind where truckers form and manage ad hoc communities through chatter on CB radio–are an excellent model for the sort of distributed software architecture that cloud-native software demands. In part 2 of my series of posts about how to “cloudify” your code and designs on Adaptive Computing’s website, I discuss the lessons that programmers ought to absorb from their role models in big rigs. Head over there and check it out.

Convoys require frequent, real-time, adaptive coordination by many independent actors. Photo credit: Sangudo (Flickr)

Stay tuned for further installments of this series each Friday. As I said in Part 1, I believe that a competence with cloud–cloud-oriented programming, if you will–will be a checkbox on future tech resumes.