As a SW developer you provide two benefits to the company:

- the build phase: develop spaghetti code

- the maintain/insurance phase: maintain the spaghetti code and keep it up to date with the software package dependencies required by the spaghetti code

In the long term its easier/cheaper to have the person who originally wrote the spaghetti code be around to maintain and add one off small feature improvements to it (i.e. ensure log4j patches are handled properly) than to find/hire/train a new developer every time a 0day patch needs to be applied.

There's one more reason - the one I use to rationalize my idleness to myself: in addition to our work output, the corporations are also paying us to be a part of their "reserve army". We might work 3-4 hours a day, but when things escalate, the company taps into its reserves to get stuff done. Having doldrums about that is like soldiers worrying they only spend 3 hours a day in combat

That reminds me of this article for some reason :)

"Google has a secret ‘bench’ program that keeps execs at the company even when they’re not leading anything"

https://venturebeat.com/2015/05/09/google-has-a-secret-bench...

I used to work in Operations...there were 2 of us on shift for a 1 man job.. The extra was 'insurance' :-)

In my experience if the system is important enough, once you ship a couple of features to production you can coast there until the system is replaced. If the features were core the better.

I don´t like it but after 2 decades of coding I have come to accept it as it is.

I think a good way to frame the role of a SW developer is you are in a sense a manager of a new "team".

But instead of developing new hire training material and recruiting/managing people to do the new task, you're developing/training/creating/deploying software programs/scripts/bots to do what needs to get done for the organization.

While infinitely easier than dealing with HR problems that humans bring along, your team of programs/bots still needs some manager.

And just like a traditional manager, if you set up your "team of bots" just right and handle all the corner cases in the training manuals, a good managers job will actually ideally not be that hard day to day - particularly since the meatspace problems have been abstracted away.

> I can't imagine ever returning to an office in which there is more pressure to spend 8 hours a day sitting in front of my computer.

But this is what you are paid for. Do you not feel that this is what you should be doing in the time you are contracted to work?

In the US, very few full time professionals work under contract. In fact, companies go out of their way to assert that there is no contractual relationship (the "employment at will" principle). They do not count their hours, and are in fact not allowed to do so.

With that said, I'd find it hard to work such a short week. The time I spend that's unaccounted for, I tend to spend helping other people at my workplace, learning new stuff, etc. I enjoy the work. Granted, I don't work as a programmer.

> In the US, very few full time professionals work under contract. In fact, companies go out of their way to assert that there is no contractual relationship (the "employment at will" principle).

Americans keep saying this means "no contract", but I don't get it. You probably have some weird American-only meaning attached to the word "contract" that doesn't apply to the rest of the world, in English as well as other languages. To the rest of us, "a contract" means a formal (usually written) agreement to exchange goods or services for payment. I find it utterly hard to believe that any full-time professional, even in America, is employed without having any piece of paper signed by their employer -- and they a copy signed by him -- that states basically "John Doe and Corporation X agree that John shall work full-time for X, and receive a salary of $Y per month".

If you do, that's a contract. If you don't, how do you know how much of a salary you're going to get at the end of the month? How does HR / Accounts know how much to pay you?

Of fucking course you have a contract. It's just that the terms for termination of that contract, whether specified within it or implicit because of "at will" legislation, are much more abrupt than most everywhere else. That doesn't make it not a contract.

> They do not count their hours, and are in fact not allowed to do so.

Like, if the company wants you to work 272 hours per week (hint: 24 × 7 = 168), you can't say you won't? Or is it the company that can't say anything if you show up three hours a month? Of course they count their hours, at least roughly. Everyone does.

Not that this has anything to do with whether something is a contract or not.

>>>> I find it utterly hard to believe that any full-time professional, even in America, is employed without having any piece of paper signed by their employer -- and they a copy signed by him -- that states basically "John Doe and Corporation X agree that John shall work full-time for X, and receive a salary of $Y per month".

I never signed such a thing. Roughly a quarter century ago, I received a job offer letter with a salary level. I verbally accepted the offer. But my salary is much different today, and there's nothing with my signature on it to that effect. It's very loose and informal. The payroll software knows. This is at a huge and well managed company.

I have no doubt that the company's ability to cut my pay is constrained by regulations, like they probably have to inform me in advance. One of my employers once announced a furlough and temporary pay cut when there was a financial disaster. Nothing was signed.

About counting hours, this is a US thing. We have two classes of employees, depending on whether they are entitled to overtime pay or not. Most professionals are not. There are criteria for classifying employees, and one of them is whether they are required to work a specific number of hours.

Sure a company can say something if I show up 3 hours a month: "You're fired." Or they can cite a specific shortcoming in my performance. What I think is a sub-plot of this thread is that measuring this performance and tying it to a relative workload is not always straightforward.

Note that I'm not a lawyer, this is not legal advice. A lot of it sounds strange because it is strange.

> I never signed such a thing. [...] much different today, and there's nothing with my signature on it

I'm forming a hypothesis -- i.e, vaguely guessing -- that this is American culture because employers have pushed it in this direction, because an absence of any paperwork for employees to point to in case of conflict benefits the employer.

> A lot of it sounds strange because it is strange.

America sure is. :-)

A verbal contract is still a contract, including amendments to it. Being on salary vs paid hourly also doesn't mean anything about whether there is a contract.

Personally most of job happens in my head, which half the time is not at work. I should probably get paid for ~15 hours a day instead of ~8. I cant tell you how many times I had a eureka moment about a work problem on a Sunday afternoon idling away at a hobby.

Actually, no, they can't pay you based on how much time you spend on a task unless you are being paid hourly (and therefore are paid overtime if required to work more than 40 hours per week).

They can ask you to be at work at a certain time, or to do some task a certain number of hours a day, but they CANNOT pay you based on how many hours you spend doing it or they are in violation of labor laws (in the US anyway).

A software engineer is not paid to sit in front of a computer and that's only a small slice of the work.