[somethoughts]

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.

[thow-58d4e8b]

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

[somethoughts]

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

[mech422]

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

[condorito]

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.

[somethoughts]

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.