What about a 40 hour week working just 4 days?
When I was in the SF startup scene, I was very fortunate to work in a company where everyone trusted everyone to work with whatever schedule allowed them to maximize productivity. It turned out that 8x5 worked pretty well for me (sometimes with an hour or two nap in the middle, though I don't do that anymore). In the beginning, I worked more hours per week, but that just resulted in me needing to fall back on the lack of vacation policy to take frequent 1-2 week vacations (adding up to maybe 6 weeks per year). When I normalized my regular schedule to 8x5, I stopped needing to do that (although I still place great value on vacation time).
Many of my coworkers had rather different schedules, including one who seemed to be able to work very long hours about 6.5 days a week without much apparent drop-off in productivity.
I think the breakeven for a 200k full time employee would be maybe 80-85k for a 20h a week. Which is still enough to get by in many places.
Why do employers not want this? I can think of a few reason. Knowledge transfer is hard. Adding workers to a project always makes it slow down by a fair bit (as in less than linear scaling). So a project that has 1 40h person right now. How many 20h employees would it take to replace him? 3? 4? 5? Perhaps 5 20h employees could do a programming project to the level of 1 dedicated 40h employee. Which then means the actual "equal" pay for your 20h employee is more like 35k per year, not the 85k mentioned above.
And for the project, if you've got two people doing that, let's say 60% of the velocity of their 40-hour selves, you're essentially getting the work product of 1.2 people for the price of 1, from 2 separate people. All while having happier, more loyal employees to boot.
I'd absolutely work 20 hours a week if I could get paid 40-45% of my current salary and if I didn't think it'd kill my career prospects at my current company. Even places that would entertain the idea of part-time engineers, I don't think they'd be promoting any of them to manager or director.
There is a HUGE communication overhead in writing code with multiple developers. HUGE. If you have Bob writing a program all by himself, he writes at speed X. Now you add Jim. Jim is just as smart as Bob. But he doesn't know the way the object model works. He doesn't know about the glitch where sending null to some method causes a really weird stacktrace that is hard to debug. He doesn't know that the reason Bob did something else was to cover a real but rare network event. So Jim makes mistakes. Jim and Bob have to discuss decisions. Jim and Bob need to have meetings, and design reviews, and repeat mistakes. So I bet the total code delivered by Bob + Jim is something in the range of .9X to 1.1X. NOWHERE near 2x like linear scaling would deliver. You can argue something like the total code quality improves with more eyes, fine. But Bob is held back a lot and able to write a lot less code because of the newly added teammate.
This is why some of the most influential pieces of software ever written were done by 1 man teams. A decent 1 man can be much much more efficient than a 2 man team.
So back to your example. Bob goes halftime, and you are right - his productivity drops from X to .6X (not a full 50% loss, because his brain is more rested). But adding in Jim, you don't get .6X + .6X.. you get more like .5x-.7X total productivity. Adding a third Billy, and you end up with maybe .8X the original Bob speed. Remember you now have 4 people. So you need 4 way meetings. Each person picks different parts of the codebase to specialize in. People now write code that will conflict with other people, maybe not even knowing it for months. Maybe a forth programmer Jen can get your total productivity back to the original X of just Bob. So you know took 4 half time employees to replace 1 full time employee.
All of this is why I think a team of 2 is almost always a mistake. A team of 1 can go pretty far, and when it hits a wall - it may be time for a team of 3 or 4. Team of 2 has all the downsides of a team (communication overhead, etc), with not enough bodies to rocket the project.
I'm going to assume this is including any stock options and other benefits? Because IIRC the software engineering profession caps out at around $200k... and that's only for the best of the best in places like SV. Please correct me if I'm wrong. I'd love to be honestly haha.
$160-200k base salary
$10-50k cash bonus
$20-200k annual RSU vesting (heavily dependent on the company, how many years
you've been earning stock awards, and whether you're
considered a high performer)
There's a reason people continue to work at BigCos, and stay in the Bay Area despite the (modestly, by these income scales) higher cost of living.
First 20 hours: read a bunch of math papers about some obscure part of stochastic programming.
Second 20 hours: figure out how to apply it to problems useful for the company.
The first 20 hours are worth $0, not $100k. If I spend an additional 10 hours/week improving my skills, that effect is multiplicative rather than additive.
Claudia Goldin has a great paper on this effect, focused on using this phenomenon to explain gender gaps in pay. (Specifically, the fields with the lowest gender gaps are the most linear fields, e.g. Pharmacists.)
http://www.aeaweb.org/aea/2014conference/program/retrieve.ph...
Week 1: First 20 hours: read a bunch of math papers about some arcane aspect of stochastic programming. Second 20 hours: figure out how to apply it to problems useful to the company.
Week 2: First 20 hours: read a bunch of math papers about some arcane aspect of partial differential equations. Second 20 hours: figure out how to apply it to problems useful to the company.
If you are only working 40 hours rather than 80 in those two weeks and you choose to do the first half of each week then, sure, your net value to the company will be $0. So don't do that. Pick one of those two 40-hour chunks and do it in two weeks instead of one.
And, boom, your value to the company has scaled linearly.
Now, no doubt your work on stochastic programming and PDEs has prepared you for some other future work of still greater value. So there's nonlinearity on longer timescales. But we can get an estimate of just how much nonlinearity there is there by looking at how your salary increases over time. Maybe you're worth 20% more each year than the year before. (That would be bigger pay rises than most people get after the first few years of working.) In that case, the first half of a given year is worth about 47.7% of what the whole year would be worth instead of 50%.
So, if your work's value is nonlinear enough to justify giving you a 20% pay increase every year, then it's nonlinear enough to justify paying you about 5% less pro rata. (Plus, of course, giving you only about half as much pay increase per year.)
That assumes that the growth in your value to your employer comes only from this nonlinearity in your work. If some of it is because of other things that you're learning in other ways, then the reductions should be less.
Second, by working more slowly and parallelizing across many more low productivity people, you lose the ability to make connections and reuse relevant expertise.
For instance, consider two lawyers each of whom are running half of a major case. When the opposing attorney presents claim A, the two lawyers may not realize that evidence X (in lawyer A's half) and evidence Y( in lawyer B's half) put together refute A.
Like it or not, there is value to having a single person who can keep the whole thing in his head.
Well, sure, half as much work means getting half as much done. That's why the pay is also half as much.
I don't disagree with any of the things you say here; there are some ways in which working part-time is less efficient than working full-time. I just think you overstated the case before.
You can make up for it the remainder 3 days of the week, but if your 4 work days are contiguous, that's a long time to be essentially absent as a parent.
Especially if you commute any significant distance. Skipping one commute a week is a big win.