If you spend an hour thinking about and writing a shell script that then gets used 8 hours a day 5 days a week till the end of times, should you get paid for just that hour or for the whole time the script is used?

I guess that's the question between being an employee and giving away 100% of the IP VS selling a product (which you don't do when you're an employee).

Ok, then how about this: If you're in any job and develop a script, can you also keep the script for yourself? Let's say it's a script that combines all the libraries just the right way. It's not a back-end but people call it back-end, but it's a script too. So it's a script... So if it's a script then you can use it right?

I'd say 80% is the easy, but less lucrative approach. There's always room for negotiation though. You could frame it as "my 100% hours are valued at X + 20%, but you're only offering X for the position. In that case, I can do 80% of hours for X." (yeah I know the math isn't exactly correct, but you get the gist).

I'd say a part-time contributor cannot be just "another engineer" (same tasks, responsibilities) but at 80%. For one thing, work tends to expand to use all time available. Most projects are constantly 'behind' in some or other dimension. And importantly it's going to cause some sort of social tension, especially if "100%" engineers do on-call, etc So I'd recommend one of: • create very distinct roles e.g. consultant/architect (in the true senses), or library developer (e.g. someone who works on the tech backlog and is removed from LOB) • Pay everyone 100% and let everyone organise their work hours as they please. 4-day week is just one of the many possible formulas (which less experienced remote workers are still discovering)

I would say 80% of the hours for 80% of the pay sounds like a reasonable request for you to make to kick off the negotiation. > (because they still bring experience to the team, take part in designing solutions, Those are some of the 'pros' for the company, but they also need to balanced against some of the potential 'cons', including: 1. Your day's off can impact the team: Example: they might be blocked waiting for your help; they need to delay meetings and decisions; they can't ask you about code you have written; a colleague's PR might be blocked waiting for your approval etc; 2. Your schedule makes you no longer usable for certain tasks. Example: If there are urgent tasks that must be completed within 2 business days and takes 2 days of work, then your full time colleagues can pick these up 5 days a week, but you can only pick these up 3 days per week (as you can't pick them up on your day off or on the day before your day off). 3. Assuming that there is a fixed amount of time for keeping up with non programming tasks (learning what the team is doing, reading codebase, meetings, reviews, career development etc) these will take up a higher proportion of time for a part time vs full time person. 4. Part time developer roles are currently not as common as full time developer jobs, so the company may feel this gives them a slight upper hand in the negotiation. All of the above issues can certainly be mitigated, overcome or (perhaps) even turned into positives, but worth being aware of this perspective for your negotiation.

Thank you so much for the inputs. Very very interesting and definitely food for thought. To be honest, I was leaning towards a simple rule "20% per worked days / week" but then started to see a bit more pros than cons for the company. All your points are very valid and it feels like the pros and cons for the employee and the company could cancel each other out in most cases. (ie, 80% for 4 days sounds like a good deal for both). But your points made me see things I had missed and I'm very grateful for that! 🙏

On teams that mostly do synchronous collaboration, an 80%-time employee is worth less than 80% of the f/t salary because the rest of the team constantly has to schedule according to the 80%er’s schedule. Also, cumulative business knowledge over time will be much larger for the 100%ers.