Never been in the military I’m guessing…

Plenty of times there were jobs to be done that had nothing at all to do with the work but with the people doing the work. Almost always, unless the higher leadership got involved, this was the punishment for whatever stupid thing someone got caught doing. Technically not extra duty (which was a formal punishment) but just some random shit job like polishing a trash can to a sparkly sheen.

The NCOs took great pride in their creativity in coming up with these non-punishments.

>Never been in the military I’m guessing… No, I haven't but a lot of my family and friends have. I do understand though, my great uncle Don used to make my dad and uncle move a cord of wood to one side of the fence one day, and then the next day he'd say "what'dya do that for? Move it back!" then wink at his wife. As a Norwegian Lutheran immigrant, the prevailing attitude was "We can't let those boys have idle hands", and they all went along with it. Don came over and landed in Idaho where he found work as a lumberjack. He got paid based on his output and took it upon himself to chop down a whole forest by hand, as legend goes. Anyway, the dude went hard, made a ton of money, and was able to use that to own a bunch of successful businesses and stuff. He wasn't going to let those kids miss out.

All that said, and while I see its importance, I was saying 'important' work to refer to things that wouldn't be if the person didn't do it themselves. Like if I'm being trained to write, it wouldn't have much value at all unless I was the one doing the writing. At the end of the day, it never mattered where the logs were.

I'm coming from a place where it really doesn't matter to me or my team as to what tools, techniques, or languages are used, so long as it solves we're all okay with owning the results of that approach. It is absolutely unimportant to bash your head against the wall to solve some concurrency lock issue, not when you haven't shipped, not when your infra is already built for parallelism. But let's say that you need a lock for business logic to work, synchronous transactions aren't viable. When something (such as concurrency) does matter, the business still doesn't care how its implemented. It is important that it implements the business logic correctly, consistently, and can evolve with the business' priorities in a way that future engineers are able to implement them safely, even promptly. Assuming all stands of Quality are met or exceeded, it is irrational for me and unfair for the business to reject it. IDGAFF if it came from a CoPilot/ChatGPT response, offshore salary triage, or some other 'crime against society' that I haven't heard of. If an engineer isn't handing in quality work, then we need to dig into why that's happening. Its usually not because of a tool.

Where the work is 90% of the time possible to do remotely and thus is AI-able, but the employer has the reasonable expectation that if they ask you can actually show up on site somewhere and have full context in verbal conversations as to the work you were "doing".