Hacker News Reader

Comment by yibg | Hacker News Reader

We’ve tried part time developers, but so far haven’t been able to do it successfully. The problem usually comes down to 2 things:

1) there is a constant amount of overhead that is always needed regardless of how long you work for in a week. Meetings and collaboration to figure out what to build, discuss issues etc. if these take up 10 hours a week a full time dev has 30 hours to do other things where as a half time dev only has 10 hours. So 2 half time dev just doesn’t get as much done as 1 full time. I guess this is also why 2 engineers don’t get twice as much done as 1, all things being equal.

2) Most part time dev candidates I’ve seen aren’t doing just a single part time job, they are doing either multiple part time jobs or a full time job + part time job. Either way the mental energy is already gone.

Maybe there is a way to make part time work, I just haven’t figured it out yet.

View on HN

I agree. There is too much shared state inside software dev work. I think the only time part time might work is if the person has worked for you full time for a while, is fairly established, is a low management overhead employee (low/no drama, no hand holding, self-directed, gets the point quickly when you ask/tell them in small amounts of description, doesn't need mentorship and and gets stuff done). But then what often happens with part time devs like this is their one foot out the door, so they will probably leave in a few months anyway.

In other professions where the shared state isn't as big, such as medicine or therapy, you see way more part time style work happen actively in the industry. Be it working for 2-4 clinics part time or just doing half hours so they can focus more on other things in their lives.

Another kind of role that I think works well part time is an advisor / consultant expert role where your hired to verify things are being done correctly in your sub field and are used to train others design wise as a 3rd party. Which is another sr / experienced type of role.

Another type of part time that might work is working on your own project as a solo dev in maintenance mode once your established. But also only lasts so long as competitors get ahead of you.

Part time not working well is something inherent to the job itself unfortunately.

> But then what often happens with part time devs like this is their one foot out the door, so they will probably leave in a few months anyway.

This sentiment is what GP points out is cultural, not practical or factual. If you compensate them well for the hours they work, many part time devs will have superior per-hour output to FTEs and also be grateful for the added flexibility you afford them.

We hired a stellar part time dev recently (contract hire to start, we just increased his rate and verbally stated we are interested in continuing the relationship long-term if he is, and offered written agreement if he is interested), and he has been working out great. The option is open to him to work full-time whenever if/when he wants by planning it ahead of time with us, but our default expectation will remain being part-time so he can pursue his game development on the side.

Finding a great part-time team member is no different than a great FTE, once you and the employee are both free of the cultural negative baggage associated wtih part-timing.

> Meetings and collaboration to figure out what to build, discuss issues etc. if these take up 10 hours a week [...]

There's your problem.

Why is this a problem? You can replace meeting time with time reading specs / requirement if you’d like. Point is you need some constant amount of time to understand the problem domain. If 2 people need to do that then that’s twice the time needed.

Yea this has been my experience as well. You either have meetings, or spend hours reading specs and a sync talking back and forth to ensure the requirements are correct.

The only way I see real value is if you’re the sold dev/architect or if you can come in and confidently pick up tickets and they’re properly scoped and documented.

Having a meeting involves more than 1 person spending time. Reading a spec involved only one person investing time (only those that need to know it anyway).

Doing it in a meeting where everyone has different questions, tangents and other cruft that you have to sit through is extremely inefficient.

Yes but if you have 2 part time devs, that requires 2 people spending time. The discussion here isn't meetings vs doc, it's full time vs part time.

If you have 2 part time devs with a manager giving them the info in the meeting, that's 3 people spending time, and the two part-time devs won't have 100% overlap of information needed and questions asked and answered (and if you have two separate meetings with each PT, then they won't have access to the questions/answers discussed with the other dev _in case_ they need it).

Additionally, everyone can focus on producing and consuming information in the downtime between focus-work sessions, without interrupting flow at someone else's convenience.

In all cases, quality documentation is more likely to produce accurate information transfer with less time wasted by everyone involved.

I dunno. I for one wouldn't want to work at a place where I'm just handed a bunch of docs to implement. I want to be able to ask questions for clarification, suggest alternatives etc. All of which takes time.

What are you building that requires an individual dev to read hours and hours of spec? I’d like to think my company builds some pretty cool shit, and even then, I can explain an issue in less than 2 paragraphs.

If you need developers to spend so much time ideating and figuring out how and what to build, you’re mismanaging those developers imo.

The time require by devs for non coding work is inversely proportional to how relatable the domain is and how specific the problem is. Tell me to build a clone of twitter and I can make a lot of autonomous decisions. Tell me to be an ERP and I'll be spending most of my time not coding. Most of software development are in domains that most people don't intuitively understand.

We run a 5-person dev team (1 designer, 2 technical founders, 1 dev full-time, +1 part-time dev) with 30 minutes of sync-time per week for non-founders. Our part-time dev can perfectly run with those specs thanks to our encouragement of daily documentation and written specs rather than waiting for a big meeting to ask and be asked questions.

Heavily depends on the nature of the work in question and size of team. Larger the team, and more foreign the domain the more time is needed to coordinate work.

Broadly, I disagree, at least when talking about any team or sub-team focused on software development.

It depends more on the personalities, values and organization of the workplace and the team — for any size, if more than 20% of people involved need to spend more than 2 hrs/week in meetings — it is an organizational/ops issue, not an inherent feature of the work.

> more foreign the domain the more time is needed to coordinate work

More foreign to who? If it is foreign to individual team members, then it is a problem of insufficient onboarding/training material and process, poor documentation, or under-qualified hire.

Foreign to the engineers. Onboarding still takes time, regardless of documentation. There is a reason why CPAs takes a year to complete, even though there are lots of high quality written material that have been used for decades. Ever tried getting productive yourself quickly when working with some domain specific software like accounting? There is a lot of context that needs to be learned.

Silly excuses. No software team needs 10h/week of meetings, that's just insane.

Fix your management and you'll be able to hire part time easily.

What's the alternative? Have some PM+EM write a perfectly detailed spec for you to implement? That sounds like hell. I can't imagine spending all my time building something that I had no input on designing.

I mean, that's one direction. But we could also give the part-time engineer more autonomy so that they can quickly make decisions on their own. They'll still need to spend time talking to people, but they can figure out an effective way to do that based on context—which might start out with them spending more time during the week just talking to people, but will fall off quickly once they build an understanding of their domain and the external interfaces of whatever they're building.

If my experience is anything to go by, this sort of self-directed collaboration—think "design discussions" rather than "meetings" or "ceremonies"—will end up far more productive for everyone involved.

The comment that started this whole thing said "Meetings and collaboration to figure out what to build, discuss issues etc". I think that covers both categories of good and bad types of collaboration you describe here.

For some engineers that would be bliss. They just want to churn through tickets and not have to talk to anyone (or very little).

And I can get someone for a quarter of the price who can do that on Upwork. (That isn’t to degrade anyone on upwork, but to point out that the code itself is a fraction of the job.)

It might be more work to develop a specification that requires no context to complete than to do it myself.

I too would crave a part time programming job, mind you, but I think that only works on a team that is completely part time.

I agree, writing the code is usually just a fraction of the work but I've yet to see someone who is good at it, costs a quarter and doesn't care about the rest of the job. (Even without the costs quarter condition.)

Hire senior level people part time. That don’t need to spend lots of time getting context. They can figure out how to solve problems matching your team’s coding style without extra meetings.

You're assuming the team works on something most developers know enough about. Often times that's not the case and it takes time to get familiar.

Understanding the problem and how to solve it is harder and more important than matching code style. Unless you're working on trivial CRUD web apps or something where problems and solutions are obvious.

Believe me, don't get me wrong, I would gladly trade 50% of my salary to work part time. But...

    That don’t need to spend lots of 
    time getting context. They can figure 
    out how to solve problems matching 
    your team’s coding style without 
    extra meetings.

I've worked a variety of enterprise-y developer jobs, and I don't find that to be the case at all. I mean, that context is the job.

Coding bits of functionality for an existing business is not a matter of "matching the team's coding style."

Heck, there are often not even engineering "problems" to "solve." It's a matter of figuring out integration with existing systems and processes, understanding the business itself, etc. That's why part-timers don't make sense. They can't just walk in, sit down, and code.

And if you could tee things up for them, to the point where they could just sit down and code, then 90% of the work is already done. And your part-time coder will take longer to deliver... why would management want to wait 2 weeks for a part time person to complete 40 hours of pure coding work, versus 1 week for a fulltimer?

Well, I think knowing the business is important on most feature work, but what if part time folks were cleaning up well-defined tech debt? Usually I know exactly what my tech debt is, I roll my eyes at it as I force myself to leave it alone. Then as I get loaded down for feature work or important bug fixes it just rots in my backlog til I notice it sometime later.

That would be much less valuable to the business. You'd probably be looking at 10% the salary of a full time dev who's actually solving business problems.

If you were a productive fulltime dev, learned the business, knew the app, knew the tech debt, knew the right people to ask about various bits of the code, knew the stakeholders, etc?

Yeah, I think you could step back from that at some point and be a heck of a part-time asset.

1. Your knowledge of the app and organization would likely decay over time.

2. I'm not sure the the organization would love this move. It would be better than losing you entirely, but probably not as valuable as having you fulltime. From your perspective, 50% of your time is better than 100% of nothing. From their perspective, they're probably going to take the "glass half empty" view.

The alternative in my experience is working on a team with a shared sense of mission. We meet at most one hour a week. We do a lot of asynchronous collaboration, it’s not always as efficient as it could be, but no one is asking for more meeting time to address that.

> We do a lot of asynchronous collaboration,

It sounds like you just amortize the "meetings" differently. Having to answer lots of async emails / slacks can waste just as much time as scheduled meetings.

We actually do most of this in issues and review. Chat is used as it should be: clarification, refining ideas in progress. I’m more sensitive to communication overhead than most, I recognize meetings masked as other communications, this is definitely not that.

> I can't imagine spending all my time building something that I had no input on designing.

Sounds like you work at startup rather than corporate. My current job is basically building on something somebody else has already prototyped. I hate it, it makes my days dull. But then one day I realized, that if I could do it as a part time job then I'd have no qualms of not wasting my mental energy, I'd gladly do what is required, clock out and spend my creative energy outside of work or with other part time gigs.

Email? The occasional 5 minute phone call to clarify things?

In the last 10 years, I have been in maybe one or two meetings each year. Everything else is done online. And I spend about 20 min a day max communicating online. And we are working on complex enterprise applications used by international airlines, airports and national rail companies. It works great. Spending 10+ hours a week in meetings is crazy.

Curious how part-time those part-time developers have been, as well as what schedule/how much work the person you are replying to was looking for.

I have successfully gotten 80% four-day-week at a string of engagements... but I work in the non-profit academic sector, and get paid quite a bit less than that $200K+ salary.

I think a four-day-week, or even a three-day-week, makes a lot more sense than tha 4-hours-a-day 5-day-week the OP was suggesting.

Because, yeah, one (or certainly two) meetings could pretty much blow a 4-hour-day. But at the 4-eight-hour-day schedule I've been doing, I feel like there is still plenty of time for meetings and overhead, and I am pretty confident I end up 95% as productive working a four-day 32 hours as I would be working 40 hours. I feel like it would still work pretty well at 3-eight-hour-days too.

Below that -- or trying to work four-hour days instead of fewer eight-hour days, I could definitely see problems with "overhead" or lack of commitment.

The meeting is part of the work. Code flies from my fingertips instantly. Figuring what to code is the painfully time consuming part. Developers barely code in the enterprise.

Of course the meeting is part of the work, I hope I didn't suggest otherwise!

I can only speak from my experience working 80% time in several different jobs, in nonprofit/academic environments. As above.

(I enjoy writing code, if writing code was "barely" part of the work I wouldn't still be here. It seems like it would be impossible to get anyone who was good at writing code in a development/engineering job where coding was barely part of the work! But I'm not sure what this has to do with the feasibility of less than full time work as an engineer/developer).

An alternate setup I've seen at (this was for a super, super experienced distinguished engineer (like a Google L9) who wanted to work part time) was to work full time one week and then take one week off

> Meetings and collaboration to figure out what to build, discuss issues etc

Remote-first, multi-time-zone companies simply don't do meetings. All communication is async and written down. Work gets done without a lot of hemming and hawing and meetings-with-no-agenda-to-talk-about-setting-an-agenda-for-a-future-meeting. It's much more efficient to come to a decision over 7 asynchronous back-and-forths, and people have the opportunity to do some research during the conversation so their decision is better informed. The whole Open Source world [when development is not done within a corporation] works this way.

I think the problem is corporations are obsessed with a definition of productivity as "the person is constantly productive". If you're not in a meeting, or have a ticket in progress, or are doing training, clearly you are just wasting time. You can't be allowed to just ruminate, or research, or play around with an idea, or talk to other teams. They'd rather you be writing code now that will be obsolete in 6 months and take a year to replace, rather than take 2 months to come up with a plan for your code that will take 3 months to write and last for 3 years. We rush into things because we have to have something to show for our work every day, and as a result the quality is poor, and that costs more in the long run.

> Remote-first, multi-time-zone companies simply don't do meetings.

Having worked for such companies, this is not true, at least in my expreience. Plenty of meetings. Very long ones sometimes, 2 hours is not unusual; 3, 4 hours sometimes on Zoom or Hangouts.

> [non-remote-first companies would] rather you be writing code now that will be obsolete in 6 months and take a year to replace, rather than take 2 months to come up with a plan for your code that will take 3 months to write and last for 3 years.

Hmm. I can assure you some remote-first, multi-time-zone companies would also rather you be writing code now that will be obsolete soon than take substantial time to come up with a plan for code that will last years and serve the product well.

Visibility counts for a lot in some remote-first environments. Depending on the management, they may regard the best form of visibility to be regular code updates, PRs, issues filed etc, rather than taking your time over deeper design and research. If they pay more attention to quantity than effectiveness, that can mean shipping code and iterating every few days is something they are looking to see, and a high priority if you want to keep your job. Async written communication on design is sometimes seen as too much talking, not enough doing.

The communication overhead should not be constant - it should be proportional to the scope of responsibility.

As a full time senior engineer I’m responsible for oversight and guidance on three separate work-streams, so I have to go to all their meetings. If I were part time then I could be involved in just one of them, and go to only those meetings.

Hr setup/issues, all company meetings, team meetings, onboarding to company specific tooling, keeping up to date with team strategic direction, manager 1on1; none of these scale with responsibility.

Yeah that 2nd point is that quite often people need "full time salary" so it is not that management somehow has backwards thinking.

I have a friend that can really work 4 hours a day, but he is a special case where he does not have a family to upkeep and no mortgage. He is also a bit hard on the frugality.

But finding such person is basically 1 in a million. If I post a job with 4h a day which amounts to 1/2 of a normal salary I will probably never get a candidate. If I post a job with normal salary and then start explaining that it is 1/2 hours and accordingly paid, some people will get angry.

I can live quite comfortably on half a typical salary, and I'm available.

I'm in the same situation as your friend and I know of at least 3 others in my friend circle. I don't think part time availability is as low as you think.

The other problem is with overhead 2 half time employees != 1 full time employee. There is the extra equipment cost, benefits (perhaps), management overhead etc. e.g. If I replace a team of 7 full time engineers with 14 half time engineers, do I keep 1 manager? That seems like a very large team for 1 person to handle, so now maybe I need another manager too. From a purely economic perspective hiring half time engineers at half the comp just doesn't seem to make sense.

You can argue that half time engineers are more than half as productive as a full time engineer because as others have said full time engineers don't work a full 8 hours anyways. While theoretically that's true, as I originally posted, that's not what I've seen. Based on my anecdotal experience, half time engineers are less than half as productive as a full time engineer.

So from both a productivity and economic perspective, it hasn't made sense.

I think the idea is that you replace a team of 7 full-time engineers with 7 half-time engineers, and get 80% of the benefits at 50% of the cost.

That's the theory, but like I said for us it hasn't really worked out like that. Maybe we're doing something wrong so who knows.

It won’t be 50% of the cost due to overheads like said above, it may be more like 60%+.

Another factor is that often the cost of developers is not the most significant factor. If a company can get say $100m of value out of $10m of salary cost on engineers, it doesn’t really make sense to instead spend $6m to get $80m of value.

And just adding more people isn’t easy as each person increases communication overhead.

Someone who's getting offered $300K+ for a full time job... Even 50% of that is already a full-time salary for many.

Not if you have a 2M mortgage

This sounds like a choice made by the person who chose to get the 2M mortgage, which is broadly speaking an outlier rather than average outcome.

If you need $300K to support your expenses, than that's a choice you can make -- if you have the ability to have a $300K plus income. That's of course a choice not available to 95% of the USA. (300K happens is around the 95h percentile income in the USA).

That some people live in houses they couldn't pay for on $150K doesn't mean that $150K isn't possibly a "full time salary". $150K is definitely in the category of "a full time salary", many people make this much or less working full time.

That a skilled engineer could possibly make $150K for working 50% time -- is a choice not available to most people, most people don't even have the choice to make $150K working full time! So a skilled engineer has that option, make would be a (healthy) full-time salary for most of the USA, working only half-time. Or anyway would, if employers would hire like this. That's the point I meant to be making.

Income distribution in the US does continue to get more uneven every year.

Personally, I would take that part time job at 80/90K a year, simply because that's all I need and I value my free time for other projects, cycling, whatever.

However, I'm not "there" yet as a developer. Maybe in a few years after I've proven myself.

> If I post a job with 4h a day which amounts to 1/2 of a normal salary I will probably never get a candidate.

I think you're mistaken about that. If you can persuade candidates that it really is 4h a day at 1/2 of a normal salary, you will get candidates who are excited by the job because it opens up their time for other opportunities for hobbies, home life, side projects, open source projects, looking after family, other consulting gigs, education, etc.

However, for developer roles you might find that potential candidates don't entirely believe the ad. I think they'd imagine the employer having unrealistic expectations of what 4h reasonable output looks like, so that they'd feel pressure to work overtime, resulting in closer to 8h anyway while pretending to get it done in less, for 1/2 of a normal salary.

This is a good point.

Persuading candidates is where it breaks. I don't have time for that, we need to hire now and if we hire someone then for next 2 years we probably won't hire anyone new, and I don't think there is enough people who would like that 4 hours. I also have to pay for ad that will get most CVs

It would be much easier if I get someone CV and he writes cover letter explaining that he would like to try such an arrangement.

I tried to get part time dev for Kibana/Elastic needs like 4 hours - anyone I approached was not even willing to discuss "why" they just said no. People also don't have time to listen to your persuasion, most of the time it is clear cut and goodbye.

> they are doing either multiple part time jobs or a full time job + part time job

Have you considered older workers that are nearing retirement? They're probably looking to lean-out, and a part-time job could give them activity in their lives, while getting you someone who is highly experienced in getting things done. You wouldn't be paying benefits, but probably a higher hourly rate (for less than 40 hours) to compensate.

Or job sharing, where you bring on two part-time workers. My sister did this for many years - it gave her time to raise her children while being able to pay a nanny + daycare. She worked Mon-Wed, and her job partner worked Wed-Fri. The overlap allowed them to coordinate, and they were able to call and send texts to each other at other times.

If I worked somewhere with 10 hours a week needed for meetings and plannings I would quit.

Who cares if they have 6 jobs, that’s not for you to worry about.

If they get good work done on your project and skip the extra meetings, they’re worth keeping around.

> if these take up 10 hours a week

Well yeah. There’s your problem.

I might look into active, high profile opensource projects to learn a thing or two from there. I think for this to work, planning needs to be very precise: as a team you know what you are going to do, devs need to be very good at what they do and enjoy what they are doing. This is often difficult for companies as there are many things that need to be done asap, projects/teams often being managed by non-tech or non-experts.

I've worked part time for a startup remotely across timezones. I personally credit the technical lead for the most part for its success. Then, the chemistry within the team was really good. When someone says something others tend to get it. And the planning. The tech lead sets up the goals for the quarter and push back on distractions from the business side except on rare occasions. The management was also very competent, they seemed to listen to the engineers.

Spending 10 hours to figure out "what to build" is madness. Having a deep customer connection should be the go to source. It sounds to me like the priority is based on momentary reckons. Sure to kill any kind of true innovation and value.

My experience with multiple part time assignments, both personally and from other coworkers, is that the contractor gets more output for the money since the mental break of switching assignments fuels mental energy, not drains energy.

10 hours of meetings a week for a dev????

Reply on news.ycombinator.com