/* and 1500 Hours: On the Engineer Who Stopped Caring, and Why That’s on You

"It's not that I'm lazy," he says. "It's that I just don't care."

The Bobs, to their credit, recognize this as a management problem. Peter is not a bad engineer. He is a completely rational engineer who has done the math on effort versus outcome and landed somewhere bleak but logical. Nothing he does matters. The reward for doing good work is more work. The reward for doing bad work is the same outcome. So why do anything but the minimum required to stay employed?

I have been a software and infrastructure engineer for over twenty years. I have worked in security, in DevSecOps, in environments where what you build has real consequences for real people. I understand why Peter got there. I understand it better now than I ever have.

The Merge Request

Here is what happened.

My team manages HashiCorp Vault with Ansible. The process for updating token policies and metadata permissions is straightforward: update the group_vars, open a merge request, get it reviewed.

I opened an MR this week. Nothing dramatic. A credential scoped to a single cloud provider, named clearly to reflect exactly that. The paths in the policy were limited to what the pipelines actually need to operate. The token lifetime was set to eight hours.

That last decision was deliberate. Our pipeline timeout is four hours. A job, by definition, cannot run longer than that. Eight hours gives the token room to breathe through the full execution window with margin to spare, and then it expires. No lingering sessions. No forgotten credentials sitting valid for days. The token lives as long as the work it exists to do, and then it is gone.

This is not novel thinking. Least privilege and short-lived credentials are not experimental practices. They are foundational. They show up in every security framework worth referencing. They are the difference between a credential that, if compromised, opens a narrow window, and one that, if compromised, opens the whole house.

The lead came back wanting to change the path to /* and set the token lifetime to 1500 hours.

Sixty-two and a half days.

What That Number Means

I want to be precise here, because precision matters.

1500 hours is not a generous buffer. It is not cautious engineering. It is a credential that, if stolen, exfiltrated, accidentally committed, or simply forgotten in a running container, remains valid for two months. That is two months for an attacker to move laterally. Two months for a misconfigured service to quietly do things it was never meant to do. Two months of exposure window on a credential attached to a wildcard path that grants access to everything in that namespace.

Combining /* with a 1500-hour token is not a configuration. It is a posture. It says: we are not worried about this. It says: the inconvenience of scoping correctly is not worth the security benefit. It says, with a kind of institutional confidence that should be alarming: nothing bad will happen here.

I have been in security long enough to know that "nothing bad will happen here" is not a risk assessment. It is a wish.

The Part That Actually Hurts

I can argue the technical merits of this all day. I have cited frameworks. I have explained the threat model. I have connected the specific choices in the MR to specific risks that specific configurations mitigate.

That is not the problem.

The problem is that this is not an isolated incident. This is every merge request. For a year now, every piece of work I submit comes back with changes or questions. Not always security-related. Sometimes style. Sometimes structure. Sometimes a preference stated as a requirement. I cannot point to a single MR in twelve months that was reviewed and approved without friction.

At some point, the reasonable conclusion is not that I keep writing bad code. The reasonable conclusion is that the process is not a review. It is a correction mechanism. The implicit message, delivered consistently over time, is that my judgment is not trusted.

That message lands.

What It Does to an Engineer

I am not going to pretend that I smile and absorb this and come back fresh every sprint. That is not how human beings work.

What actually happens is subtler and more corrosive. You stop proposing the better solution because you know it will come back marked up. You start writing the MR you think will survive review rather than the one you think is right. You do the minimum required to move the ticket to done. Not because you are lazy. Because you have learned, through consistent feedback, that the effort required to do more is not going to produce a better outcome.

Peter Gibbons did not become checked out because he was a bad engineer. He became checked out because Initech had successfully communicated to him, over and over, that it did not matter whether he was a good one.

That is what chronic over-review does. It does not raise the quality bar. It lowers the effort ceiling. The engineers who care the most are exactly the ones who take this signal hardest, because they are the ones who were investing something real in the first place.

The Security-Specific Damage

There is a particular cost when this happens in a security context that I want to name directly.

Security is not a feature you can add at the end of the sprint. It is not a checklist. It requires engineers who are actively thinking about threat models, who are making deliberate tradeoffs, who are bringing genuine judgment to configuration decisions rather than just copying the last working example.

When you consistently override the secure defaults in favor of the permissive ones, you are not just making a technical choice. You are signaling what you value. You are telling your engineers that the eight-hour token is unnecessary work and the /* path is fine. You are teaching them, through the actual decisions you make in code review, that security is something you talk about in all-hands meetings and deprioritize in pull requests.

That signal travels. Engineers internalize it. And eventually you have a team full of people who know better but have learned not to bother, because the lead is going to change it anyway.

A Word to the Leads

If an engineer on your team has twenty years of experience in the domain you are reviewing, and they have made a deliberate, defensible choice in their MR, the burden of the review is not to find something to change. It is to understand the choice and determine whether it is sound.

Asking a good question is not the same as requiring a change. Suggesting an alternative is not the same as mandating one. There is a version of technical leadership that makes engineers better by engaging seriously with their thinking. There is another version that makes engineers smaller by treating every review as an opportunity to assert authority over the output.

One of those produces teams where people bring their full capability to their work. The other produces Peter Gibbons.

The pipeline timeout is four hours. The token is eight. The paths are scoped to what the job actually needs.

That is not a mistake. That is the point.