Hacker News Reader

Comment by qrohlf | Hacker News Reader

I experienced this in the extreme recently. I'm a very experienced dev in a very in-demand field. Money is not a huge priority for me in my career. Flexibility is. I have a proven track record of success in part-time roles after converting to part time at my previous company (after 2 years of full-time, of course). I spent 3+ months trying to get part-time engagements, and was willing to consider both consulting and W-2 arrangements. I got interviewed and then ghosted by two companies, was offered a laughably low rate by a third, and a fourth showed interest but then basically told me that I'd need to work a 40-hour week. I know that a vocal minority has success in part-time consulting, but it's quite difficult to accomplish if you live outside of a tech hub (I'm based in Central Oregon) and don't have SV connections.

Contrast that with when I gave up and decided to make myself available for full-time (remote) work. In the span of about 5 weeks, I got over 200 recruiter emails, interviewed at 10 companies, and received 10 offers, mostly in the upper end of the $200k-400k range.

I firmly believe that this is a cultural block, rather than one that's rooted in rational/pragmatic concerns. Tech companies want to feel like they're getting your full intellectual output, even if that's demonstrably false in the status quo. There's also this issue that gets brought up of "if Bob is gone half the time, isn't that going to breed resentment with his full-time coworkers?" (answer: only if you have a shitty "butts in seats" management culture).

I honestly don't think we're going to see meaningful change in this area for a while. The 40-hour work week is something that's heavily ingrained in tech culture, to the point where certain companies' "perks" are heavily tuned towards incentivizing you to stay at the office longer and frequently turn that 40 hours into 60. I think it will take an external disruptive event on the scale of COVID-19 in order to change this aspect of tech culture.

View on HN

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.

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.

> 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

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.

> 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.

> 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.

> 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.

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.

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.

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????

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.

As someone who's hired part-time developers off and on for years.... the issue is that they typically start out working the agreed-upon number of hours, then begin to work less & less over time. There's no feasible way to make someone work more hours remotely, and they're usually sharp enough to get partway into a project before flaking out so that it's difficult to just replace them- you'd have to hire an entirely new developer to understand what they've done to date. From the developers' point of view I think they're just constantly looking for new work, better-paying work, or at least lining up a project for the future- then they get overloaded and choose to flake out on the client.

In theory hiring freelancers part-time should be a great solution for everyone involved, in practice the issue is flakiness

More money per hour is a buffer for finding work after your project ends.

I agree this is a real problem for freelancers, but for part-time employees? It might be that someone needs to make a better system for remote work that gives some options for enforcement.

How is this different than a full time employee who starts to slack off?

Or is your point that part time employees are more likely to slack off because they are looking for other work/have other responsibilities that take precedence?

Because I've definitely seen my share of fulltime employees who slacked pretty darn hard.

Not OP, but there's more tools managers have to guide slacking IC's back in line when they're full time. Loyalty to coworkers/"company culture", easier to discipline if it goes on the official performance review, more of an "official" paper trail available versus contractors and part time who may be hired even by a third party agency. Part time / contractors are sometimes, not always, but sometimes in general lower quality as far as work ethic goes.

Contractor <> part-time

You can have actual employees working only 24 hours a week.

Great, more performance reviews I have to write.

Are you hiring them per/hour? Why not do a part time salary position? They are expected to spend an agreed number of hours per week (or maybe do it by the day) and the salary is proportional to that.

If they want to change the hours then renegotiate time and salary.

I think the pool of developers who are not freelancers, are OK with part-time work, don't need more salary than you're paying them for part-time work (like they have a cheap lifestyle or are already well-off?), and won't continuously keep looking for more work is in practice just a very small number of people. Sure, there's some people that meet that description, but just not very many. There's a reason the labor market has evolved to the binary of either being a full-time employee or a freelancer on project-based assignments

This seems like an assumption. We have people secretly working two jobs, and openly in cases like Microsoft’s company policy. Even companies that have 20% of time for other work in the company like Google. A part timed salaried position should be fine. Their are European and Scandinavian countries that half it established.

The other issue is flow. Flow is vital for execution, and distributing your attention amongst multiple projects means your flow breaks. Also part time devs might not commit to daily meetings, or being on call for downtime incidents.

This seems like a non issue and “Flow” is hard to quantify. Devs shouldn’t have many daily meetings period.

> Also part time devs might not commit to daily meetings

Daily meetings kill flow

They don't have to! I've worked at places with very low meeting load. A first-thing, 15-minute daily standup (with the team actually standing in a circle and going over how to share the day's work) can be lively and energizing, which helps me get into a flow state once I sit down to code.

What happens to everyone who doesn't start work at exactly the same minute you do?

> 15 minute standup.

It's literally called a "standup" to enforce the most important rule: it should be much shorter than 15 minutes.

Normally I'm an early arriver, so in those conditions I generally take care of non-coding stuff. If I run out of that, I start in on the coding work.

Thanks, I'm familiar with why it's called a stand-up. On my teams the go-through-the-kanban-board phase of the meeting is generally faster than that. But that phase also tends to spark post-standup discussions. "Oh, you want to work on that subsystem too? Let's talk a bit about where we want to take it." I think it's better if people allocate time for that, which is why, especially in places like this, I'll talk about it as I did.

Do you have this problem with people working full-time too?

If not what's the difference, do you think?

I'd say it would probably be important to have a set schedule for the less-than-full-time workers. Or at least as set as the full-timers.

The way many people I've known seem to achieve flexibility is to accept a role somewhere relatively laid back, typically at a large but non-tech corporation. If they're coming from a much more intense environment and working remotely, it often requires only a couple of hours work a day to over perform, if that.

It seems like it's almost impossible to get a role that's explicitly part time (as you've experienced) but plenty of companies are willing to offer lower salaries while turning a blind eye to enforcing the supposedly 40 hour work week.

The other ways seem to involve some combination of working for yourself, consulting, and short periods of full time employment interspersed with not formally working.

How do you in advance if it's relatively laid back?

You don’t. You’re taking the laid back job for the flexibility. If you want to make lots of money and climb the dev ladder, you work for startups or giant corps offering RSUs

If you're explicitly looking for part time you're probably not looking to advance too.

It's kinda either/or

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.

Even your pragmatic issues have a strong cultural component. There are quite a few important projects that on my team that we could afford to have take 20% longer. It's more important they have a good result than they arrive as soon as possible. We also have some projects we need done ASAP, which would naturally fall to a full-timer.

So, it makes sense to hire part-time people when the timelines can slip and they aren't on the critical path? That's not a very good sales pitch.

I'm getting downvoted, but I really don't see the problem? Not all of our projects even have a timeline to slip.

I can believe they don't have explicit timelines. But I'd bet there are implicit ones. Or are you saying that if you just never do them, nobody will notice?

That could be a cultural component. But from what I've seen, more often it's a business component. Software features should have a high ROI. The later you put something in production, the lower the return and the higher the investment. Further, the longer a team's cycle time is, the harder it is for the organization to learn.

And even for issues that are "cultural", I think one needs particular strategies for managing them. Stakeholders for the important projects that are being delayed will generally not be excited about that. And given that most companies have competitors, those stakeholders might have legitimate reason to want things to go 25% faster. So I'd be curious to see what strategies people have for solving the cultural problems.

> Contrast that with when I gave up and decided to make myself available for full-time (remote) work. In the span of about 5 weeks, I got over 200 recruiter emails, interviewed at 10 companies, and received 10 offers, mostly in the upper end of the $200k-400k range.

The secret is to take a full time job and then only work 20-30 hours a week. Pre-pandemic I was only really productive 4 hours a day anyways, but I had to sit in an office the entire day. With remote work, it’s much easier to do “full-time” work.

At most companies you get full benefits at 30 hours a week.

I think their comment went over your head

Totally. Circumstances differ of course. How efficient are you? What's the overall workload? To what degree can you work asynchronously?

But working remotely, the reality is that at least some people can get off without working a 9-5 day so long as they are at least somewhat available during the workday.

Taking it to first principles, I don't see part time as feasible until documentation has negligible marginal cost. It takes time to get people up to speed.

Another blocker is the inane requirement in employment agreements by many large corps in the US that they own your IP while you work for them, regardless how it was developed or what the topic is (one place I worked at owned children's books if you published them, despite being a software developer). Until that is unacceptable, either legally or culturally, working part-time presents a conflict of interest. Rather than valuing the breadth a part-timer might bring, it's viewed as a liability.

I’ve always been able to successfully negotiate those IP ownership clauses. Usually without any hassle at all.

US person detected. Good luck negotiating any terms in Europe. Not happening.

Brit here. Garbage. I have simply told the mixed US/UK company I worked for that they had no rights over a personal project of mine and they were cool with that. By your dismissive, failure-assured attitude I can guess that you've never tried.

> Brit here.

> Garbage.

Hmm...

"Litter"

Europa is a big place and how things like this work varies a lot.

Spaniard here. Definitely negotiated IP terms for my current contract :-)

I think it has to do more with the size of the company.

Good luck negotiating that with a FANG, smaller companies won't give a damn (unless they have a dumb HR department who doesn't understand how hard hiring devs is)

There are a lot of things in this world that are not rooted in rational/pragmatic concerns. For example, in the automotive industry, a lot of the margin comes from upper-end variants of any given model, which are perhaps 10% more capable as the base model but cost disproportionally more and are a lot more desirable. Why do people go for that? Emotional reasons. Are the $2,000 vintage Nikes worth that much, especially if you end up actually wearing them? Depends on if you're deciding on a rational or emotional basis.

A lot of this translates to the work environment. Someone making $300k might feel exceptionally rewarded for their work, until they find out that their peer makes $320k. Suddenly that $300k no longer looks that desirable anymore. Call it an innate quest for justice, call it culture shock, call it whatever you want - if you cannot see why your individual arrangement might produce a net negative result for the rest of the company, then you're ignoring the reality.

You just have to implement certain rules and treat everyone the same. You're either a full-time company, or you're a part-time company. You're either an on-site company, or you're a remote company. If you allow hybrid, you have to allow it for everyone. And if one person gets to work 20 hours a week, then it needs to be a 0-friction process for everyone else to transition to the same arrangement if they so desire. From a staffing point of view, that last part is an absolute managerial nightmare ("sorry, the project will be pushed back by 12 months because all of our engineers decided to move to part-time, and we cannot hire new engineers, because the existing staff may also move back to full-time at any given point").

There is, however, a solution for you - just work for extremely well-funded early-stage startups, because their CEOs will be more than glad to rock the boat internally in exchange for your skills and experience that they would be otherwise struggling to find in a full-time hire. By the time that startup scales and their CEO starts thinking about culture and retention, you'll be off to the next boat that you can rock as hard you'd like.

In Switzerland it is extremely popular to work part-time in IT. To the point that most men I know have reduced to 4/5 when they became parents and most women to 3/5.

The deal in companies is that it's relatively easy to reduce your work % but it's a one way street. To get back your manager needs to find a budget the same way as if they were hiring (but I don't know anyone who did want to increase it back).

Seems to work well.

Are these figures x/5 weekdays, a range of daily hours, or something else?

I (a man) was 4/5 when my kids were small but I'm currently 9/10. Contractually it's yearly, but it ends up weekly. 9/10 tends to be difficult to distinguish from full time, since you get more focused after this mid week break.

I think if I was to go for 9/10 I’d argue for 10/10 salaries because as you mention it’s practically indistinguishable

It depends on your job and responsibilities.

I've had managers/POs/PMs/... work 90% and simply take every Friday afternoon off.

But if you're a dev then yes, taking half a day off is pretty meaningless. I see it as a way to force yourself to take 22-23 additional days of vacation, and at least two of these every month.

In Switzerland jobs are usually advertised in %, where 40h-45h/week is 100%. From that it is also usual to talk about 80% or 4/5days/week (and so on for other percentages).

Fascinating! I heard the Netherlands has a strong part-time job culture too.

I’ve worked anything from 24-32 hours a week in the Netherlands, but never 40.

Salaries (even full-time) are crap though.

Only if you consider 32/36 hours as part time - the culture is strong in the sense that those are often considered full time as well, and are therefore allowed, but getting a job with fewer hours than that (eg for a three-day work week) will be a lot more difficult.

Depends on the company but I've seen all possible deals. - 4x8h a week - 5x6h a week - fully flexible 50% to reach each quarter

Most of my consulting has been full-time but I have had a few part time - generally these are in:

1. not in demand fields but fields that for some reason are momentarily needed by the company.

2. fields the company hopes to teach someone else to handle.

3. using technology that the company wants to move off of because they don't have anyone that knows it anymore.

Those fields - Accessibility (achieving WCAG 1.0 conformance), XSL-T - had an xml + xsl-t generating website, team is rebuilding to React and know nothing about the old tech, DSSL stylesheets that needed to be moved to XSL-FO. I also nearly had a part time JQuery maintenance 2 month project about a year and a half ago.

My suspicion, if it's an in-demand field people want you full time, that stuff is IN DEMAND after all.

I do think a lot of it is "tradition" for lack of a better word. That aside--and knowing some part-time contractors (not in technical roles)--a few things.

1.) A significant percentage of cost per employee to a company is benefits. So work half-time and the breakeven to the company is probably something like 1/3 pay if you get full-time benefits.

2.) The above doesn't even count that there are a lot of other overheads (management, coordination/meetings/collaboration) to having more people doing the same work.

3.) It depends what part-time means. Many of us might be OK with 4-day workweeks or shorter days--though to some degree those may be possible in practice today with the appropriate workload and degree of synchronicity. However, if your preference is to take month+ blocks of time off on a regular basis, that's much more difficult to accommodate. (And, if you unplug during those times you lose a lot of context. Earlier in my career, I did take month long vacations now and then but it's hard to norm as a regular thing for lots of good practical reasons.)

I experienced the same. I asked an acquaintance who runs a 1000+ dev company, why is it so difficult for devs to find part-time jobs. He replied that he had thought only admin staff could do that, he found the concept weird. Very much in line with "this is how it works" as the article mentioned.

How did this person come to run the business?

Had some academic ties and some project was spun-off. But it was a long time ago, when C++ was the shiny new thing. How I understood the business grew naturally from 3 people to 1000+ today.

Maybe try working through an agency?

I'm in a similar boat, and I've been doing part-time work through Toptal. You certainly get more opportunities if you're full time, but I've been able to steadily get 10-20 hours a week at a rate that would come out around $300k if I was working full time. For me that is plenty to live comfortably and I'm able to choose to have more free time and not feel "owned" by a full time salary position that would likely be more like 60 hours a week of my time.

If you think your job as an engineer is to write code, then sure -- part time makes sense.

If you think your job as an engineer is to build a solution as a team, then one person hopping in and out of availability creates a hassle for an entire team. Can't have project meetings on Mon / Fri because X is never there. If a project with involvement by a part timer isn't done by eod Thursday, a fulltime person has 2 dead work days until the part time person shows up again. etc etc.

I agree that someone working fewer days per week might be hard to fit into a full-time team culture, but someone working fewer hours per day ought to be pretty easy. For the "fewer hours per day" case, it's just like working across different time zones, which many companies are already well-acclimated to doing -- e.g. you need to schedule all your meetings with this person in the morning because their 5pm is at our 11am.

Not easy at all if you have remote workers.

Someone from EST works 9am-1pm; someone from PST starts work at 9:30am. Daily overlap: 30 minutes.

Yes it could be solved if you want to define core hours in the middle of the day, but I suspect people who want half time work don't view working in the middle of the day every day as the point of the exercise.

But this is great. If your company culture doesn’t depend on everyone always being there, it has a million benefits unrelated to productivity.

Working becomes so much more relaxing.

But also less profitable per hour. Doing "line" work where you have no unique contribution means you have less negotiating power and so get paid less.

The bigger issue I've seen is that there's a relatively fixed amount of time required for overhead activities (e.g. compliance training) and context sharing (meetings). Purely hypothetically, if those sorts of activities eat up 10 hours a week, then a full time developer gets 30 productive hours, whereas a half time developer only gets 10. You might think there's room to cut down on overhead, and you might be right, but when the majority of employees are full-time, it may not be the most pressing issue to change.

I believe a large part is also due to the incentives of recruiters and how they is structured. Most recruiters take a fee that depends on the hours put in or a percentage of the total contract, or a mix. Surely some exceptions exist but I believe most are incentivised to only go for atleast 32 hours to make it worth the effort, and thus don’t bother eating a potential 40 hour contract on a smaller 16 hour one. I see the flawed logic but I’ve asked around a ton already and it’s always no while I know the market is there when I’m already inside. I just haven’t met the right clients I guess.

Not really. Yes they will push for more, but by far the most important factor in sales income is number of deals closed, not +30% deal size.

I’ve done part time and managed somebody doing part time. The biggest issue is that you have everybody else not tracking hours at all, just thinking about the work that needs to be done and one person who is militantly tracking hours to ensure that the exit the moment the clock hits the hours limit.

It gets weird on a team of full timers if the part time person is expected to interact with the full timers at all, especially if they are all working and need to communicate with the person but they are out.

Believe me, I sympathize though. It does create a strange dynamic though.

In my experience, tech consulting firms are very friendly to contracting arrangements. They tend not to be stuck in a “butts in seats” culture because of how they operate with their customers.

I've long suspected this. Question for anyone who wants to take a stab at it: how, as someone wanting an 'in' to the consulting world, to best find and separate companies that are actual consulting firms and not just burn-and-churn MSP shops that carefully and sometimes convincingly disguise themself as such?

In my opinion, I would ask three things:

1. Ask about the makeup of a typical team. The more layers of bloat and regurgitation between the customer and the developer, the more likelihood that the people doing the actual work need a high degree of hand-holding.

2. Ask about their overall approach to customer success, and specifically, what they do before they start development. Good quality consulting firms will have entirely separate non-development projects focusing on fully understanding the problem space before they ever start development. If their customers just throw software requirements on their desk and ask work to start tomorrow, they’re probably not competing on premium quality solutions.

3. Ask about how (or if) the development team works cross-functionally with the customers’ business teams. Burn-and-churn shops will hide their developers from their customers. High performing teams may send a developer solo on a flight to a customer site.

Excellent feedback, thank you!

> burn-and-churn MSP shops

What does this mean?

Finally something I can answer! I've been doing tech consulting for over six years now.

- Straight up ask them if they're an MSP, lol. MSP isn't a bad business at all; I highly recommend it for juniors needing an in or people who want a lot of exposure to a lot of companies simultaneously. But you don't want MSP work.

- Avoid avoid AVOID WITCH companies (Wipro, Infosys, Tata/TCS, Cognizant, HCL). While they have _some_ A-team strategic work, the lion's share of their business is butts in seats labor arbitrage.

- Also avoid WITCH-adjacent companies (Teksystems et al). Same reason.

- Do a LinkedIn deep dive. If a majority of the company's employees work in an offshore location, they are more than likely butts in seats. This isn't always the case, but it's generally safe to assume so. If you're really interested in what they've got going on, bring it up in the interview and turn your bullshit meter to 11.

- This gets a little tricky for big tech shops, though (Red Hat, IBM, Accenture). They have a lot of butts-in-seats stuff, but they also have a lot of very interesting, very high-impact projects. There are ways to monitor what you're being considered for during the interview process; see below.

- Ask about some engagements they've done (client names don't matter), generally ones they are proud of. Ask about how those projects were structured, the number of people involved, and the objectives. Huge implementation projects usually have a high BIS factor, but some consulting companies charge through the roof for onshore consulting with an emphasis on high-quality software craftsmanship. This usually comes out in the interview; the interviewer mentioning xDD, hard 40 hour limits, and first principles is a good sign.

- Ask them "in your opinion, what's the ratio of staff augmentation to strategic work at this firm?" BIS work is called "staff augmentation" or "staff aug." Not all staff aug is BIS (some better firms take staff aug since it's much easier to sell than strategy but the consultants assigned to those still have autonomy, i.e. they can roll of when they've had enough/they can contest decisions with support of their engagement team/etc), but a high ratio of staff aug to strategy work smells like high BIS.

- The technical interview should be focused on your thought process and experience. "Tell me how you designed this system/explain this decision/if I changed x, what would happen" are some questions that should come up. If they are asking you very-specific trivia (what command would you run to do x/what is the name of y component that does z), then expect a high BIS factor.

When you say you made yourself available, what does that mean in practice? Targeted network outreach? A LinkedIn post?

Reply on news.ycombinator.com