I was talking to a developer friend today about developers who don’t get the importance of communication. Look through any want-ads for developers and right after the alphabet soup of technologies you have to know is the same requirement—must have “excellent written and verbal communication skills”. You’d be hard pressed to find a programmer job without those requirements.

But, expressing yourself clearly is only half of communication. The more important aspect is listening to and understanding other people. This is what separates good and great developers. And the most important skill in understanding is empathy—not only understanding someone, but being able to be them.

To be a successful developer, you have to learn more than just the software aspect of your business. Developers who understand this are more valuable and valued more. If you want to do this effectively, you have to think like a saleperson, a marketer, a CEO, your customers, the press, etc. You have to think like them because they aren’t all going to try to think like you (but if they’re going to try, by all means, help them).

Another part of empathy is thinking about how they will interpret your words. For instance, avoid rhetorical tics like “think about it” and “you’re not seeing the big picture”. Not only are they annoying, but it puts people on the defensive.

If you understand—not only what someone is saying, but why—you’ll have a much better chance of expressing yourself. So, the next time you have a communication gap with a non-developer, stop talking and ask yourself how much you even understand about them.

I’ve written a couple of add-ins for CityDesk, and of course, it’s tempting to think about trying to make some money off of them. I’m already a partner in another add-ins business (Spheresoft, which makes MS Office addins — check out Highlighter if you view realtime data in Excel), so I know a little about what goes into the development, support, marketing, sales, licensing, etc. of doing this kind of thing.

Add-ins are a great business for small companies, because they are much easier to implement than a full-blown product and the software you are adding on to will help with marketing. Another add-in that Spheresoft will be publishing soon, changes the nature of spreadsheet modeling, but we’d never want to compete with Excel on thousands of other tiny features, so it makes more sense for this to be an add-in.

But, with any business, you have to decide how much effort you are willing to put in and what you are expecting back. The market of people who have Office is huge and I have a reasonable expectation of making a good enough return on Office add-ins to warrant the time spent writing and supporting them.

I’m not sure I can do the same for add-ins for Fogcreek products. I’m glad that people find them useful, and I do them because I need them as well. I would never make enough money to recoup support costs I would have to undertake if I charged for them.

So, they will remain free and pretty much unsupported for now.

This article on Domain Specific Languages from Martin Fowler got me thinking on code generation in general. A project I’m working on right now has many opportunities for generating code—not from a domain specific language, but from the requirements documentation and other source information.

I am working on a project now with a very detailed requirements document. For instance, practically all of the strings shown to the user are in there. Since the project uses string resources, there’s no reason to manually copy and paste—the string resource is easily generated from the document.

The project also has a lot of images.  And images are associated with each other (some images are the small version of another, or meant to be the same object but from another angle). Luckily, the artist used a directory and naming convention that makes these associations easy to figure out, and generate an XML resource descriptor and object building code from.

Tying together this information (each image has a string descriptor) is also easy, given the detail in the document and the naming convention.

Actual logical code generation is almost possible as well, as the project is a kind of complicated finite state machine. In this case the document doesn’t go far enough to be a source. A Domain Specific Language might help here, and leaves me with source that might be able to be maintained more easily that a Java representation.

This brings up a good lesson for those writing requirements, even if you don’t know how to program. If you follow conventions closely, it might be a good starting point for generating code.

I’ve been playing around with the Furl Beta. It’s looking pretty good. Essentially, it’s a personal online cache of web pages that you can view, search, and share. Better than bookmarking because you can search the contents of it later, and it’s accessible from any browser. You can even provide RSS feeds to your Furl content.  Collaborative research on the internet just got a whole lot easier.

One drawback, there does not appear to be any way to make the cache private, so I can’t possibly use it, because there is no way I want a public database of every site I find interesting or useful. I definitely would share some of it with some people, but totally public is not an option.

Perhaps there will be a pay service for a private space.

Update: My bad. Just mark the item private when you Furl it.  Duh.  Didn’t see that on the Furl dialog and still don’t see how to make a public item private (except to change its topic to personal, but then I lose the utility of topics). Anyway, now the biggest drawback is that the first dialog comes up at the wrong size and there is no scrollbar, so you can’t see the buttons.