I use a MacBook and a Mac mini personally, and I do not generally maximize any application that isn't implicitly a full-screen experience (e.g. a video player or a computer game).
I was charged with felony unauthorized access of a government computer years ago for an even stupider reason. Nobody should underestimate the state's willingness to prosecute over anything.
I'm a technical lead, and I often tell my teammates exactly how I want them to implement something. I am not looking over their shoulders at every line of code, but I will tell them plainly that I want an interface, a concrete implementation of the interface that is up to them, and a configuration option for substituting a different concrete type.
I don't do this because I don't trust them but because I have different requirements. What matters most to them is completing their work items according to specifications. What matters more to me is long-term maintainability of our projects for the rest of the team.
Some of them have the long-term needs in mind. Some of them just don't think that way. I try not to make them feel like their work can't be trusted or like my demands are arbitrary. I think they are more receptive to my demands when I can at least provide context for them. That seems absolutely necessary to me.
I ask myself all the time whether I'm insisting on too much control. I appreciate you asking of yourself, "Is this my ego?" It can definitely go both ways.
DBAs don't necessarily need telemetry in an app to diagnose an issue with the app's behavior. They can run a trace and see some SELECT is running a thousand times a second and deduce that it's being called in a loop over the result set of an earlier query. And they'd be right to say hey, this is an app issue, open a ticket with the developer.
If you put that responsibility on the developer--meaning you expect the dev to diagnose an issue that they introduced in the first place--what kind of result do you think you're going to get?
Layering these demands takes away from the overall quality of the application in my experience. You want an app developer to learn all about Prometheus so the app can have an endpoint with all these custom metrics, okay, and you want structured logging and expect the dev to learn how to use Kibana effectively? All that's a huge cognitive burden that eats a slice of the same pie (their brains) as domain knowledge, language & runtime knowledge, etc.
Get maybe one app developer to specialize, get maybe one app developer to cross-train with ops or monitoring even. But leave most of us out of it.
When you flip that expectation of developer involvement in operations, it exposes how unreasonable that arrangement is. Hey, DBA, the app is sucking up resources. Why don't you crack open an IDE and write a patch for it? What do you mean you don't know Go, what do you mean you don't use Git? Every DBA should know how to attach a debugger to a remote process, shouldn't they?
It's just exploitative. Or at least that's been my experience, so there's my bias.
Here's the extent of my interest: I take my understanding of your use case and specifications, then I write source code that tries to generate as few instructions to suit your needs as possible while still being comprehensible to the next maintainer.
The app should write records to a database? Fine. Here's where you configure the connection. The app in production is slow because the database server is weak? Not my problem, talk to your DBA.
The app should expose an HTTP endpoint for liveness probes? Fine. It's served from the path you specified. Your reused it for an external outage check, and that's reporting the service is down because the route timed out due to your ops team screwing up the reverse proxy? Literally not my problem, I could not care less.
The first time my director asked me if I'd ever heard of DevOps, I said, "Sure, doing two jobs for one paycheck." I'm a software developer, buddy. I write the programs. Leave me out of running them.
A non-mocking use of mine: I have a factory with a method that returns instances of a particular interface for publishing typed events to a pub/sub service. The caller of the factory doesn't have to be updated with new concrete types as new events are added, because it's the factory's responsibility to create the events. The event types themselves just implement the interface that's required to serialize them for the pub/sub service.
I frequently place emoji in code files and database scripts to ensure other people aren't using the wrong encoding in their editors when working on our projects.