I work typically 3.5 hours per day, at a high enough billing rate to cover my expenses. I've been doing this since 2009 reasonably successfully. However, I am a contractor - I'm not working for a single employer on their payroll.
Your employer, in this circumstance, will be a very small organization and you will most likely be their only programmer. In short, they're too small to afford full time, so they'll look for part time. Such an organization might have 50 employees and between 25 and 40 computers.
Good candidates for this are small wholesalers, medical clinics, highly specialized small volume factories, small restaurant chains, etc. Manufacturing, for instance, often has unusually specific issues - food packaging (and other perishables) have unusual recordkeeping requirements, for example. You will need to be an expert in how those things work, although it is something you can build up over time.
How to Find
Given that there are probably thousands of SMBs (small and medium sized businesses) scattered around the country, it's an interesting trick to figure out which ones can sustain a developer. Often such companies put out indecipherable ads, or something hopelessly vague. Examples are 'Programmer', 'VB6/Microsoft Access', or 'Reports and Spreadsheets'. Some other things to expect with it: ridiculous pay rates (you will have to negotiate hard to get 'fair market value'), mixture of developer and non-developer work (I've seen ads for 'VB6 programmer, help answer phones when not programming' or 'Server and PBX tech support'), and 'SQL Server Stored Procedures and Photoshop' - i.e., you're a graphics artist and database guru.
Many of my clients are word of mouth, so someone knows them and knows me. Sometimes one of your tech friends is trying to take care of someone they can't handle since they're overcommitted. So some of this stuff shows up via the grapevine.
In short, you're going to be dealing with non-technical people, so you have to figure out how to communicate in their language. I have often walked in on organizations who have a contractor who says things like 'Oh all that is technical stuff and you wouldn't understand it' - usually these people are taking the client for a ride. It's critically important to treat the client as if they know what they're doing, even if they don't, and expect them to take command of their requisition process, even if they're highly deferential. In short, expect them to grow into a smarter IT services consumer. At the start, they might find this bewildering, but as you show them how it's done they will really appreciate it.
