Reminds me of my time at University, an English University studying English literature not English as a foreign language.
A fellow student decided to to test the marking system and wrote an entire 2000 word essay in this fashion. Simply wrote sentence after sentence that would collect positive marks but made absolutely no attempt to link them in any meaningful way.
If you actually 'read' the essay it was pure gobbledygook, if you just skimmed through it looking for valid points about the literature you would see many.
He got either a top B or bottom A if I remember correctly.
I was working at the NHS (National Health Service in the UK) a few years back when a 'flu pandemic' was being predicted, bird flu I think. Anyway, as a developer there I was pulled into a meeting to discuss plans to create some sort of emergency website with contact details if things went really bad.
Whilst we waited for various people to get on the phone etcetera the guy next to me, a very senior doctor in the service, started moaning about why he was there. To paraphrase and the figure I use is one I just plucked out of my head but you get the idea...
"I don't know what all the panic is about. The prediction for deaths from this flu over winter are 40 thousand. Pretty much every year 40 thousand people die from flu, it's just that this one has a name."
Some on this thread have obviously had worse experience of ageism but I'd actually tend to err on the side of life experience when hiring a developer. Or at least I'd like a good mix of youthful exuberance and wily know how on my team. I've frequently worked with guys in your age bracket and generally find them much easier to communicate and compromise with (there are always some compromises when a team builds software).
Get dabbling/learning and start pushing some small open source projects up onto sites such as http:www.github.com coupled with a http://www.linkedin.com/ profile and you may well find that job comes knocking before the 4 years are up.
Good luck & enjoy.
But... It can be done.
Start with a general discussion about how you might standardise code so that it's easier to switch between areas as a team. Little things like naming conventions and code formatting. If you can't get buy in to that then abandon ship.
Otherwise, introduce tools to start enforcing those rules. Hey let him decide what most of them are.
After this hopefully you have broken the barrier of being able to speak about each others code and you've planted a seed in his head that a bit of formalisation isn't a bad thing.
Rince & repeat upping it a notch each time.
Well according to this post http://science.slashdot.org/story/12/02/15/2338229/scientists-study-how-little-exercise-you-need?utm_source=feedburnerGoogle+UK&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot+(Slashdot)&utm_content=Google+UK earlier today. A person's maximum heart rate can be calculated: "very roughly, by subtracting our age from 220".
From these two 'facts' that I have learnt today I conclude that once your maximum heart rate drops to 106 - you die.
Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?