Hate to be one of those guys, but a really simple integration test would have caught this.
I think my larger actual problem with the article is that it brushes over the flaws of a generic, adapted solution. You mention that the differences between a bunch of languages is the standard library, for instance, and you know on some level, you're right. An if statement is an if statement and a lot of these languages are quite similar.
But there's always the want to find 'the jumper that fits' if you get me, and for good reason I think, it can be a waste of time hammering squares into circles so they fit the shape of the solution. These generic adaptable technologies become overcomplicated I find as a result of the push to make them adaptable.
I'm a big fan of specialised technologies if used sparingly. If your stack reads like the tag list to a question on stack overflow, perhaps that's overkill, but in the critical areas for your company, I think you're well served using something that is very close to what you need and needs minimal adaptation.
a really simple integration test
Or even a basic design review.Fields that can't be used computationally should never be stored as if they were attribute-free integers. Not only for this risk, but in the specific case of phone numbers, there is positional importance to specific digits (e.g. country code, area/region code, etc.) requiring that left-justification be maintained and zero-padding avoided.
100% agree. Senior people shouldn't suddenly become junior people just because they change tools. (or rather they shouldn't stay junior for more than, say, a couple weeks)