Ladder Safety

When I bought my house, one of my thoughts was “brick! I don't need to paint!” Over the past six years, I've learned just how much wooden trim is on a brick house. And I've learned that after 75 years, the layers of paint can be measured with a ruler. And so this week, I found myself on a ladder again, heat gun in one hand, putty knife in the other. And I tried to think of a way to turn the experience into a programming-related blog posting.

When you're standing on a ladder, there's really only one safety rule: keep your hips between the ladder rails. As long as you remember this rule, you can twist your upper body and stretch your arms as far as they can reach. You can stand on one foot. The ladder isn't going to move — provided, of course, that it was set up properly (feet on solid ground, correct angle, both tips in contact with the wall).

Which, of course, brings us right back to the idea of reinforcing practices. If you set up the ladder with one foot on concrete and the other in mud, it doesn't matter how careful you are about body position. Sooner or later one side will sink, and then you'll fall. Extending the metaphor, proper ladder setup doesn't mean that you're going to get a decent paint job.

Speaking of which: the heat gun quickly bubbled the old paint, making it (relatively) easy to remove. Yet some adjacent boards, which I'd pre-painted before installation a few years ago, were unaffected. I'm sure there's a programming metaphor to be found there…

The Resume

It's time to update my resume again.

It's starting to get too long: I've never given much thought to keeping it at a single page, but the HTML version is now at five printed pages, covering 17 years. One solution is to drop older entries, but I'd really like to keep my Fidelity experience listed: it was a major part of my career, and shows I've been something other than an individual contributor.

There's also the matter of the number of entries. When I first entered the professional workspace, my recruiter told me that the average job span was two years. I've kept pretty close to that, at least as a full-time employee, although my contract jobs tended to be a year or less. However, a bunch of short gigs raise red flags, even when listed as “contract.” That's always been a peeve of mine, since the sign of an advancing career within the same company is a new position every couple of years. I simply do it with different companies.

The skills section doesn't need too much editing. I've always taken the attitude that I should be able to stand up to an experienced person quizzing me on any skill that I've listed, and when sitting on the other side of the interview table, I tend to do just that. The database section needs some work — Teradata? what's Teradata? Actually, it's been long enough that I don't think I can call myself a “database programmer” anymore, so maybe I should just merge it into another category.

And then there's the readability issue, in particular the issue of whether I'm writing for a human or a search engine. Search engines have been good to me: I've seen many hits in my access log from people using them, and gotten more than a few follow-up emails (which is impressive, given how I don't provide an easy email link on my website). But ultimately, it's a person who's reading, who can get bored, who can throw it in the trash based on font choice or layout. HTML has some decided negatives here: no matter how much I tweak the CSS, I'm not going to match the layout that I had with Word.

One thing that I don't plan to change is the structure of the entries: early on I decided that my resume would speak to what I've done, rather than how I've done it. That causes problems with a lot of recruiters: they want to see buzzwords everywhere, on the belief that hiring managers want the same. And perhaps some hiring managers do want that, but I've decided that I don't really want to work for those managers. I'd rather work for someone who wants the same things I do.

Resources

Resources are working on the issue.

If there's one word that I'd take out of the corporate lexicon, it's ”resources.” It seems harmless enough. After all, you can't complete a project unless you have the resources to do so. Some of those resources are people, some are materiel. Yet wherever I've seen people referred to as resources, I've seen a dysfunctional company.

At first glance, the reason seems obvious: when you dehumanize someone, there's no reason to consider them in your decisions. Do you need 80 hour weeks to get the project done? No problem, we have the resources! Don't have anyone with the skillset to do a job? That's nonsense, just move a resource into the slot! These, and similar, are fodder for a host of TV shows and movies … as well as more than a few real-world companies.

But the damage goes further than that: it separates people from their work, giving them an excuse not to care. That quote at the top of this article? It came from the production support team, not some random manager. Did you notice that it doesn't say we are working on the issue?

In a world of “resources,” there's no reason for an individual to feel responsibility. After all, he or she is just a cog in the wheel. To be replaced or re-assigned at the drop of a hat. And once you adopt that attitude, it really doesn't matter what you produce. It's a short step from there to ignoring broken windows.

This is not news, and it's not an issue confined to the software industry. One of the essays in a rather obscure book on railway locomotives, first published in 1959, discusses the effects of crew assignment on the well-being of the trains themselves. Not surprisingly, the engines that “belonged” to a single crew or small number of crews were consistently in top shape. Engines from a “common pool,” which would be crewed by whomever was available, were consistently in the worst shape.

Even on an assembly line, the home of interchangeable jobs, people are not interchangeable. You can't take a person with ten years of experience threading wiring harnesses, and drop him/her into a welding station. Or vice versa. Unless you actually want to lower product quality and create unhappy workers.

The real issue is why the belief in “resources” persists, even among the people so labeled. I suspect that it comes from a feeling that humans can adapt to anything; that “specialization is for insects.” While that may be true in the long run, in the short run it's just wishful thinking. And being told “you are not a beautiful or unique snowflake” is bound to leave a few psychic scars.