Hacker News Reader

Comment by dangrossman | Hacker News Reader

Salary is only roughly half the cost of employing someone, so while a 25% salary reduction for 25% fewer hours is fair for you, the employer is not seeing a 25% cost reduction. They're not saving 25% on payroll taxes, benefits, workers comp, PTO, training time and management overhead. In fact, more people working fewer hours increases most of these costs.

View on HN

This is the correct answer, and I'm speaking as someone who got a large raise last week as I was forcibly switched from part time to full time. I'm working in a generally low-profit area and the numbers stopped working.

I started it because I'd repeatedly burned out of full-time jobs. Working 3 days/week was a great 4.5 years for me, far more rewarding than the added salary I passed on could have been. Aside from lower work anxiety, I had time to write two books, give three conference talks, get engaged, get married, take up several hobbies, and enjoy life thoroughly. My work has been overwhelmingly better: I stay out of rabbit holes, I recognize deep patterns, I prioritize ruthlessly, I deliver the things my users didn't realize they need. It's not magic, it's just downtime for my unconscious to noodle around with problems without pressure.

I think working part time is a hugely valuable experience for anyone who doesn't have a pressing need for dollars in the door (eg to pay off US medical bills or student loans). There are plenty of blogs out there on frugal living + investing (I recommend MrMoneyMustache and Bogleheads wiki), so you can live comfortably and still save significantly towards retirement.

I can't argue the financial math of why it rarely works, but I'd do 3 or 4 days a week again in a heartbeat. (15 year dev, currently Rails/Django/Haskell, Chicago/Remote, peter@valent.io if anyone's looking.)

I can second the "more time for subconscious to noodle around" benefit.

I spent 7 years working remotely part of the year while living in coastal South America, and I've been transitioning to a 3-day week now that I moved back to the States and married someone from my hometown.

I believe it results in better software.

(For contrast, I had a previous approach which was itself pretty good, if somewhat adventurous -- I took fewer projects per year, with a target of working only 1 day out of every 4 in a year. That way, when I worked on a project I was able to be unreasonably focused on it because I was craving collaboration).

Sounds like my dream, how did you initially get into 3days/week? New job? Negotiated for it at an old job?

Asked for it in the initial interview. I thought I was going to give back a day in negotiation and do 4d/w, but it didn't come up. I figured I could always come back after and ask for more hours if I need the money or couldn't fill the time.

I have heard of exactly two other devs at 3d/w in the last 5 years so I wouldn't pin any hopes on that, but there's plenty of people at 4d/w.

I'm currently doing 2 days a week on a contract. It's a fixed monthly rate contract.

When summer is over I'll likely move to 3 or 4 days a week (my choice). It's a sacrifice in money, not to mention the work is for a non-profit open source project. But it's relaxing.

What project may I ask?

I'm currently doing ~2d/w at our company. The arrangement was - I'd spend as much time working as I could and want. However a baby and the other matters tend to take their share of time, leaving 60-70 hours of work per month on the average.

There are a few other developers/devops in the same office who are working on the same arrangement.

I wouldn't think that this situation is unique to the industry.

I've just been doing 3 d/w for the last 3 months. Negotiated it on a contract. I did it initially to decide whether to start a startup, but at the same I sorted out loads of admin, bought a guitar, and learnt loads of other stuff. I loved it.

Mind you, where I am is incredibly flexible with me. Last year I worked 1 d/w remotely for the summer (two mornings a week in fact, not even a whole day :-)).

It's probably easier to get this on a contract (and it'll probably help with the IR35 thing if that ever comes up)...

"They're not saving 25% on payroll taxes, benefits, workers comp, PTO, training time and management overhead. In fact, more people working fewer hours increases most of these costs."

* Payroll taxes: OF COURSE they're saving the same amount on taxes! It's not like they pre-pay taxes on an assumed amount. It's a % of what they pay you. If they pay you less, they pay less taxes on your behalf.

* Workers Comp: Firms play insanely low rates on workers comp for programmers, and workers comp is generally calculated at (RATE for job class) * ($100 payroll allocated to job class). If you pay the employee less, your workers comp premium decreases at the same rate.

* PTO: If the company wishes to offer full time PTO benefits to a part timer, they may, but many businesses have separate PTO policies for full and part time employees, including slower accrual for part timers.

Training time and management overhead are probably the real costs here.

> In fact, more people working fewer hours increases most of these costs.

More people working fewer hours could also increase productivity (that's the point of this discussion) thus could increase revenue and profit, as well.

If you pay 10% more and make 20% more revenue, that's a GOOD DEAL

You're correct but you're missing one large expense: Health/Wellness (at least, in the US, where it's partially paid for by one's employer).

I'm assuming the OP was expecting to keep this benefit since it's a critical thing for most people. The company could choose to pay for less of a share (and most companies reduce or eliminate this benefit for part-timers) but assuming it's left alone, it would not be reduced any with a reduction in the cost of salary.

You mentioned training time and management, but there's also "employee support costs" that increase by employee count regardless of salary such as HR and other support staff, state/local/federal compliance requirements that are based on the total number of people employed rather than salary (though many of these are limited to full-time staff) and others that I can't speak to since it's not my area of expertise, but his point is still valid in those areas.

On PTO - you're right in that I haven't encountered an employee that doesn't reduce the total allotment of PTO for part-timers. But even if they didn't, this would go down precisely with salary since it's paid as a full day's work not worked and that day would now be 25% cheaper.

In a sane system the health insurance costs scale with wages.

Do the US ones not do that?

In a sane system healthcare is provided to everyone free and has nothing to do with employment status ;)

There's no such thing. It's just deluding yourself and a bit dishonest to say "free" in this context, please try to say what you mean.

Is it actually, 'In a sane system healthcare is billed to everyone as a percentage tax on their income capped at some dollar amount'. Or perhaps you think it should be an uncapped percentage of income? I expect there is no country on Earth where the cost of healthcare literally has nothing to do with employment status, in-so-much as single-payer healthcare is always funded at least partially by income taxes.

One advantage most other countries have, with the government being the plan manager, is that the pool of taxes they can utilize for funding is larger. Income taxes partially fund health care, yes, but so does VAT.

But at any rate, if you ignore the "free" point of the original poster, that post was quite correct. America leans heavily on corporations to perform the management of health care, and I don't see that as particularly "sane" to be honest. To me, such is an unnecessary competitive advantage to large corporations that can better manage the bureaucracy and expense. Small business owners often cannot afford the time and expense to offer this (understandably, to be honest). Consequently, employees that are self-employed or working for small companies may have to forgo health insurance.

It is very possible that this leads to some talented employees resisting leaving a corporation purely for health insurance reasons, a phenomenon called "job lock" (https://www.jstor.org/stable/2118427?seq=1#page_scan_tab_con...).

At least when corporations search for a health plan, they are intensely competitive in finding the best plan for the price. Every year when their policies renew is another round of searching, comparing, and analyzing the various options in their local market. Health insurance has got to be the most expensive benefit a company offers by far, and I know even at a small startup we spend a lot of time finding the best plan for the money for our group.

Compare that to the US government, which isn't even legally allowed to negotiate on drug costs, and look where that has brought us [1,2]. So you could argue companies "waste" an enormous amount of resources having to procure health insurance for their employees year after year, but it also at least helps establish at least some competition in the market, which puts at least some pressure on prices. Companies health insurance budgets are not unlimited (unlike the Fed's) so we don't see quite the same run-away pricing as you do when the purchaser is literally printing the money to pay for it.

Obama's famous "you can keep your Doctor" lie is very telling. Different companies will elect for very different levels of coverage. The law requires that whatever level of coverage you chose to offer your employees is offered consistently from management down to your cheapest full-time employee, which is a really smart policy. Large corporations have better negotiating power in almost all respects of their operations, supply chain, and yes, employee benefits. We wouldn't imagine trying to 'level the playing field' in any other aspect of the operation of a company, so I don't think that's a compelling argument for single-payer health insurance?

When small businesses chose to forgo even offering health insurance (which is that even legal now?) that is actually a competitive advantage for them; they avoid a huge operating cost, and implicitly are selecting for the type of worker they are looking for -- single, young, and healthy.

[1] - https://www.cms.gov/Research-Statistics-Data-and-Systems/Sta...

[2] - http://www.nola.com/politics/index.ssf/2016/07/medicare_pric...

The advantage of a "single payer" system would be to bring the benefits of large corporation negotiating power down to everyone.

If there was no competition at all, I'm sure that there is some potential for rising costs. But a lot of "single payer" systems actually do offer a fair bit of wiggle room for private market competition. The mess that is the state of the United States government health care really isn't a compelling argument here against single payer (the statistics for most of the rest of the world's health care systems, which are more integrated, kind of show this). I would expect that any "Medicaid / Medicare for all" system emerge in the United States would be two-tiered, like is the case in several other countries.

To be honest, I would almost describe the situation in America as oligopoly-like in many cases (in insurance and hospital networks in particular) depending on where you are, and that would mute the effect of any corporate competition.

You've made a false assumption that "intense competition" (italicised for emphasis!) always makes things cheaper. It doesn't apply with health insurance, which is why health costs are so much higher in the U.S than anywhere else. [1]

Fact: the system of private health insurance in the U.S makes it more expensive for everyone. Source: every other western country paying far less. It is possible for the free market to fail when the thing people are buying is something they would pay any amount of money for.

[1]http://gamapserver.who.int/gho/interactive_charts/health_fin...

Obviously I am talking about free like "education", not free as in "no human input" It's a bit "dishonest" to take ridiculous literal meaning of the word to misrepresent what's clearly my point.

To explain fully, I am advocating the system where a person who earns $0 per day can enter and leave a hospital treated for free. They don't work, don't contribute to society, but as a unit everyone just agrees to look after their basic health as a minimum. As well people with money can do the same without even a thought about what their health insurance does / doesn't cover or when it kicks in, they just pitch up to the hospital.

That is of course implicit. No wages, no costs.

The funding for health care still needs to come from somewhere, this optimally being a tax on income.

Yeah I got straw-manned pretty hard (and took the bait), like I was advocating a fully volunteer health network or money on trees situation...

Why would that be a sane system? IMO a sane system is one where the paid cost scales with the real costs of the health care, no?

Ones health care costs arent going to be cut in half if hours are cut in half. Still need just as many annual checkups, may still have the same diabetes etc.

It is a sane system because everyone is paying into it, and you can do things on a larger scale to help more people. With health care being disconnected from the job, it doesn't tie people to an employer they hate and changing jobs is less of a risk. There are pluses and minuses, of course.

They still should have checkups, but not everyone needs them annually. Still might have diabetes, but with less stress and actually having time to cook proper meals, the diabetes might be better controlled and have cost savings in the long term (fewer complications) - and possibly short term if they have type 2 and go from insulin to pills. Sweden has been testing out 6 hour days - with nurses, they find overall absenteeism has dropped and folks are happier. Large scale, this would probably mean that folks are sick less often. Might not be cut by 25%, but improvement is still improvement.

No, health care is implicitly a system of shared costs to benefit all of society by limiting the amount of ill people present as much as possible, thus increasing the health of everyone else by reducing contacts with ill people. In such a system, costs are of course taken on by every single participant according to their means.

Read up on german health insurance for example.

I agree that that is a sane system, but it's not correct to call the payment an "insurance cost" if it is calculated according to means, not according to expected future treatment costs.

That's what was causing the confusion and dissent.

(Also … don't ask what US health insurance costs are based on. It's too horrible to contemplate. They're based on, among other things, your employer's negotiating power vis-à-vis the health insurance industry.)

Fair enough. I spoke a little simply.

Forgive my sarcasm:

> Read up on german health insurance for example.

Which one, the one where middle income employees pay healthcare for all the poor and incapable, or the one where the wealthy and some happy civil servants don't?

The American system is terrible, but I really don't think that we are qualified to point fingers.

>the one where middle income employees pay healthcare for all the poor and incapable

That about sums up the US system... I don't particularly like the idea of the federal government getting their grubby fingers into more than they are constitutionally mandated to, but a single-payer system could cut out the byzantine insurance coding and billing bureaucracy that causes medical costs to be completely arbitrary and opaque.

You failed to formulate a coherent disagreement. Please address the actual points of my post and speak clearly.

> In a sane system ... US

No. Almost nothing about the US healthcare system is sane, by any interpretation of the word.

In a sane system the health insurance pays for only catastrophic scenarios and has nothign to do with employment.

Providers post prices publicly and compete on said prices while maintaining customer satisfaction.

The US does not do that.

We have 1000s of reviews for restaurants and how the server behaved but no site where you can type a zip code and a procedure and get a list of providers and their prices and reviews.

> > They're not saving 25% on payroll taxes, benefits, workers comp, PTO, training time and management overhead. In fact, more people working fewer hours increases most of these costs."

> Payroll taxes: OF COURSE they're saving the same amount on taxes!

No, they aren't, in the US.

> It's a % of what they pay you.

Not a flat percentage; the social security portion of payroll tax has an income cap (the smaller Medicare portion does not), which is less than what most programmers make, so payroll taxes do not go down proportional to income for workers who are above the cap to start with.

Are you being serious? The cap is $118,500, you think most programmers make more than $118,500 per year?

A lot more than you'd think, after a few years of experience. 130k with benefits is par for the course in St.Louis for a full benefits senior programmer. Contracting, you can get way more: I reached the cap in August last year.

In the Bay Area, if you don't make that kind of money, you better be living in company housing, or you will have trouble renting a closet by yourself.

So yes, enough programmers make more than 120k for the payroll tax to be the same regardless.

In the bay area one can easily live on $100k a year. So long as they're willing to have a housemate (share a 2 bd room with someone else). Clearly not possible on a single income family, but either 1) Single person sharing a 2bd room place with someone els or 2) a dual income home renting a 2bd room place for their approximate 1 child.

I see too many bay area people thinking that ubers and expensive meals out are the "bare minimum".

I don't see how someone can rationalize that someone making $100k should have to have roommates.

I am not saying they need more money, but I don't understand how we have gotten to the point of chiding people making six-figures like they work at McDonalds and want a BMW.

Its simple. Prices are insane. So we expect people to do sane things, like live with other people.

Much of the rest of the world does it, no reason North Americans cant.

In the bay area, I'd expect median to be somewhat higher than that. Which is obviously not the entire world or country, but is where a lot of the focus of this forum is.

Let me Google that for you. In the Bay Area, the average salary for a software engineer is $103K [1] - $110K [2], so below the cap.

1: http://www.payscale.com/research/US/Job=Software_Engineer/Sa...

2: https://www.glassdoor.com/Salaries/san-francisco-software-en...

The median salary for all "Computer and Mathematical Occupations" for San Jose-Sunnyvale-Santa Clara for 2015 was $128,850, for Software Developers the medians were $147,220 (Applications -- there were 42,650 of these) and $142,950 (Systems Software -- there were 27,260). Of the programming-related occupations, Computer Programmers and Web Developers were lower than the cap, but very small numbers of people (6,510 @ $93,940 and 2,930 @ $107,500, respectively.) From 2015 BLS data, which is more comprehensive and representative than whatever payscale and glassdoor are using. [0]

San Francisco-Oakland-Hayward is a little lower, but both kinds of Software Developers still average over $120K. [1]

[0] http://www.bls.gov/oes/current/oes_41940.htm#15-0000

[1] http://www.bls.gov/oes/current/oes_41860.htm#15-0000

Those use self-reported data which is unreliable and only San Francisco, which is only a small portion of the Bay Area.

Using BLS data, which should be more reliable, for the San Francisco[1] and San Jose[2] metro areas, the average weighted by number of people in the job of annual mean wages for the job categories of "Computer Programmer", "Software Developer, Applications", "Software Developer, Systems" and "Web Developer" is $129,730.54.

[1] http://www.bls.gov/oes/current/oes_41860.htm#15-0000 [2] http://www.bls.gov/oes/current/oes_41940.htm#15-0000

Thanks to you and dragonwriter for the links.. informative. So let's compromise on "It's right around the cap" :) Interesting that self-reported data is actually lower than the BLS figures--I'd have guessed it would be the opposite. A lot of people here like to humblebrag about how they "only" make $150K and how their stock options make their taxes so painful.

> A lot of people here like to humblebrag about how they "only" make $150K and how their stock options make their taxes so painful.

To be fair, as well as regional there is also industry variation, and a lot of people here work in the "Other Information Services" sector -- most online services would seem to be in that category -- which is (at least nationally) significantly above average pay for programming occupations. If that industry-based trend is also true for the region, then $150K for a developer could well be a below-median salary for region/occupation/industry combination.

I looked at the Glassdoor data as well. Remember that they're looking narrowly at job titles. If you add "senior software engineers," their average is around $118k. If you add "software architects," their average is around $140k. And so forth.

So if we're not talking about people with the job title "software engineer," but instead talking about people who are software engineers, including people who have a more advanced title, the average salary moves up.

> The cap is $118,500, you think most programmers make more than $118,500 per year?

On review of the data, no; I was actually thinking more narrowly of software developers rather than broadly to all programmers, and even then its a little high (though the median salary for application developers (Software Developers, Applications) in the Information sector is close to the cap. [0]

Still, a substantial minority of programmers (broadly speaking) will be making above the cap, so reducing programmer salary in exchange for reduced hours will reduce payroll taxes by a substantially lower percentage than the percentage reduction in salary.

I would hope that they do, if they have any experience and are actually good. I don't have that many years of experience, and am working for a rinky-dink small ISV well outside any kind of tech hub, and I'm not far off from that.

In California? I'd hope that a typical developer makes around that much.

If they are any good at all, yes.

That's not even close to true. The west coast is not the entire industry, no matter how much it likes to think it is.

It always makes me sad to see this same argument happen in every thread mentioning salary. Nobody ever wants to believe that their profession actually pays as much as it does.

Yes, you can certainly find a company to pay you less than $100,000 to program computers for a living. That's not in dispute. But know that you (meaning you as well as anybody else anywhere in the US or the English speaking world) can also find a remote gig paying more than that.

Good developers are very valuable. Even in the sticks. Please don't sell yourself short.

It always makes me sad to see this same argument happen in every thread mentioning remote work.

Exactly HOW does one get $100,000 working remotely? When no-one's ever heard of you?

People should add a footnote when saying things like this.

"Yeah just get a six figures remote job......... if you have tons of experience/large network/expert on a niche/top open source projects".

While I usually appreciate this kind of talk, it's irrelevant here. How much a theoretical developer could make has no bearing on the median developer salary right now, which is solidly below 118k.

Ha. That's a good one.

Employers appear to want you to be in at least a somewhat similar time zone as their core team and have some prior experience working remotely.

Take this hypothetical person living in the sticks. 3.5 years of experience doing local development. No prior remote experience -> not given the time of day by remote shops -> can't get remote experience.

As I said, it makes me sad. Because you're wrong. You've internalized this as though it were a fact, so you don't even try. And the only one it hurts is you.

You're assuming every developer is a "good" developer. The top 10% could probably find remote work, but the rest of us are stuck with what we can get. I've been trying to go that route for 3 years now and I'm at the point where I have to get a 'real job' to make ends meet.

Nowhere did I say I don't try. I do try. And in the rare instance that I receive a response, what does it say? Exactly what I said in my post.

> The west coast is not the entire industry, no matter how much it likes to think it is.

True, though many people live on the coast specifically because of its tech industry. Sweeping that away is no better than pretending that it's the only game in town.

Another facet of this is that with more people comes more communication needs. So either more management or things get dropped.

So while it seems like a 25% drop in hours would only mean a 25% increase in number of employees that later number will go up much more just to handle the increase in communication.

Depending on the state, payroll taxes, workers comp, pto etc may or may not apply, or may be at a cap. If you're working 3 days a week, and that still meets the cap on worker's comp/unemployment, etc, then they're still paying the same amount. Many places will hit the max on a lot of employer-side taxes/benefits when you are working full time.

If this was the main reason, then surely it would only be a matter of negotiation on salary? Out of experience I can tell you that this is not the case, most companies won't even discuss it. I have asked for half time at a half dozen places, and actually got it at two (those that accepted were not pleased but they really had no choice as people with my skill set are hard to find).

In my experience, the real reasons are (in order of importance): 1. It would hurt morale (or so they fear) 2. It complicates booking meetings and such 3. They suspect that you're doing something creative on your "other time" and thus they don't have your "full attention"

They're not losing 25% productivity either unless you're incorrectly assuming output is linear to butt-hours.

It really depends, but I could tell a story that is pretty convincing that says they will lose more than 25%.

Lets say you get to work, sit down, and you veg out for 30 minutes to kindof ease into the zone. Then you get going on your project, and it takes another hour or so to get fully up to speed, track down a failing test that someone committed, whatever. Then in the afternoon, you chat with a co-worker for half an hour after lunch.

Now you have 6 hours of productivity in an 8 hour day, but 4 hours in a 6 hour day. The main point being that there may be some 'fixed cost' things that don't scale up or down so much.

Throw a sprinkling of strategically placed meetings, an "Agile" standup, and a smattering of impromptu "hallway chats" into either the 6 or 8 hour day, and you have 0 hours of production either way...

We got rid of most of that but then we went ahead and moved to a new office building where we're the first tenant.

Every day is just the constant sound of construction and I'm finding it more and more necessary to work from home and maybe find a new job entirely.

I have fantastic noise-cancelling headphones and they don't help a damn bit.

This++ ... I know it's hard, but would love for anything beyond a 15-minute stand up be limited to one day a week for developers.

This is why we do 12-hour shifts at my workplace. It takes about two hours to get into the groove, and the other 8-9 hours of work are productive.

Doing an 8-hour day means that you get 5 hours of decent work, which is not viable for the output that we need.

With 12-hour shifts, we work 3-4 days a week and get more done than people who work 8 hours a day, 5 days a week. And we get overtime!

This is an argument for moving to a 4x 10-hour work-week. From there, you could work backwards using the same arguments as above.

4x10 is probably the optimal 40 hour work week - particularly if you can set it up so that you have alternating Mondays and Fridays off, such that you can get a four-day weekend half the time.

Perhaps we should realize that different people work differently, yes?

I, for one, would quit my job if I had to work 10 hours every day. I would not be able to stand it. It isn't that I don't like what I do, but I like what I do outside of work to not want to be there all the time!

From personal experience, being at work five eights vs four tens has very little impact on time away from home, like maybe one hour per day or something like that. While the five eights are sitting in their car for an extra 30 minutes during each rush hour commute, I'm sitting at my desk working. I suppose your local traffic patterns may vary.

There are downsides. Less time commuting means less time listening to audiobooks and podcasts.

Like many people, once my brain is fried I'm simply done for the day, doesn't matter if that frying happened at 9am or 7pm. So statistically a three hour staff meeting causes more total lost productivity for a ten-er than an eight-er. Scheduling people make sure meetings only happen during common time (uh, thanks?)

When the weather is bad (blizzard or whatever) or go home sick a half day, obviously that's more expensive for a tener than an eighter. Of course that is balanced out, I'm more likely to have a sick day on my weekend than an eighter and if there's a blizzard on my weekend I obviously don't miss any work.

You should consider the opportunity to have an entire uninterrupted day to pursue your hobbies, whilst most other people are at work. I found myself more personally productive on that one free day than in an entire month of 5x8-delimited evenings.

If I'm not careful, I just end up playing video games. It's hard to be aware from 'the grind' long enough for me to be drawn back into my productive hobbies en force.

Lots of companies assume exactly this.

Yep. It's politics, too. I recently got asked to stay longer at my job - not to do more work or be more productive, but because the apparent flexibility with which I approached my schedule was causing consternation among some nearby department (who are tied to their desks 8.5 hours a day). Why that is considered my problem, I've yet to find out..

Not to mention, for most engineering jobs, the onboarding/training process is long and expensive. Generally I think an engineer has negative productivity within the first 3 months of employment. So if an employer is willing to put down so much effort upfront for you to work there, you better to willing to work 100%.

Negative productivity for 3 months seems like a very conservative estimation. Most places I know have people commit to the code base pretty early. Quite often the onboarding process already has them commit small stuff. You might say...well they are only doing small things like fixing minor bugs but that's a minor bug a more experienced developer doesn't have to fix.

If you also assume that people strengthen their own understanding of a topic if they teach it new engineers don't drain resources if they ask other developers questions. They might make your other workers more productive in the long run. At the very least I'd argue that the time other devs spend on onboarding isn't wasted 100%.

I suppose the dynamics change if you hire fairly bad people who make things worse with their early commits but that mostly means your hiring process (and most likely your code review or whatever measure you set up to prevent bad code) is broken.

> If you also assume that people strengthen their own understanding of a topic if they teach it new engineers don't drain resources

In practice I've found this assumption is only true if you have very small growth/turnover. I.e. If you hire a new engineer once every couple of years it's probably the case, but if you hire a new engineer every few months it isn't.

On average I'd say we have our senior engineers spend 40-50 hours total in the first month teaching/helping a new senior dev. Probably a similar number of hours in the second month, and then it drops to maybe 10 hours/month for the next year.

From what I have seen a new senior dev is around 10% of the productivity of a existing senior dev for the first month, 20% for the second, and rapidly reaching 80% by the end of a year.

So they are at 1 unit/hour of productivity for the first month and add 160 units of productivity for the month. However, senior devs, at a cost of 10 units/hr, have spent 40-50 hours helping them at a cost of 400-500 units of productivity.

Second month they add 320 units but cost another 400-500. By the third month they add maybe 450 units and only cost 100 units. And at this point they have managed to pretty much break even.

Of course if you assume training costs are not a real cost but rather beneficial for your existing senior devs then the new senior dev looks productive from the first month. But then you are really just talking past each other.

I'm guessing it depends on the company... at my last place (small startup so makes sense) I was expected to be productive the first week and actually got in trouble for looking at non-work stuff every now and then :p

Meanwhile some of my friends at large companies "train" for weeks. Pretty interesting difference.

You are forgetting the time other members of the team are spending explaining things.

I disagree with this so much. I'm not saying there isn't some onboarding cost, but with experienced engineers its a lot less than you think. At worst you should be "breaking even" with a Senior Engineer almost immediately. When I look back at what I've done for the company I just started with 7 months ago, I completed a highly valuable, and large project for them in the first 3 months. I could probably get the same project done a lot faster now than I did then, but that doesn't mean it wasn't worth it to the company.

This is a very valid point. But what stops both parties to agree on 40h weeks during onboarding phase and then shift to the reduced work time?

I hear this perspective but in my experience hiring people who've been pushing an open source project forward already, it can be more like unleashing a coiled spring. They'll bring code and question the culture in productive ways.

Not sure about engineering in general, but I find places that expect 3 months for a programmer to become productive are a huge red flag.

A programmer should be able to checkout, build, run in minutes and then to start fixing bugs on day 1.

Building, running, and nominally fixing bugs (are you tracking regressions well?) is not always the same as being productive. It's important to not treat the work as fungible units that go from developer to developer equally, without accounting for getting used to the code base, problem space, etc.

I wouldn't expect them to be as productive, or anywhere close to it. But IME a 3 month ramp up time is usually a sign of too much complexity for individuals to deal with. Usually from technical debt or too broad an area of responsibility.

> A programmer should be able to checkout, build, run in minutes and then to start fixing bugs on day 1.

I have never met a programmer who could do that. I'm sure some of them can, in specific domains. But I'd consider expecting that to be a huge red flag: I've worked at exactly one place that expected a day 1 hire to match their veteran coders, and I wouldn't work there again.

I'd note that this could be seen as much as a statement about the organisation one is moving into as to the skill of the programmer involved.

i.e. If it takes someone 3 months to be productive, there's probably something wrong with the build system/documentation, or code organisation/structure (+ comments, or lack of), lots of knowledge in people's heads etc.

To be clear, I wouldn't expect them to match the veterans, or even to fix anything, but they should be able to get started on a simple issue given decent reproduction steps.

My main objection was that there shouldn't be 3 months of negative or near zero productivity. Or there should at least be a good reason for it.

Whilst being helpful is one thing, if you can't afford to give people a proper amount of time to bed in (3 months doesn't seem unreasonable), then you might hurt your chances of retention going forwards as well - depending on the size of the org of course, but there's plenty of places where to really understand the business needs to make informed decisions, it takes a long time. If you fail that step, then staying for any reasonable amount of time becomes untenable.

Companies often feel that they are moving fast when they are setting up huge tech debt pits and building custom infra that will be hard to learn quickly. Then they wonder why they are not being successful with all the new hires, given how productive the old timers are.

Welcome to the midsized, pre IPO startup.

I'm 6 months into my current job and I'm still 60% useless to them. And a couple other people have already been moved out of this position because they couldn't hack it.

What is it making you/them 60% useless? Tech debt? Responsibility?

I would not ever permit a new programmer near production code on day 1, let alone fix a bug.

That ramp up period involves learning the subtleties of the business, inter-team dynamics and processes.

The first bug I ever fixed resulted in costs for the company. My mentor had left the company within a week of me starting and I waded into the code with good intentions, but put us out of compliance with regulations.

> I would not ever permit a new programmer near production code on day 1, let alone fix a bug.

You wouldn't let them check out and run the code? The business processes etc all have to be learned of course, but the code is where most of the time should be spent.

> The first bug I ever fixed resulted in costs for the company. My mentor had left the company within a week of me starting and I waded into the code with good intentions, but put us out of compliance with regulations.

I would consider that a failure of the company, too many responsibilities are pushed down to the developer. If there are strict compliance regulations then there should have been some sort of QA process and/or a domain expert validating the results.

>I would consider that a failure of the company, too many responsibilities are pushed down to the developer. If there are strict compliance regulations then there should have been some sort of QA process and/or a domain expert validating the results.

This is detached room reality. There arent many jobs (other than junior level programmer) where you just churn out code without actually having to think about the requirements, use cases, security, etc. Having responsibilities is a very common thing as a software engineer.

Yes there are a lot of things you have to think about, as well as a lot of domain knowledge to pick up.

But expecting the developers to act as the domain experts is also detached from reality. I've never worked with anyone who I would consider a domain expert that also keeps up to date on a technical level.

This is why there needs to be less taxes and mandatory benefits. Counter-intuitively, these things work together to reduce the number of jobs and reduce worker flexibility and happiness.

I think the money just needs to be spent better.

In Australia "taxes and mandatory benefits" on a $100k USD salary cost the employee ~30% in taxes and medicare levy and the employer ~5% payroll tax + ~10% superannuation (401k). In total, 1.15x the salary is being spent and of that, 0.69x goes to the employee.

If the employer pays an extra 50% salary in the US, then 1.5x the salary is being spent but the employee only gets salary after tax, which (based on my payslip) is only ~0.65x salary. So the employee only gets 0.43x the total amount being spent. If the employer has a fairly generous 401k match that results in an extra ~10% going to the employee from that extra 50%, that's still only 0.50x the expense going to the employee.

As someone who's lived in both countries, I don't really get anything extra in the US thanks to that cut. The health insurance seems to be the main thing people care about but I found healthcare in Australia to be cheaper and superior to the care I've had in the US (on PPO).

I think the US needs to adopt single payer healthcare like the civilised world and work out its government spending and taxes a little better.

Your math(s) is hard to follow. Could you just put all the numbers in USD instead of "x salary" (for two different salaries) and "x expenditure"?

Or completely the reverse - all mandatory benefits as a percentage of wages. We kind of, sort of do that in Germany (up to about 50k for health insurance, 90k for retirement, I think)

How would increased taxes and mandatory benefits reduce the cost of employees?

Increased employee costs make an employer less likely to take risks and produce pressure to hire less workers. Then a few workers gain at the expense of others not having a job at all. Why do you hate workers?

It would make benefits a more constant cost per 1k paid to employee, making the cost per hour of a 30 Hr/wk employee closer to that of a 40 Hr/wk employee.

Come to think of it, that's probably why I have so many colleagues on 20-32 Hr/wk contracts... Mostly, mothers of young children. But they're doing the same sort of technical work others on full time contracts are.

Yay, Germany!

Disagree. Payroll taxes are a percentage so they would see a reduction. The employer would obviously offer less pto if you're not full time. And they'd offer less benefits.

In the US, they are saving 25% on payroll taxes. With paid time off, if they give you 15 days off of 6 hours a day vs 15 days off of 8 hours a day, it's 25% less paid time off (even though it's the same number of days).

Depending on the state, a lot of employer-side expenses are capped above a certain salary, most developers are well above that cap... so 25% less for you, doesn't mean 25% less for the employer.

I guess that's why contracting is a win-win situation since contractors have to take care of their own taxes and they typically get paid double or more (which usually more than offsets the taxes for the contractor).

Contracting feels like you're only selling your time. With full-time work, you're also selling a big chunk of your freedom (which you don't get paid for unless you get % equity in the company).

Contractors don't get holiday or sick leave though.

Meh, that's peanuts. You could take 5 months of holidays each year as a contractor and still earn more at the end of the year. Especially in places like London (UK) or Sydney (Australia). Senior software dev contractors in London can easily earn USD $800 per day.

Also, when working full time, if you take a sick day, your boss might look down on you and ask probing questions like "Are you feeling better?" to try to check that you were really sick (and to discourage you from taking more sick leave in the future).

If you're a contractor and you take a day off (for whatever reason), nobody will say anything - It's your business - You didn't get paid.

It feels a lot more natural and it eases a lot of tensions in the workplace.

It still sounds like its an interesting thing to consider though. It sounds like what you're saying is that for it to be equitable for companies, it might have to be a 25% hour reduction for a 35-40% pay cut. But that is probably a lot less appealing to most programmers

Indeed. This is another of the myriad reasons why developers should always negotiate employment as a 1099 contract. It takes this rationalization off the table.

If they're paying for the hours you work and nothing else, it makes it a lot easier to quantify the value of "4 days of you" vs. "5 days of you each week".

And of course, the laws that caused all that trouble for Microsoft in the 90s around the distinction between contractor and employee help a bit, since it now needs to be the contractor rather than the employee who decides when and how the actual work takes place.

Unless the work product is directly related to the number of hours put in (say cutting trees), the concept of fairness is a bit skewed.

I wrote a very long comment expanding on this : https://news.ycombinator.com/item?id=12168363

So why don't they hire fewer people for more hours (at higher pay)?

They do. Minus the pay. It's called downsizing.

The current trend is to have a strategy/build/run model. The "run" people keep the lights on and run as lean as possible. Builders build stuff -- code and infrastructure. Code is high value, off the shelf stuff is going cloud. Strategy is architecture and mapping back to business needs and dollars.

You pay as little as possible to run. You pay whatever it takes to build. As cloud tools mature and standardize, costs will drop here. Strategy is the governance process -- light in a startup, heavy in a bank.

>You pay as little as possible to run

If that were the case people wouldn't be using 'the cloud'. For any non trivial size of compute load that isn't on demand, paying aws or gce is flushing money down the toilet.

Depends on lots of stuff.

Companies think short term, and will perceive savings if they can avoid making capital investments in datacenters or long term leases.

it shouldn't be about the hours you put in, it should be the product you produce

Reply on news.ycombinator.com