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:
When an English speaker is drowning in details that make the big picture hard to see, she might complain, “I can’t see the forest for the trees.”
image credit: Miguel Virkkunen Carvalho (Flickr)
It’s an odd expression, partly ironic and partly humorous. When I hear it, I sometimes think of my sister, who, after moving from Indiana to Utah, complained that the mountains were getting in the way of her view. (Her tongue was firmly in her cheek… :-)
The expression also describes an important problem of software engineering–one that a lot of engineers don’t understand well enough. It’s a problem with generalization.
I’ve been involved in a learning experiment these past six weeks. Now that it’s winding down, I thought I’d reflect a bit on some themes that emerged.
For the past 9 months or so, I’ve been taking classes online from Coursera to complete a Cybersecurity specialization taught by the University of Maryland. I’ve learned about security and usability, various flavors of software vulnerability, secure integrated circuit design, digital watermarks, and encryption theory.
In early May I began the final class in the sequence–a capstone project where teams of students attempt to build secure software to match a spec, then try to break one another’s submissions with a combination of pen testing, static code analysis, fuzzers, and theory taught in our other security courses. The project is framed as an international coding/testing competition hosted on builditbreakit.org (hence the “bibifi” in the title of this post), and this May’s running of the contest includes several hundred very sharp participants from around the world.
Partial bibifi scoreboard, showing 5 of about 100 teams. I was on team “SEADA”. Net of score in buildit round minus bugs logged against code in breakit round shows current overall standings.
Sometimes developers limit the choices that are offered to their users as a way to simplify. This can be a good thing; I’m a big fan of simplicity.
However, this strategy comes with an important caveat:
If you’re going to force all choices into a few predefined buckets, you better provide buckets that match the needs
of your users
Broken buckets will not earn you brownie points. Or revenue.
image credit: Eva the Weaver (Flickr)
Today I was adjusting my 401k contribution. Here’s the broken buckets I saw when I logged in to the financial services website:
Recently I’ve run across several uses of the phrase “rockstar developer” or “rockstar programmer” (“code ninja” is another hip variant). The term shows up on slashdot, for example. I’ve also seen it in job postings and in blogs.,, A rockstar hacker archetype is standard fare in TV shows, where his or her computing feats are practically a superpower (Agents of Shield, Person of Interest, Leverage, Scorpion, …) Of course Hollywood loves the notion, too; I thought The Imitation Game was fascinating, but besides taking liberties with history, it portrays Alan Turing in a distorted way that feeds such mystique. (Turing was absolutely brilliant, and certainly one of the most important pioneers in computing. But he didn’t invent his codebreaking machine alone.)
from The Imitation Game: Alan Turing and team members at Bletchley Park, with a forerunner of the modern computer — technology invented by brilliant people to break the Nazi Enigma encryption. Screenshot from official trailer, under fair use.
It’s even in my inbox. After I began writing this post, I got an email from a recruiter on LinkedIn, looking for “superstars”:
The buzz about these mythical supercoders has begun to raise my hackles.