This is absolutely what the programmers need. Someone who can explain domain knowledge and how they expect to use the software without starting to go off on about how you can just use a database widget to manipulate the numbers here in that java thingy. If I was going to write accounting software, I don't need someone telling me what library function to use to calculate interest, I need someone to tell me what happens when a user chooses cash basis or accrual basis, and which one is a more likely choice so we can make that the default and save the user a click (or perhaps it is absolutely vital that the user chooses one without simply accepting a default).
The general case of learning to ____ for the purpose of interacting with someone who _____s makes my skin crawl. The accountant should consider this the other way around and ask himself how they'd feel if the programmers started coming up to him to ask if his receivable cash bases are dollar averaged or some other mishmash of terms that will hopefully sound inane to an accountant.
That said, there's nothing wrong with learning to program for the sake of learning to program, and if he was able to bootstrap himself to a level appropriate for the task on hand it would almost certainly be beneficial to himself and his team (unless his team members are paranoid that he's looking to replace them). The main issue is the strain he'd put on the programmers if he tries at too low of a level, and the programmers end up taking time from their actual job function to train him.