3 ms·

Do you still want full health insurance benefits, a full laptop, and a full vacation policy? I think the breakeven for a 200k full time employee would be maybe

Do you still want full health insurance benefits, a full laptop, and a full vacation policy? 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.

pc86 10y ago
Why in the world would it take 5 people to do the same thing as 1 when they're working half the time? First, you're assuming that it's not possible to do 50% of the work in 50% of the time. If you look at the people on HN working full-time (e.g. not founding a start-up or doing their own thing but working a regular W2 gig), they could probably complete 60-70% of the work they do in 40 hours in 20, especially if they got to choose what 20 hours they're working, and especially if they're paid break-even like you said, somewhere in the 80k range. Which, before we start hearing from the SF people about they pay $25k/mo for a studio, is many tens of thousands above the average US household income and nearly three times the average US individual income. 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.
- brianwawok 10y ago
  I think you missed something. 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.
- ksk 10y ago
  You can't really call someone out on assumptions when your rebuttal contains "probably".
  - pc86 10y ago
    You're probably right.

pc86 10y ago

Why in the world would it take 5 people to do the same thing as 1 when they're working half the time? First, you're assuming that it's not possible to do 50% of the work in 50% of the time. If you look at the people on HN working full-time (e.g. not founding a start-up or doing their own thing but working a regular W2 gig), they could probably complete 60-70% of the work they do in 40 hours in 20, especially if they got to choose what 20 hours they're working, and especially if they're paid break-even like you said, somewhere in the 80k range. Which, before we start hearing from the SF people about they pay $25k/mo for a studio, is many tens of thousands above the average US household income and nearly three times the average US individual income. 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.

brianwawok 10y ago
I think you missed something. 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.
ksk 10y ago
You can't really call someone out on assumptions when your rebuttal contains "probably".
- pc86 10y ago
  You're probably right.