Advice To Amateur Programmers

The article below was copied from and is placed here to ensure access if their site goes down.

Advice to amateur programmers | 1 October 2010 | by Julian G4ILO

If you know a bit about programming and have been thinking of writing a ham radio application, here’s a word of advice. Don’t. If you do, it will take over your hobby, your spare time will never be the same again and you’ll be lucky to receive much thanks for it.

First, you’ll have to spend countless hours answering emails that ask the same basic questions. You’ll have to do this no matter how much time you put into writing documentation or creating an FAQ or a wiki, because no-one will read it. And believe me, starting the day with an inbox full of the same old questions gets tiresome very quickly.

Second, you’ll be expected to know why your program won’t run on a user’s computer, without being given any idea what kind of computer it is or what version of operating system it uses. If the user has done anything that might affect your program’s ability to run, you won’t be told that either. And beware if you should choose not to spend too much time looking into someone’s obscure problem. One user of VOAProp who had a problem several years ago that I was unwilling to solve threatened to write to the RSGB accusing me of lacking in ham spirit. That bruising encounter is one reason I gave up developing programs for the hobby completely and now make it as clear as I possibly can that the programs I wrote continue to be available on the sole condition that I provide absolutely no support for them whatsoever.

Third, you’ll receive a lot of requests from armchair programmers for changes and improvements. Some of these might be good ideas, though you still may not want to implement them. But many will be things that only that person thinks is a good idea, quite possibly because they haven’t read the instructions or understood how the program is supposed to be used. These requests will contain no acknowledgement of the amount of time you will have to spend making these suggestions happen. You’ll have the job of justifying why you shouldn’t spend several hours or days coding some function that you personally have no interest in using. And some people find it hard to take “no” for an answer. If you wanted to write programs to someone else’s spec you’d get a job as a programmer, wouldn’t you? Then at least you’d be paid for it.

Last, but by no means least, you’ll get complaints about bugs. Yes, complaints, even if your program is free. Often, these emails will be the first contact you ever have with that particular user. But don’t expect them to start with any pleasantries. If you are particularly unlucky, as I was with one email I received from someone who couldn’t get KComm to run, you’ll be blamed for wasting their time. Sometimes the “bugs” will be due to user error or failing to read the instructions, but it’s rare that you’ll receive an apology after pointing that out. And believe me, those who complain most bitterly won’t get the joke if you offer to refund what they paid for the software.

Fortunately there are users who will make you feel that your effort is worthwhile. You might even be lucky and build a team of online friends who test your program and give you useful feedback about it. But it doesn’t take many of the other sort of comments to make you wonder why you bother. If you develop your program solely for your own use you will save yourself a lot of trouble.

It’s a good job no-one takes my advice because if ham programmers didn’t release their programs for free and put up with all the brickbats I’ve described the hobby would be a lot poorer for it. But if you’ve ever seen a program mentioned in some old forum posting and been unable to find a copy of it, now you know why.

So next time you use a bit of free ham radio software ask yourself: Did I remember to say thank you for it? Before bothering the developer with a question, take the time to read the documentation and search any relevant forum for the answer. And if you think you found a bug or have a suggestion for an improvement, try not to make it sound like a criticism or a demand. A little tact goes a long way.

Julian Moss, G4ILO, is a regular contributor to and writes from Cumbria, England.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License