 |
Advice to amateur programmers
1 October 2010 | by 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.
2 Responses to “Advice to amateur programmers”
 Ham Radio Deluxe |
 Ham Radio Prep |
 Ham Radio School |
 KB3IFH QSL Cards  Hip Ham Shirts  HamRadioAuctions Reliance Antennas Enigma Shop |  morseDX  Ni4L Antennas  R&L Electronics antennas.us Ears to Our World |
- Matt W1MST, Managing Editor
I think this problem exists in any hobby. When people use software they feel they have a right to working software, and when it doesn’t, they feel jipped.
The software I write that has a ham radio spin to it generally just for myself and a few friends who might be interested. I’ve thought about open-sourcing some of it so those who might have good idea, or just be better programmers, can have it, but I’m always left with this uneasiness that the true direction of the software will be lost. That’s just my internal issue to be worked through. However, we must be aware that if no software is written and given to the public, something great could be lost, as in the case of UI-View.
I do in fact disagree with your statement that people should not write amateur radio software. This goes against the very point of amateur radio as a hobby, and perhaps even to public service to some degree. Where would we be with your “don’t do it” mentality? We’d never have digital amateur radio, not packet, not PSK31, not WSPR, nothing.
Perhaps it would be better to rephrase your position to one that begs people to understand that when they release software to the community, be it with that purpose or not, they take on certain responsibilities. If you really want to provide to the community without this responsibility, release it anonymously.
You provide not advice, but the rant of a frustrated programmer who allowed himself to be frustrated. Either suck it up or stop writing software, but keep quiet and stop trying to kill off the very reason most of us are hams to begin with.
RANT!!!!!???????? I think not… as a programmer who does most of his own stuff, I did not read Julians notes and interpret them as a RANT. I saw it as a basic statement of the experiences he had gone through, and his opinion. Which in fact is really a toungh(sic) in cheek look and advice to anyone wishing to undertake this course and what they may expect. Course that all depends upon thier programming skill level, and the kind of product they hope to provide.