Perhaps the thing I hated the most was that I rarely talked with the people who ended up using my software. I was given a list of requirements, told what was expected, and that was it. I never found out whether my work met the needs of those using it, never got to ask them how I could improve it, never knew if my software was a blessing or a burden to them.
Apparently that was smart business, because the companies I worked for charged their clients an obscene amount for my work. But it was a lousy way to write software. The whole point of writing software is to create something useful – to create something that, even if in a small way, makes someone’s life better. And how can you know whether you’re doing that if you don’t talk with the people who use your applications?
I broke out of corporate development by getting lucky with HomeSite, which I never expected to become as successful as it was. Looking back, it’s clear that its success wasn’t because it was a “killer application,” but because I opened the floodgates and directly communicated with my customers. By talking with customers I helped ensure that it met their needs, which is the best any developer can hope for.
It seems so obvious: if you want to develop software that’s useful to people, you’ve got to talk with them. But too many developers take the anti-social approach and consider customer support to be beneath their status. Besides, talking with customers would distract them from important code-slinging.
Look, I can understand that viewpoint, especially if you’re working on something that’s very popular. You can’t create anything if you spend all your time doing support. But avoiding support completely is a big mistake.
If you’ve never supported your own software, spending just one day doing tech support will be an eye-opening – not to mention humbling – experience. You’ll have to keep your ego in check, because most people who contact tech support do so because they’re having problems with your software, some of whom will use colorful language to describe the annoyances they’re running into.
But that’s the stuff you need to hear. You need to hear it because you’re the one who can solve those annoyances. You’re the one who can get rid of all the things that prevent your software from being that kick-ass program that people recommend to their friends and co-workers.
You also need to hear an unfiltered view of what people want your software to do for them. If you rely solely on your tech support team to tell you the features that customers want, chances are you’ll develop those features without really knowing why people want them.
And that’s not meant as a criticism of your tech support team. When NewsGator was still doing tech support for FeedDemon, they did an excellent job of answering people’s questions and forwarding feature requests to me. But I would still follow-up with customers to figure out exactly why a feature was necessary, and quite often it turned out I didn’t really need to add a new feature, but instead needed to change how an existing one worked. A lot of feature requests were the result of people being annoyed with how an existing feature worked, and they wanted some way to get around it.
If you really want to write useful software, stop spending all your time keeping up with technology. Don’t worry if your resume isn’t filled with the latest buzzwords. Instead, invest your time in talking with your customers. They don’t care what programming language you use – they only care whether your software meets their needs, and the best way to ensure that is by breaking out of your cone of silence and opening the lines of communication.