PragDave

My EuroRailsConf Keynote is Online

I had an emotional trip to England back in September. I was reunited with family I hadn't seen for quarter of a century. It was the fifth anniversary of 9/11. I was due to give a keynote at the European Rails Conference, and I wasn't sure what I was going to say.

Somehow all these things came together at just the right time. The keynote is now online (44 mins). In it, I talk about terrorism, risk, fear, Ruby, Rails, and hope. I think it's one of my better talks. Enjoy.

End of the Knowledge Worker?

Knowledge work is dying. We all need to move up the ladder if we’re to keep our jobs.

Broken Raspberries

I came across (yet another) example of real-life broken windows last night.

I went to the supermarket about 6:30pm to buy some lettuce. Big mistake. At that time of night it’s crowded, full of folks on their way home. All the checkout lanes were four people deep, and every employee was working a register. It was chaotic, and a high pressure environment for those who worked there. Customers picked up on the tension: everyone was a little on edge.

Then, three people ahead of me in line, a women dropped a box of raspberries out of her cart. They spread out in a patch maybe 18" across. The woman was embarrassed, and pointed out the spill to the guy running the checkout. He craned his head to look, then looked at the length of the line and the expression on the face of the person he was serving. "I’m too busy to deal with that now," he said. But he did call out to the floor manager. She was on her way to start up a new checkout, clearly harried. "No time" she called. So the raspberries lay there. As the line moved forward, the woman tried to move the raspberries out of the way, but she wasn’t too successful. In fact she managed to squash a few of them. The next person in line also tried to be careful, but his trolley ran over some, and got raspberry juice on the wheels. And so it went. By the time I checked out, the raspberries were a purple-red mess on the floor. The mess had spread from a small, contained spot to a large stain, and there were red tracks leading from the checkout to the two doors. The stains were already drying. It was going to take someone a while to clean it all up.

On the way home, I thought "that’s another great ‘broken windows’ story." Fail to fix something early, and reap a whole lot of extra work later. Had the assistant said to the line: "Let me clean these up before they get all over your shoes" and spent 30 seconds with a broom, the problem would have gone away, and no one would have complained. In fact, the customers would have left the store glad that someone actually cleaned things up. Instead, we walked away with a bad impression and red-stained shoes.

It’s the same on software projects. Even when (especially when) things are chaotic and pressured, make the time to fix the small stuff. Otherwise it’ll just become big stuff, and your customers will end up seeing red.

How to Keep Your Server...

My talk How To Keep Your Job just got Slashdotted as a result of a CNN article on the move of IT jobs abroad. There's a telling quote in the CNN article:

Like many unemployed programmers, Kerrigan blames the sour labor market on offshore outsourcing -- the migration of tech jobs to relatively low-paid contractors or locally hired employees in India, China, Russia and other developing countries.

The real problem is that as development becomes a commodity, basic economics dictates that companies have no choice but to look for the cheapest options. The only solution for Mr Kerrigan and the thousands of other displaced developers is to reexamine their position in this brave (and scary) new world. What is our individual value-add, and how can we position ourselves to be effective and attractive in the new marketplace? We need to think hard about the value chain and our position on it. And once we've made our decisions, we have to work hard to position ourselves. In the long term, the industry will simply move up the value chain, which will be to all our benefits as long as we're prepared to move with it. In the short and medium terms, though, we're facing a massive shakeout. Perhaps it's time to dust off your Pragmatic Investment Plan...

Declaration of Independence

On the Fourth of July, I went over to the archives to read a transcription of the Declaration of Independence. In a way it seems cheap to draw project-team lessons from such a document, but there is a wonderful quote in the middle that I hadn’t noticed before:

"experience hath shewn, that mankind are more disposed to suffer, while evils are sufferable, than to right themselves by abolishing the forms to which they are accustomed."

Are we currently putting up with things "to which we have become accustomed" rather than fighting to right them?

Quote o' the Week

This one has no definitive source, so it may well be totally inaccurate, but the concept is sound even if it was never said. :)

Francis Ford Coppola is reputed to have said that the difference between a good movie and a bad movie is getting everyone involved in making the same movie.

How could this apply to your current project?

The rOOts Conference

I just discovered that I'll be giving "How to keep Your Job" as a keynote at this year's rOOts Conference. This came as something of a surprise: I hadn't actually realized that I was invited. It'll be good: rOOts is a great conference: it is nice and intimate, the audience and speakers have a wonderful time, and Bergen is a great town.

One of my New Year's resolutions is to try to plan the conference trips better. Traditionally, I travel somewhere, do the conference, travel back, and then two weeks later get an e-mail from some company in the conference city saying "oh, we wish we'd known you were going to be here." Perhaps there should be a site where speakers can register their itineraries. In the meantime, it looks like I'm going to be in Norway in early May if anyone wants to meet up.

Random Quote o' the Week

That which is overdesigned, too highly specific, anticipates outcome; the anticipation guarantees, if not failure, the absence of grace.

-- William Gibson. All Tomorrow's Parties

Every Day in Every Way

Imagine a simple (and somewhat boring) card game. In each round, all players are dealt one card each. Each player may hold at most three cards (so after the third round they must start discarding). After an arbitrary number of rounds, the player with the highest card total wins.

The strategy is pretty simple: when forced to discard, always discard your lowest card. No rocket science here: when you can’t control the cards you’re dealt, you win by eliminating the weakest of your holdings.

This seems to be a reasonable strategy in any situation where you need to optimize some collection of "things," but where the resources you receive have unknown characteristics.

Our industry is suffering from an embarrassment of bad programmers. Much of the blame can be leveled at the hiring frenzy that occurred during the dot com boom, where anyone who could play Quake (or who had once watched someone play Quake) could get a job coding (and playing foosball at work). Many of these people are still in the industry.

So now we have a problem. Interviewing and recruiting good people is very difficult; For most organizations we’ve seen it’s a hit or miss affair. This means that the bad get let in along with the good (just like being dealt random cards). However, once the bad folks have been hired, it turns out to be hard to fire them. Unlike the card game, they stay in your hand, dragging down your overall score.

There are three things to be done here. First, companies could get better at recruiting. Unfortunately, one of the best indicators available to recruitors, past performance, is hard to come by. In the US at least, employers now tend to give anodyne references to ex-employees rather than tell the truth and risk being sued.

Second, we could find a way to fire the ineffective developers. If that happened enough times to an individual, they might get the hint and leave the industry (which would be good for all of us). Unfortunately, that’s also unlikely to happen. Even though most developers in the US are employees at-will (meaning they are in theory employed at the whim of their employer), in reality the various anti-discrimination laws make firing a risky business for most companies.

Our third strategy isn’t available to the card players: we can improve the individual cards in our hand. This means working hard to train and retrain folks, not just in the specifics of technologies and languages, but also in the soft disciplines: communications, business practices, and so on. Some developers aren’t trainable, but I’m thinking that the vast majority will benefit.

Interestingly, there are companies who recognize the value of attrition. GE, for example, has every level of manager rank their employees. After justifying these ranks to the manager’s manager, the company then puts in place an action plan for the bottom 10% (a plan which can include termination, a performance improvement plan with a time limit, or a move to a more suitable position). I don’t think I like the rigidity of GEs policy (at least as externally stated), but I think the intention is good.

Over the next few years, we all have to do something to improve the quality of the work delivered by our industry. If we don’t, we’ll find legislators doing it for us (possibly with professional licensing schemes and attempts to hold developers liable for faults in software). And improving the quality of work means improving the quality of the development community. Maybe it would be in our long-term interests to find ways to make recruiting more reliable (perhaps by setting up a way for employers to comment truthfully on a developer’s past performance). We need to make it easier to fire the truly bad developers (contract to hire and probationary periods are a good interim measure). And we need to find ways to promote on-going professional training. If we don’t help ourselves, someone in government will do it to us.

Learning From Mistakes

I read a lot of aviation magazines. In every one, you’ll find at least one column dedicated to reporting on accidents. These reports are fairly dry: a restatement of the facts issued by the various government agencies that investigate transportation problems. Depressingly, a large number end with the summary "pilot error."

Are our pilots a bunch of cowboys, recklessly flying planes in to the ground? Quite the reverse, the vast majority are conservative, careful aviators. So why does "pilot error" figure so prominently?

The authorities quite rightly give the pilot of an aircraft ultimate authority over that aircraft’s operation. It’s up to the pilot to check the weather, the condition of the plane, the distribution of weight, the fuel required, and many other factors, all before setting foot inside the plane. Once flying, the pilot’s job continues, monitoring weather, fuel remaining, aircraft performance, navigation, collision avoidance: the list is long and complex.

It isn’t easy keeping all these factors balanced, particularly not when the weather is closing in, fuel is starting to look marginal, turbulence is jarring your teeth loose and you’re at the end of a long, exhausting day. And yet we all (quite rightly) expect our pilots to maintain a level of near perfection. So pilots, being human, make mistakes, and sometimes these mistakes have tragic consequences.

That’s where the accident reports come in. Pilots read them, and read them avidly. They aren’t reading to gloat. They’re reading to learn. The pilots they’re reading about are for the most part every bit as careful as they are, and yet still something went wrong. So pilots read the reports to find out what happened, and maybe to try to tune their personal procedures to stop it happening to them. By reading these reports, pilots improve both their own performance and aviation’s overall safety.

Computer programming is perhaps half the age of powered flight. We face different issues; our mistakes can cause inconvenience, but rarely loss of life. But perhaps still there’s something that programmers can learn from the attitudes of pilots. Is it conceivable that we might one day have a way for developers to report problems during development to some anonymous forum so that others might learn? Could we start to use our own history as a tool to help us all improve?

How To Keep Your Job

Jay Zimmerman (www.completeprogrammer.net) arranged for me to give a talk at the Austin Java User’s Group (www.austinjug.org) as a way of publicizing his upcoming Lone Start Software Symposium. I decided to try giving my "How to Keep You Job" talk for the first time (online at www.pragmaticprogrammer.com/talks/HowToKeepYourJob/HowToKeepYourJob.htm).

I’ve been getting more and more convinced that this topic is significant. The industry is changing underneath us, and most developers seem oblivious, preferring to blame the recession rather than face an awkward fact: we’re never going back to the easy life of the late 90’s. Instead, every developer is increasingly going to have to fight to stay attractive, working hard to develop the skills needed as the industry matures and more and more of our work becomes commoditized.

I’m liking the Knowledge Portfolio metaphor as well: it seems to communicate the idea of taking personal responsibility for your future. The financial portfolio concepts of planning, diversification, regular investing and periodic rebalancing fit nicely into the knowledge metaphor too.