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.
[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:
[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
In Douglas Adams‘ novel, Life, the Universe, and Everything, a spaceship lands in the middle of a stadium of screaming fans during a cricket match, and nobody notices. The ship doesn’t use a Klingon-style cloaking device to accomplish this amazing feat; instead, it is hidden by a “Somebody Else’s Problem” field, which operates on the principle that if something is perceived to be somebody else’s problem, the brain of onlookers will treat it as if it were invisible.
Adams was a sci-fi author, but I see applications of his metaphor in the day-to-day work of software engineering.
To one degree or another, we all exhibit inattentional blindness from time to time. And that can be a good thing. Being able to zero in on a particular block of code, to the exclusion of the guy sneezing or yawning in the next cube, is healthy. We don’t want to be like the dogs in Pixar’s Up!, who keep getting distracted by squirrels.
However, truly superb engineers have a capacity to see through the cloak of somebody else’s problem; they think simultaneously on multiple levels of abstraction. They tend to ask “meta questions” (judiciously) that poke at larger issues, broader contexts, or more distant time horizons. Not coincidentally, Continue reading
(A post in my “Role Models” series.)
When I worked at Perfect Search, we had a standing joke that after the meeting agenda was done and we had given the word to adjourn, it was time to turn to Lynn and get his feedback. This joke was funny because on many occasions we’d seen Lynn ask penetrating questions after the rest of us rushed headlong through an issue and assumed all the thinking was done.
Although Lynn tolerates this joke with good grace, I think the joke isn’t really fair to him, because there’s nothing funny about thoughtful listening. The world could do with more people who’ve mastered Lynn’s skill.
Listen to understand, not to respond. Photo credit: Prisoner 5413 (Flickr)
I recently blogged about the importance of humility. It is not an accident that humility Continue reading