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 (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

A grumble about buckets

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:

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


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

Continue reading

Know Your Limits

I just finished the nastiest debugging experience of my career–nearly 3 weeks on a single bug. After days and days of staring at code, swearing at core dumps, tailing logs, connecting to gdbserver via a multi-hop ssh tunnel from inside a secure environment, and general programmer misery, I felt like doing cartwheels when I finally figured it out, tweaked a few lines of code, and observed stability again.

Hindsight teaches me this lesson: undocumented, unhandled constraints waste enormous amounts of time and energy. If you’re interested in writing good code, you must know your limits, and you must communicate them. This especially matters when the constraints are obscure or surprising.

image credit: ericdege (Flickr)

Naive optimism

My bug seemed simple enough at first blush: Continue reading

A More Important Manifesto

A couple years ago, I wrote about signing the Agile Manifesto and the Manifesto for Software Craftsmanship.

Today I want to write about something a lot more important.

Let me use résumés to provide some context.

I used to think that the “Objective” section of a résumé was fluff–a place to dump vague platitudes, maybe. You know the stuff I’m talking about:

Objective: Craft high-quality, enterprise software in an environment where I can make significant contributions to the bottom line of a growing company.

Blah, blah, blah.

Theoretically, this stuff helps you get jobs, but as someone who writes a lot, my drivel-o-meter pegs at such verbiage. Usually, it means about as much as the Business Buzzwords Generator recently posted by the Wall Street Journal.

image credit: David Blackwell (Flickr)

But it doesn’t have to be that way.

Your objectives ought to matter.

Continue reading