As a developer, I agree there's a cultural issue, but think there are pragmatic issues. I have done both part-time consulting and part-time contract developmen

As a developer, I agree there's a cultural issue, but think there are pragmatic issues. I have done both part-time consulting and part-time contract development. Pure consulting (when one's output is advice) is doable part time, because you're not a blocker and generally don't have to keep up with the day to day. But I would only do part-time contract development under pretty specific circumstances: 1) I'm the only dev on the project (or at least I know the other devs really well), 2) I am not on the critical path for anything urgent, 3) the organization can sustain an interest in the work (and therefore in paying me) despite it not being urgent. For example, I knew somebody who needed a discrete service, a PDF form-filler, replaced. The old version was a pain operationally and I think it was built on EOLed tech in a language the team didn't know. That was a fine part-time project because the existing thing worked tolerably well; I was just cleaning up a mess that bothered them. I'd feel the same about, say, tech debt cleanup. Or quick, throwaway prototyping. But in general, software is a team sport, a collective intellectual work that requires a high level of coordination between both devs and many others. I don't want to be part time on a team of well-meshed full-timers because the overhead of keeping track of the team's progress is fixed. I'd have to spend a notable percentage of my time keeping up, and I'll be adding to the coordination burden of the team despite not contributing as much, so my net ROI is lower. I'd hate it. That said, I'd be interested to see a project that's, say, all 4-day-a-week people. Maybe even people who work 6 hours a day, 4 days a week. I could imagine that working pretty well while still being enough to keep stakeholders satisfied.