Entries from July 2005 ↓

20 hours in the air

I don’t understand why, no matter how much water I drink and how carefully I eat, I wind up getting sick on long flights.

When I flew to Africa six years ago I made the bonehead mistake of taking a pill to help me sleep and wound up sick as a dog for the last 12 hours of flying. So this time I didn’t take any drugs and made sure to drink tons of water. But at hour 17 found myself hunched over in the airplane bathroom, wondering if I was going to get sucked out of the little hole and shot into the atmosphere at 33,000 feet.

“Rob was a good husband and programmer. He crystallized before he hit terminal velocity.”

After 20 hours of flight I exited the plane to the smell of the humid African air and realized that the trip was worth it.

Leaving on a jet plane

I leave for Ghana (West Africa) in 48 hours.

Lately, my mind has been filled with thoughts of how a for-profit technology company could be run with social justice as its focus, and along a related line how technology can be used to fight poverty. The reading and writing I’ve done in the past few months has culminated into a new question for me:

What’s the point of technology if we’re not focusing on people?

I don’t mean that we focus on people so we can get more work out of them so we can turn a bigger profit. I mean make people the focus above everything else, even shareholder value. What would that look like?

Stay tuned to hear more.

My RSS Feed Is Broken

For those of you who followed my recommendation and installed an RSS reader, you probably want to switch to consuming the Atom feed for the time being (located at the top right of this page).

I just found out that the RSS feed in Community Server, the blog software I use for this site, is broken and won’t be fixed until the next release. The result is your reader will never detect new posts to this blog. This is extremely disappointing considering I’m using version 1.0 of the software and would expect this functionality to have been tested.

There is a fix available but it involves modifying and recompiling the code, which is not something I will have time for in the near future.

I’m going to remove the RSS link from the header until this is resolved.

Thanks for your patience. I will post again when it’s fixed.

Becoming a Better Developer, Part 2: Know Your Core Competencies

For years business consultants have instructed businesses to “know your core competencies.” What this means is “know what you do well and stick to it.”

For example: Harley Davidson makes great motorcycles. But they’re probably not so good at making perfume.

Smith & Wesson makes some of the best six-shooters around, but I question whether their bicycles will be a smashing success.

McDonald’s is…well I won’t say they’re very good at making food, but they are pretty good at selling a ton of it. But they should never, and I mean not between now and the day that Eternity decides to cash it in and become a Las Vegas showgirl, make a Lobster Sandwich.

As a developer knowing your core competencies can help keep you out of trouble. I’ve been building web applications for most of my career and I’d like to think that I’m pretty good at it. But there are certain things I’ve never done and would not do well right off the bat: writing a compiler, building a super-fast search application, and implementing my own encryption algorithm are a few that come to mind. This reminds me of a story…

I was co-maintaining a successful e-commerce website and we were looking for a way to encrypt passwords so they wouldn’t be stored in plain text. The site was written in Java, which I had used for the previous 6 months or so, but even after 6 months I could not for the life of me find anything in Sun’s documentation (does anyone know how to effectively use their search tool?).

After literally hours of combing through the documentation I gave up and decided to write a quick, simple encryption algorithm to hash passwords. Take the ascii value of each character, add something to it, divide by something…whatever, it’s all just numbers, right?

Oops.

Street in AntiguaI implemented it. We launched. And sure enough, within a few days people were complaining that they couldn’t login. I thought surely we had a bizarre coincidence on our hands; ten people all at once misremembering their passwords. I was ready to call the papers until, after about 20 minutes of investigation, I realized that my encryption algorithm didn’t really work for a couple of characters at the edge of the visible ascii range. It processed the values, but the encrypted result was actually an invisible character, also known as a “control” character.

Control characters can create difficulty because anytime they cross a boundary, whether from the database to the application, or the application to a web browser, they run the risk of being accidentally changed up by a mis-encoding between the layers. Sure enough, some of the decrypted ascii values were incorrect resulting in a handful of people who couldn’t login.

On that day I learned the importance of sticking to what you do well. After many successful launches we had our first setback; luckily we were able to fix it without a lot of effort.

This doesn’t mean that you should never branch into new things. On the contrary, you must constantly build on your core competencies or become outdated. But be smart about it.

Realize that moving from building web applications to desktop applications is not a huge stretch. Moving from web applications to compilers, while possible, is going to take more than browsing an online tutorial. And stay away from encryption; it’s a nasty beast!

When dealing with tasks completely outside your realm of knowledge expect to spend a lot of time researching, becoming familiar with the subject, and learning it slowly as opposed to copying and pasting the first code sample you see.

I can make web applications like it’s nobody’s business, but don’t hire me to work on your next compiler.

Is Programming Art?

There’s a new article on O’Reilly’s ONLamp.com that talks about the similarities between art and computer programming. It’s along the lines of Paul Graham’s Hackers & Painters, which I’m currently reading (I’m going to put a recommended reading list up in the next week or so).

I’ve been thinking about this subject quite a bit over the past few weeks, and here is my take on it:

First, let me say that this is a purely academic discussion. There’s no benefit to objectively proving that computer programming is or isn’t an art except to brag or cry about it, whatever the case may be. I don’t think any of us plans to apply for an NEA grant in the near future.

So is programming art?

It can be.

Most programmers, probably more than 95%, resemble house painters rather than impressionist painters. I don’t mean this in a derogatory way; it has nothing to do with their ability or the prestige of the work, rather their motivation for doing the work.

If you take a starving artist, whether a musician, a writer, or a hacker (in this context I mean someone who writes really good code), he has a certain amount of desperation and passion. Every day he plays/writes/programs not because it makes him rich, but because that’s what he loves to do. It fulfills an intense desire in his soul that spurns him to create.

In this sense programming is art.

I bet that most of us started out that way; teaching ourselves Perl for fun. We built websites because we wanted to, not because they served a purpose. This resembles art: guitar players write songs because the desire burns within them. Painters create paintings because it fills an emptiness. The creation has no other purpose but to bring pleasure to those who experience it; to inspire and create emotion.

But once the writer decides to make money writing ad copy or the hacker decides to take a salaried position building business applications, some of the passion inevitably leaves the process. When an artist is not free to create from the soul but is instead told to write a jingle for Loads of Fun Laundromat or build a web page to sell “I heart your mom” bumper stickers, the emotion is lost. And art relies heavily on emotion.

For the record, I love my job and I can’t think of anything I’d rather do for a living. And although I like to think that what I build everyday is a brilliant work of art I have to be honest and realize that there is a difference between me and the starving artist down the street.

Nerds make better lovers

According to an article in the New York Daily News, nerds make better lovers. Since I qualify as a nerd, this is great news!

Though you have to love how they arrive at their conclusion: If Christina Aguilera says nerds are better, then it must be true!

Becoming a Better Developer, Part 1: Making Fans

This is the first of what I hope to become an ongoing series about non-technical ways to improve yourself as a developer.

Becoming a better developer involves more than learning new technical skills; learning about your company and co-workers will dramatically improve the software you build. One of the most important lessons I learned during the first year of my career is to be so nice to the people around you that they can’t help but become your biggest fans.

When I graduated from college I began working for an electrical contractor in Northern California; the company where my dad has worked for 37 years. My first year of management training was spent shadowing the Chairman of the Board followed by a foray into managing construction projects. During that first year I was anxious to be accepted by the office staff and tried my best not be viewed as the kid out of college who was given a job because of my dad. As a result I went out of my way to spend time talking to people around the office, asking about their lives and families, and making conversation with pretty much everyone I met. Word got around quickly that I worked hard and I was a nice guy.

I didn’t realize the side effects of this reputation until a year later, when I went into the field and began managing projects.

Downtown Los Angeles

The first projects were overwhelming for me. I’m the type of person who needs to be in control, and on a construction site everything feels out of control until you get used to how it works (and even then everything’s out of control). So I was constantly calling the office, asking for favors and looking for answers to question. To my surprise people were willing to help me. It was like someone had gone around and asked everyone to make sure I was taken care of. And one day I realized it: unintentionally, that someone was me.

When I invested time in my co-workers I was unconsciously making them see me as someone they could talk to; someone who cared about them. This empathy meant that when I called they took the time to understand my dilemma and did everything in their power to ensure I got out of it alive, even if they had to drop what they were doing to help me. This is the power of making fans.

As an aside, I’m not suggesting that you build false relationships in pursuit of fans. That’s a lot like writing fake grass-roots letters in hope of creating a buzz; you’re going to get caught and it’s not going to be pretty.

I am suggesting that you invest in building genuine relationships with your co-workers, especially those in other departments who you would normally not have contact with. If nothing else you will learn to empathize with them so you can one day feel good about dropping everything to help them out.