teamwork

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 →

My Bibifi Adventure

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.

Bibifi Scoreboard

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.

Continue reading →

“Rockstar Developers” are a dangerous myth

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.[1],[2],[3] 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.)

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.

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”:

superstar

The buzz about these mythical supercoders has begun to raise my hackles.

Continue reading →

Why you should use an IDE instead of vim or emacs

With a title like the one above, you may be expecting a rant from an IDE bigot. I know there are plenty of flame wars on this topic, on both sides, and if I raised your hackles (or whet your appetite), I’m sorry.

This is not that kind of post. For one thing, I don’t take myself so seriously:

There’s a keystroke for that! Image credit: xkcd.com

What I’m hoping to do here is point out some subtleties to this debate that don’t get a lot of airtime, and explain to my supercharged-text-editor friends why I work the way I do. However, I also plan to write a companion to this post, explaining why you need to learn a tool in the vim/emacs category, and I’ll have plenty to say on that topic as well. Hopefully that buys me a few minutes of an open mind. :-)

From a distance

If you step back from the debate over IDEs vs. supercharged text editors, and squint to suppress the details, you’ll see that most exchanges on this topic look like this: 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 →