Would I approach it as if I wanted to eventually code, but stop once I view my understanding as adequate for it's purposes? Or is there a different approach specific to my having little interest in actually coding myself?
I'll be interested in what others' experiences entailed. But for us, I think we deemed it simply necessary for you to have a good idea of the technical side of things. You don't need to code and interest in learning to code isn't needed. But when I talk about topics regarding code, you should at least have an idea of what I'm referring to; you are, after all, aspiring to work in a technical project.
So when I refer to something like vim or memory control, you should have at least a vague idea of what I'm referring to. Brush up on that. Read a lot on technology.
A good person that came up in the discussion as an example was Steve Jobs. In many ways, he wouldn't be seen as the technical partner (at least when compared to Woz), but he does seem to know and understand the overall idea behind some of the hardware he mentions, which is vital.
However this is extremely time intensive, and can defocus you from your primary skills and abilities which would be most beneficial to the company anyway.
The second best way is to project manage some software projects. This will give you several sobering doses of reality, and will provide you with very useful reference experiences and skills in relation to software.
So, put together a spec for something you need done. Write it down in plenty of detail.
Then try to find someone to do it for you for a fixed price.
(Advanced Level : Find someone to do it for you at an hourly rate.)
Ask them to keep you up to date on their progress, and to keep you abreast of the challenges and problems they face.
Offer yourself as a sounding board to talk out problems, and challenges. The more you listen to people talk about software, the more you'll start to get an intuitive understanding of whats going on, and how developers approach development.
After a few hours, the first thing you'll notice, is the need to make everything as simple, and distilled as possible.
That whizbang spec you put together that will revolutionize life on planet Earth? As you have written it, it will take 40,000 man years and will require a budget of the GDP of a European nation.
Get used to cutting things down into bite sized chunks, and cutting those chunks into bite sized chunks.
After about 5 or 6 software projects, you will have a decent understanding of the complexities and difficulties in software development.
Ideally, most of those projects will be complete failures.
Then you will have an advanced understanding of the complexities and difficulties in software development.
After completing these tasks, you will never again utter the phrase : "But it's just a simple requirement. Just do it, it should only take an hour or two."
You should also be filled with respect and admiration for people who can turn ideas and solutions into workable and clean software.
You are now ready to not make your technical co-founder go completely insane.
Good luck !
Some possibly helpful resources which you may have already seen:
http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...
http://www.joelonsoftware.com/ (right sidebar has a ton of articles)
http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...
http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...
Joel Spolsky mentions that every manager at Microsoft has to read it (I could be wrong on that, but a lot do read it apparently).
(Note: I differentiate "knowing how to code" from being a coder. One means I made it through Python for Dummies; the other means I have a history of making software and understand the issues around it. That is far more than useful.)
The biz cofounder needs to understand the technology as it applies to their business. Simple example: my startup relates to email. I have to understand SMTP, IMAP, and POP pretty well. I don't have to know how to build a mail agent.
You need to understand your particular technology backwards and forwards. When you are out talking to people, you are going to get asked technical questions. You need to understand all the pieces of the system and how they work together.
In a big company, marketing, product management, and even sales engineering may get away with just using marketecture documents. You can't do that. You need to understand the full architecture.
A biz cofounder don't necessarily need to know how to code. Picking up a book and learning how to code won't help significantly. The value of a coding background for a biz person is understanding the development process, which kinds of things are easy to change (and which aren't), and (perhaps) acting as a sounding-board for the tech founder.
Since you aren't going to pick those up without a few years experience, just learning to code gives less value. Learning the meta information about coding (project management, agile development (and what that means to both developers and product owners)), mythical man-months, etc, are more valuable.
(All of this is, of course, my own opinion and worth every cent you paid for it, though I'm not sure it's worth every cent pg paid to host it...)
I wasn't sure if there was a way to learn the foundations and jargon for what technical cofounders do, without actually beginning to physically code. It seems that the main intention is to be able to communicate on a higher level with a programmer than describing in layman's terms what I want.
I think a big issue is understanding the software development process. I would check out "Inspired" by Marty Cagan and a lighter (more anecdotal) read in "Dreaming in Code".