An untrusted developer is a net loss


An untrusted developer is a net loss.

The impact:
Each line must be carefully reviewed in hopes of catching all the mistakes.

We can’t assume anything works reliably, makes sense, does what it claims, or matches requirements.

We must question every line.

That’s a big problem.
Reviewing untrusted, poor quality code is time-consuming and demoralizing.

We're unlikely to catch all the problems.

It's impractical to "review our way to quality" when starting with code that's low quality, or solving the wrong problem.
Thankfully, most my career, my teams have worked with developers we could trust. But when we couldn't, PR’s required HUGE amounts of time, multiple rounds of comments, and occasionally, a complete rewrite.
And yes, we paired in hopes of resolving as well. But, pairing doesn't magically fix this issue either. It merely places more pressure on one dev in the pair to be conscientious enough to offset the untrusted dev.
Software development requires organization, clarity, naming well, covering edge cases, following requirements, collaborating on designs, documenting intent, and testing comprehensively.

When a dev consistently fails to do these things, it's probably time to find someone new.
Oh, and I should clarify that this isn't about junior devs.

I'm a big believer in hiring juniors and helping them grow. 👍

I'm referring to an ongoing, systemically poor quality work. This problem can occur at any seniority level.

View original on X