Rands is usually good for something interesting, but this time he’s really on to something. In today’s world design is a part of development, and development is a part of design. You can’t effectively do one without knowing something about the other. If you’re a one-person shop, you have to do both at the same time.

Some pull quotes:

“Designers have two choices. Either dip their feet into the programming pool and learn this frontier technology, or figure out how to speak developer.”

“…they must be passionate about something other than writing fast, bug-free code because software is art.”

The last quote is deceptive. Writing fast, bug-free code is an art, all by itself. It’s simply one that the customer appreciates only secondarily. That was the hardest lesson I ever had to learn as a developer. Learning how to use any of the 23 different languages I’ve coded in was simple, compared to that.

The customers don’t care how good the code is, how artfully it has been written, unless they can actually use it. Yes, speed is appreciated, as is reliability. But first of all they have to be able to use, and even more, they have to be comfortable using it.

I can’t tell you how many times, back in my naive, all-powerful coder years, I “improved” programs for my co-workers, only to find them continuing to use the old, slow, inefficient ones. I felt I was surrounded by defectives. I was creating masterpieces of code that were far more efficient and reliable than the crap they were using. Could no one appreciate my genius?

Gradually I grew to understand (or you could say “I grew up”). They were more comfortable with the old, buggy programs because they understood how to use them. I was throwing brand-new, whizz-bang interfaces in front of them, when all they wanted to do was their job, and their job didn’t include trying to figure out what I thought their job was.

So I sat there and grumbled about casting pearls before swine, and about unappreciated genius. The epiphany came when I managed to pull my own ego out of the process. It wasn’t that they didn’t appreciate fast, reliable code. They did, just not as a primary concern.

The primary concern of every customer is the performance of the tasks which lie before them. Appreciation of artistic code is not one of those tasks. As a developer, I was a tool-maker. If a hammer was too heavy to lift, what good is it, no matter how efficiently it might drive the nail?

It was at that point I became aware of design. I concentrated on fitting the tools I worked on to the hands of the people I was building them for. Sometimes it was just one individual, sometimes an entire group. Was I always successful? Of course not. Anyone who worked with me during that time should recall some spectacular failures. I know I can, anyway. But I learned from each one, and they came farther and farther apart.

And along the way, a funny thing happened. The same folks who didn’t appreciate my code, started to. They started to notice how it ran faster, gave better results than the old tool. They weren’t indifferent to the questions of reliability and speed. Those questions just weren’t at the top of the list.

Yogi Berra once said, “I don’t know where we’re going, but we’re sure making good time.” That’s the plight of a good developer who isn’t familiar with design. The code is fast, the code is solid, the code isn’t usable; the destination is unknown.