A boss' job is not to babysit. Keep the higher ups off the team's backs, run the management infrastructure needed for stuff like project planning, stuff like that. I am not at my desk for my whole work day. However not once has anyone been less than very pleased with my output. More time at my desk would not mean more work - it would mean less. The recharge time I take means that I almost universally have a good attitude at work and I'm good at untangling problems that others either can't deal with or are avoiding dealing with.
Forcing presenteeism rather than a results-based approach is utterly idiotic.
I'm pushing 40 and I've never owned my own VCR. When I was at university a landline was thrown in with our internet connection but we didn't have a use for it. Landlines have been irrelevant my entire adult life.
You're getting ragged on but I would very much prefer an approach with these things that used some sort of modular system.
I'm imagining the service would have the option for "address for communication bridge" and it'd pass messages to it using JSON or something. The communication bridge would then decide which medium that would go through (email, SMS, smoke signals, whatever the owner configures).
As far as the service is concerned messages come and go (or just go) and how that side of things works isn't its problem. It'd also mean that one could configure fallback messaging mediums and use dummy ones for if one doesn't want anything like that (much like the "emails print to the console" debug tool Django has).
I don't think that'd be much good when the way the specs are written are not based purely on technical merits. We also aren't paid to test hardware - we have hardware because we develop software to test hardware on. Knowing how to navigate those waters is the key skill. Once I've got a solution that'll work getting it implemented is relatively trivial as our approach is extremely atomic.
In general what you describe sounds like a tremendous amount more overhead than we currently have for little to no gain. What I could do with is a few more engineers that I could train up to have sufficient contextual knowledge, not another junior to babysit. I trained one up and he's tremendously useful - apart from when he leans too heavily on LLMs. That cost a side project two months of unnecessary faff and sapped team morale massively in the process. I ended up dragging the damn thing over the finish line after he refactored it into something that was exhausting to work with.
Unless it's the most rudimentary logic I tend to have to hold the LLM's hand through the entire design. Sometimes that involves breaking the damn thing's fingers.
I mostly use them to write stuff that I can do but hate because the syntax is a faff (argparsers, docstrings, shite like that). There's just too much contextual knowledge needed for them to be much use with the codebase I work with, much of which is not in the codebase so much as in the metatextual knowledge needed. I write a lot of software for testing hardware and there's a needle that has to be threaded - the specifications are not bulletproof, the hardware being tested failing may be the desired outcome (so code that passes on it is inherently wrong), and there are various limitations and priorities that inform test approach.
The actual code I write is fairly minimal but the knowledge needed to write it is extensive.
Occasionally I'll take on side projects at work to get my hands dirty on something more involved but simpler.
"to make sure they're working"
A boss' job is not to babysit. Keep the higher ups off the team's backs, run the management infrastructure needed for stuff like project planning, stuff like that. I am not at my desk for my whole work day. However not once has anyone been less than very pleased with my output. More time at my desk would not mean more work - it would mean less. The recharge time I take means that I almost universally have a good attitude at work and I'm good at untangling problems that others either can't deal with or are avoiding dealing with.
Forcing presenteeism rather than a results-based approach is utterly idiotic.