In software development we have some things understood as universal best practices, such as encapsulation, locality of reference, using good names. And we have

In software development we have some things understood as universal best practices, such as encapsulation, locality of reference, using good names. And we have a much larger set of specific best practices that change fairly often, or have multiple implementations. Password management is an example. Teladoc could, for example, email a link to log you in rather than using a password reset system, or maybe an outsourced authentication system. Systems tend to have problems at the boundaries. That’s true in software and plumbing. Modern software systems have lots of boundaries, both between internal modules and applications and with external services. Programmers don’t usually have control over the landscape their code runs in. Errors are infrequent so they either get ignored/not accounted for, or they send the user into a maze of confusing behavior. What you perceived as a failure to reset a password could have any number of causes, from a database table primary key overflowing to network latency to a glitch in a string library. There might not be an obvious smoking gun bad chunk of code written by an amateur to blame. I do see programmers who have no interest in their craft and don’t know what they’re doing. I see a lot more who don’t have a lot of experience, putting their mental effort into learning nuts-and-bolts stuff like languages, libraries, frameworks, APIs. Even very experienced programmers can’t possibly keep all of the details straight, or think through all of the possibilities. A lot has been written about writing better code, and making teams work together, and how psychology plays out in software development. You can find books on the subject going back to the 1960s. As Fred Brooks wrote, there’s no silver bullet.